#25 MP3val deletes good frames

[Anonymous]

When MP3val "repairs" files with the errors "Garbage at the end of the file" and "It seems that file is truncated or there is garbage at the end of the file" it removes the "garbage" PLUS the last MP3 frame, even when there's nothing wrong with it. This is easy to demonstrate: Start with a "clean" file - one which passes MP3val's scan. Add one or more bytes of random data to its end, if it has no ID3v1 tag or, if it has an ID3v1 tag, between the last frame and the tag. Let MP3val "repair" it and watch the last frame disappear. Is this the way it's meant to work?

[FeRD]

(Ancient issue, but since it's still open here...)

I believe that's proper behavior. It's somewhat unfortunate, but due to the way the MP3 file format is specified that's likely the best way for mp3val to handle the situations you describe.

The key issue is that frames are delimited only by a start header, and not an end marker. So, the way mp3val (or any parser) identifies the end of a given frame is by finding the start of the next frame. If it finds something other than a frame header where it expects to find one, then it has to assume the frame has been corrupted.

So, by adding in garbage characters at a position where there should be a frame header, you're effectively corrupting the last frame. Or, to put it another way, imagine that instead of appending two bytes of garbage, you'd replaced the last 500 bytes of the file with 502 bytes of garbage, so that the last frame really is corrupted. I don't believe there's any easy/reliable way for mp3val to tell the difference, at least in the general case, so in both situations it's forced to assume the worst about that last frame.