Question

I’m now doing some work with decoding MP3 files, but just have some basic knowledge about the MP3 file. I implement a simple decoder for MP3 these days. When comparing the decoded result with that of Maaate decoder, I encounter this problem.

My decoder extract one more frame than the Maaate decoder. After scrutinizing the result of a sample MP3 file, I find the first frame is abnormal. For my sample file, the first frame is 413 bytes long with frame header 0xfffb9064 different from all the other frames with 100 byte-length and header 0xfffb1064.

My question is:
Is the first “frame” in the result a real frame? Is so, why it seems different from others? If not, what is this structure used for and how to distinguish it from others for both of them share the frame sync code 0xfff?

Answer 1

MP3 streams don’t have a file header. It sounds a bit odd that you have just one frame at the beginning which is longer than the rest, but this is perfectly legal.

There’s a quick description of the bits in the header at: http://www.datavoyage.com/mpgscript/mpeghdr.htm

In your case, both types of header share in common:

• MPEG-1
• Layer 3
• Not protected
• 44.1kHz
• No padding
• Not private
• M/S joint stereo
• No copyright
• Original media
• No emphasis

The first frame differs from the rest with:

• 128kbit (resulting in the 417 byte frames minus 4 byte header)

The rest are:

• 32kbit (resulting in 104 byte frames minus 4 byte headers)

There’s a formula in that page for calculating frame size based on header: 144*bitrate/samplerate+padding.

I suspect the 128kbit first frame is an artifact (bug) of the encoder used to generate the sample. It’s still a constant bitrate file at 32kbit after the first frame. Given that an MP3 decoder can’t produce output until it has a few frames, and it won’t suddenly hit a bump in bitrate half way through, this is unlikely to upset anything.