Which is the best lossless codec?, Discussion thread Options

[greynol]

You're right, when you delete some bytes the output from that point forward is pretty much toast.

This post has been edited by greynol: Oct 30 2006, 21:44

[rjamorim]

You're right, when you delete some bytes the output from that point forward is pretty much toast.

Right. And, for instance, in network transfers, it's much more likely to lose some bits (lose a packet) than get those bits replaced by something else. So, I guess (?) that kind of error is more common.

FLAC and WavPack, on the other hand, somehow manage to resync after missing some bits. I think that's because WavPack and FLAC are packet based. I suspect Monkey's isn't packet based, like WavPack3.

This post has been edited by rjamorim: Oct 30 2006, 21:47

[greynol]

I thought about what type of corruption would cause missing bits and came up with the same conclusion.

Of course this brings us back to the issue of legal ownership.

I wish your chart had a better ranking/explanation for error handling.

[guruboolez]

So, where are your tests?

Last time (here) I had to bring myself the proof that Greynol's claim was wrong.
A bit like God integrists, Greynol is by defaut right... unless you can prove the opposite.

As I already said in a past topic, I encountered a -c2000 encoded files which was completely unreadable after the error even with Winamp. But as I can't submit it, I'm surely wrong...

[greynol]

This was a good discussion and I learned something from it. It would have been nicer (for me) that the missing bytes issue was addressed in the other thread so that we wouldn't have to go a second round.

You weren't surely wrong, guruboolez, you just never bothered to tell me why, or else I would have found it out myself as I did with Roberto's help. I tried to find your claim about -c2000 encoded files being completely unreadable, sadly I couldn't. I'm not saying that you didn't say that, just that I'd like to read it since it sounds like I offended you by holding you to some sort of standard. (this is reminding me of trumpets )

This post has been edited by greynol: Oct 30 2006, 22:07

[guruboolez]

Tell you what? (it's clearer after your edit)

I tried to find your claim about -c2000 encoded files being completely unreadable, sadly I couldn't

I can't myself. I thought I precised it but obviously I didn't.
But what I don't understand now is why you challenged Roberto to decode a corrupted -c3000 encoding? The previous discussion didn't conclude on the possibility (or impossibility) to decode corrupted ape file according to the profile.

This post has been edited by guruboolez: Oct 30 2006, 22:22

[rjamorim]

Of course this brings us back to the issue of legal ownership.

Oh, come on... I can have the APE files on my computer and stream them over wi-fi to the media center in my living room. No legal issues whatsoever there.

As for the better explanation on error ranking: sure, as long as someone takes his time to throughtly test all involved codecs.

This post has been edited by rjamorim: Oct 30 2006, 22:19

[greynol]

Sorry, I was thinking p2p transfers.

@guruboolez:
What do you mean "tell you what?"?
I've found no past topic where you stated -c2000 couldn't decode. Perhaps you can give me a link. My point being was that Roberto was able to explain how a -c2000 file can get corrupted beyond the ability to decode. This was quite a bit more helpful than opting to compare me with a God integrist.

@Roberto: Thanks for acknowledging my comment about the chart. This is all I really ever wanted from you regarding this subject.

EDIT: Would it be too difficult to simply describe the criteria of the test to determine "error handling" in a footnote?

This post has been edited by greynol: Oct 30 2006, 22:31

[Alex B]

Right. And, for instance, in network transfers, it's much more likely to lose some bits (lose a packet) than get those bits replaced by something else. So, I guess (?) that kind of error is more common.

TCP/IP and for example NetBeui are error correcting protocols. You cannot lose a packet because of network errors. Your LAN would be generally unusable before you start losing packets. Naturally you can have faulty hardware like bad memory sticks or broken network adapters that cause errors or your network connection can be too slow for real time playback, but these are different issues.

Even on WAN it is unlikely that a direct file transfer would not be perfect. TCP adjusts its error correction parameters automaticallly when the connection is less than perfect. It just gets slow. Streaming for real time playback is a different story, but this applies only to those lossless formats that can be streamed.

Edit: typo

This post has been edited by Alex B: Oct 31 2006, 00:02

[Fifoxtasy]

i wish there was an up to date graph like this one on the wiki's comparison page
i think this is by far the best way to present differences in codec performance.
codecs just have too many modes to just put one comression ratio and speed.

This post has been edited by Fifoxtasy: May 26 2007, 04:44

[Allan Gabston-Ho...]

I have to find myself questioning the validity of "Doesn't support RIFF chunks" as a 'CON' for any lossless format. The obsolete RIFF structure has not been adopted by any new multimedia formats since the early 90's; and, even microsoft has abandoned it in favor of the DRM-crippled ASF container format.

Comparing ASFs other features against the cadre of other container formats out there, there is nothing compelling about the format which would otherwise foster its adoption. Matroska or NUT are far more worthy container format choices, IMHO.

I am also somewhat confused with regard to defining the lack of hybrid/lossy modes, for any lossless format, as a 'CON'. My perspective is that my choice of a lossless audio format precludes any interest in lossy audio compression scheme, thus rendering any hybrid format as irrelevant. For my needs, that is the exact case.

It seems reasonable to anticipate that, were I to desire a lossy compression storage scheme, I would select a lossy compression format; not a lossless compression format that is trying to be all things to all people; and, in all likelihood, not accomplishing either task very well at all.

[Domenic]

I'm sorry if it's bad to bump this topic, but FFmpeg now supports ALAC encoding, therefore ALAC has Linux support.

[Dewey, Cheathem ...]

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

I've heard this term used throughout this discussion, but what is "pipe support"?

[bryant]

Pipe support means that the codec command-line encoder/decoder can accept input from stdin and/or send output to stdout.

Many tools (like foobar) have provisions to use encoders that support stdin to encode without intermediate files, and other programs (like Logitech's SqueezeCenter) can use decoders with stdout support to play otherwise unsupported formats.

And, of course, on Linux everything uses pipes!

[Mach-X]

This is a ham-fisted reply, but can't we just stick with FLAC for all our lossless archiving needs? Having all these different codecs is confusing. I'm fine with different lossy codecs but for archiving purposes hasn't FLAC been established de facto yet? Its open source, supported natively by sansa's and cowon's excellent daps, as well as android. Am I missing something here? Wouldn't it be better suited for all these different developers to try and improve the FLAC format itself, thereby providing a single universal lossless codec?

[Destroid]

This thread is ancient, but I'll bite...

Yes, there is no inherit downside to FLAC. But people want more. I feel any lossless codec that 'delivers' (input = output) is still worthy and useful. Since lossless compression (in digital data) is visible all over the place (ZIP/RAR/7z/PNG and et cetera) it seems taken for granted. Then there is the issues of support (platform/licensing/third-party software) and versatility.

Nowadays I am much more hippie about lossless audio codecs since I joined HA and I have come to embrace all of the formats But I also understand the confusion of the lack of standard lossless audio format. Despite MPEG-4 using the LPAC derivative I have yet to witness its adoption in regards across all areas of consumer audio (I expect parts of its technology might exist in Dolby TrueHD).

The "best" lossless codec? It would appear to be the same as asking, "What is the best formal designer clothing?" It depends on the person and what their expectations are. I guess try them them all out and decide which is most comfortable. Personally, I decided that fixating on a single brand may hinder myself in the long run since all of them are useful and better than going naked (meaning error correction and tagging and so on ).

edit: grammar

This post has been edited by Destroid: Dec 23 2012, 12:11

[ktf]

Hi guys,

I know this is an ancient thread, but I would like to say something about the wikipage this thread relates to, instead of 'just' editing the wiki without telling why. I did some tests for the lossless comparison I'm currently working on, and I found some results that are quite different from the data in the Wiki.

First, WMA Lossless has, according to the Wiki, compression ratio's surpassing TAK, FLAC and WavPack. This recent comparison shows that's really wrong, and my own comparison tells me the same. I suppose the table states compression ratios associated with the default setting of each encoder, so WMA Lossless should have a ratio higher than FLAC probably. According to my tests, it should be 1.5 percentage point higher.

Second, WMA Lossless is actually pretty fast according to my tests. Could it be they sped up the encoder or changed the preset in the past 8 years?

I'll add some graphs of the Windows-part of the tests. First the encoding part: (note this was compared to FLAC -6)


Last the decoding part:


This post has been edited by ktf: Dec 30 2012, 16:51

[lvqcl]

According to my tests, it should be 1.5 percentage point higher.
Second, WMA Lossless is actually pretty fast according to my tests. Could it be they sped up the encoder or changed the preset in the past 8 years?

Yes, I noticed this too.

[ktf]

First, WMA Lossless has, according to the Wiki, compression ratio's surpassing TAK, FLAC and WavPack. This recent comparison shows that's really wrong, and my own comparison tells me the same. I suppose the table states compression ratios associated with the default setting of each encoder, so WMA Lossless should have a ratio higher than FLAC probably. According to my tests, it should be 1.5 percentage point higher.

This is getting really weird.

I got the results from my previous post on an updated Windows 7 computer. I did the conversion through dBpowerAMP with the Windows Media Player 10 Pro release. However, I am migrating my test setup to an old computer running Windows XP (using software mentioned here) and I got some preliminary results that are completely different. It is a different set of samples, but the results shouldn't have this much of a gap really.



Does anyone have any idea why this big difference? These results on Windows XP were with Windows Media Player 11 installed and indicate a pretty slow codec with fairly nice compression ratios, but the results on the Windows 7 computer show a much faster codec, but with less compression. Or could it have to do something with dBpowerAMP?

What should I do with this?

This post has been edited by ktf: Jun 18 2013, 10:11

[TBeck]

Probably the explaination is a lot simplier, but one quick hypothesis:

1) Maybe the codec is using different filter implementations depending on the available instruction set extensions and/or the cpu speed.
2) Possibly those implementations are not equally accurate mathematically.