With FLAC 1.3.1 released, it was time for an update. Results have been updated for FLAC, refalac and WavPack. I haven't rerun all codecs. The CPU used is still an AMD A4-3400.
Results are here: http://www.audiograaf.nl/downloads.html (http://www.audiograaf.nl/downloads.html)
Main results are below, and to have some variation, this time the inverted plots (showing CPU-usage instead of speed). This means, lower numbers are better for both axes.
(http://www.audiograaf.nl/misc_stuff/rev4-encodep.png)
(http://www.audiograaf.nl/misc_stuff/rev4-decodep.png)
Thanks!
IIRC all these codecs you mentioned (FLAC, Wavpack and refalac) have 32-bit and 64-bit versions. What versions did you use?
I've used 64-bit versions if possible. I did so in the previous revisions as well, FLAC 1.3.0 was tested with a 64-bit compile as well if I remember correctly.
This means, lower numbers are better for both axes.
Which means that Apple is more or less the only to perform nearly as bad as Microsoft ...
And that FLAC / WavPack / TAK might have a few useless settings.
If the FLAC encoding datapoint closest to the origin is the -5 setting, this graph shows it to be a good default.
Likewise TAK and the -p2 setting.
Funny point for the mono-encoded-as-stereo audiobook:
A last remark is that LZMA2 (7-zip’s compression mode), while not displayed in the graph, does very well considering it is not an audio codec, it scores 30% compression and outperforms ALAC fast, FLAC -0, -3 and Shorten here.
Nice to see how FLAC's line stands out as the most erect line among all lossless CODECs at the decoding stage.
Would it be too far-fetched to conclude your portable DAP's battery is up for a treat when it comes to decoding FLAC at any of its compression settings?
If the FLAC encoding datapoint closest to the origin is the -5 setting, this graph shows it to be a good default.
No, that datapoint is -4 actually.
Would it be too far-fetched to conclude your portable DAP's battery is up for a treat when it comes to decoding FLAC at any of its compression settings?
Not really, no. (edit: I mean, it wouldn't be far fetched at all ) http://www.rockbox.org/wiki/CodecPerformanceComparison (http://www.rockbox.org/wiki/CodecPerformanceComparison)
According to those comparisons, FLAC even outperforms the ancient MP3 format on most ARM devices, and it is 10x faster than HE-AAC for example.
If the FLAC encoding datapoint closest to the origin is the -5 setting, this graph shows it to be a good default.
No, that datapoint is -4 actually.
The diagram uses log scale. Anyway there is no universally valid metric measuring "closest to the origin" (only partial ordering, if X beats Y on both parameters).
But -5 is just NW of the (0.3,57) coordinate, right? Looks reasonable except that I encode once and store every day.
But -5 is just NW of the (0.3,57) coordinate, right? Looks reasonable except that I encode once and store every day.
No, that is -4. -5 is approximately at (0.43,57.0) The confusion probably stems from the fact that FLAC's preset numbering starts with 0. So, there are 9 presets/datapoints.
edit: it would probably help if there was a neat way to attach labels to these points, but it usually gets unreadable anyway.
The only main difference between flac presets -4 and -5: -5 uses mid-side, -4 uses adaptive mid-side. In some sense, -5 is more robust (for example, it is better suited for LossyWAV).
The only difference between flac -4 and -5: -5 uses mid-side, -4 uses adaptive mid-side. In some sense, -5 is more robust (for example, it is better suited for LossyWAV).
Slight difference in the rice partition order? Or has that also changed recently?
Although adaptive mid-side coding sounds better, in reality it is just trying to guess whether mid-side or independent is better. Non-adaptive actually tries both to see which is best. Obviously slower but also obviously better.
Not really, no. (edit: I mean, it wouldn't be far fetched at all ) http://www.rockbox.org/wiki/CodecPerformanceComparison (http://www.rockbox.org/wiki/CodecPerformanceComparison)
According to those comparisons, FLAC even outperforms the ancient MP3 format on most ARM devices, and it is 10x faster than HE-AAC for example.
Yeah, I recall that.
If memory doesn't fail me, and on a side note, it also showed how Musepak was (one of) the best in terms of battery life. (sigh)
edit: it would probably help if there was a neat way to attach labels to these points, but it usually gets unreadable anyway.
I was looking at chart.js (http://www.chartjs.org) and it seems doable. I might play around with this after work.
Slight difference in the rice partition order?
Ah yes. -r 4 vs -r 5.
Interesting to see that compression-wise tak pretty much starts where flac ends. And the CPU load for decoding isn't even that much higher.
If memory doesn't fail me, and on a side note, it also showed how Musepak was (one of) the best in terms of battery life. (sigh)
Your memory doesn't fail you, mpc scored slightly better than flac on my rockboxed sansa clip test. Too bad the format is pretty much abandoned.
starts with 0
*facepalm* Beginner's mistake.
Too bad the format is pretty much abandoned.
I'm assuming by "abandoned", you really mean "mature", right?
Too bad the format is pretty much abandoned.
I'm assuming by "abandoned", you really mean "mature", right?
I didn't mean it in the sense of "no updates = abandoned", more in the sense of widespread use. I know of many software players that play it, but there is next to no hardware support, nor will there ever be, it seems: google recently closed the request to implement it in android as "obsolete", same for wavpack.
I'm pretty sure I understand what you mean, I just don't agree. Google's "obsolete" comment is their own semiotic issue. Hardware support is almost meaningless in today's world. Rockboxed players get more battery life out of Musepack at bitrates comparable to or lower than the equivalent quality level for MP3. There is a really solid use case for it still. The format is mature. The bitstream isn't changing. Support continues to improve, and once foobar2000 Mobile hits, it will run on all mobiles easily.
Well, there are software players out there that play all of them, including wavpack and mpc, so it's not like it will be anything new - unless foobar mobile will be free.
I'm more interested in seeing how far opus can be optimized at the moment though, because it's transparent at a lower bitrate for me... /OT
[...] google recently closed the request to implement it in android as "obsolete", same for wavpack.
I'm as oblivious to this as I am curious right now.
Care to share more info/links about it, please?
Edit: I've already google'd for it in and outside HA with no avail.
Musepack: http://code.google.com/p/android/issues/detail?id=4397 (http://code.google.com/p/android/issues/detail?id=4397)
Wavpack: http://code.google.com/p/android/issues/detail?id=4854 (http://code.google.com/p/android/issues/detail?id=4854)
ALAC: http://code.google.com/p/android/issues/detail?id=19000 (http://code.google.com/p/android/issues/detail?id=19000)
non-Subset FLAC: http://code.google.com/p/android/issues/detail?id=35348 (http://code.google.com/p/android/issues/detail?id=35348)
ReplayGain: http://code.google.com/p/android/issues/detail?id=4455 (http://code.google.com/p/android/issues/detail?id=4455)
Hah, every feature request the devs don't like -> obsolete.
Yeah, one can safely state when it comes to begging Her Omnipotence Google, "pretty please" won't do it.
Much obliged, lvqcl.
Morons ... though I wish they were right about ALAC.
To throw a bit of a wrench into the WMAL results, according to this MSDN article (https://msdn.microsoft.com/en-us/library/windows/desktop/ff819329(v=vs.85).aspx), it would appear that the performance/efficiency ratio for WMAL encoder changed between Vista and Win7. Did anyone try testing with both versions to see the difference?
Did anyone try testing with both versions to see the difference?
Yes, indeed. I've had some unpublished results from a Windows XP system which I planned to use for the third revision of this lossless codec comparison (I switched to a Windows 7 system shortly after), but I noticed that WMAL was indeed much more competitive (but quite slow in decoding) in earlier Windows versions.
Here is one album tested with that Windows XP device
(http://www.audiograaf.nl/misc_stuff/new-results-WMA-lossless.png)
As you can see, WMAL was in a very different spot comparing to where it is in my recent results.
I've written about this earlier: http://www.hydrogenaud.io/forums/index.php...st&p=837436 (http://www.hydrogenaud.io/forums/index.php?showtopic=33226&view=findpost&p=837436)
Yes, indeed. I've had some unpublished results from a Windows XP system which I planned to use for the third revision of this lossless codec comparison (I switched to a Windows 7 system shortly after), but I noticed that WMAL was indeed much more competitive (but quite slow in decoding) in earlier Windows versions.
Thanks for the report! I started a discussion with lvqcl about potentially changing the default complexity value for WMAL in wmaencode.exe, as I'm guessing most people on HA would prefer higher compression ratios over faster encoding times.
http://www.hydrogenaud.io/forums/index.php...st&p=887951 (http://www.hydrogenaud.io/forums/index.php?showtopic=90519&view=findpost&p=887951)
Thanks for the report! I started a discussion with lvqcl about potentially changing the default complexity value for WMAL in wmaencode.exe, as I'm guessing most people on HA would prefer higher compression ratios over faster encoding times.
To be honest i doubt the typical HA member will use WMAL at all. No matter how it compresses.
Thanks for the report! I started a discussion with lvqcl about potentially changing the default complexity value for WMAL in wmaencode.exe, as I'm guessing most people on HA would prefer higher compression ratios over faster encoding times.
To be honest i doubt the typical HA member will use WMAL at all. No matter how it compresses.
Sure, but for a comparison like this ...
but I noticed that WMAL was indeed much more competitive (but quite slow in decoding) in earlier Windows versions.
From my old tests (about 5 yesrs ago) on WinXP: WMAL compression was somewhere between Monkey's Audio fast and normal, en/decoding speed is slower than Monkey's Audio high.
Just as in your graphs.