While upgrading my CloneCD to the latest version, I saw that the newest version includes a VirtualDrive program.  It creates a fake drive in which you can mount CloneCD images and use them as if they were an actual CD-ROM drive.  I made an image of an audio CD and used the VirtualDrive to rip from the image in EAC.  Using Accurate Stream with test & copy it took me about 5 minutes for the full length CD!!!  Now granted, I do have a fast hard drive, Western Digital 8mb cache, but it should still be faster for most people than actually ripping from the CD.

I keep all my music in the best condition possible, so I am not worried of any scratches. ... I have yet to hear anything wrong with any of the encodes I've done.

Numlock: I don't.  But since EAC can use C2 error information which is stored in the subchannel data... I also don't know the difference between the individual DAE quality settings in CloneCD.

However I think that absolute raw reading won't overcome problems like correct positioning of the laser, dust or scratches. Audio CDs weren't designed to allow accurate seeking and accurate reading (i.e. error detection/correction) so having all the subchannel data won't help, since it is not sufficient to determine the correctness of a rip.

The images contain are perfect copies containing all subchannel info, cd-text, etc.  And EAC treats it just like any normal CD-ROM drive, it slows down extraction if need be, performs error correction where needed, detects gaps, etc.  I have not noticed anything that would leave me to believe this method is inferior to ripping from the CD in EAC.  This way is just much faster for me.  EAC treats it like a real CD, that's why I trust EAC's extraction over something like CDMage.  Who knows, maybe this all is a big waste of time , it's just something I'm fooling with right now.

I also don't know the difference between the individual DAE quality settings in CloneCD.

EAC treats it like a real CD, that's why I trust EAC's extraction over something like CDMage.

I have not noticed anything that would leave me to believe this method is inferior to ripping from the CD in EAC.

If you are insterested, you can try to detect the error correction and error concealment abilities of your drives following my method : http://pageperso.aol.fr/lyonpio2001/dae/dae.htm
It's not finished yet, but it can be useful here.
The way to detect the error correction strategy is explained in appendix 2. You don't need to understand all the calculus. All you need is understanding how to run Andre Wiethoff's DAEquality package, and download the calculated patterns at the end of part 3.3 of the appendix 2 of my page.

You could do Pio2001's test he mentioned in this thread to find out if there are differences between EAC extracting from a real drive, EAC extracting from a virtual CloneCD drive and CDMage extracting from .ccd image.

@Gecko:  would perfect CD copies be possible at all then?

The emphasis lies on audio CDs. Afaik it is not possible to create a rip and be 100% sure that it is correct. You can just tell with a certain propability that it might be correct. This propability is comparably low if you just rip in burst mode. The various tricks used by clever extraction software such as EAC try to raise the probabilty of a correct rip.

Data CDs have extra error detection layers to determine if the byte you just read is correct. The chance of not noticing an incorrect read are extremely unlikely.

The difficult part of the extraction (actually getting the data from CD) was allready done by CloneCD.

I will do all the testing tonight when I get home and report back here.  And btw, CloneCD really doesn't have any settings, just tell it what kind of cd, Audio, Data, Multimedia Audio, etc. thats it.

EDIT: Also, in case you enable "c2 detection" in EAC, you'd have to TRUST Virtual CD - because it will be doing C2 error detection for you. If the C2 errors aren't reported by Virtual CD, you're screwed (ie: EAC will read the same WRONG result from the image, each time it tries).

EDIT2:  Gecko - If I understand it right, when DISABLING "c2 error detection by drive" in EAC, it performs the verification in software ?  That should be reliable, then

No no, I think, on the opposite, the goal is to prevent CloneCD for interpreting the raw data in any way (I don't think that's the default behaviour in the audio profile). Then, we'd only have to trust Virtual CD about returning the data at the correct offset (which I think we can assume), then it's up to EAC, really, to ensure that all ECC info (ie: C2) matches, and that the data is correct.

The problem I see, is if the drive is NOT "accurate stream". In that case, since the audio is already ripped, it would be too late for EAC to fix/detect the problem.

Quote

EDIT: Also, in case you enable "c2 detection" in EAC, you'd have to TRUST Virtual CD - because it will be doing C2 error detection for you. If the C2 errors aren't reported by Virtual CD, you're screwed (ie: EAC will read the same WRONG result from the image, each time it tries).

EDIT2:  Gecko - If I understand it right, when DISABLING "c2 error detection by drive" in EAC, it performs the verification in software ?  That should be reliable, then

AFAIK "use c2 error correction" in EAC works like this: normally EAC would read each sector twice and compare if the result is the same. If you use c2 error correction it only reads the sector once + the c2 information, which is used to determine, if the sector was read correctly. This is problematic in two ways: most drives don't return correct c2 information and even if they do, the chance that the data matches the c2 info but is actually wrong isn't so small as to rely on it.

Using EAC with Virtual CD software does have some benefits though: CDDB support and offset correction, allthough I don't know if CloneCD is "offset free".

Reading in raw mode prevents the drive from doing it's own error correction so you can copy CDs with intentionally false error correction code. I think the question is: is there such a thing as non raw audio extraction? I think that what we call "digital audio extraction" is allready reading in the rawest mode possible, but this is beyond my knowledge.

That could also be the reason why some copy protection schemes work. Some samples are intentionally false and give a buzzing sound when extracted digitally, while your CD player just smooths them out due to error correction. (But then how come some drives can correctly extract these types of CDs?)

I think method 2 is used, but I don't know actually. If method 3 were used, then how come EAC needs to check if the drive properly reported c2 info.

On the other hand, what if method 3 was used and your average drive in reality only reads the actual audio data ignoring the c2 info and calculates it's very own c2 checksum from the data it just read... for conveniance or whatever. That is why you can give EAC an insanely scratched CD and use the "test if drive supports c2" and it still doesn't report a single error.

(Am I making sense?)

About the chance of c2 missing an error: I only read somewhere on this board that it was insecure... perhaps it isn't after all.

Since I can't offer any more knowledge, I have asked PIO to have a look at this thread, hopefully he can help.

When an error occurs, the C1 and C2 processes can recover exactly the info. This occurs inside the drive, and can't be accessed from outside.
The only thing viewable from outside is the C2 flag, that is 'right' or 'wrong'.
'Right' means that either there was no error, either there was a perfectly corrected error.
'Wrong' means that the C2 info couldn't be used to reconstruct the missing data.

From here, the processes of audio playback and audio extraction differs.
Audio extraction stops there, and a wrong data is returned.
Audio playback then perform "error concealment" : wrong data are interpolated from neighborous valid samples. That's why in most cases, a scratched CD clicks when extracted, and doesn't when played.