Here’s an example audio file you can use to check an application: ( audio file link). This causes the decoded audio to be truncated by up to 1152 samples. Without this, it loses synchronisation on the last mp3 frame, which is consequently never decoded. More importantly, they aren’t providing the decoder an expected but undocumented small block of zero data at the end of the file.(This is in addition to the variable mp3 encoder delay, and note that the metadata frame is not the same thing as an id3 tag - those are not actually mp3 frames and so don’t have the same problem.) If an mp3 file starts with a Xing/LAME information frame, they are feeding that frame to the mp3 decoder rather than filtering it out, resulting in an unnecessary 1152 samples of silence at the start of the decoded audio.Here’s what almost every user of this library seems to be doing wrong:

I checked the code of a few other open source applications that use it, and found that all of them (including widely-used programs like Audacity) suffered at least one of the same problems as mine did. I discovered this week that I’ve been using this library wrong for many years in a couple of small ways. It’s now getting old (last updated in 2004) but people trust it. It’s a respected library that consists of high quality C code, has a fairly friendly API, and was evidently written with great care. The MAD mp3 decoder library is widely used in open source applications that play or edit mp3 audio files.

Doing it wrong mp3