Subchannel issues

vbimport

#1

Not sure if I'm posting this in the right section.

I'm trying to extract 100% of the subchannel data off an audio cd. I'm using alcohol to extract the subchannel information. However, I want to make sure the subchannel data was correctly extracted. I have a program that can compare binary files bit by bit. As a test, using alcohol, I extracted RAW DAO and subchannel data multiple times. I compared the extracted images but each time the subchannel data varies somewhat. I tried extracting at various speeds such as 1X but it didn't fix the problem. How can you extract the subchannel data accurately if possible? That must be some consistency here. I'm using a plextor DVDR PX-716A. Is there another program that does a better job?


#2

Channels R-W should be zeroised for CDDA.

CDTool and CDGTool will let you use the Reed-Solomon EDC-ECC logic
inside the 716 for R-W, and proprietary (Truman-IpseDixit) correction algorithms
for P&Q, so you can have a corrected subchannel and free from random errors.

Click on Xpert tools in my signature for official thread (download and guides).


#3

Whoa! Thanks a lot. I’ve never seen any program out there like this. So you totally recommend Clone CD for burning then? I noticed there is even an option to read the lead in/lead outs. Is that really necessary for making a true perfect 1:1 copy (all correct subchannel data included)? I believe the plextor 716A can read lead in/lead out but only so far. If the plextor can’t read all of the lead in/lead out what is the point of reading them? I assume the burner program recreates the lead in/lead out when burning, correct? What about the pregap? Is that attached to track 1 or is that created too when burning? As long as the burner recreates the lead in/lead out and pregap exactly as the original audio cd I’m fine. I just want to make sure I’m extracting everything that is necessary. I did run a test and it says the lead in is -150 (sectors I’m assuming) and the lead out is -150 sectors. So the lead in/lead out are two seconds each? Is that true for all audio cds or does this length vary? Now the TOC is in the lead in. If you don’t extract the lead in do you miss the TOC? Man, so many questions I’m trying to find the answers for. Reply when you can. Thanks again.


#4

Okay, I’ve been playing with the CDtools program. I’m getting some interesting results. When I select “P-W PACKED de-interleaved, or RAW interleaved …” it extracts the data at an extremely slow read speed even though I have max speed selected. Something like 46 kilobytes/second. I actually waited for the audio cd to finish over a period of 7 hours or so. When I used the C2 file it found a fair amount of !00 non zero values. Therefore, I cleaned the audio cd even though it wasn’t that bad. I decided to try the other option “P-W RAW interleaved …” and then I checked deinterleave subs (I’m supppose to deinterleave subs right?) To my amazement it extracted at the max speed of 40x. I also discovered using that subchannel option the C2 had no non zero values. So selecting “P-W PACKED de-interleaved, or RAW interleaved …” is giving me two problems. Uncontrollable slow read speed and non zero values in C2. Therefore, “P-W RAW interleaved …” is what I’m using (fast read speed and no non zero values) But why is this happening if you know?


#5

Thread moved from copy protection forum.


#6

Okay, I’m trying to extract all of the subchannel data P-W from a standard audio cd. I’ve been using Cdtool/Cdgtools to correct the P and Q channels.
I’m using a plextor 716A. Here are some of my results below in a hex editor:
Two 96 byte subchannel blocks

00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 03
26 21 00 03 28 21 1C 98 FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

00 00 00 00 00 00 00 00 00 00 00 00 01 01 01 03
26 22 00 03 28 22 C2 29 FF FF FF FF FF FF FF 7F
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF 7F FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF
FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF

As you can see, the R-W subchannels are basically filled with “FF” bytes. A standard audio cd should not have data in R-W subchannels. I assume the “FF” bytes are just fillers kind of like “00” bytes are fillers. However, if you look closely in the 2nd block you will notice two “7F” bytes. I believe these are incorrect and are basically errors. It should be all “FF” bytes because as fillers, everything should be the same. Everytime I extract the subchannel data I keep getting various errors like the “7F” bytes seen above. I assume they are errors because there is no pattern. Totally random. I’m no programmer so I can’t really fix them unless I do it manually which would take forever. Are they really errors? Do they all need to be corrected to “FF” bytes? Any software available? I’ve been looking everywhere. Thanks in advance.


#7

Why do you ‘want to make sure the subchannel data was correctly extracted’? Or a better question may be: What exactly are you trying to do?

If you are wanting to read Audio only CDs, then why bother with reading any of the R-W subchannel data and worrying if they are correct or not? If you don’t plan to read something like CD+G and you don’t need the R-W then it is a waste of your time to read and worry with.

The R-W data only has 2 symbol error correction. It is quite normal to read the same CDs R-W data multiple times and get multiple R-W data. Nothing can be done about it. A few R-W errors here and there would not cause a major problem during playback of CD+G discs (such as some Karaoke CDs).

Some drives (some Plextors for example) will allow you to read part of leadout (usually not very much). The CD-DA spec does not allow for any user data to be in leadout so it doesn’t make sense to read it. Any data found in leadout should not be considered ‘good’ data. Reading the TOC is basically the same as reading leadin. I’ve not found a drive that actually lets you read leadin directly. When you issue the read TOC command, the drive reads a sample of the leadin and returns the data found.

The first 2 seconds of the first track of a session (this is an example of pregap) also can not contain valid user data. All pregap data happens at the beginning of a track and is part of the track. The pregap between 2 actual tracks may contain valid user data (unless writing in TAO (track at once) mode).

Leadin is usually 2-3 minutes or so long and varies with each disc. Leadout is usually 1 to 1 1/2 minutes long (it all depends on if the disc is multisession or not).

R-W data on a CD audio only disc should contain all 00 data (not FF).

Reading pregaps and leadout is argued to be needed in some cases due to a drive’s ‘skew’ or offset.


#8

Richman! Thanks for your response. Well, basically what I’m trying to do is make a copy or near almost copy of an audio cd including all subchannel data. I understand the R-W subchannel data is not used in a standard audio cd. Me being a perfectionist in all though, wants to include it. Yeah, I didn’t think reading the leadin and leadout was necessary. I only asked that because it was included in the options in Cdtools. Got me wondering. I assume when you actually burn a copy of an audio cd the leadin and leadout are reconstructed. Yeah, I figured R-W data had poor error correction. I’m always viewing everything in a hex editor to gain a better understanding of all this. My perfection side of me says there must be a way to correct those R-W errors. Maybe comparing various extractions could lead you to the correct data. Then you could just edit everything in a hex editor.

And like, for example, with read offsets. When I extract a complete audio cd I view the last sector of the last track. If it doesn’t end in 00 data I perform a read offset to overread into the lead out. I then could add that missing portion using a hex editor. I know the read offset of my plextor but I read that topic about offsets and how EAC could be off 30 samples.

Now that whole issue about the R-W data being only 00 data for an audio cd makes sense. However, it keeps reading FF for this particular audio cd. I haven’t seen even one 00 data in the R-W data of this audio cd. It is only a single session audio cd with no extras. I can’t explain why I’m only receiving FF data but I know it is correct because I have two different cd-roms extracting to compare. I’ve used various programs to perform the extraction. If “FF” is correct then those errors such as “7F” could be replaced by FF data in a hex editor you think?

This website here has some pretty good tools but they might not be available for personal use.

http://www.eclipsedata.com/products/index.htm


#9

Hello all.

I compared the extracted images but each time the subchannel data varies somewhat.

They’re random errors:

…because of pre-mastering faults, random
defects originated between mastering and pressing,
or burning or readout errors by the drive. Of course
scratches, dust and fingerprints play a role here too.

Spec establishes a limit for random errors: the BLER
(BLock Error Rate) averaged over any 10 s shall be
less than 3 x 10^-2. BLER is measured at the input
of C1 decoder, blocks are erroneus when at least a
symbol is erroneus and symbols are erroneus when
at least a bit is erroneus. All this happens at main
channel and unfortunately I see no spec for subs,
but you can understand now that random errors
aren’t necessarily an indication of a faulty drive.

How can you extract the subchannel data accurately if possible?

Listing the different protection schemes for the 8 subcoding channels…
Channel P: no protection, Channel Q: 16-bit CRC, Channels R to W:

[FONT=Arial][SIZE=2][SIZE=2][FONT=Arial][SIZE=2][FONT=Arial]To protect the data in the subcoding channels R to W, a (24, 20) Reed-Solomon error correction code is used. To improve the burst error correction capability, 8 times interleaving is added to this error-correction system. The first two symbols in a PACK have additional protection with a (4, 2) Reed-Solomon error correction code.
[/FONT][/SIZE][/SIZE][/FONT][/SIZE][/FONT]

[SIZE=2][FONT=Arial]Only a packed mode reading drive (100b) can make a difference [/FONT][/SIZE][SIZE=2][FONT=Arial]by decoding[/FONT][/SIZE]
[SIZE=2][FONT=Arial]subchannels R to W, “cleaning” them from reasonable amounts of random errors.[/FONT][/SIZE]

Is there another program that does a better job?

[SIZE=2][FONT=Arial]The rest of the job (P and Q) can only be carried out by software, like in CDGTool.[/FONT][/SIZE]

As you can see, the R-W subchannels are basically filled with “FF” bytes. A standard audio cd should not have data in R-W subchannels.

That’s correct, but unfortunately this practice is frequently performed by the industry.
This is the reason behind the insane amount of time it takes to dump these subcodes.
The 100b decoder just has a hard time trying to process so much nonsense information.

I’m no programmer so I can’t really fix them unless I do it manually which would take forever. Are they really errors? Do they all need to be corrected to “FF” bytes? Any software available? I’ve been looking everywhere. Thanks in advance.

Yes, random errors to be corrected to “FF” bytes, I selected this thread to release
Truman’s R2WFill, a proggie to fill channels R to W with any value, keeping P&Q.

R2WFill.zip (2.73 KB)