Decoding and editing CloneCDs x.sub and .ccd files

If I compare “usual” 2448 ISOs (as ex. Gamejack or Discjuggler) with the Clone CDs “splitted” *.img and *.sub file I have very big subchannel bytes differences.

As example:
The “first” 00 02 01 02 sector at DiscJ. (same in Gamej.) has the following format:

00 40 00 00 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 40 -23x 00s- 40 -22x 00s- 00 00 00 00 00 00 00 00 40 40 00 00 40 00 00 40 00 00 40 00 00 00 00 40 00

But the "first 96 bytes of Clone CDs sub file of the same CDs ISO look like:

41 01 01 00 00 00 00 00 02 00 28 32 -84x 00s-

This is really confusing! Why CloneCd can’t use the 2448 format?
Please can someone explain to me the format, and how to convert it from one to the other, and does exist a program which ich able to convert the 2 formats ?!

My second question:

Is ist possible to edit the .ccd file to create “special” pregaps??

As ex:

[Session 1]

Or other values?! I try to burn special pregaps with edited data, but at the moment its not possible with CloneCD. My idea is: Making the LEAD-IN pointing to a special “after pregap time”, but burn the 1st “pregap” intentionally together with the usual ISO. So eventually there’s a way to set the values for writing the Pregap to zero, but leaving the Lead-In values as usual!

CU, Sam

CloneCD does uses 2448 format. .img is 2352 bytes per sector and .sub is 96 bytes per setor, making a total of 2448 bytes.

The 2448 ISO you mentioned stores the .subs in interlaced format same as on the CD, while CloneCD stores the .subs after deinterlacing them in groups of 24 bytes for each sub-code. The deinterlaced format is actually better for looking because you will be able to see the information plainly. You can find a little more info in the MMC specs.

Some info (in laymans term) about format of sub-code:

As defined in red book, they have created 8 BITs (also known as 8 sub-channels) to represent sub-codes called: P, Q, R, S, T, U, V, W

In a sector there are 12 bytes of each sub-code making a total of 12 x 8 = 96 bytes.

Interlaced format

On the CD the subcodes are stored in interlaced format (I’m ignoring sector scrambling) which is written like this:

P, Q, R, S, T, U, V, W,
P, Q, R, S, T, U, V, W,
P, Q, R, S, T, U, V, W,

12 times

You can see that they are written with a P BIT first then a Q BIT then a R BIT, and so on repeating.

De-interlaced format

The information is useful only if we de-interlace them - meaning if we group the sub-codes together, i.e. group P codes together, group Q codes together, and so on.

The sub-codes are in bytes so 8 BITs need to be grouped together for each sub-code. Note, the first P sub-code BIT represents BIT 7 (MSB) of a byte, the next BIT 6, etc.

Here is an illustration:

As before interlaced format:

P1, Q1, R1, S1, T1, U1, V1, W1,
P2, Q2, R2, S2, T2, U2, V2, W2,
P3, Q3, R3, S3, T3, U3, V3, W3,

12 times

De-interlaced format:

P1, P2, P3, P4, P5, P6, P7
Q1, Q2, Q3, Q4, Q5, Q6, Q7
R1, R2, R3, R4, R5, R6, R8

12 times

I hope the info above is accurate. Any corrections are appreciated.

Anyone upto the challenge of writing a code for the conversion?

I have written one but it’s in Delphi.

WOW! Fantastic information! Thx alot!!

CU, Sam

Are there exist some tables to calculate the bits-bytes interleaved-deinterleaved?

And do exist some descriptions of the different values and variables of the *.ccd file?