{"id":926,"date":"2009-01-21T22:52:02","date_gmt":"2009-01-22T06:52:02","guid":{"rendered":"http:\/\/multimedia.cx\/eggs\/?p=926"},"modified":"2009-01-21T22:56:26","modified_gmt":"2009-01-22T06:56:26","slug":"lossless-audio-anomalies","status":"publish","type":"post","link":"https:\/\/multimedia.cx\/eggs\/lossless-audio-anomalies\/","title":{"rendered":"Lossless Audio Anomalies"},"content":{"rendered":"

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<\/a>. This effort predated FATE<\/a> by a number of years. Nowadays, FFmpeg<\/a> 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.<\/p>\n

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. <\/p>\n

The following lossless algorithms produced identical output across platforms, even with an incomplete final chunk:<\/p>\n