Pardon me for saying, but that doesn't quite make sense. I haven't read the spec, but it would be silly if it said "look for this signature to find the music data". You'd have to have a hecka long signature to keep from accidently grabbing the wrong data.

No, it's not like that. I'll try to explain again. Emplode only needs to look for a valid MP3 frame header (perhaps a few in a row) to verify that it's a valid MP3 file. The frame headers are not very big and they are easily recognizable. Hell, I'm doing it in slow-as-tar Visual Basic in my Gapkiller program and I can still rip through a 100-megabyte file in seconds, while reading and verifying every single frame header. (Part of the trick is using the last frame header data to decide where to begin looking for the next frame header.)

The reason Emplode goes to the trouble of verifying that the file is a valid MP3, is so that you don't try to import and play EXEs and DLLs as songs.

The problem occurs when the file does not START with valid MP3 frame headers. Such a file is, technically, completely out of spec and should in theory be ignored by Emplode. But Emplode gives it the benefit of the doubt and says "Okay, I'll look through the file a little bit, and if I don't see a valid MP3 frame header within the first couple hundred K, then I'll give up and assume it's garbage". It does this as a speed optimization.

So, if a file is out of spec (it doesn't start with a valid MP3 frame header), and also its art data is more than a couple hundred K, then emplode has no choice but to give up on the file and assume you're trying to feed it pictures of your dog instead of proper music files.