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

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

Get up-to-date binaries of Lame, AAC, Vorbis and much more at RareWares:http://www.rarewares.org

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

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

Breath is found in waveform and spectral plots;DR figures too, of course.

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.

@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

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

Breath is found in waveform and spectral plots;DR figures too, of course.

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.

i wish there was an up to date graph like this one on the wiki's comparison pagei 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.

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.

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.

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?

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

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)

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?

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?

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.

So far I found wavpack as my best choice, reasons are1. versitile format but suitable more for keeping images2. Flexibility in packaging as single .wv or ISO packaged3. Suitable for bit rates up to 24/1920004. Allows seek without additional navigation table as FLAC or APE require5. Reasonable CPU consumption, you can observe that my playing devices either Android phones or Raspberry Pi

to inflate the file size, of course! Or perhaps because of the overtones being 'preserved'. Or perhaps it's because we will shortly be able to GM our ears so that we will be able to hear everything up to 40kHz?There's a few vinyl digitization efforts going on on various classical blogs that believe strongly in the value of digitizing at 96k/24 or 192k/24; I don't mind because foobar can dither, but it seems a bit of a waste of disk space..

when I started compressing my CDs as lossless audio files, FLAC was the most widely spread format which also worked on my mobile "MP3" player, so there was no choice.

These days, as I find myself mainly listening to music on my laptop and my smartphone (with headphones), I'm not sure if I should try TAK instead. (Admittedly, TAK support for my music playing app is still "planned".) How's the common conception for this?