Breaking Eggs And Making Omelettes

Topics On Multimedia Technology and Reverse Engineering


Archives:

Lossless Audio Anomalies

January 21st, 2009 by Multimedia Mike

Some years ago, I took a 1-minute sample of a song from a CD and compressed it using every lossless audio coder I knew of at the time — a dozen of them in all. I put the samples here. This effort predated FATE by a number of years. Nowadays, FFmpeg contains native decoding support for 7 of those lossless audio algorithms. And since lossless decoders, by definition, are supposed to have bitexact results, this should be an easy task to add automated tests to FATE.

My pragmatic rule for FATE samples is to try to keep the samples under 2 MB where feasible. Since most of these lossless samples I created weigh in between 6-7 MB, I set about slicing off the first megabyte of each supported sample. And that’s when I noticed that the output was not bitexact across configurations, at least not for all the algorithms. This struck me as odd.

The following lossless algorithms produced identical output across platforms, even with an incomplete final chunk:

Apple Lossless generates 4 results — all Linux/x86_32 agreed, all Linux/x86_64 agreed, all Linux/PPC agreed, and Mac OS X x86_64 and PPC agreed.

True Audio Lossless generates 19 different results — all configurations disagreed except for Mac OS X x86_64 and PPC, which agreed with each other.

Digging deeper using ‘-f framecrc’ demonstrates that all frames agree across configurations until the last, incomplete frame (and, of course, the complete files are bitexact). No big emergency; I just thought it was interesting. I will be able to contrive a new, smaller ALAC sample using iTunes (or FFmpeg using Jai’s encoder), and it looks like True Audio’s encoder is still around as well, and available for Linux to boot.

Posted in FATE Server | 7 Comments »

7 Responses

  1. Kostya Says:

    Meanwhile you can also look at VMD – it should be good enough for tests (I think). LSL7 sample is short enough to be FATEd.

  2. Multimedia Mike Says:

    Thanks. I will add VMD to the queue to re-test.

  3. Robert Swain Says:

    That in itself makes for an interesting regression test. I’m sure Michael would want to know about this.

  4. Vitor Says:

    About ALAC, it is even surprising that you got the same result in more than one platform, see https://roundup.mplayerhq.hu/roundup/ffmpeg/issue758 .

  5. Multimedia Mike Says:

    @Vitor: Thanks for the affirmation that these are actually bugs that need addressing. I’m thinking that the demuxer is sending incomplete frames (I don’t know if this is policy) and/or, as you wrote in your bug report, there is uninitialized data in the buffer. I wonder if it’s reading off the end of a buffer? valgrind should indicate if this is the case.

  6. Vitor Says:

    I don’t really know if the problem is in the demuxer or in the decoder, but valgrind surely complains of reading unitialized mem…

  7. astrange Says:

    If valgrind complains about reading uninitialized data, make sure the allocation properly allocates and clears FF_INPUT_BUFFER_SIZE.