FLAC, a popular lossless audio compression format, is well known to be very CPU-firendly while decoding. Having seen many statements that "FLAC decoding speed is the same no matter how it was encoded" I set out to test whether this is correct.
All tests were done on an Intel Pentium 4 1500 MHz, with 512 MiB RAM. I used Foobar 2000 0.8.3 with the speed meter, and thread priority set to max. Each of the 14 samples used were encoded with 10 different settings, and each setting was decoded 12 times. Thus, a total of 1,680 decodings were performed. The hard disk which contained the files was a Western Digital Raptor 36 MB SATA drive. It was defragmented before each test to minimize seek-related performance penalties.
Each sample was an entire CD, which ranged from 43:47 to 72:49. The total length of all samples was 14 hours, 28 minutes, and 13.8 seconds. Since the input format was CD, all samples are 16-bit stereo.
Sometimes the first decoding of each file was much slower than the rest. In these cases, it was thrown out. Therefore seven of the samples only had 11 data points.
Eleven of the samples were classical, which is known to compress very well. Therefore, absolute compression ratios presented here should not be extrapolated to other genres. However, I have no reason to believe that the relative ratios are related to genres.
The graphs are filesize ratio (x) and decoding speed (y).
Overall:
Full:
With these graphs, one can say with 95% certainty, that:
As you can see, setting "0" was the fastest decoding, but also the lowest compression. "ss", on the other hand, had high compression but rather dismal decoding speed. You can see the absolute differenced in the full graph above.
The problem with this graph is that it averaged together samples which were easy to encode with samples which were difficult. Therefore, whereas the relative speeds showed similar patterns, the absolute speed was different. I have come up with what I think is the best solution for this. The next ten graphs are the average of the relative speed between the encoder settings and a "pivot" setting.
For example, the first graph shows all the settings' speeds vs. "0". Notice that they are all safely below 1 on the vertical axis. This means that, for a given sample, encoding it with the "0" settings will decode faster than "1"-"8" and "ss".
0:
1:
2:
3:
4:
5:
6:
7:
8:
ss:
From these graphs, one can conclude with 95% certainty, that for a given sample :
Note that, for example, "2" has both higher compression and decoding speeds than "1". The faster decoding may be attributed to the higher compression; fewer disk accesses were needed during decoding.
The Mathematica 5 notebook used to store the data and perform the analysis is available in a RAR archive here [52 KiB]. The notebook is in text form and, except for the embedded images, human-readable. An additional text file containing the data may be provided if there is sufficient interest.
All recommended presets were in the 70-75x range, so it is fairly safe to say that additional compression settings have little speed penalty. Furthermore, there is EXTREMELY little difference between "4" through "8". However, decoding speed is definitely dependant on encoding parameters.
"ss" was by far the slowest in terms of both encoding and decoding. Encoding speed was not tested, but took around 5 hours per sample on my computer. Compression was marginally better than the presets. I must therefore agree that it is "totally impractical" and should remain "super secret" as its name suggests.
Josh Coalson for creating FLAC
Peter Pawlowski for making Foobar 2000
Darin Morrison and everybody at Hydrogenaudio for teaching me so much about audio
UCSC for giving me the web space to put this up