Nice work! Thanks for looking into that. Worth discussing with the
On 4/11/2010 10:17 PM, LRN wrote:
> I've studied libmad sources yesterday. And i just want to point out (for
> confirmation), that the "libmad being tolerant to the point of importing
> almost any binary data as junk audio" bug that we're experiencing for
> some years is indeed a fundamental design issue with libmad, and not an
> oversight on our part. Two reasons for that:
> 1) libmad ignores unsubstantial values of various header fields. Namely,
> it doesn't care whether 11-byte magic signature is '11111111111' (as it
> is in the specs) or not, because it affects only header validity, not
> the decoding process. On the other hand, when layer version bits are
> '01' (reserved value), libmad gives up on that header (because it is
> ambigous what should have been the right layer version, and without that
> you can't decode anything).
> 2) Once libmad decides that the header it observes is not, in fact, a
> header, it just shrugs and tries to read next sequence of bytes as
> header. I.e. when it loses the stream flow, it tries to pick it up back.
> That is great for catching up with corrupted network mp3 streams, but
> for us it is a disaster, because header contains only few possible
> restricted values, and thanks to theory of probability any binary data
> eventually forms a pattern that doesn't have these values and passes as
> a valid header, allowing libmad to decode some audio data - giving us junk.
> I don't believe it can be fixed by any other means that implementing our
> own (or using 3rd-party) mime-type checking (or simply a function that
> checks mpeg header validity (with optional id3 tags) from the beginning
> of the file and reports failure immediately instead of trying to dig the
> header up from garbage).