CIRC encoding/decoding

CD, DVD and (Ultra HD) Blu-ray Writers
#1

I try to write software to CIRC encode and decode Sectors. Has anybody done this before, does anybody know free source code that does the job?

Particularly I have a problem with figure C.1 of the EMCA.130 document. It really helps looking at this figure if you read any further.

In a first step half of the bytes from an F1 Frame are feed in Delay Elements.
Then 4 Q Parity Bytes are calculated…

The Question is, if you start Circ encoding, what values are used to claculate the Q Parity bits. Since this is the first F1 Frame for encoding there are no delayed bytes from previous Frames.
Do the delay elements return 0 if there are no previous bytes?

Did I totaly misunderstand the CIRC encoding?

I hope someone can help.

#2

I have written code that does at least the decoding part (error checking, not error correction yet), and I could probably also provide encoding (this is quite simple).

The main attraction is that one needs to be able to calculate in GF(2^8). Adding is just a XOR, but multiplying is slightly involved; it can be implemented using exponent/logarithm tables for GF(2^8).

Particularly I have a problem with figure C.1 of the EMCA.130 document. It really helps looking at this figure if you read any further.

In a first step half of the bytes from an F1 Frame are feed in Delay Elements.
Then 4 Q Parity Bytes are calculated…

The Question is, if you start Circ encoding, what values are used to claculate the Q Parity bits. Since this is the first F1 Frame for encoding there are no delayed bytes from previous Frames.
Do the delay elements return 0 if there are no previous bytes?

Did I totaly misunderstand the CIRC encoding?

No, you are right. The situation for P-parity is even worse, by the way: you will have to emit P values that depends on data that was from >100 frames ago.

I suspect you are right that you can presume zeros; this is probably one reason why a CD has a “lead-in” area.

In fact, I am in the process of rigging a CD player to get access to the raw channel to answer this kind of questions. I already collected very small samples (0.1 seconds) of raw channel data which has helped me to understand the encoding and helped to verify my CIRC checker; you may want to read the “Offset handling (syncing of audio data vs. Q channel)” and “What makes CD-DA different from CD-ROM” threads to get some info on this work.

Regards, Sidney

#3

Hello!

I am in the process of developing CDG software and hence attempt to read raw subchannel data. MMC docs say that the data is protected by Reed-Solomon error-correction code.

Truly there are parity bytes 4 for 24 block and 2 for the first two symbols. But as far as I understand the algorithm this information is not enough to fix the errors, parity bits allow only detecting the wrong. One would also need error location information.

For audio data one can read error information explicitly, but what about subchannels? Is it possible at all? How can one perform error correction for raw subchannels?

BTW, there’s a useful library for RS error correction:

http://rscode.sourceforge.net/

Taras

#4

That depends on which subchannel you’re talking about.

The P-channel should contain all-zero or all-one data for any given sector.

The R/S/T/U/V/W channels are zero for the majority of CD’s; I’d have to look in to other uses for more info on possible error correction / detection.

Which leaves the Q channel. It is protected by a 16-bit CRC value. Usually, CRC’s are used only for error detection; but in principle, they can be used for error correction as well. Simply try all possible error vectors (starting with single-error, then two-errors-per-sector, etc.) and wait until you see a sector that yields a correct CRC value. In case of ties, it is often possible to decide which of the possible corrections is the right one by looking at contexst (e.g. preceding/following sectors).

Regards, Sidney

#5

Thanks for the reply. I meant R-W subchannels for I develop CDG stuff. I would appreciate your hints about error detection and correction for these data.

Taras

#6

thank you for the replies!

@ reddish:

You have a very interesting project!!
I will check the appropriate threads for updates.

#7

I haven’t got access to the relevant standards describing the encoding I’m afraid, so I cannot help a lot here.

Regards, Sidney

#8

I’ve seen CD+G ripping capable karaoke software that claims to do deinterleave and error correction from RAW R-W subchannel data, it’s supposed to have the same results that when reading packed R-W with the adecuate drive (developers recommend Plextor and Yamaha).

#9

That was a comment inspired by this:

For audio data one can read error information explicitly, but what about subchannels? Is it possible at all? How can one perform error correction for raw subchannels?

And to precise this:

Truly there are parity bytes 4 for 24 block and 2 for the first two symbols. But as far as I understand the algorithm this information is not enough to fix the errors, parity bits allow only detecting the wrong. One would also need error location information.

There’s a little note in MMC fig-11: sizes shown are in 6 bit words. If we do a subcode block RAW read, deinterleave and take just R-W channels data… we’ll be taking 72 bytes (12 for each sub). To translate to packed mode, such 72 bytes are distributed in 4 groups of 24 6-bit words (4246=576 bits=72 bytes).

First 6-bit symbol is used for mode & item selection (3 bits for each one), 2nd symbol is instruction. These two first symbols are guarded by the next two (EDC/ECC Parity Q0/1), then comes 16 symbols for user data, protected by our last 4 symbols (EDC/ECC Parity P0-P3). Two 6-bit symbols are added in front of pack for sync.

#10

What document are you referring to, exactly?

First 6-bit symbol is used for mode & item selection (3 bits for each one), 2nd symbol is instruction. These two first symbols are guarded by the next two (EDC/ECC Parity Q0/1), then comes 16 symbols for user data, protected by our last 4 symbols (EDC/ECC Parity P0-P3). Two 6-bit symbols are added in front of pack for sync.

That is interesting, I haven’t seen any decent technical description of subchannels R–W so far, this could be it. I’d be very interested to read the description myself.

Regards, Sidney

#11

I’ll be happy…

http://t10.org/drafts.htm#mmc-

The R-W description figure is in page 42.

The description doesn’t cover the technique for building data packets (must be in the red book), but maybe your Plextors can do R-W packed mode reading, from which you can do reverse engineering by comparing to conventional P-W RAW read.

#12

Does anyone know where I might find some Sample code that can show information on the Software deinterleave of the r-w codes. I have this correctly working on drives that support inteleaved data, but I am unable to get the r-w code correctly on drives that don’t support this. I now need to finish the Deinterleave part with the Reed Soloman correction. Any help would be greatly apreciated.

Thanks,
Bry21317