Tag Archives: fate

Alpha FATE

Do you remember the DEC Alpha CPU? Måns Rullgård does. He still has his unit in service and running Linux. So why not run FATE? Just like FFmpeg supports impossibly obscure multimedia formats, why shouldn’t it also support CPU types of approximately the same prevalence? In both cases, as long as the support overhead is not too arduous, it’s not a problem.

What I’m saying here, in case I was unclear, is that Måns has an Alpha CPU contributing build/test results to the central FATE database.

In other FATE news, today was a very busy day. I carefully evaluated and entered 18 new test specs:

With this, I have eliminated much of the low-hanging fruit on the FATE Test Coverage wiki page. My excuses to avoid testing the more complicated (read: bit inexact) formats are dwindling.

Meanwhile, the front page of FATE is reaching critical mass. I really need to come up with a new presentation because the front page is getting harder and harder to digest.

Lossless Audio Tests

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:

Lossless Audio Anomalies

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.