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 don't see the point. EAC makes rips secure by lowering speed and reading the same position several times. The virtual drive doesn't contain information about the output of the real drive + original cd with different extraction speeds. Besides this your method might help to extract audio from copy protected CDs - but why not extract from the .ccd image directly using CDMage for example?

Just wanted to say that using your method, the "test & copy" is completely useless, because the reading process from virtual drive is deterministic (ie: identical result each time).

By the way, I don't think you really get more secure audio extraction than EAC burst mode, here.

Cheers

EDIT: Depending on how exactly CloneCD reads the cd, it might be possible to get perfect results even with scratched cd's - though not as secure as regular EAC w/ test&copy... in all cases this would need investigation :-)

Um... Yeah, it works, but what good will it do?

The point of using EAC is mostly accurate ripping, since correctly ripping an audio CD is complicated. With your method, CloneCD will have to do the audio extraction which will be less secure than what EAC offers. When CloneCD emulates the drive and the medium it contains, it does so in a perfect manner. i.e. you tell the drive "read sector 23" and it will give you exactly what is present in the image each and every time. The virtual drive doesn't have to battle with exact positioning of the laser or scratches on the CD. And why test&copy? Basically you are reading a file from your HDD, presented in a way that it seems to be coming from a CD-Rom. Do you expect that file to change over time?

This method may be usefull to rip copy protected CDs but the weak link is the insecure audio extraction of CloneCD.

Gecko: Do you know at what level does EAC read the audio data ? I mean, as long as the subchannel is included in the image, it should be easy to detect any positioning errors during RAW extraction, am I wrong ?

In other words: ultimately, if it were possible to request the RAW ANALOG LASER DIODE INPUT data from the drive, we could rip accurately in a single pass, always, couldn't we
Then, all filtering of the analog data would be performed by the CPU..

Well that's utopia I know, since we can't access the analog or even "below-C1" level... But still, the lower level of CloneCD extraction, the better...

My question is, what does RAW reading exactly mean ? The whole subchannel data (including positionning info !!) should be returned by the drive, shouldn't it ? In that case, with proper processing of the CloneCD image, there should be no need to read the source CD twice (unless we find jitter or unrecoverable errors) B)

EDIT: clearer answer.

CloneCD can make perfect 1:1 copies of any cd, given you have a capable burner, which I do (Lite-On). I keep all my music in the best condition possible, so I am not worried of any scratches. So what I do is create a CloneCD image which is a perfect 1:1 copy, and that is a fast process, only a few minutes. And then I rip from the image in EAC which is also very fast. I only used test & copy in the aforementioned case only to prove the speed of the whole process. If I have a perfect 1:1 image of a CD on my fast hard drive, why not rip from that instead of a CD? I have yet to hear anything wrong with any of the encodes I've done.

EDIT: all subchannel info, cd-text, etc. is included in these images

If this is enough for you, why don't you use eac burst mode or other (fast) audio extraction software?

IMO the reason to use eac secure test & copy is to have objective 99.99% security that there are no errors (at least on CDs without copy protection) and you won't get that with CloneCD (see previous posts).

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.

bman1: CloneCD can NOT make perfect copies of audio CDs because of the aforementioned weaknesses of audio CDs. Don't you think someone would allready have implemented raw audio extraction, if it gave perfect results? Why would EAC, cdparanoi etc. make such a fuss about circumventing the cache and reading each sector twice, if it were that easy? I imagine direct raw extraction to be quite simple (if the drive supports it). The reason why none of your rips sound bad is probably because your CDs are in good condition, and your drive has solid audio extraction capabilities.

As a matter of fact, you're certainly right. The subchannel info does NOT contain enough info

Would have been too beautiful...

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.

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

CloneCD has worked marvelously for any CD's I copy. It has copied many game CD's that many other burners can't.

The mounted image (ie: Virtual CD) behaving exactly like an original CD, can be true ONLY if the cd isn't scratched. This is because during extraction, CloneCD CANNOT "see" the EFM and C1 error correction layers. Thus the drive corrects most errors by itself, before CloneCD even gets its hands on the data !

So, your image contents has already been processed (and possible corrected) by the original drive's C1 layer. There's nothing we can do about it.

I don't know either..


I agree completely with this. But that doesn't mean it's as secure as extracting from a physical CD.

For example, if two 1352-byte sectors get inverted because of the drive's firmware... the inversion will be present in the CloneCD image, and upon extraction with EAC, all C2 info should match, so the resulting WAV file would be wrong.

In secure mode, with the original CD this error would be detected immediately.

Otherwise, I admit that if a cdrom drive with decent firmware AND correct clonecd settings (ie: no correction by clonecd) are used, however, then your idea might work.

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

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.

bman1, if you do this test, please describe the CloneCD settings used
This might be interesting to do with Alcohol 120% as well (it includes a cd emulator that supports CloneCD images as input). Maybe we could even try to make the image using A.120%.

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.

When you extract from the virtual CD with EAC not only do you have to trust EAC, you also have to trust CloneCD's ripping, and the correct funtionality of your virtual drive. Using CDMage is the more direct method since you are circumventing the virtual drive which wraps up your image file to make it look like a CD again. My personal experience with virtual CD software shows that it is not easy to correctly emulate a CD drive. All that CDMage has to do, is copy the desired data out of the image file into a new file. You don't have to do any additional processing to ensure that the read data is actually the same data as in the image file. 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.

Yes.


Exactly.


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.

If you don't want ANY C2 error correction on audio, I think (but not sure atm) that you can either use the DATA profile, or customize the AUDIO profile for that matter.

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

Gee, this thread grows fast.

Gecko, I don't understand a few things.

I'll try to keep it VERY simple: In secure mode, EAC wants to get correct audio data from the drive.

There are three methods I can see to achieve this:
1 - EAC requests the AUDIO data several times (and checks if the result stays the same or not)
2 - EAC requests the AUDIO data, and the error status "flag" from the drive. If the info bit indicates an error, the read operation is re-tried.
3 - EAC requests a RAW 1352-byte sector (including AUDIO + C2 ECC info), then check everything by itself.

Could you please tell me which one of those three methods, does NOT exist in EAC ?

More precisely, when ENABLING "drive capable of c2 error correction reporting", which method is used ? "2" or "3" ?

It seems to me that, in all cases, "method 3" would be PERFECT for use with a virtual drive.

By the way: I don't think there's a chance of C2 missing a single error ! I mean, by using a simple 32-bit CRC, the probability is already 1/4,000,000 ! With 128 bits, it just CANNOT happen (that's why cryptography is possible btw). So what about the hundreds of bits of C2 ECC ?

Thanks.

That's what I think too. If we're right here, the "clonecd image" method could give great results imho (as long as CloneCD's DAE function doesn't mess with the audio data !!). There is probably a setting to disable all error correction (for audio) in clonecd.


Fortunately, I don't think they can corrupt the C2 data on purpose ! The reason for that, is that almost all standalone cd players try to CORRECT the audio using the C2 info. They use error concealment (ie: interpolation) as a last resort only. Last resort = so many scratches, that 15% reed-solomon redundancy is not enough.

The most nasty things (regarding so-called "copy protection") that I heard of, are corrupted index markers. The index markers are used by cd-rom drives to reach the correct audio data sector, and it's NOT USED by standalones (which just read the audio continuously). So they just corrupt that part of the subchannel data sometimes.

By the way, the "CloneCD method" would be immune to these kinds of tricks

Gecko, I took the liberty of posting your interesting PM answer, for comments. I hope you don't mind.


Well, to me you make perfect sense ! I agree with everything you just said.

But then again, what about REAL "raw reading by the drive" ?!?? If our belief is correct, it means that real, genuine "RAW" audio reading is not possible on cd-rom hardware, which would be a shame... So, I hope we're wrong !


Good idea

EDIT: just a small correction: C2 is not only a checksum; it is Reed-solomon based ECC, which enables both detection (with a very high probability) and - if needed - correction up to a maximum number of recovered samples. Very similar techniques are used by SmartPAR, FSRaid and the new RAR 3.0.

A quote from Pio2001 - can be found on: http://www.digital-inn.de/showthread.php?threadid=9805


Gecko, it seems like "method 2" is used. So, it is the responsibility of the cd drive to perform the C1+C2 processes. For this reason, IT IS NOT POSSIBLE to perform proper EAC extraction on a non-perfectly-extracted CloneCD audio image.

In other words, EAC is useless on CloneCD images. CDMage does the same job.

Conclusion: better not use CloneCD - at least not until it becomes better than EAC

Good try bman1

Lemme see if I understand what is going on...

on a data cd, when you ask the drive for a block, it will either give you the block without errors, or give you a message that the block is faulty...

on an audio cd, when you ask for a block, the cd will give you the block, and if you ask again, it might give you a different result for the same block (since there is supposedly no error detection/correction). that is why you need various passes with audio data... to get the "real" data that is supposed to be stored

that is why CloneCD won't work as well as EAC for audio ripping. because it only does one pass.

am i right?

It's not that simple.

On a data cd, the errors will be reported correctly by the drive (althrough problems CAN happen with bad drives).
On an audio cd, the drive is *supposed* to report all C2 errors, without concealing them. This is the theory only, and we know how it is in practice.

So in theory, with a perfect audio-reading cdrom drive, you could extract ANY VALID, BUT SCRATCHED AUDIO TRACK properly in one pass (or get an error - in case the media is unreadable).

In practice, you can read the audio data several times, to try to compensate in case a non-reported C2 error happens.

Sorry, this weekend my computer broke. I've just repaired it, and spent half an hour answering you.

I don't know what key I've just touched, but Internet Explorer went back to the previous page, and all I've typed is lost.

I'm going to bed

bman, sorry, but clonecd doesn't make 1:1 copies, or even better copies than EAC, of *audio* CDs. Its focus is on data CDs, or game CDs and their copy protection more precisely, regardless of what they'll officially say it is for. It does not contain any "secure" reading methods for audio, it's rip quality settings for audio do absolutely nothing but slow down the speed at which it burst-reads.

<edit> you can test it for yourself if you like (or take the word of the author of clonecd for that matter, he stated it doesn't rip anything like EAC does, and only uses burst mode) take a somewhat scratched cd that will not give you matching CRC values in EAC when using burst mode, but will give you matching CRC values when using secure mode. Then rip a track. Copy that CD to an image with clonecd and rip it from a virtual drive as you've described. Chances are slim to none that the wavs will be the same, since clonecd only rips in burst mode.

Oh, no, Pio2001.. I'm sorry to head that :-(

what happened to your computer ?
Cheers

I read through the thread, and noted the following points :

-In the FAQ, the link
Why is not CloneCD advised for audio ?
Is audio extraction different than raw mode ? @CDFreaks
explains that audio extraction is just a plain raw mode, and that CloneCD can't go rawer.

-The C2 information is not in the subchannels, see the Chip's CD Media Resource Center (in the FAQ too), part Encoding, Frame Structure & Error Correction . In one frame, there are 3 bytes of synchronization, 24 bytes of audio data, 4 bytes of C2 error correction, 4 bytes of C1 error correction, and 1 subchannel byte.

-There can't be C2 error correction codes in a virtual drive. C2 codes can't be accessed from outside the drive. They must not be mistaken for the C2 flags read by EAC, that just say if a byte was right or wrong according to internal C2 error correction.

-EAC can't access below the C1 level, nor below the C2 one. It can't even access the C2 level itself, it can only read the final wav data and the C2 flags that come with them.
In each sector, there are 2352 raw bytes. Besides the 12 sync bytes and the 4 header bytes, all of them are just audio bytes, as they appear in a WAV file. There is not the slightest error correction information in them, not C1, nor C2. The optional C2 flags come in addition.
In a CD ROM, there are only 2048 bytes of user data, and 276 bytes for an additional layer of error correction (plus 28 bytes of sync, header, EDC, etc). That's why when you rip a 74 minutes CD, you get 740 MB of audio wav files, instead of just 650 MB, that is the capacity of the CDR for ROM data. When CloneCD reads in raw mode, it reads all the 2352 bytes, including error correction codes for CD ROM, instead of just reading the user data. The error correction used in audio is the standard error correction for all CDs (NRZ+EFM+CIRC), that is also present, no more visible than with audio, in CD ROMs.
So, in reality, if we count all the data, until EFM, with all error correction codes (NRZ converts binary into pits and lands, so we can't count in bytes anymore at this level), we have 98 frames per sector, 75 sectors per seconds, 60 seconds per minutes, 74 minutes per CD, thus 32,634,000 frames per CD.
One frame is 24 bytes of data, 4 bytes of C2, 4 bytes of C1, 1 byte of subchannel = 33 bytes.
Each of them is converted into EFM (8 to 14 bits) and 3 merging bits are added : 17 bits per byte. We now have 17x33=561 bits.
There is also a 24 bits sync word, + 3 merging bits. 561+24+3=588 bits. That is 588/8=73.5 bytes.
So the total amount of raw binary data in a 650 MB CD is
32,634,000 x 73.5 = 2,398,599,000 bytes,
Or 2287 MB.

So when you see an image file 2287 MB big coming from a CD, you'll know that you have got all the raw data


-I remember having tested the CloneCD DEA quality long ago, when they improved it... I found some errors in the resulting wav and didn't investigate further

-My drive tests (http://pageperso.aol.fr/lyonpio2001/dae/dae.htm ) were done following Andre Wiethoff's DAEquality setup : all extractions must be performed in burst mode. No secure, nor paranoia mode.

-The messages of mine quoted above is old and wrong : some CD ROM drives do perform error concealment

-Some protected CDs do introduce C2 error. SafeAudio claims to do so. They say that computer drives not performing error concealment, the sound is affected. Andre Wiethoff says that Cactus Datashield 200 also uses C2 errors. But it is difficult to know if a noise in the wav comes from a sync error due to the lack of timing markers, or from a C2 error. It is possible that C2 errors are perfectly interpolated by some CD ROM drives. I saw in my test one hifi player capable of interpolating up to 8 samples, and 4 CD ROM drive capable of interpolating up to 1 sample. It is also possible that SafeAudio C2 errors affect more than 1 sample at once and can only be interpolated by hifi players.

Just that's why I "rip" copy-protected CDs digitally via digital input...

I splitted this topic, people who took part in the other discussion can still find the messages here.

Please keep this thread on topic. Thanks.

Thank you for your most informative messages, Pio2001

To me, pretty much everything seems settled now, except about error concealment of CD-ROM drives.. you mean they might do it, if the C2 wan't capable of correcting everything.. well.. is it (at least) limited to the analog playing mode ? And, do you know if specific cd-rom drive brands/models are known to do it ?

About the intentional C2 errors in Cactus Datashield 200 (and maybe SafeAudio) : well, I'm astonished ! At first, when people started to claim that copy-protection could shorten the life of a CD, i just took it as an "argument" used against "corrupted audio CD's".. but if C2 is involved it's really serious

I mean, when a C2 error happens, most of the time it can be corrected. But to involve "error concealment", they NEED to make the data SO DAMAGED, that C2 fails to recover all the bytes ! Needless to say, the error-correction circuitry is stretched to a maximum ! Then, the remaining destroyed bytes need to be interpolated by the drive..

I don't think there can remain any doubt now, about the non-compliance of such a CD, to the Redbook standard ! I mean, how the heck could they CLAIM it to be compliant, when part of the audio is UNREADABLE (by any means) data ?!?

The worst thing is that, even if it gets interpolated decently (and without the player skipping), the SLIGHTEST scratch will make nearby samples unrecoverable too... and the problems would most certainly get very audible

This is disgusting, isn't it.

Thanks for the information, Pio, that was very helpfull. Oh yeah, and thx for splitting this thread.

The kind of copy protection that uses intentional errors makes me sick as well. (Well, any type of copy protection actually ) There is some kind of "cd quality test" in the Plextools package. I once ran a copy protected disc through that test and found an uncountable number of errors.

I learned the fact that they do here :

How does reading twice allows EAC to detect errors
Discussion reliability DAEquality test @EAC

...and tested the first drive.
Then, I also tested my other drives. The error concealment results are in this page : http://pageperso.aol.fr/lyonpio2001/dae/in...terpolation.htm

The drives were tested in audio extraction mode, plus SPDIF output for the Memorex, but there was no difference between the "analog" playback (through the digital output ) and the extraction mode.



The specifications say that no C2 error (no E32 error, in fact) must occur. Therefore such CDs are actually outside specifications.
The error correction shouldn't be too much stretched, since only one error at a time is created.
To affect the minimal amount of samples, one must take into account the variety of chipsets used is drives.

If we stick to original specifications, we can generate just an E32 error. 3 C2 bytes must be destroyed, creating 2 or 3 unreadable mono samples. 6 stereo samples are then left without C2 error correction, but they are interleaved, and their neighbours always benefit from complete error correction.
It also leaves three C1 frames without C1 error correction, who in turn generate 72 samples with only C2 error correction.

But thanks to the chipsets used, all the drives I tested are capable of correcting such a C2 error anyway, without needing interpolation.

Now, if they want the sample to be unreadable on any drive, it must be an E52 error : 5 C2 bytes destroyed; 6 samples without C2 error correction, but with all neighbours in perfect shape (with all their error correction); 5 C1 frames affected, but only 5 wrong bytes in them, thus at most 25 samples with only C2 error correction (no C1).

Wether these samples are neighbours, or if bytes are combined into samples, depends on how the error is chosen.