Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Ripping programs and CloneCD VirtualDrive (Read 12011 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Ripping programs and CloneCD VirtualDrive

Reply #25 –
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?

Ripping programs and CloneCD VirtualDrive

Reply #26 –
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.

Ripping programs and CloneCD VirtualDrive

Reply #27 –
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

Ripping programs and CloneCD VirtualDrive

Reply #28 –
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.

Ripping programs and CloneCD VirtualDrive

Reply #29 –
Quote
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

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

what happened to your computer ? 
Cheers

Ripping programs and CloneCD VirtualDrive

Reply #30 –
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.

Ripping programs and CloneCD VirtualDrive

Reply #31 –
Quote
Pio2001 Posted on Jan 14 2003 - 04:23 AM
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... 

Ripping programs and CloneCD VirtualDrive

Reply #32 –
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.

Ripping programs and CloneCD VirtualDrive

Reply #33 –
Quote
[...]
-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.

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. 

Ripping programs and CloneCD VirtualDrive

Reply #34 –
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.
 

Ripping programs and CloneCD VirtualDrive

Reply #35 –
Quote
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 ?


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.

Quote
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 !  
(...)
I don't think there can remain any doubt now, about the non-compliance of such a CD, to the Redbook standard !  
(...)
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


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.