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.
Meanwhile you can also look at VMD – it should be good enough for tests (I think). LSL7 sample is short enough to be FATEd.
Thanks. I will add VMD to the queue to re-test.
That in itself makes for an interesting regression test. I’m sure Michael would want to know about this.
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 .
@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.
I don’t really know if the problem is in the demuxer or in the decoder, but valgrind surely complains of reading unitialized mem…
If valgrind complains about reading uninitialized data, make sure the allocation properly allocates and clears FF_INPUT_BUFFER_SIZE.