Skip to main content
Topic: Lossless codec comparison (Jan '15) (Read 8465 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Lossless codec comparison (Jan '15)

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

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.


Music: sounds arranged such that they construct feelings.

Lossless codec comparison (Jan '15)

Reply #1
Thanks!
IIRC all these codecs you mentioned (FLAC, Wavpack and refalac) have 32-bit and 64-bit versions. What versions did you use?

Lossless codec comparison (Jan '15)

Reply #2
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.
Music: sounds arranged such that they construct feelings.

Lossless codec comparison (Jan '15)

Reply #3
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.

Lossless codec comparison (Jan '15)

Reply #4
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.

Lossless codec comparison (Jan '15)

Reply #5
Funny point for the mono-encoded-as-stereo audiobook:

Quote
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.

Lossless codec comparison (Jan '15)

Reply #6
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?
Listen to the music, not the media.

Lossless codec comparison (Jan '15)

Reply #7
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

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.
Music: sounds arranged such that they construct feelings.

Lossless codec comparison (Jan '15)

Reply #8
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.

Lossless codec comparison (Jan '15)

Reply #9
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.
Music: sounds arranged such that they construct feelings.

Lossless codec comparison (Jan '15)

Reply #10
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).

Lossless codec comparison (Jan '15)

Reply #11
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.

Lossless codec comparison (Jan '15)

Reply #12
Not really, no. (edit: I mean, it wouldn't be far fetched at all ) 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)
Listen to the music, not the media.

Lossless codec comparison (Jan '15)

Reply #13
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 and it seems doable. I might play around with this after work.


Lossless codec comparison (Jan '15)

Reply #15
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.



Lossless codec comparison (Jan '15)

Reply #18
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.

Lossless codec comparison (Jan '15)

Reply #19
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.

Lossless codec comparison (Jan '15)

Reply #20
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

Lossless codec comparison (Jan '15)

Reply #21
[...] 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.
Listen to the music, not the media.


Lossless codec comparison (Jan '15)

Reply #23
Hah, every feature request the devs don't like -> obsolete.
"I hear it when I see it."

Lossless codec comparison (Jan '15)

Reply #24
Yeah, one can safely state when it comes to begging Her Omnipotence Google, "pretty please" won't do it.

Much obliged, lvqcl.
Listen to the music, not the media.

 
SimplePortal 1.0.0 RC1 © 2008-2018