do lossless codecs ever screw up? if so, how often?

I've never heard of a lossless encoder screwing up, but a lossless encoding (just like any encoding) could become corrupted as a result of a hardware or system problem.

And if a CD is damaged, then it's resulting data after extraction may be damaged as well (unless the ripper is able to correct the errors). But a lossless encoding of such an extracted file would be encoded exactly as it exists, errors and all.

Maybe someone else has experience with an actual error that's the fault of a lossless encoder.

My experience is with FLAC, Monkey's Audio, WavPack Lossless and WMA Lossless.

I've never experienced any problem with an encoder. As I understand it, it's physically impossible for an encoder to make a mistake (unless a bug gets placed into the programming code, extremely unlikely on a matured lossless codec). However, ScorLibran is right in that they can become corrupt to due to hard drive/CD/DVD fault. This is why you should keep backups (for me, lossless files stored on hard drive with DVD backups stored in a dry, no sunlight environment).

I don't recall a real problem with a lossless encoder but overclocked CPUs tend to cause problems (=outputs bad data).

If you encode to lossless, I'd always perform a verify run after encoding, i.e. add "--verify" or "-V" to your command line when you encode to flac.



When the verify ends up flawless, you can be sure, that nothing went wrong during encoding. Consider also to add a checksum file, like md5 or sha1 to run a quick test from time to time. If errors are detected, par2 files can repair dropouts.

That's right, but overclocked (i.e. overclocked beyond the CPU's capabilities) CPUs tend to cause all sorts of problems, as they basically act as damaged CPUs, especially under heavy load. This effect, however, is not specific to lossless encoders, even though lossless encoders might be especially sensitive to it, just like some other applications. I don't know whether this is the case, but it's quite possible, because lossless encoders typically produce full CPU load.

Seen as lossless codecs inevitably take more data than lossly ones coding for the same given audio source, recording defenition etc. this actually makes lossless coded files more susseptible to errors than lossy ones per music time encoded given that errors are likely to occur at an consistent errors per data rate over enough data (storage, transfer errors and whatnot, don't forget cosmic rays). True it's not likely to happen very often (you may never hear the effects in your lifetime), but on a large enough data set it becomes inevitbale, even if it's at that moment 'in silico' even when not overclocked. I'm pretty sure a standard non-overclocked cpu can make mistakes from (very rare) time to time. Otherwise Nasa wouldn't spend so much on data-redundancy

Haven't heard of a case where any data have been lost, just problems with seeking in flac, now fixed in cvs:
http://www.hydrogenaudio.org/forums/index....showtopic=19197
http://www.hydrogenaudio.org/forums/index....showtopic=16699

well, since I'm primarily an ape user (best compression, better integration into EAC than FLAC), I'm a bit curious about its issues.

Monkey's audio is great for detecting bad RAM -- on my older system it kept generating corrupt files. Lo and behold, I ran memtest86 and it turned out I had some bad SDRAM.