Which is the best lossless codec?, Discussion thread Options

[rjamorim]

for the 'hardware support', 'good' for ALAC seems like a stretch as it is only supported in one device (ipod); FLAC devices are in the teens or maybe 20s now

10% of the iPod units probably sums to more than all sold units supporting flac :B

So, while FLAC indeed does have a bigger amount of options in the player market, it's much more probable that you run into an ALAC-playing device when searching on the wild.

Error tolerance usually means you can damage some bits and recover them later - i.e. RAID1, RAID5, par2, ...

Well, in that case, no codec is error tolerant.

As I said earlier, I was just trying to differentiate codecs that will completely break at an error from those that can ignore it.

ALAC is also used by Airport Extreme with AirTunes. Furthermore iPods comes in different models, even different manufacturers (HP).

That too.

How about an overall notation system?
3 points for very good/fast
2 for good/yes/fast
1 for average
0 for bad/no/slow

Why?

Correct me if I'm wrong but WavPack can't yet be read on Linux.

It can.

And probably not yet on MacOS either, I suppose.

It can.

For linux, you are supposed to be able to compile the sources yourself. If you can't, it's your fault for choosing this overcomplex OS.

from a mass-market point of view, I think no lossless codec can earn a "good" score. Players bought in millions in the whole world are portable players, car players and standalone DVD players

iPods represent more than 50% of the DAP sales. Enough said...

This post has been edited by rjamorim: Nov 29 2004, 00:35

[rjamorim]

I'm missing native ReplayGain in the table.

Good point. I'll add it when I return home.

[Zurman]

How about an overall notation system?
3 points for very good/fast
2 for good/yes/fast
1 for average
0 for bad/no/slow

Why?

Just to sum up a bit. You're multiplying the table entries, but that could be nice to see which one is the best, according to those entries.

For example, Someone who just wants a fast decoding codec would pick, among those which have "very fast decoding", the best rated.

[dev0]

Just to sum up a bit. You're multiplying the table entries, but that could be nice to see which one is the best, according to those entries.

For example, Someone who just wants a fast decoding codec would pick, among those which have "very fast decoding", the best rated.

I don't think it should be the purpose of this table to somehow rate the different lossless codecs according to some weird point-system. Different people have different needs and this table is merely a help for comparing the offerings in the lossless codec world.

[Tang]

Hi,
Very nice THREAD thanks to Amorim and every contributors... However I'm wondering about something... Recently I heard (from Guru) about the interesting "asymetrical" feature of some lossless codecs... Curiously I haven't seen this point mentioned in the thread, did i missed it?...
If not I thought this option should appear as "PRO" or at least as "OTHER FEATURE" (somewhat valuable)...
Regards,
Tang

[music_man_mpc]

Recently I heard (from Guru) about the interesting "asymetrical" feature of some lossless codecs... Curiously I haven't seen this point mentioned in the thread, did i missed it?...

The asymetrical "feature" you are referring to is WavPack with the -x option enabled from the command line. All it does is allow better compression at the cost of encoding speed only, instead of both encoding and decoding speeds. Most other codecs are natively asymerical, but it is neat that the user gets to choose if they want to use this "feature" or not. This feature falls under the flexibilty category in the table.

[BoraBora]

For linux, you are supposed to be able to compile the sources yourself.

That's what I meant: I remembered reading there wasn't yet a plug-in for popular Linux players (or any Linux player, BTW). Is there one on MacOS?

If you can't, it's your fault for choosing this overcomplex OS.

I don't use Linux. Wavpack in Windows is good enough for me!

[guruboolez]

How about an overall notation system?
3 points for very good/fast
2 for good/yes/fast
1 for average
0 for bad/no/slow

Nonsense. flac is probably excellent for someone looking for a very fast decoding format, but completely bad for someone looking for very strong ratios. A bad lossless encoder would be something bad on every point (encoding, decoding, seeking, ratio...). Most of current encoders have at least one strong advantage: LA and Frog are strong; alac, flac, shorten and wavpack are potentially very fast on decoding, MAC is very flexible, WMA offers good ratios, etc....
In other words, there are no "good" or "bad" lossless formats. Some are better for one specific usage, and worse for other purpose.

This post has been edited by guruboolez: Nov 29 2004, 10:39

[guruboolez]

(...) Most other codecs are natively asymerical (...)

Are you sure about this?

[rjamorim]

I don't think it should be the purpose of this table to somehow rate the different lossless codecs according to some weird point-system. Different people have different needs and this table is merely a help for comparing the offerings in the lossless codec world.

Right. Oversimplifying the table wouldn't really help users. After all, this thread isn't a competition to decide the best lossless codec in the world. It's just feeding information to the users so that they can judge for themselves, based on their needs.

That's what I meant: I remembered reading there wasn't yet a plug-in for popular Linux players (or any Linux player, BTW). Is there one on MacOS

Well, you asked if it could be read on these OSes. By read, I understand decoding, so yes, it can be read.

And no, it can't be played back yet.

(...) Most other codecs are natively asymerical (...)

Are you sure about this?

Indeed, some codecs are symmetrical (Monkey's, OptimFROG, LA, WMA), others are assymetrical (FLAC, ALAC, RKau, LPAC). WavPack is the only codec I know of that can be both.

I mentioned this feature at the Other Features section.

[guruboolez]

Indeed, some codecs are symmetrical (Monkey's, OptimFROG, LA, WMA), others are assymetrical (FLAC, ALAC, RKau, LPAC). WavPack is the only codec I know of that can be both.

Is ALAC asymetrical? In iTunes?
Anyway, we're far from "most formats". Rkau is totally outdated, Lpac is dead. Most living formats (Monkey, WMA9, Real, ALAC, OptimFrog, LA, TTA) are not asymetrical (no options at least in the executable).

[rjamorim]

Is ALAC asymetrical? In iTunes?

It seems to be the case.

(no options at least in the executable).

Assymmetrical means encoding and decoding take different amounts of CPU load. Symmetrical means both take about the same amount of CPU.

[guruboolez]

You're right. I had in might asymetrical with different settings (like flac or wavpack -xn).

This post has been edited by guruboolez: Nov 29 2004, 14:34

[Tang]

(...) Most other codecs are natively asymerical (...)

Are you sure about this?

Okay thanks Roberto this point looked relevant to me but others deserve credit for this...

[jcoalson]

for the 'hardware support', 'good' for ALAC seems like a stretch as it is only supported in one device (ipod); FLAC devices are in the teens or maybe 20s now

10% of the iPod units probably sums to more than all sold units supporting flac :B

So, while FLAC indeed does have a bigger amount of options in the player market, it's much more probable that you run into an ALAC-playing device when searching on the wild.

well, if I were evaluating a codec w.r.t. hardware support, the number of units sold is irrelevant, what I care about is how much choice I am going to have.

right now, that goes like this: do I choose ALAC (supported on 1 device, a portable) or FLAC, supported on several, including portables, home stereo, car stereo components, OEM devices (roll your own). the # of ipods sold makes no difference.

Josh

[GeSomeone]

RJAmorim,
I think it would be a good idea to add version numbers. The things said about speed and options are tied to certain versions.
Example: wavpack was not so fast before the recent beta versions, some other codec might add hybrid/lossy from a future version on.

I understand that this would mean updating once in a while, but at least one could see from the version numbers when this would become necessary.

Another thing, I personally don't think not having hybrid/lossy capabilities is a negative point for a lossless codec. As these features are meant for lossy use. On the other hand it is a pro for the codecs that have it (see what I mean?)

[Faelix]

Another thing, I personally don't think not having hybrid/lossy capabilities is a negative point for a lossless codec. As these features are meant for lossy use. On the other hand it is a pro for the codecs that have it    (see what I mean?)

Certainly people who don't care about hybrid encoding will not take this feature into account when evaluating lossless codecs, so I don't think it is necessary to diminish its place on the comparison table.

(To me, for instance, hybrid encoding is a great selling point, and I think the table would be less helpful if it ignored this capability.)

[rjamorim]

I think it would be a good idea to add version numbers. The things said about speed and options are tied to certain versions.
Example: wavpack was not so fast before the recent beta versions, some other codec might add hybrid/lossy from a future version on.

The table is meant to always reflect the latest version available.

I understand that this would mean updating    once in a while, but at least one could see from the version numbers when this would become necessary.

OK, but still, sometimes there's a version upgrade without any meaningful change that would justify updating the table.

I would prefer that, when somebody notices there is something outdated in the table, post here and then I'll upload a new version.

Certainly people who don't care about hybrid encoding will not take this feature into account when evaluating lossless codecs, so I don't think it is necessary to diminish its place on the comparison table.

(To me, for instance, hybrid encoding is a great selling point, and I think the table would be less helpful if it ignored this capability.)

Yes. The table's purpose is precisely to allow people to compare codecs based only on the features that matter to them.



So, nobody here willing to help me with TTA features and filling the blanks in the table? :B

Just uploaded a new table with ReplayGain information, BTW.

Regards;

Roberto.

[kurtnoise]

For TTA :

Encoding Speed : fast
Decoding Speed : fast
Compression : ~55%
Flexibility : bad
Error Handling : I don't think so
Seeking : yes
Tagging : yes
Hardware Support : yes ~~> available in standalone player
Software Support : good
Hybrid/Lossy : no
ReplayGain : yes
Streaming : no
OpenSource : yes
Multichannel : yes
High Resolution : yes
OS Support : All

[rjamorim]

Excellent. Thank-you for the info. I just updates the table and the post.

Compression : ~55%

Actually, according to Hans Heijden's comparision, it's closer to 57%.

Unless you take into consideration their own highly biased (and badly outdated) comparisions

Hardware Support : yes ~~> available in standalone player

Hrm... OK, if people consider DVD player support as "hardware support"

(I don't think it's much different than claiming WMA Lossless has hardware support because it can be played on the XBox)

This post has been edited by rjamorim: Dec 9 2004, 19:57

[buzzy]

Nice work.

As some of the comments here suggest, the point of this is for a given person to decide best not in some theoretical sense, but best for a specific use they have in mind. So, for example, the best format for file sharing (like etree) is clearly flac. But someone in search of the best format for archiving their CDs might decide that the absolute best file compression is the only criterion that matters.

So some intro / comment to that that effect - that best depends on how you weight the factors you've listed - will probably help the thousands of newbies who will read this thread.

Also, the table might need a bit of a key or explanation of what some of the items mean, rather than expecting people to read the whole thread.

As for hardware support, it's much more about whether the codec lends itself to that application - which will matter much more over time than it does now. Even with faster / cheaper hardware, the codecs with high complexity decoding don't look like good bets.

Ease of use / interface is a little different than what you might have in mind for "software support" - but has always been a strong point of Monkey's and should be for ALAC. And is a relative weakness of flac, for widespread (as opposed to "technology enthusiast") use.

But "software support" is a bit unclear - people would keep using shn forever for music sharing if someone was maintaining GUI tools for it on Windows. But that's not the case. mkwACT, for example. In practice, the lack of easy to use software tools for shn are what's going to kill it. And if the tools were better for flac, the shift tfrom shn to flac would happen a lot faster.

This post has been edited by buzzy: Dec 9 2004, 21:06

[guruboolez]

LA has both seeking and tagging functionality. I can't answer for multichannel/high resolution.

[Mindaxiz]

EDIT: --post deleted--

Looks like TTA has been taken care of.

This post has been edited by Mindaxiz: Dec 10 2004, 00:35

[Mindaxiz]

Rjamorim, you either edited the table super fast or i need to refresh the window more then once a day. Wonder which is it

[witt]

Monkey's Audio
- No multichannel or high resolution audio support

Monkey's Audio supoports 24bit/192KHz. No multichannel support.

WavPack
- Fits the Matroska container

What app can it mux?
mkvtoolnix (still) doesn't support WavPack.