If you load this in an application that uses MAD and find the first burst starts around 0.05 sec, then you have the first of the above problems. This file contains two very short bursts of noise, one right at the start of the file and the other at the end, separated by a second and a half or so of silence.Īfter decoding with MAD, the first burst should start around 0.025 seconds in, and the second should finish just before the end of the decoded audio. 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:
Doing it wrong mp3 code#
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.
0 kommentar(er)
