Windows – CD-ROM subchannel is different when dumping the same disc

clonecdcompact-discdisk-imageoptical-drivewindows

I'm making backup copies of old video games with CloneCD 5.3.3.0 on my Windows 10 x64 computer with a Samsung SH-S223L drive.

One of them is Hellfire for PC (Diablo 1 expansion):

  • The disc has a COMPACT disc DATA STORAGE logo
  • Serial number: S0011770
  • Factory SID-Code: IFPI 1218
  • CD-Master SID-Code: IFPI L032
  • ISO 9660 PVD creation date: 1997-11-18 16:30:00.00

I use the redump.org CloneCD profile recommendation:

[CloneCD ReadPrefs]
ReadSubData=1
RegenerateData=0
ReadSubAudio=1
AbortOnReadError=0
FastErrorSkip=0
ReadSpeedData=8
ReadSpeedAudio=8
IntelligentBadSectorScan=1
SectorSkip=1
NoErrorReport=0
FirstSessionOnly=0
AudioQuality=3

As far as I know the game has no protection but when I dump the disc twice I end up with different subchannel files (.sub). The .ccd and .img files are identical, only the .sub differs, I used SHA1 checksums and a hex editor to verify this.
I uploaded two .sub file dumps here.
I have to mention that I own two copies of this disc and the behavior is identical with both discs.

I also dumped several other CD-ROM media, sometimes I get this behaviour sometimes the subchannel is consistent across dumps.

What is the explanation of this behaviour?

Edit:

I dumped the same CD-ROM again with a Lite-On iH124-14 drive and I see the same behaviour (different .sub files).
I also checked the medium for errors with KProbe 2 and I get the following result:

KProbe 2 BLER scan

Edit:

It seems that the disc condition and/or the lack of precision of the drive added to the fact that subchannel does not have error control mechanism (except Q channel) explains why I get different .sub files when dumping the same medium multiple times.

I have to mention I also got a Plextor PX-712A drive and managed to get consistent .sub files across dumps by using Disc Image Creator. This software leverages 0xD8 instructions instead of 0xBE instructions to read the disc, resulting in more accurate images. Only a few drives (mostly Plextor) support this instruction.

Also I actually own two physical copies of this CD-ROM I'm dumping (same serial number, same IFPI codes and same laser engraved information).
If I dump the same disc multiple times with Disc Image Creator I get consistent .sub files but not if I dump the first disc and then the second disc.
I guess it's related to the media conditions since one of them has a few scratches and more C1/C2 errors.

Best Answer

The various CD formats are a bit involved, and the official specifications ("red book" for audio CD, "yellow book" for data CD) are not freely available. But you can find some details in available standards like Ecma-130.

The original audio CD (also called CD-DA) was modelled on the vinyl record, which means it also uses is a spiral track of continous audio data (the DVD later used circular tracks). Interleaved within this audio data in a very complex way are 8 subchannels (P to W), of which the Q subchannel contains timing information (literally in minutes/seconds/fractions of seconds) and the current track number. For the original purpose this was enough: For continous play, the lens was just adjusted slightly to follow the track. To seek, the lens would move while decoding the Q subchannel until the right track was found. This positioning is a bit coarse, but completely adequate to listen to music.

Still today, many computer CD drives cannot completely accurately position the lens and synchronize the decoding circuitry so that reading of audio samples starts at an exact position. This is why many CD ripping programs have a "paranoia" mode, where they do overlapping reads and compare the results to adjust for this "jitter". As part of the audio stream, the subchannel is also subject to jitter, and that is why you get different subchannel files when you rip on a CD drive that cannot position accurately.

When the data CD (CD-ROM) specification was developed to extend the CD-DA specification, the importantance to accurately address and read data was recognized, so the audio frame of 2352 byte was subdivided into 12 sync bytes and 4 header bytes (for the sector address), leaving the remaining 2336 bytes for data and an additional level of error correction. Using this scheme, sectors can be addressed exactly without having to rely on the Q channel information only. Therefore the jitter effect doesn't apply, you get always the same data when you dump a CD-ROM, and no additional cleverness in dumping is needed.

Edit with more details:

According to Ecma-130, the data is scrambled in stages: 24 bytes make up an F1-Frame, the bytes of 106 of these frames are distributed into 106 F2-Frames, which get 8 extra bytes of error correction. Those frames in turn each get an extra byte ("control byte") to make them into F3-Frames. The extra byte contains the subchannel information (one subchannel for each bit position). A group of 98 F3-Frames is called a section, and the 98 associated control bytes contain two sync bytes and 96 bytes of real subchannel data. The Q subchannel in addition has 16 bits of CRC error correction in those 96 bits.

The idea behind this is to distribute data on the surface of the disk in such a manner that scratches, dirt etc. don't affect a lot of continous bits, so the error correction can recover the lost data as long is the scratches are not too big.

As a consequence, the CD drive hardware needs to read a complete section after repositioning the lens to find out where it is in the data stream. The descrambling of the various stages is done by hardware, which needs to sync itself to the 2 sync bytes in control-byte stream. All CD drive models need a different amount of time to sync compared to other models (you can test that by reading from two different drives, if you have them), depending how the hardware is implemented. Also, many models don't always take the exact same time to sync, so they can start a little early or late, and output the descrambled data not always at the same byte.

So when the ripping program issues a READ CD (0xBE) command, it supplies a transfer length and a start address (or rather, Q-channel time). The drive positions the lens, descrambles the frames, extracts the Q-channel, compares the time, and when it finds the correct time, it starts to transfer. This transfer doesn't always begin at the same byte as explained above, so the result of multiple READ CD commands may be shifted against each other. That's why you see different subchannel files from your ripper.

Depending on the hardware and the circumstances when the lens is adjusted, it's more or less random if the transfer starts a few samples early or a few samples late. So the only pattern you'll see in the results is that the shifts are a multiple of the transfer length.

Some drive models actually have accurate hardware which will always start transfer at the same time. The standard defines a bit in mode page 0x2a ("CD/DVD Capabilities and Mechanical Status Page") which indicates if that is the case, but real-world experience shows that some drives claiming to be exact are in fact not. (Under Linux, you can use sg_modes from the sg3-utiles package to read the mode pages, I don't know what tool to use under Windows).

Related Question