Is the leading structure in MP3 file a real frame?

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.

Answer 2

The very first frame can be used as what is often called the "LAME Tag" (The generator's name does not have to be LAME, though).

There has been (and may still be) a way to create this tag in ffmpeg when the encoder doesn't yet know what the future data is going to be and so ffmpeg would simply use some defaults such as 128kbps instead of the speed defined in your MP3 data.

So whether you have CBR or VBR data can't be based on that frame.

To see whether you have such a Tag, print out the first 64 bytes at least (or use an Hex editor) and you should see the letters "Info" (CBR) or "Xing" (VBR) pretty close to the start (often around byte 0x24). The eyeD3 and ffprobe are capable of decoding this tag.

I have a page about the format here.