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: how mp3 decoders handle broken frames and garbage data? (Read 4117 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

how mp3 decoders handle broken frames and garbage data?

When there is a broken (incomplete) mp3 frame in an mp3 file, how do decoders handle them? Are they just ignored, partially played, some recovery is made, or something else? If such broken frame occurs in the middle of a file rather than at the end, how does it affect decoding the next adjacent frame? Suppose we have two mp3 frames f1 and f2 next to each other in that order, and f1 is incomplete. When decoding f1, is it
- possible to recognize f1 is broken (do something for that) and successfully decode f2,
- or the beginning of f2 is somehow mis-considered as part of f1, so f2 fails to decode?

How about garbage data after a valid frame? Are they completely ignored until another valid frame is detected?

 

how mp3 decoders handle broken frames and garbage data?

Reply #1
I don't know about MP3 specifically, but in general:

The front of each frame in most formats has a header that you can sanity check.  If it fails you try to skip to the next frame.

If the next frame passes the sanity check you decode it and everything is fine except for a couple dozen milliseconds of missing data.  If it doesn't, then you can keep going looking for a valid frame, or give up and ask your file parser for the next packet and hope its ok.

In rockbox for example, the WMA decoder retries decoding frames 5 times in a row.  After that it gives up and asks the ASF parser for the next packet.  If that packet doesn't pass a sanity check, it will request the next packet up to 5 times.  After that it gives up and goes to the next file in the playlist.  I added this logic after someone sent me a file that had some corruption.  It fixed decoding of it with only a barely noticeable glitch.