Cactus Data Shield: no-C2 secure mode vs DbD mode?

[Porcus]

I have finally started to rip those pesky silver discs (not many, this s**t only enters my collection by mistake). Some of them have the Cactus Data Shield, and of course ended up with all errors when attempting to rip in a normal mode (the 26 frame error message usually displayed when the disc is damaged beyond repair, a fitting description ... OK, I'll stop ranting).

To the matter:
Some web searching reveals that people have successfully ripped CDS discs with EAC by simply turning off C2. Which brings me to the question: which mode is "best" in dBpoweramp -- normal ultra-secure ripping with C2 off as long as it works, or the DbD mode, which seems to be a just a simple rip?

Indeed I suspect the latter to coincide with burst mode for these CDs?
(Spoon, can you confirm?)

[Spoon]

You canot guess which is the best, each different drive will react differently to those discs, so you need software + capable drive to read past the various protections (if you see the Defective by design settings page it describes the different protections in place and what is needed to overcome them).

[Porcus]

And as for my question, that's a trade secret? ;-)

[Spoon]

DbD will can use c2 also. There should be no real reason why you would get better results with c2 off, after all it is just a reporting method (reporting the error), that is not to say some drives cannot read those discs with c2 on.

[neslekkim]

But... you need to turn off C2, right?, since that is the idea with the Cactus protection, there is noise in the C2, which makes C2 aware drives incapable of reading those discs.
Old cd-audio players did not use C2, it was beeing used on cdplayers for computes since C2 makes more sense there, and therefore also giving us the problem with difficulty to rip those cd's.

I'm not sure why, but I cannot make dbPoweramp to rip these, but CDEX did, ok, it took a while, but it did. Also reads, and hears from other that EAC will ripp these, takes forever but it will be ripped.

So, how can we do it, if possible with dbPoweramp?, I guess C2 must be off, drive speed turned down, buffer turned off, sectors needs to be repeatedly ripped and compared?, or something?, to find out what could be an "good" rip?, exactly rip I guess will be impossible, but atleast, if we can get rips that is without hearable glitches, I'm fine.

Guess I have to rebuild my old computer with cdex, or try EAC.
This is the cdex for those who are unaware:
http://cdexos.sourceforge.net/
It's kinda old, does not look like it would like my Vista 64bit computer, and certainly I will not try, I have had my share of driver issues so no more at this time.

[EliC]

My understanding of Cactus is that there are intentional errors on the disc. Interprolation can be used to "cover up" these errors. The discs can be ripped accurately, but since they have intentional errors, consistent across all discs, then the resulting rips will have clicks/pops/spikes.

Spoon, would it be possible to create a DSP to look for these types of sound artifacts in a rip?

[Spoon]

It would have to be done with c2 as only that can detect these errors.

[EliC]

from wikipedia
Interpretation of Corrupted Data

An old-fashioned CD player reading subcode correctly sees a missing audio frame and interpolates any missing information that it cannot correct using information from neighbouring frames. Because these missing frames occur at points where the waveform was nearly a straight line anyway, this interpolation is very accurate and generally transparent to the user.

What happens with computer drives is very specific to the hardware and firmware of the drive in question, assuming they have at least seen past the second data session and can play the audio session.

Some older drives simply ignore the subcode and "play" the data frames, resulting in loud audio glitches. Some are overwhelmed by the number of errors needing correction and interpolation, and these drives may then output occasional glitches. Ripping at the drive's minimum speed can reduce or eliminate this effect.

The majority of new drives can successfully correct and interpolate all missing audio even at maximum ripping speeds.

Shouldn't these errors have a signature sound that may be recognizable. Analyzing the audio should be able to detect this. It would be easy to accidentally rip a disc and not know you are ripping a CDS disc. A DSP that recognized these characteristic errors would be nice to let users know that they may need to use DBD.

[EliC]

Spoon, depending on the drive, is the software able to know what the subcode is that has been read? The "signature" according to the entry above, would be data frames in the middle of audio. If the drive is able to read the subcode and this is passed to the software this is a pretty clear signature for CDS.

[Spoon]

No because only the drive reads such low level stuff, a program only has c2 pointers to go off.

[EliC]

Originally Posted by Spoon

No because only the drive reads such low level stuff, a program only has c2 pointers to go off.

Spoon, I don't think you are correct about this. In fact many different software packages read subcode. After a search I believe this is how discjuggler and clonecd work.

[Spoon]

You can read the subcodes, but they contain nothing of the quality of the audio, it is timing, cd-text, etc in these subcodes.

[EliC]

yes, but don't the subcodes also identify the data as either AUDIO or DATA? CDS has bad audio data, that the subcodes identify as data, so an audio only player will see the subcode, say "i don't play data", interprolate the frame, and move on. A CD-Rom drive may try to rip the DATA as AUDIO and that is why the rips are bad.

[EliC]

I have been asking about this over at CDFreaks to try to get a better understanding:

http://club.cdfreaks.com/f52/audio-cd-subcode-299815/

I know these discs are no longer made, but it sounds like they should be easily detectable and it would be nice if dBpoweramp could have an option to say that a CDS disc is detected. This is important because users don't have time to listen to each rip when doing many discs. It would also be helpful for users of the batch ripper to identify these discs. It sounds like it would probably be very easy to implement.