I feel a little more confident about the lossless audio decoders in FFmpeg — some of them, at least — so I activated the FATE tests that I had staged for them:
Further, I have added some tests related to Sierra game formats:
See Also:
I was catching up on about 3 months worth of QuickTime movie trailers when I viewed the trailer for a movie called Miss March. The part that stood out for me is that the main characters meet a rapper whom they address as “Dot MPEG”. The IMDb page for the movie actually lists the rapper’s name as — ahem — Horsedick.MPEG.
No big meaning to this post; I just thought it would be interesting to the multimedia nerd readership of this blog.
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.
I modified my distributed RPC test staging utility to implement my imprecise audio testing idea. This is the output under typical conditions:
There was 1 unique stdout blob collected all successful configurations agreed on this stdout blob: pass
So, it worked. Yeah, I’m surprised too. That result means that all the configurations (20 total) produce an audio waveform in which no individual PCM sample deviates from the reference wave by more than 1. Since I had to choose some configuration to generate the reference sample, I used Linux / x86_32 / gcc 2.95.3.
BTW, this is the general Python algorithm I am using to compare the waves. It takes a full minute, give or take a second, to compare 2 33MB samples:
I replaced abs() with a branch to check if the diff is < -1 or > 1, but that didn’t improve speed measurably. I think the constant unpacking might have something to do with it. Better solutions welcome. (By comparison, performing a comparison using ‘cmp’ of 2 identical files that have the same size as the test above, living on a network share, takes less than 2 seconds.)
For a 10-second sample of a .m4a stereo AAC file (882,000 samples), these are the number of PCM samples that deviated by 1 (first number), and by more than 1 (second number). You will notice that no samples deviated by more than 1, which was my hypothesis at the start, and the basis on which I devised this plan:
Mac OS X / PPC / gcc 4.0.1 432691, 0 Linux / x86_32 / icc 238, 0 Linux / x86_32 / gcc 2.95.3 0, 0 Linux / PPC / gcc 4.0.4 Linux / PPC / gcc 4.1.2 Linux / PPC / gcc 4.2.4 Linux / PPC / gcc 4.3.2 Linux / PPC / gcc svn 432701, 0 Linux / x86_64 / gcc 4.0.4 Linux / x86_64 / gcc 4.1.2 Linux / x86_64 / gcc 4.2.4 Linux / x86_64 / gcc 4.3.2 Linux / x86_64 / gcc svn 248, 0 Linux / x86_32 / gcc 3.4.6 Linux / x86_32 / gcc 4.0.4 Linux / x86_32 / gcc 4.1.2 Linux / x86_32 / gcc 4.2.4 Linux / x86_32 / gcc 4.3.2 Linux / x86_32 / gcc svn 237, 0 Mac OS X / x86_64 / gcc 4.0.1 244, 0
I have thrown RealAudio Cooker and 28.8 samples at this, and both work. I am still testing this against some more audio samples to ensure that this idea holds water.