1. LOWER COMPRESSION BUT HIGHER CPU USAGE
2. NO COMPRESSION MODE TO SELECT

EDIT : But compared with Monkey's Audio, WMA still use more power.

WMA = 34.0MB = ~13% CPU Usage
Monkey's Audio - High = 33.7MB = ~7% CPU Usage

Thanks. I added "unefficient" to WMA's cons.

I'm not sure unability to select compression mode is necessarily a bad thing. It surely makes up for it in ease of use.

So, I don't think it's a factor worth taking into consideration. For the same reason, one could put "too many compression modes" in FLAC's cons.

roberto , i'm so sorry
wma compression is a bit better than flac-8, but not much

I've encoded a sample 5:39
and this is what i get
original size = 57.1 MB
wma lossless = 34.0 MB
Monkey's Audio - High = 33.7 MB
FLAC-8 = 34.8 MB
FLAC-5 = 34.9 MB
REAL Lossless = 35.2 MB
Apple Lossless = 35.1 MB

but when I playback with foobar2000
WMA = 932kbps
FLAC = 860kbps
?????is this a bug?

this is the first time i test REAL,no kidding, REAL Lossless encodes very fast, comparable to FLAC-5, deocoding use less than 2% CPU usage with real player (P4 1.4GHz)

1. inefficient not unefficient

2. Neither FLAC nor Monkey (MAC) are error robust. A single bit error in a MAC file will render the file undecodeable. A broken FLAC file will be playable but probably cause error in player. FLAC and MAC have built-in error checking not tolerance. Error checking has nothing to do with "robustness" IMHO.

3. Missing items on pro/cons list: Tagging system

Another lossless comparison (in french, but the table is clear enough whatever the reader's language):

Guruboolez tests

Maybe add an item "Still in development/Not developed anymore" ?

Guess so...



That's interesting. Thanks for mentioning that.
I just added an entry for Real Audio.



Interesting idea. I'll try to come up with a table comparing them.



Oops. Thanks for correcting.



Well, I think I remember someone once reporting that new versions of Monkey's Audio would skip errors. Won't be able to find that post though...

And my idea was precisely to mention formats that would skip errors, opposed to formats that would break the playback from the error onward completely, like WavPack3, LPAC and so on.

Maybe I should change the wording?



Added, thanks.



Nice, just added the URL.



Hrm... I think it's kinda hard to draw the line there. Where does a format stops being developed? Shorten, as a format, stopped being developed years ago. But given its popularity tools for the format and playback plugins are still being developed, so I wouldn't say the format is really dead.

I guess that would only really apply to RKau (which I probably won't even add to this list) and, maybe, LPAC.

Regards;

Roberto.

<zealot>

I see no reason to put very fast decoding with FLAC and fast decoding with Wavpack when Wavpack actually decodes faster in the modes with the same compression.

Wavpack supports floats, which AFAIK FLAC does not. Optimfrog also supports floats, dont know about the others.

Also, Wavpack is supported in Nero.

</zealot>

Good point. I changed that.



Well, I think that falls into high resolution audio support. I don't think that is a popular enough feature to justify being mentioned, but I wouldn't know...



Ah, indeed. Thanks for reminding me.



I just added a color-coded table with features and whatnot.

Regards;

Roberto.

I've tested recently with MAC 3.99 (artificial corruption through hex. editor): files are perfectly playable with foobar2000. A small part was missing, the console poped-up in order to inform me about a CRC error. No player crash, no abrupt sound or ending.
~Three years ago, I was able to do the same thing with Winamp MAC plug-in.

Some notes about RALF :

I made some quick tests with Helix Producer to see the behaviours of this lossless codec with some others...Why Helix Producer : because there are 3 encoding modes whereas in RealPlayer it's only one. So, according to my results I'll be much less enthousiast like kotrtim...

The method that I used is the same as Speek. For the Real Audio Lossless, I extracted my wave files with EAC and then encoding with Helix Producer. Decoding has made by RealPlayer 10.

I created some tables to observe different results (it's in French, but I think it's readable.) BTW, some Hints : vitesse d'encodage == Encoding Speed ; vitesse de décodage == Decoding Speed ; Ratio de Compression == Compression Ratio ; Taille == Size.


Global Results:




Sample 1: (En Quarantaine_Miossec (extract of "1964" album) / Duration = 2''29 ) // Hint : french pop rock




Sample 2: (Sample 2 : Rock el Casbah_Rachid Taha (extract of "Tékitoi ?" album) / Duration = 4''33.) // Hint : rock.




Sample 3: (Mouth's Cradle_Björk (extract of "Medúlla" album) / Duration = 4''01.) Hint : electro.




Sample 4: (Symphony n°4 (Sehr Behäglich)_Gustave Malher / Duration = 1''52.) // Hint : classic.




Tests made on Pentium 3 800 Mhz & 512 Mo RAM. I hope that help somebody.

I forgot: nice initiative Roberto.
Two comments:
- LA is missing. Deliberate choice?
- I suggest an additional line, with "extra-future" including all things "that is a popular enough feature to justify being mentioned" like:
high-resolution audio, md5 hash, self-extract module, various containers compatibility, etc...

according to the player itself (Itunes n Real)
Apple Lossless encode at ~18X
Real Lossless encode at ~12X

If Real is "VERY FAST" Apple shouldn't be "AVERAGE"

To be more accurate, someone has to use a stop watch? and encode the same uncompressed file to measure the speed........ That needs lot of time

Hrm... the plot deepens

OK then, I put Monkey's as error robust again.



It will be very useful for me, thanks. And no worries about french, je peut comprendre un petit peu



Thanks



No. As I wrote near the end of the comparision:
"Formats I need help from forum members about pros and cons: TTA, LPAC, LA..."

I didn't add LA because of lack of information on it. But I guess i'll add it now with whatever I know about it, and count on users to help me fill the gaps.



Good idea. Maybe something that doesn't really justify as pros and cons, like container support, but still might be interesting to some people. I'll work on it.




Haha, dude, you said yourself Real is very fast



Since Hans never got around to testing Real on his comparision, I couldn't rely on him to provide speed values. So I relied on your data :B

Another suggestion: what about "adaptability" of each format? In other word, the possibility for the user to choose a better (for himself) compromise between ration/encoding-decoding time. Some people are not interested by the defaut setting of their favorite lossless encoder, but are using different profile : in order to reach an ultra-fast decoding, or to obtain the very best encoding ratios. Monkey Audio for exemple allow impressive ratio, with still acceptable decoding/encoding speed. WavPack allows very-fast decoding process, acceptable ratio but very slow encoding speed (asymetrical mode).

Some format are very malleable, and therefore very different for different users (MAC, OptimFROG, WavPack). Some other format are very restrictive: you must accept the choice made by the developer (TTA, WMA, ALAC). This flexibility is in my opinion something very precious. The current table is a bit simplifying, and it masks some of possible features of these flexible audio formats.

OK, that makes sense. I added a "Flexibility" entry in the table. Codecs with 4 or more different settings (which actually make some difference, unlike FLAC which outputs pretty much the same results after -4) are ranked very good. LA only has two modes, so it's ranked average. The formats with only one mode are ranked bad.

I ranked Real Audio bad since you can't reach two of the three settings on Real Player, you need Producer for that...

I would say "none" rather than "bad" flexibility. The lack of flexibility is not necessary a bad thing, and sometimes makes sense (alac for exemple: hardware decoding/battery life as main target).

Indeed back in May I wanted to test Real as well, and initally had several problems getting the software to function correctly. With the help of Karl that was solved ultimately. But then it appeared decoding required the "plus" version of RealPlayer 10. Only free solution for decoding was the Helix software. All these complications made me decide to put Real lossless on hold, so it can mature and become free. (See edit below)

FWIW, I do however still have the 7-album ("all") result, for compression only:
high mode: 56.94% at 3.2x speed
medium mode: 56.98% at 4.2 speed
low mode: 59.36% at 10.5 speed

Great to see that all the other important properties of lossless compressors are becoming gathered here, that's too much, and too changeable for me to deal with!

Edit: After reading again some emails with Karl, I recall some more things. In the end I used the Helix software for both compress and decompress. It was free and only required registration. But the files produced some audible skips during playback in RealPlayer, and certain error messages during decompression with Helix.

for me its very fast man, LAME 3.96 mp3 preset stansdard only encode at ~4X
MPC at ~6X, Monkey's Normal at ~8X, that's why 12X to me is considered very fast

EDIT: Mplayer Linux, Xine Player Linux can play both WMA pro and Lossless

I see...

Your results will be valuable neverthless. Thank-you for them.



I know, but I would rather list only official support, and not hackish windows emulation that will only work on x86 Linux.


I'm travelling right now, and depending on cybercoffees without MS Excel, so I probably won't update the table until I return, around December 10th.

Thank-you for all your support so far.

Regards;

Roberto.

this table is nice, good to finally have a sticky topic, hopefully it will cut down on the redundant questions.

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

http://flac.sourceforge.net/links.html#hardware


FLAC is error tolerant; damage is limited to corrupted frames. whether any particular player chooses to recover from errors or stop with with a warning is an implementation detail. I believe it's the same with wavpack.

Josh

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

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

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

About OS support: I understand what it means, but newbies could misinterpret this as "I can play this format on my OS" which is not exactly the same thing. Correct me if I'm wrong but WavPack can't yet be read on Linux. And probably not yet on MacOS either, I suppose.

About hardware support: 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. Everything else is still a niche market (home streaming etc.). ALAC and Flac have somewhat good support when you compare them to other lossless codecs (which have none ) but from a consumer point of view are a very limiting factor in hardware choice. Including all codecs, lossy and lossless would go like this:

MP3 = Very Good
Ogg Vorbis = Good
ALAC and Flac = Average or bad (I'd say "bad" myself)

Of course, this is only valid from a mass-market point of view.

Nice work.

I'm missing native ReplayGain in the table.
I know that FLAC support this feature.

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



That too.



Why?



It can.



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.



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

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

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.

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

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.

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?
I don't use Linux. Wavpack in Windows is good enough for me!

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.

Are you sure about this?

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.



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.



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.

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

It seems to be the case.



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

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

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

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

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?)

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

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



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.



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.

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

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



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



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)

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.

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

EDIT: --post deleted--

Looks like TTA has been taken care of.

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

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


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