IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Parsing the MP3 Data, Isolating the MP3 Data Only
samokan
post Dec 16 2011, 06:57
Post #1





Group: Members
Posts: 8
Joined: 16-December 11
Member No.: 95828



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. crying.gif

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 smile.gif
Go to the top of the page
+Quote Post
mjb2006
post Dec 16 2011, 08:19
Post #2





Group: Members
Posts: 784
Joined: 12-May 06
From: Colorado, USA
Member No.: 30694



Is http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx any help?
Go to the top of the page
+Quote Post
samokan
post Dec 16 2011, 09:12
Post #3





Group: Members
Posts: 8
Joined: 16-December 11
Member No.: 95828



QUOTE (mjb2006 @ Dec 16 2011, 16:19) *


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 .. crying.gif

Go to the top of the page
+Quote Post
alexeysp
post Dec 16 2011, 13:20
Post #4





Group: Members
Posts: 130
Joined: 3-April 09
Member No.: 68627



QUOTE (samokan @ Dec 16 2011, 11:12) *
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 .. crying.gif


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.

Go to the top of the page
+Quote Post
pdq
post Dec 16 2011, 15:12
Post #5





Group: Members
Posts: 3391
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



QUOTE (samokan @ Dec 16 2011, 04:12) *
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.
Go to the top of the page
+Quote Post
Sebastian Mares
post Dec 16 2011, 15:31
Post #6





Group: Members
Posts: 3629
Joined: 14-May 03
From: Bad Herrenalb
Member No.: 6613



Right, LAME uses its version string as frame padding.


--------------------
http://listening-tests.hydrogenaudio.org/sebastian/
Go to the top of the page
+Quote Post
samokan
post Dec 19 2011, 03:00
Post #7





Group: Members
Posts: 8
Joined: 16-December 11
Member No.: 95828



QUOTE (alexeysp @ Dec 16 2011, 21:20) *
QUOTE (samokan @ Dec 16 2011, 11:12) *
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 .. crying.gif


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 crying.gif

Thank you for the information though.
Go to the top of the page
+Quote Post
samokan
post Dec 19 2011, 03:04
Post #8





Group: Members
Posts: 8
Joined: 16-December 11
Member No.: 95828



QUOTE (pdq @ Dec 16 2011, 23:12) *
QUOTE (samokan @ Dec 16 2011, 04:12) *
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 ?

Go to the top of the page
+Quote Post
pdq
post Dec 19 2011, 05:33
Post #9





Group: Members
Posts: 3391
Joined: 1-September 05
From: SE Pennsylvania
Member No.: 24233



Correct. You could replace it with almost anything else and the file would play exactly the same.

This post has been edited by db1989: Jan 5 2012, 12:30
Reason for edit: removing unnecessary full quote of above post
Go to the top of the page
+Quote Post
samokan
post Dec 19 2011, 09:54
Post #10





Group: Members
Posts: 8
Joined: 16-December 11
Member No.: 95828



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 smile.gif

This post has been edited by db1989: Jan 5 2012, 12:31
Reason for edit: ditto
Go to the top of the page
+Quote Post
Sebastian Mares
post Dec 19 2011, 12:12
Post #11





Group: Members
Posts: 3629
Joined: 14-May 03
From: Bad Herrenalb
Member No.: 6613



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.


--------------------
http://listening-tests.hydrogenaudio.org/sebastian/
Go to the top of the page
+Quote Post
samokan
post Jan 5 2012, 04:37
Post #12





Group: Members
Posts: 8
Joined: 16-December 11
Member No.: 95828



QUOTE (Sebastian Mares @ Dec 19 2011, 20:12) *
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.

Go to the top of the page
+Quote Post
benski
post Jan 5 2012, 17:06
Post #13


Winamp Developer


Group: Developer
Posts: 670
Joined: 17-July 05
From: Brooklyn, NY
Member No.: 23375



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.

This post has been edited by benski: Jan 5 2012, 17:09
Go to the top of the page
+Quote Post
samokan
post Jan 6 2012, 09:18
Post #14





Group: Members
Posts: 8
Joined: 16-December 11
Member No.: 95828



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 smile.gif

This post has been edited by db1989: Jan 6 2012, 17:14
Reason for edit: see previous edits
Go to the top of the page
+Quote Post
samokan
post Jan 10 2012, 08:11
Post #15





Group: Members
Posts: 8
Joined: 16-December 11
Member No.: 95828



thank you for all the response. it is finally working.

appreciate all the help guys smile.gif
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 23rd August 2014 - 15:53