Quote

Just tried that Vanilla APP on my Samsung Galaxy Tab (Android 6), it doesn't show me any bitrate at all. At least song duration is correct and seeking works too.

Its because you have to long press the artist/album name in playback view (I mean when you are inside your song with the seek bar, at the top) , then the details of the song appear.
Please tell me what you have.

Let me explain a bit about frames and bits and all that:

The MP3 format defines a structure of packets that are stored one after another.
Each one of these packecks, can have one of 16 predefined sizes, ( the fixed bitrates like 128, 160 192, etc that the format can have at the packet level, which also depend on which layer the format is in, but that's for another subject).
The duration of each of these packets is also fixed (it doesn't matter which bitrate it has, there is a fixed amount of milliseconds in each packet, depending on the samplerate used).

Now, going back in time, when MP3 codec developers started to push the format capabilities, one of them, Xing technologies, invented a "tag" that their encoder wrote into the first packet of the MP3 file, the XING VBR tag/header. This tag had additional information about the total track duration and also a seek table, so that seeking would not need reading all the packets to know where to seek to (remember , VBR = different packet sizes).

Later on, LAME incorporated this tag, and extended it for other purposes, like sample accurate length and codec information.

On another front, the inventors of MP3, frauhoffer, added an alternative tag to their encoder, the VBRi, which is also written to the first packet of the MP3, and has a similar amount of information (the format is shown in the link that you were given earlier in this thread).

So, if the developer of Vanilla is telling you that the MP3 frame header says 128, then, he is correct, but he is missing completely the point: IF the first frame of the MP3 contains a VBRi or XING tag inside, that tag has to be read in order to give the correct information.

Rereading it on my computer where I can see the screen shot you posted, that developer is definitely wrong.  He is confusing the frame size of the VBR header (in this case the header physically spans one 128kbps sized frame) with the bitrate computed from the header (243 kbps).  Assuming the file is 243 kbps, the header is correct. 

Since that app is using your phone's firmware to read the header, it sounds like its either a bug in your phone's firmware or the wrong API is being used to check bitrate.

https://android.googlesource.com/platform/frameworks/av/+/master/media/libstagefright/MP3Extractor.cpp#301

In 6.0 they changed the parser to ignore the Xing header size, but I think this is actually still wrong. If I understand correctly, they use the correct bitrate from the header for seeking calculations, but actually store the first audio frame bitrate as the listed bit rate even though the correct one is parsed just before.

I'm tempted to submit a patch to libstagefright fixing this issue, but I'm not even sure how to compile a new ROM or how to test it.  I wonder if they'd even be interested in something like this.