I had to backup a CDR that was beginning to be unreadable. Especially the last track.

I used three methods to recover the track :


-Ripping with EAC, secure mode C2 (Sony DDU 1621 drive), then applying deglitch.exe
-Playing in the Sony DDU1621 and recording the SPDIF output with the Marian Soundcard slaved to the digital input
-Playing in the external hifi Yamaha CDX860 CD player and recording the SPDIF output with the Marian soundcard slaved to the digital input.

Both deglitch and the Sony SPDIF output helped reducing the amount of clics compared to the raw wav file read in secure mode (By the way, EAC log : "there were errors" (and a lot !), so the secure mode is not at fault)

But some clicks are still audible.

Only in the recording from the standalone player Yamaha, there was no audible click at all.

This experiments questions the ability of the Sony DDU1621 to perform error correction in analog playback, the better results being possibly explained by the slow reading speed.
There are very few clicks, often barely audible, so it's not easy to test now the analog output of the Sony, or the SPDIF output of other drives, etc, because I'd need to listen to the whole track each time with much care in order to see if there are some audible clicks.

I'll test further when I have a worse Cd to recover. But until then, I'll keep the standalone player at hand

I'd say that the reason for this is that Redbook cd error correction can work better or worse depending on how it's implemented. In cheap cd players, the error correction is not as good as in good cd players. And I'd say that in cd-roms and dvd-roms the error correction algorithms must not be of the best type ones. These drives are optimized for speed and data reading, but Redbook cd reading capability and built-in digital to analog conversion just works because it must, but I'd not expect it to be very good quality.

Isn't it just interpolating between the neighborous samples affected by C2 errors ? Substracting wavs, I get only isolated clicks, no more than one erroneous sample at once. How could they implement this badly ? Repeating the previous sample instead of interpolating ? Arg I don't want to believe this.

Hey, Pio2001, this is an interesting experiment and thanks for checking out DeGlitch. I have found a couple different situations in which DeGlitch does not completely remove all glitches. Speek sent me a sample from a badly scratched CD where a few the glitches exceeded the 1:3 maximum that DeGlitch can handle. Basically, DeGlitch recognizes glitches that fall into one of two patterns:

OOOXOOO or OOOXOXOOO

where O is a good sample and X is a bad sample. However, the sample Speek sent had a few cases like:

OOOXOXOXOOO

and even one or two like:

OOOXOXOXOXOOO

I have been thinking of ways I might be able to handle these, but have been too busy to try them. Of course, it is having such a narrow definition of a “glitch” that makes the program rarely trigger on music.

Another problem I have seen is that sometimes another attempt at C2 correction (by either the drive or the ripper) actually fails and ends up corrupting the data stream so that DeGlitch no longer recognizes the glitch. It might be interesting to rerun your test with all other C2 error correction disabled.

BTW, here is a short sample rip from my scratched copy of Abbey Road that I used when developing DeGlitch and is an example where it works perfectly (at least to my ears). It is a self-extracting WavPack executable:

www.wavpack.com/because.exe

I wouldn’t think that a stand-alone CD player would be any better (or worse) than the CD playing section of a CD-ROM drive at error concealment, but there are a couple of possibilities. One is that the read electronics (and laser assembly, etc.) in the Yamaha is better and so it has a more error-free signal to start with. Another is that some of this error correction and concealment stuff might be done in firmware in the Sony, and when a certain threshold of errors occurs in a short burst, it may simply run out of time and have to let some through.

Also, it may be that above a certain threshold of C2 errors it is no longer possible to know even which samples are bad but just that the block has uncorrected errors. In that case, the player (or drive) would have to use an algorithm like DeGlitch's to guess which samples are bad, and there could be a lot of variation there.

The weather's too hot to test anything right now !

[img]1717ef235d[/img]

Hmmm... disturbing thought that C2 might not be as bulletproof as expected! Will be interesting to see what gets revealed here..

Here's a wierd thought.. if you're really desperate to restore that CD, you could try a de click processor (like us crazy LP-CD recording guys use) to clean the wav, then burn it back onto disk. It probably would work extremely well on very sharp, short, similar clicks like you describe.. "real" LP clicks vary hugely in size and character.

Let me know if you need any program suggestions..

The matter of C2 accuracy was discussed there : best drive for ripping?

Here, it's a different matter : I start from an extraction where EAC told "there were errors", properly detected with C2. It means uncorrectable errors, therefore glitches.

I sometimes tried the noise reduction plugin of soundForge on scratched CDs, but it does a poor job, it doesn't detect small clics.

For this track, no problem, I got it right copying it from a standalone player. Thanks.