Which is the best lossless codec?, Discussion thread Options

[rjamorim]

IMHO something is only open source if it is controlled by those who release the open source code - FLAC is.

From an ideological point of view, you are correct. But from a practical - I.E, the end user's - point of view, it makes no difference who is releasing the sources, as long as they can decode the bitstreams.

This post has been edited by rjamorim: Apr 12 2005, 23:03

[Mr_Rabid_Teddybe...]

Seems like Wavpack and FLAC are the most “green” out there.
Too bad they're not very good at compression ratio…

Well, that depends.... If you use the x switch with Wavpack you can achive some mighty good compression, but it's mighty slow too....
I recently compressed some improv disks with wavpack -hxmt and got results in the range of 30-40% of original wavs. Now I guess that's much due to the music; like much classical, improv is music with much "air" in it, as opposed to e.g. contemporay pop or metal, but still I found this quite impressive. It was veeeery slow, though, unlike wavpack at default settings, which is what's used for rjamorim's table.

[Mono]

Ah, very interesting. I tried feeding a multichannel stream to my iTunes and my QuickTime, as well as a high-frequency stream, and both programs choked on both streams.

I wonder if the MacOS versions of these programs don't show these limitations.

I've got samples on my Win desktop. I'll transfer them to my iBook tomorrow and test it out.

The multichannel file choked iTunes and QuickTime, which I didn't expect. I know that lots of users work with multichannel files on Macs. The hi res file played fine, encoded fine, but the decoder output a 44.1 kHz stream (the original was 96 kHz).

[shadowking]

Seems like Wavpack and FLAC are the most “green” out there.
Too bad they're not very good at compression ratio…

Well, that depends.... If you use the x switch with Wavpack you can achive some mighty good compression, but it's mighty slow too....
I recently compressed some improv disks with wavpack -hxmt and got results in the range of 30-40% of original wavs.

-h by itself is comparable to Monkeys audio normal mode.

[moozooh]

Well, that depends.... If you use the x switch with Wavpack you can achive some mighty good compression, but it's mighty slow too....
I recently compressed some improv disks with wavpack -hxmt and got results in the range of 30-40% of original wavs.

-h by itself is comparable to Monkeys audio normal mode.

Are these swithes enabled by default? AFAIK, this comparison table is based on every encoder's default settings…

[Mr_Rabid_Teddybe...]

Are these swithes enabled by default? AFAIK, this comparison table is based on every encoder's default settings…

If i understood this right, and rjamorim has used it without specifying switches, then Wavpack just uses it's default settings. AFAIK neither -h nor -x are turned on by default. In Wavpacks pure lossless mode -h and -x are switches you can play with for that extra compression, at the cost of speed. The -h switch makes both encoding and decoding about twice as slow, the -x switch turns on asymmetrical mode and makes encoding very, very, veeery much slower, but don't hurt decoding speed. So -hx gives you Wavpacks best compression and slowest encoding.

[Ariakis]

So -hx gives you Wavpacks best compression and slowest encoding.

Actually, -hx6 would give you the best compression, as the -x switch alone will give you different parameters depending on the compression level.

This option accepts an optional numberic parameter from 1 to 6 that overrides the default amount of "extra" processing done. The defaults were choosen to provide the greatest "bang for the buck" and are -x6 for "fast" mode, -x4 for the normal mode and -x3 for the "high" mode.

That's straight from the WavPack manual. =)

[Mr_Rabid_Teddybe...]

Actually, -hx6 would give you the best compression, as the -x switch alone will give you different parameters depending on the compression level.

Yes, I know that, but -hx was slow enough for me....

[rjamorim]

Seems like Wavpack and FLAC are the most “green” out there.

Indeed. If the RockBox guys release their unofficial iRiver firmware with WavPack support, and if Kuniklo finishes the XMMS plugin, WavPack will be the only all-green format in the table.



I just edited the table. ALAC's open-sourceness becomes light green and it's not featuring multichannel and high resolution anymore since no implementation supports them. If QuickTime 7 adds these features, I'll change the table back.

This post has been edited by rjamorim: Mar 9 2005, 16:02

[rutra80]

Few concerns about OptimFROG column:
1. Why ReplayGain row says "no"? I have all my OFR files replaygained by fb2k, values are stored inside the file's APEv2 tags, and they get gained on replay, isn't it ReplayGain support?
2. Pipe support row is blank, while "ofr.exe - --output %d" in fb2k's DiskWriter works, so I guess it supports pipes?
3. Why Encoding & Decoding speed rows say "slow"? As Flexibility row says, it's very flexible. With default settings it's at least average, and surely can be fast with proper settings.

This post has been edited by rutra80: Mar 16 2005, 01:16

[rjamorim]

1. Why ReplayGain row says "no"? I have all my OFR files replaygained by fb2k, values are stored inside the file's APEv2 tags, and they get gained on replay, isn't it ReplayGain support?

That only means Foobar supports replaygain, not that Optimfrog supports replaygain.

It's the same situation with Monkey's. If features require that the format user is locked to a third party software, then it's not a format feature, but a third party software feature.

2. Pipe support row is blank, while "ofr.exe - --output %d" in fb2k's DiskWriter works, so I guess it supports pipes?

Yes, it does. I'll add that to the table. Thanks for looking into that.

A blank cell means I don't know about that feature, so any information is welcome.

3. Why Encoding & Decoding speed rows say "slow"? As Flexibility row says, it's very flexible. With default settings it's at least average, and surely can be fast with proper settings.

I always use Hans Heijden's lossless comparision to evaluate speed vs. efficiency, etc. By "slow", I consider codecs that encode at less than 10X real time in the default setting. Even in the fast setting, OptimFrog encodes slower than 10X...

And I chose to represent only the default setting because the table would become a mess if I tried to evaluate the efficiency of every setting. It's also the developer duty to make the default setting output the best "bang for the buck" for users.

This post has been edited by rjamorim: Mar 16 2005, 01:40

[rutra80]

Another idea - how about adding a "Size limit" row? I read that even WAV has a 2GB limit and I know that some lossless encoders have internal limits too (not related with file-system or other things).

[rjamorim]

Another idea - how about adding a "Size limit" row? I read that even WAV has a 2GB limit and I know that some lossless encoders have internal limits too (not related with file-system or other things).

Well, if someone is willing to test each codec's limits...

Problem is, most of them read from wavs. So, you would have to make a wav several gigabytes big in order to test them, and such wav would be corrupt because of that same limitation.

This post has been edited by rjamorim: Mar 18 2005, 04:00

[Cyaneyes]

Well, if someone is willing to test each codec's limits...

Problem is, most of them read from wavs. So, you would have to make a wav several gigabytes big in order to test them, and such wav would be corrupt because of that same limitation.

See my last post in this thread from last month. The wav I was encoding was 5.5 hours, 44.1/16, size about 3.5 GB

[kjoonlee]

Another idea - how about adding a "Size limit" row? I read that even WAV has a 2GB limit and I know that some lossless encoders have internal limits too (not related with file-system or other things).

Well, if someone is willing to test each codec's limits...

Problem is, most of them read from wavs. So, you would have to make a wav several gigabytes big in order to test them, and such wav would be corrupt because of that same limitation.

This is only a partial solution, but here goes..

If they support pipes, and if they support raw PCM, they could be fed raw gigabytes from standard input. You could just feed the encoder repeated pieces of small audio files this way.

[rjamorim]

Small change: WavPack software support goes from average to good, thanks to the recent release of Kuniklo's beta XMMS plugin and Toff's alpha directshow filters.

[Skymmer]

Just want to add some details about LA to your great comparison table:

-tagging is possible  (I'm using Tag.exe to add APE2 tags, the Winamp plugin can display them, the command line decoder ignores them)

-PIPE is supported  (I'm using it in my small "la2mp3.bat" script - la.exe pipes decoded data to lame.exe)

Well I don't want to say that you lie but probably you're just little bit confused. I've tried MultiFrontend and LA Frontend with APEv1/APEv2 tags and also Foobar's Diskwriter Commandline Encoder with selected APEv2 tag and found that Winamp doesn't support APEv2 tags. Tried both 0.4 and 0.4b. Foobar does but it's more native Foobar functionality than support from format. Furthermore official documentation of LA says: ID3 v1.1 tagging support

[rjamorim]

Thanks for spotting it. I just updated the table and post.


Edit: I wonder if ID3v1-only support shouldn't be in "cons" instead of "pros" :B

This post has been edited by rjamorim: Apr 13 2005, 03:32

[guruboolez]

I've just noticed the blank cell for "pipe support" and WMA lossless. Pipe seems to be OK: I can transcode directly a WMA LSL file to another formats (lossy and lossless) with foobar2000.

EDIT: iTunes is also able to import WMA LSL file without needing a temporary decoding file.

This post has been edited by guruboolez: Apr 13 2005, 14:05

[rjamorim]

I've just noticed the blank cell for "pipe support" and WMA lossless. Pipe seems to be OK: I can transcode directly a WMA LSL file to another formats (lossy and lossless) with foobar2000.

EDIT: iTunes is also able to import WMA LSL file without needing a temporary decoding file.

Thanks, I just amended the table and the post.

[rjamorim]

Also, I suggest you guys check out the Wiki entry that is a copy of the first post in this thread:
http://wiki.hydrogenaudio.org/index.php?ti...ess_comparision

I think Jan S. will eventually redirect this thread to the wiki. It's a better solution, since in that case everyone can change and correct the article, and not only me.

This post has been edited by rjamorim: Apr 13 2005, 16:31

[Digga]

FLAC
CONS
- Compression efficiency not on par with other lossless codecs

------------------------

WavPack
PROS
- Good efficiency (not as good as Monkey's or OptimFrog, but not as bad as SHN or ALAC)

hmm, did you decide on a point where you call a codec not on par that lead to WavPack not falling into that category (i.e. everything above 58.0%)?
considering the difference btw FLAC and WavPack is only 0.70% in default mode and FLAC and ALAC are also very close, the quoted statements look a bit irritating.
I would suggest to change WavPack also to 'Compression efficiency not on par with other lossless codecs' or at least to remove the 'good efficiency' part.

[rjamorim]

hmm, did you decide on a point where you call a codec not on par that lead to WavPack not falling into that category (i.e. everything above 58.0%)?
considering the difference btw FLAC and WavPack is only 0.70% in default mode and FLAC and ALAC are also very close, the quoted statements look a bit irritating.
I would suggest to change WavPack also to 'Compression efficiency not on par with other lossless codecs' or at least to remove the 'good efficiency' part.

Good point. I based that mostly on a Garf's statement that is hidden in some other thread (JanS is working on the redirection)

BTW: It's important to mention that efficiency is not compression ratio. Efficiency is a relation between compression ratio and encoding speed.

I'll look into that issue further, based on Hans Heijden's findings, and edit the wiki if appropriate. The first post in this thread will soon be deleted in favour of the wiki article, so no point working on it any more.

Also: Yes, 58% is the line I drew to separate green compression to light green compression.

This post has been edited by rjamorim: Apr 13 2005, 17:09

[Digga]

BTW: It's important to mention that efficiency is not compression ratio. Efficiency is a relation between compression ratio and encoding speed.

ah yes, you're right, I totally forgot about that.

Also: Yes, 58% is the line I drew to separate green compression to light green compression.

what about TTA and LPAC vs. FLAC and ALAC? both are either above or below the 58% mark and both are light green...

The first post in this thread will soon be deleted in favour of the wiki article, so no point working on it any more

o.k. fair enough.

This post has been edited by Digga: Apr 13 2005, 17:15

[rjamorim]

what about TTA and LPAC vs. FLAC and ALAC? both are either above or below the 58% mark and both are light green...

Oops, sorry about that. Actually 57% is the line.

I considering making 58% the line once, but that would result in too many dark green cells, so it wouldn't be useful for comparision purposes.

This way, it is more or less equilibrated: 4 dark green and 4 light green.

In the comparision, I replaced "Compression efficiency not on par with other lossless codecs" with "Relatively slow encoding" (that is, comparing to other codecs that compress much more at same speed). I think it's fairer towards FLAC. Do you agree?