Skip to main content

Topic: Incorrect Bitrate displayed for VBR files (Read 1542 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • saratoga
  • [*][*][*][*][*]
Re: Incorrect Bitrate displayed for VBR files
Reply #25
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.

  • robert
  • [*][*][*][*][*]
  • Developer
Re: Incorrect Bitrate displayed for VBR files
Reply #26
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.
Ok, managed to see it now. It sure looks like the info displayd as format is just about the first found mpeg frame, the Xing/Lame info frame.
My guess, the App uses the MediaMetadataRetriever java class to read the infos. There is some METADATA_KEY_BITRATE they could query, maybe they do and it reports the wrong info.

From the infos of the Xing/Lame info frame it is possible to calculate the average bitrate.

  • saratoga
  • [*][*][*][*][*]
Re: Incorrect Bitrate displayed for VBR files
Reply #27
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.

  • andiandi
  • [*]
Re: Incorrect Bitrate displayed for VBR files
Reply #28
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.


Thanks you summed it up well, so its what I thought the player have to look inside the data header and not only outside the frame (to the bitrate that only matches that same frame).


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.

As Robert says below, I think its mainly an android issue that apps have to overcome by using external libraries than android (e.g Jaudiotagger) to read that header.

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.
OK, it sounds like so they didn't want to solve that "problem" and apps still have to go through those external libraries.

I can conclude that there isn't any issues with my MP3s but just with the OS and the app.
  • Last Edit: 08 July, 2017, 03:34:29 AM by andiandi

  • saratoga
  • [*][*][*][*][*]
Re: Incorrect Bitrate displayed for VBR files
Reply #29
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. 

  • andiandi
  • [*]
Re: Incorrect Bitrate displayed for VBR files
Reply #30
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. 

Its a very specific issue, the thing is that a majority of people use famous music players as Poweramp, Phonograph, Black etc.. So they are not concerned about it, but yeah some other people might be interested. It'd be a great initiative.

Try to go to XDA developers if you don't for there is many custom Roms creator that could help.