Okay, I got nerd sniped [0]. Here's the script I've made:

    https://gist.github.com/paskozdilar/6095fe73c80ad21fda3f518177699149

This isn't an exact method, so it will only print bitrates and their respective "difference" parameter. In general, as the difference parameter rises, you're more likely to have reached the "true" mp3 quality, and a sudden jump in difference parameter is an almost certain indicator of true quality.

E.g. for a System Of A Down song "36", encoded at 320kbps, I get the following output:

    user@hostname:~/temp$ ./main.sh 36.mp3
    320: 0.075272
    256: 0.121475
    224: 0.160858
    192: 0.193726
    160: 0.237717
    128: 0.308029
    112: 0.363953
     96: 0.409012
     80: 0.454941
     64: 0.578598
     56: 1.105850
     48: 1.081100
     40: 0.629898
     32: 1.223129

Here, we have a jump immediately after 320kbps, which shows that this file is true 320kbps.

When I compressed the song to 64kbps and then re-compressed it to 320kbps, I get this result:

    user@hostname:~/temp$ ./main.sh 36-reencoded.mp3 
    320: 0.146484
    256: 0.146484
    224: 0.146484
    192: 0.146484
    160: 0.146484
    128: 0.146957
    112: 0.178665
     96: 0.210373
     80: 0.175171
     64: 0.211609
     56: 1.054886
     48: 0.944687
     40: 0.505280
     32: 0.852020

As we can see, the most significant jump happens from 64kbps to 56kbps, which confirms that this file's true bitrate is indeed 64kbps.

Though, as sibling comment says, it's not confirmed that this kind of process works across encoders. I think that it should, because MP3 as a lossy codec mostly removes higher frequencies, and re-encoding compressed signal with same bitrate should remove less higher frequencies, because there are less to begin with. But I have no way to confirm - I'd need an array of encoders to actually verify this.

[0] https://xkcd.com/356/