Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Problems decoding MPEG frame header (Read 3706 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Problems decoding MPEG frame header

Hello!

The attached MP3 file is causing trouble. EncSpot will show me that the file uses padding and Winamp (because foobar2000 won't display that information) reports that no CRCs are used.
However, my Pre-Alpha version of VBSpot (which works fine with all other MP3s I tested) reports no padding, but CRC usage.

Which tools are now right and why?

PS: I should add that the first frame header is 0xFF 0xFB 0x90 0x4C while all others are 0xFF 0xFB 0x92 0x4C

Problems decoding MPEG frame header

Reply #1 –
FF FB 90 4C = no padding, no CRC (frame length = 417 bytes)
FF FB 92 4C = yes padding, no CRC (frame length = 418 bytes)

This is normal. Quoting from http://www.mp3-tech.org/programmer/frame_header.html:
Quote
Padding bit
0 - frame is not padded
1 - frame is padded with one extra slot

Padding is used to exactly fit the bitrate.As an example: 128kbps 44.1kHz layer II uses a lot of 418 bytes and some of 417 bytes long frames to get the exact 128k bitrate. For Layer I slot is 32 bits long, for Layer II and Layer III slot is 8 bits long.
So there's no CRC on any frame (CRC should be either always present or always absent), and there is padding on some (but not all) frames. Encspot is not wrong saying that padding is used because it's used on at least one frame.

Problems decoding MPEG frame header

Reply #2 –
Thank you for the help.

VBSpot is returning Padding = False (0) because this Pre-Alpha relies on the first frame header found.
The problem with the CRC is the following: the value for the CRC is 1 and I assumed 1 means True and 0 False, but in this case, it is the other way round.

Problems decoding MPEG frame header

Reply #3 –
Quote
The problem with the CRC is the following: the value for the CRC is 1 and I assumed 1 means True and 0 False, but in this case, it is the other way round.

Yes, that's a little confusing but you have it right now.