Subcode differences & error correction

vbimport

#1

As the subject had changed somehow the thread ‘subcode conversion’ thread was split giving this new thread. Truman

Hello to all and thanks for building this very interesting thread.

I wonder how have yannick got those 80 (not 96, not even 98) byte long subcode blocks.

I still haven’t seen a packed subcode block. How should they look like?
Does anybody know of a drive that can read subcode in packed mode?
Please, maybe Truman?

All I can say is that I’ve never managed to obtain two identical subchannel readings (*.SUB file) when reading from the same CD-DA/CD-TEXT.
Is that normal when reading in RAW mode because data isn’t corrected because CD-DA/CD-TEXT format doesn’t carry EDC/ECC in all subchannels?

Now, does a CD+G carry EDC/ECC in R-W subchannels?
Please, maybe taras g?


#2

Only audio data is subjected to Reed-Solomon coding (C1 & C2).

Subcode channel data (channels P…W) are not subjected to interleaving or error protection.

Now it is possible to detect errors in the P subchannel (it should be all-ones or all-zeroes), and also in the Q sub-channel (of the 96 bits of Q-subchannel data in a sector, the last 16 are used as a 16-bit CRC value). In fact, this is probably where the number “80” comes from you asked about (80=96-16), it is the number of information-carrying bits in the Q-subchannel, per sector.

While CRC’s are usually used only to do error detection, it is possible (and not very difficult) to use them for a limited form of error correction as well. This is a matter of trying error vectors with increasing weight (reflecting decreasing probability); starting with the (unique) zero error vector of highest probability (i.e., a perfectly read channel); then the 96 error-vectors with weight one; then the (96*95)/2 vectors with weight two, etcetera. The first one you encounter for which the CRC is correct is the most likely candidate for the original channel data.

Some sophisticated refinements are also possible, e.g. taking into account the “expected” value for the Q channel (e.g., their are 8 bits that are supposed to be zero among the 80 data bits; and it is mostly possible to predict the ABS-TIME, REL-TIME, TRACK, and INDEX fields (etc.). Apart from that, one could take into account the P…W channels as well since they share the same eight-to-fourteen encoding in the channel, so they are very closely correlated. It is quite possible (though not trivial) to use that information to improve the Q channel decoding.

Regards, Sidney


#3

Now it is possible to detect errors in the P subchannel (it should be all-ones or all-zeroes), and also in the Q sub-channel (of the 96 bits of Q-subchannel data in a sector, the last 16 are used as a 16-bit CRC value). In fact, this is probably where the number “80” comes from you asked about (80=96-16), it is the number of information-carrying bits in the Q-subchannel, per sector.

You’re right on that math, but that’s 80 bits for Q and yannick posted two 80 BYTE long subcode blocks. BTW, I’ve seen weird readings (image files) in P (and R-W) channel like “00 00 00 40 00 00 00 00 00 00 00 00” (that was supposed to be just deinterleaved), sometimes even in Q, I see MSF adresses that change from 01:22.45 to 01:32.46, then 01:22.47… I think such P error detection and Q CRC were not implemented (i.e. RAW reading). I guess that R-W channels just have 0s at least during the entire program area.

I’ve just seen that CD+Gs use EDC/ECC for R-W and makes sense. BTW, drive has not to be able to read in packed mode if Karaoke software does the deinterleave and error correction. What method is more likely to be reliable?

Thanks, and Merry Christmas to everyone.


#4

I would guess he’s showing the entire set of 8 subchannel bytes then, without the last 16 bytes (which is a rather strange thing to do).

BTW, I’ve seen weird readings (image files) in P (and R-W) channel like “00 00 00 40 00 00 00 00 00 00 00 00” (that was supposed to be just deinterleaved), sometimes even in Q, I see MSF adresses that change from 01:22.45 to 01:32.46, then 01:22.47… I think such P error detection and Q CRC were not implemented (i.e. RAW reading). I guess that R-W channels just have 0s at least during the entire program area.

Yes, you’re seeing uncorrected single-bit errors - that’s only natural, since the standard prescribes no correction mechanism for the subchannels - only detection.

I’ve just seen that CD+Gs use EDC/ECC for R-W and makes sense. BTW, drive has not to be able to read in packed mode if Karaoke software does the deinterleave and error correction. What method is more likely to be reliable?

I don’t know.

Thanks, and Merry Christmas to everyone.

Likewise! Happy yuletide everyone! :slight_smile:


#5

Hey,

I have the same problem. Subsequent CloneCD reads of the same CD with identical settings, produce different .sub files each time, although 75%-85% of the data is the same. This is annoying me, because my aim is to make 1:1 backups of my audio CDs, and clearly I cannot, because I don’t know which (if any) of the .sub files are correct!

I am assuming that this is unavoidable? I’m thinking of getting a Plex Premium, but if no drive can read 100% identical sub data, I’d be just as well sticking with my Lite-On LTR-52327S.

Any more developments?


#6

Recording software seem to distinguish between drives that can read subchannel and the ones that not, some of them even seem to detail if the reading can be in packed mode or software deinterleave and correction is needed.

Misteriously, until now… I’ve not seen a single drive specs sheet that claim subchannel reading or packaging that show CD+G compatible reading. I suppose they’re only a few (if any). There must be a reason for manufacturers to ommit talking about subchannel reading capabilities in specs or publicity, even when their drives appear to acces such areas (not always in the way we would like).


#7

Wat do you mean by the percentage, exactly?

This is annoying me, because my aim is to make 1:1 backups of my audio CDs, and clearly I cannot, because I don’t know which (if any) of the .sub files are correct!

The .sub mismatch problem is fixeable, in principle. What you’re seeing is mostly random bit errors in the subchannel, which is the one byte out of 33 in each “frame” that is not subjected to Reed-Solomon error correction. However, at the very least for the P and Q channels it is, in principle, possible to fix the vast majority of these errors; the Q channel is the difficult one, and has a 16-bit CRC that could be used for error correction (although it isn’t intended for that).

The bigger problem is the exact matching between subchannels and audio channels. I am trying to use a rigged CD player to get to the bottom of this, but I’ve run into some trouble;it’s not easy to get a couple of megabytes-per-second of information onto my harddisk, it appears, from a simple TTL level probe point. Still working on it - it doesn’t help that I’m a software-guy, not a hardware-guy, by training.

Regards, Sidney


#8

> Wat do you mean by the percentage, exactly?

Well, if I take a look at it two reads of the same subs with a hex editor, the majority of the data is the same; it’s just one or two bytes here which differ, and they’re not usually close together.

My apologies; the percentage was just a rough estimate by myself; I imagine that most of the data of subsequent reads is identical, I’m just curious as to why certain bytes differ every time.

I will find a way to explain this better and post again! Thank you for your help.

> The .sub mismatch problem is fixeable, in principle.

I used CloneCD’s Repair subchannel data option; will this give me accurate copies of my originals?

Anyway, thanks again. :slight_smile:


#9

Are u sure this isn’t to do with your CD, i.e. dirty, scratches (includes fine difficult to see scratches), etc. You should really try out more tests. Also since many audio CDs are now protected with some form of protection - this really makes it hard to analyze. I suggest you try out some clean or new (make sure it doesn’t have protection) CDs first, before blaming your drive.

The reason I say this is because I do have a Lite-On LTR-52327S and I’ve tried this on a clean audio CD (Phil Collins Hits) and I do get identical .sub clone files.

Update: I’m surprise I do get different subs with my older LiteOn 24102B. But the newer Lite-On LTR-52327S is fine.


#10

Ok. To answer the latter question: to the laser, a CD looks like a bunch of “lands” and “pits”, like this:

------------------____----------

Following this text representation, 4321800 “dashes” or “underscores” are read each second. A “land” can be 3, 4, 5, 6, 7, 8, 9, 10 or 11 dashes long; similarly, a pit can be 3, 4, 5, 6, 7, 8, 9, 10 or 11 underscores long. Now the important point is that the CD player needs to be able to distinguish all these; consider the following two fragments:

----------------------------
___-------
--------------------

These are both valid, but have different meaning. The fact that a single land/pit boundary has moved just one bit to the right on subsequent readouts (a spec of dust, dirty finger, or passing lorry truck is all it takes - but it can also just be that this reflects a physical defect in the CD from production) changes the meaning quite drastically: due to the way the data is subsequently processed, this will corrupt one byte of data. Now if this byte contains audio/CIRC data (this is true for 32 out of 33 bytes encoded in a single frame), the error will probably be caught by the CIRC error correction scheme.

However, subchannels were added somewhat as an afterthought, it seems; either that, or the data they contain is deemed less critical. Anyway, no error correction scheme for the subchannel is present - so subchannel errors are just passed through.

> The .sub mismatch problem is fixeable, in principle.

I used CloneCD’s Repair subchannel data option; will this give me accurate copies of my originals?

I don’t know. It “sounds like” the idea of abusing the q-channel CRC-16 for error correction rather than error detection, but I don’t use CloneCD, have no access to its documentation or source code, so I cannot speculate what it means precisely.

Best regards,

Sidney


#11

It is abusing. But I think more precisely is that when an error is detected by the Q sub CRC the software could do a re-read. On the other hand maybe C1/C2 info could give this, but unfortunately not all drives can report such info for the software.

You can download and use the demo for 21 days at:
http://www.slysoft.com/en/download.html


#12

Sure, it could be like that - but this will not help if an error is caused by faulty fabrication or similar, and is thus reproducible. It is possible to do an all-software repair (without rereads) but I don’t know what CloneCD does.

On the other hand maybe C1/C2 info could give this, but unfortunately not all drives can report such info for the software.

How do you reckon C1/C2 info would help here? Subchannel bytes are completely independent of the two CIRC stages; C1 and C2 are only used for audio data, not for the subchannel. Subchannels P–W come from an unprotected EFM-encoded byte, located just after the sync pattern/merge bit triplet in every 588-channel-bit frame.

Regards, Sidney


#13

Oh right I didn’t know that. Sorry, I assumed it was also part of the 2 CIRC stage.


#14

Unfortunately, it isn’t. This would fix a couple of problems!

Regards, Sidney