Why Final Scratch doesn't like your mp3...

What final scratch likes

I'll start off by describing what Final Scratch is happy with, and then go on to what can go wrong.

1. Optional Header within first 8k of the file

This header can be either

2. Valid, error-free mp3 frame

The header must be immediately followed by a valid, error-free mp3 frame. (more on this later).

3. MP3 frames

It appears that after this the player is fairly robust. Gaps and bad frames are skipped. There's nothing in the player that would make it specifically have problems with VBR mp3's. (there's another small caveat, more later)

Observed Situations where FS has been unhappy

Gaps after ID3v2 headers

I found this with ALL of my CDex 1.4 encoded mp3 headers. There was a valid tag and valid mp3 data, but in-between there was 731 zero bytes. Oddly enough this was the size of an mp3 frame at the bit rate of the encoded file (224 kbps). The Windows Box Editor available on this site can fix these issues. There's also a standalone executable.

Bad first frames

There's a fair number of mp3 encoders out there, and the usual testing regimen seems to be, does it work with winamp and media player. The decoder used in fs (MAD), like all mp3 decoders, is fairly tolerant of error, but it does return an error when the frame is processed. A macro (MAD_ERROR_RECOVERABLE) is provided so the coder can work out if he should continue playing.

This error detection and recovery is implemented in the main body of fs, but the first frame has to be error free.

As an experiment, I added a valid frame of silence onto the beginning of an mp3 I suspected was having this problem and it made fs happy.

There was an odd audio effect, but I suspect this was to do with mp3 frame types. There's short, long, short->long and long->short frames in mp3. I'm just beginning to learn about this stuff.

I received a helpful note from ZeBee/sMiLe

Hi pete!

I have amazing news for you. I know now why some of my files aren't playing. It's not about long/short, its because of bit reservoir. All mp3s I tested seem to be cut with an mp3 cutting tool. The result of that is that the first frame cannot be decoded because of missing data from the predecessor that was cut away. That also explains any glitches u may hear.

I checked the theory using lame --decode on the non playing files. He said for every file: Can't step back xxx!

This perked my curiosity, so I googled around for more info and found a powerpoint presentation (http://www.ee.cuhk.edu.hk/~wkcham/ele5431/MP3.ppt) that contained this picture.

This would explain why mp3 trimmers could cause problems with some mp3's.

Sebastian had some code that suggested zeroing out the side info would let the parser slip past this first dodgy frame.

Speculation about other possible reasons

Dodgy VBR tags

As well as ID3 + ID3v2 tags, there's a lesser known tag called the Xing VBR tag. When Xing started producing VBR mp3's they introduced the issue that seeking is non-linear over the file, so they added data to the mp3 to help with this. It seems to sit just after the first mp3 frame, not sure how it works really. But I'm guessing there may be issues when the decoder looks for the second frame.

More as I discover it...