Hello -
I hope this question doesn't fall outside this list's domain, but I figure there's probably a ton of mp3 know-how in this group... :)
Anyway, I was looking at the mp3 headers from a file, and my calculation of the frame length appears to be wrong, but I can't figure out why. The first frame of the file looks like this:
ff f3 68 64
which tells me that this is a 48kbps MPEG2 Layer-3 file at 16000Hz in joint-stereo, which is true based on what madplay says. I'd like to calculate the frame size based on this info, and using this equation for Layer-III files from http://www.dv.co.yu/mpgscript/mpeghdr.htm -
FrameLengthInBytes = 144 * BitRate / SampleRate + Padding
I calculate that the frame size is 432 bytes. When I scan through the file given this information, I find a total of 1924 frames. When madplay scans through the file, though, it finds twice as many, 3848 frames. So it seems that my frame length is 2x too big. Why does this equation hold for my 128kbps version of the same file, but not for this version (or am I missing something obvious)?
On that note, does anyone have any suggestions for an mp3 frame-related resource? The one I mentioned above seems decent, but if there are any better ones, I'd love to know...
Thanks for any help, Haig
On Sunday, March 31, 2002, at 10:23 PM, Haig C Didizian wrote:
Anyway, I was looking at the mp3 headers from a file, and my calculation of the frame length appears to be wrong, but I can't figure out why. The first frame of the file looks like this:
ff f3 68 64
which tells me that this is a 48kbps MPEG2 Layer-3 file at 16000Hz in joint-stereo, which is true based on what madplay says. I'd like to calculate the frame size based on this info, and using this equation for Layer-III files from http://www.dv.co.yu/mpgscript/mpeghdr.htm -
FrameLengthInBytes = 144 * BitRate / SampleRate + Padding
I calculate that the frame size is 432 bytes. When I scan through the file given this information, I find a total of 1924 frames. When madplay scans through the file, though, it finds twice as many, 3848 frames. So it seems that my frame length is 2x too big. Why does this equation hold for my 128kbps version of the same file, but not for this version (or am I missing something obvious)?
The formula you cite is only correct for MPEG-1 Layer II or Layer III. For MPEG-2 Layer III, the constant 144 should be changed to 72 -- so your frame size is really 216 bytes. This is because MPEG-2 (and MPEG 2.5) Layer III has only one granule per frame, instead of two as in MPEG-1.
On that note, does anyone have any suggestions for an mp3 frame-related resource? The one I mentioned above seems decent, but if there are any better ones, I'd love to know...
I think mp3-tech.org may have some useful resources.
-- Rob Leslie rob@mars.org
Hallo Robert,
Happy Easter!
once again, I try to get help with my problem. I have written some mid level routines around mad to open, close, read and seek within mp3 somehow seek does not work. My goal is seeking to any sample position within the decoded stream And to be fast I just decode each frame header. The Problem is now, that something is wrong. I seek to a wrong position Can you please have a look into my code and saying what is wrong ?
Thanx in advance
rds Guenther
On Monday, April 1, 2002, at 01:14 AM, Guenther Sohler wrote:
once again, I try to get help with my problem. I have written some mid level routines around mad to open, close, read and seek within mp3 somehow seek does not work. My goal is seeking to any sample position within the decoded stream And to be fast I just decode each frame header. The Problem is now, that something is wrong. I seek to a wrong position Can you please have a look into my code and saying what is wrong ?
Guenther,
I'm sorry I haven't responded to your question. I don't really understand what problem you are having, and your code is difficult to digest.
My first suggestion would be not to read the .seconds and .fraction fields directly from the mad_timer_t structure, but to use the API routines such as mad_timer_count() and mad_timer_compare() instead.
In general I think you have the right idea; by decoding only the frame headers you can advance through the stream knowing exactly how much playing time is represented by each frame. You correctly use mad_timer_add( ) to sum these times and maintain a timer with the current time position. I would suggest using mad_timer_compare() to compare the current time position with a desired time position.
I notice that you call mad_stream_buffer() before every call to mad_header_decode(); this is neither necessary nor recommended. You should only call mad_stream_buffer() after (re)loading your buffer with new data, for example in response to MAD_ERROR_BUFLEN. Perhaps this is a source of the problem you are having.
-- Rob Leslie rob@mars.org
Thanx Robert,
I think its quite severe that I call the stream function far too often this might be the reason why seeking is so far/wide. I put the streaming function into the wrong brace hierarchy
rds guenther
On 11-Apr-2002 Rob Leslie wrote:
On Monday, April 1, 2002, at 01:14 AM, Guenther Sohler wrote:
once again, I try to get help with my problem. I have written some mid level routines around mad to open, close, read and seek within mp3 somehow seek does not work. My goal is seeking to any sample position within the decoded stream And to be fast I just decode each frame header. The Problem is now, that something is wrong. I seek to a wrong position Can you please have a look into my code and saying what is wrong ?
Guenther,
I'm sorry I haven't responded to your question. I don't really understand what problem you are having, and your code is difficult to digest.
My first suggestion would be not to read the .seconds and .fraction fields directly from the mad_timer_t structure, but to use the API routines such as mad_timer_count() and mad_timer_compare() instead.
In general I think you have the right idea; by decoding only the frame headers you can advance through the stream knowing exactly how much playing time is represented by each frame. You correctly use mad_timer_add( ) to sum these times and maintain a timer with the current time position. I would suggest using mad_timer_compare() to compare the current time position with a desired time position.
I notice that you call mad_stream_buffer() before every call to mad_header_decode(); this is neither necessary nor recommended. You should only call mad_stream_buffer() after (re)loading your buffer with new data, for example in response to MAD_ERROR_BUFLEN. Perhaps this is a source of the problem you are having.
-- Rob Leslie rob@mars.org
Guenther Sohler
NewLogic Technologies AG Millennium Park 6 A-6890 Lustenau Phone: +43-5577-62000-507 E-Mail: guenther.sohler@newlogic.com Fax: +43-5577-62000-988
-
Guenther Sohler -
Haig C Didizian -
Rob Leslie