I'll start off by describing what Final Scratch is happy with, and then go on to what can go wrong.
This header can be either
The header must be immediately followed by a valid, error-free mp3 frame. (more on this later).
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)
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.
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.
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.