Skip to main content

Topic: Parsing the MP3 Data (Read 16720 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • samokan
  • [*]
Parsing the MP3 Data
Hello Everyone.

I am still a newbie when it comes to MP3 and its detail/internal structure.

This past few days, I have been parsing different MP3 files most of which have ID3vxx format. So basically to get the Mp3 data, I just read the data after the tag in case of ID3v2 and before the tag in case of ID3v1.

So now I am given a Lame encoded? MP3 file. I can get the Header Information but not the actual audio data. 

So basically what I'm trying to do is to get the MP3 header and MP3 data only and ignore any tag/header or info within it.

Thank you for any information.

** I hope I posted this in the correct area 

  • mjb2006
  • [*][*][*][*][*]
Parsing the MP3 Data
Reply #1

  • samokan
  • [*]
Parsing the MP3 Data
Reply #2
Is http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx any help?


Thank you for that sample code.  Besides the VBR/Xing Headers area, my code basically has the same concepts.
I dump the HEX value of the mp3 file and there is no "Xing", "Info".

One file have the LAME3.94 Version somewhere at the bottom of the file and the on the other file it is scattered all over the file.
So basically I need to know the starting point of the audio stream and how big it is so that I can read it from the file and copy it to the memory and give it to the decoder .. 


  • alexeysp
  • [*][*][*]
Parsing the MP3 Data
Reply #3
So basically I need to know the starting point of the audio stream and how big it is so that I can read it from the file and copy it to the memory and give it to the decoder ..


To find the start of the actual audio stream you have to skip the ID3v2 tag if it is present, using the tag size field from the tag itself, and then start scanning the stream for a valid mp3 frame header, which always starts from the 11 bits all set to one. Then parse the header to verify that this is actually a valid frame and find out its size.

If the first frame of the stream does not contain VBR ("Xing" or "Info") header, then there is no way to find out the length of the entire stream except to parse it frame-by-frame until there are no more data to process.


  • pdq
  • [*][*][*][*][*]
Parsing the MP3 Data
Reply #4
One file have the LAME3.94 Version somewhere at the bottom of the file and the on the other file it is scattered all over the file.

I believe that LAME fills any bits not used for data with its version string, thus you will see that throughout the file.

Parsing the MP3 Data
Reply #5
Right, LAME uses its version string as frame padding.

  • samokan
  • [*]
Parsing the MP3 Data
Reply #6
So basically I need to know the starting point of the audio stream and how big it is so that I can read it from the file and copy it to the memory and give it to the decoder ..


To find the start of the actual audio stream you have to skip the ID3v2 tag if it is present, using the tag size field from the tag itself, and then start scanning the stream for a valid mp3 frame header, which always starts from the 11 bits all set to one. Then parse the header to verify that this is actually a valid frame and find out its size.

If the first frame of the stream does not contain VBR ("Xing" or "Info") header, then there is no way to find out the length of the entire stream except to parse it frame-by-frame until there are no more data to process.


That is what I did for files with ID3v2 tags and ID3v1 tags. 

Unfortunately, my test file right now does not contain "Xing" or "Info" header that is why I am having a hard time knowing where the actual audio stream are located in the file. Our decoder is very hardware specific and the api is very limited and not very friendly to use 

Thank you for the  information though.

  • samokan
  • [*]
Parsing the MP3 Data
Reply #7
One file have the LAME3.94 Version somewhere at the bottom of the file and the on the other file it is scattered all over the file.

I believe that LAME fills any bits not used for data with its version string, thus you will see that throughout the file.


So I can just  basically ignore this data ?


  • pdq
  • [*][*][*][*][*]
Parsing the MP3 Data
Reply #8
Correct. You could replace it with almost anything else and the file would play exactly the same.
  • Last Edit: 05 January, 2012, 06:30:51 AM by db1989

  • samokan
  • [*]
Parsing the MP3 Data
Reply #9
Thank you. I was able to find some source code for reference:

mp3val : http://mp3val.sourceforge.net/
mp3diags: http://mp3diags.sourceforge.net/index.html

No Xing or Info Tag Header within the file so I guess I have to manipulate per frame and check if the decoder will be able to play it.

Will update as soon as I get it working
  • Last Edit: 05 January, 2012, 06:31:08 AM by db1989

Parsing the MP3 Data
Reply #10
What I don't fully understand is what you are trying to achieve. The LAME version string at the end of the file is part of a valid MP3 frame, so is the Xing / Info data at the beginning of the file.

  • samokan
  • [*]
Parsing the MP3 Data
Reply #11
What I don't fully understand is what you are trying to achieve. The LAME version string at the end of the file is part of a valid MP3 frame, so is the Xing / Info data at the beginning of the file.


I need only the actual audio stream. The decoder is very hardware specific and very limited API.
So I am stripping all the additional information and get the actual stream give to the decoder and check if it can play it or not.


  • benski
  • [*][*][*][*][*]
  • Developer
Parsing the MP3 Data
Reply #12
once you skip the ID3v2 tag, you can basically send the data to the decoder.  If the decoder requires complete frames, you'll need to parse the 4 byte MPEG frame header to determine the complete size of the frame (trivially computed from the bitrate index, samplerate index, layer and version.  unfortunately the byte size isn't encoded directly like it is with ADTS AAC, for example).  As Sebastian stated, things like "Xing Headers" and "LAME padding area" are actually parts of valid MP3 data and your decoder will be able to deal with it.  In this case, LAME is putting useful, but not necessary for decoding, data into the "ancillary data" portion of the fist MP3 frame. Not all encoders produce this silent first frame with data embedded in the ancillary data.
  • Last Edit: 05 January, 2012, 11:09:26 AM by benski

  • samokan
  • [*]
Parsing the MP3 Data
Reply #13
thanks for pointing that out. I check all my working test mp3 and some of them were actually lame encoded but with an ID3 tag .

I can see the light.  I will update once I tested them all
  • Last Edit: 06 January, 2012, 11:14:35 AM by db1989

  • samokan
  • [*]
Parsing the MP3 Data
Reply #14
thank you for all the response. it is finally working.

appreciate all the help guys