Which subchannels are used on different cd types?

(Alexnoe, spath, feel free to move this thread to the newbie forum or wherever you think appropriate if you don’t think it belongs here.)

The reason for my query is the recent release of a new version of the cdrdao burning engine which supports raw reading and writing of rw subs but, strangely, not the pq subs.

OK, now my understanding is that, ignoring atip checks and whatever nightmare method of “verifying” an original cd that may have been used on NWN 1.21 and 1.22, securerom uses the pq subchannels (so a raw + 16 byte write is sufficient to duplicate the relevant subchannel data). However, since cdrdao doesn’t support pq subs, it can’t duplicate the protection even with a full raw read and raw dao96 write (my tests confirm this to be the case).

Cd-text, on the other hand, appears to be stored in the rw subchannels and can be duplicated by the latest version of cdrdao even though pq subs aren’t supported (again my tests confirm this).

As for kareoke cds, I don’t have any to test (and have no intention of ever buying one :wink: ) but my understanding has always been that a full raw dao96 read and write is necessary to duplicate them. However, a couple of sites I looked at after a google search seemed to indicate that the relevant subs were contained in the rw subchannels. Is this so? (If it is then there doesn’t seem to be any reason why a kareoke cd can’t be duplicated by cdrdao notwithstanding its lack of support for the pq subs.)

Finally, libcrypt protected psx. Again, I’ve always understood that a full raw dao96 read (at least of the data track) and write are necessary to duplicate these cds. Given that libcrypt was developed by sony (as was/is securerom), I would assume that the pq subs are used, presumably in addition to some of the rw subs given that a dao96 write is required, but I wasn’t able to confirm this by searching the net generally (and a search of this forum was stymied by the search function not accepting 2 letter terms like pq, rw or pw). Which subs are actually used with this protection? (Again, if pq subs aren’t used, duplication with cdrdao should be possible.)

http://www.chipchapin.com/CDMedia/cdda9.php3

I wondered also about the subchannel stuff in the changelog of cdrdao. To my knowledge subchannels were designed for audio cds. Because datacds (yellow book) are based on audio cds (redbook), datacds also use subchannels. For datacds I think there is no real usage of the subchannels (besides protections).

Edit:

The subchannels of datacds are still used for low-level seek operations.

P-Channel => simple flags to denote the start/end of user data tracks
Q-Channel => all kinds of timing information. This timing info in the q-channel is used by your audio cdplayer to display the playing time, total playing time, elapsed time, etc.
R-W Channel => cd-text or karaoke or cd+g

Use the Subchannel Analyzer to see what is inside your CloneCD subchannel file.

For libcrypt the protection is in the q-channel. They’ve modified the crc-checksum to an illegal value. When writing dao16 you cannot control the checksum value of the q-channel. That is why you need to write dao96. Dao96 gives full control over the subchannel, so also over the crc-checksum in the q-channel.

More information in the urls on top of this post.

:smiley:

I’ve had somebody checked the NWN 1.21 - issue and my theory about the T-channel. It didn’t work :frowning: So there must be more.

According to the author of Feurio!, cd-text is stored in the subchannels r-w of the leadin only.(http://www.feurio.com/index_german.shtml).

libcrypt: it afaik only uses the q-channel, BUT: the q-channel contains a 16 bit CRC check sum. If you write raw-dao-16 (only some old writers) or raw-dao-94 (only some Acers do this), the burner will always calculate this sum on its own. libcrypt CDs contain some invalid CRC sums, so you need raw-dao-96 in order to write the original, “wrong” CRC value.

EDIT
Upp: 19-09-2002 13:53
Me: 19-09-2002 13:58
/EDIT

Thanks guys. In summary, so far as cdrdao is concerned, cd-text, kareoke and cd+g, yes; securerom and libcrypt, no.

(Wonder why there wasn’t support for pq subs though. Maybe in the next version but we’ll probably have to wait another year for that unfortunately.)

Alexnoe, don’t worry, you’ll beat NWN 1.21 yet (or someone will ). :slight_smile:

Originally posted by philamber
Wonder why there wasn’t support for pq subs though.

In normal writing mode the subchannels are created by the writer. It will always write the p+q channels and fills up the r-w channels with zero. When writing in dao96 mode, you have full control over the subchannels by software. If you can write r-w channels (only possible in dao96 mode) you can also write the p+q channels…

:smiley:

> For datacds I think there is no real usage of the subchannels
> (besides protections).

Subchannels are needed to read a cdrom also, f.i. for seeks.

> According to the author of Feurio!, cd-text is stored in the subchannels
> r-w of the leadin only

CD-Text can also be stored in the program area.

Originally posted by Upp3rd0G

When writing in dao96 mode, you have full control over the subchannels by software. If you can write r-w channels (only possible in dao96 mode) you can also write the p+q channels…
:smiley:

Then the limitations of the latest version of cdrdao must lie in an inability to read the pq subs accurately. The change log for the latest version states that only rw subs can written and, more significantly, they are the only ones that can be read raw.

What is, seen from hardware, the difference between reading p/q and reading r-w? There shouldn’t be any…if they can’t read p/q reliably, then they shouldn’t be able to read r-w reliably either :confused:

Originally posted by alexnoe
What is, seen from hardware, the difference between reading p/q and reading r-w? There shouldn’t be any…if they can’t read p/q reliably, then they shouldn’t be able to read r-w reliably either :confused:

I couldn’t understand it either. :confused: I’d always understood that subject to hardware limitations a raw + subs read would either be raw + pq (dao16) or raw + pw (dao96) but what the changelog of cdrdao suggests (and my own tests seem to confirm) is that it’s reading raw + bytes 17 to 96 (rw subs only) and, presumably, leaving generation of the p & q subs to the writer (though accurately reproducing the r to w subs) with a dao96 write. :confused:

Perhaps an investigation of the cdrdao executable and/or the relevant cygwin dll by someone who knows what they’re about (which excludes me :wink: ) may explain this oddity.

Maybe sony has made a secret deal with them to prevent bypassing securom?

Originally posted by Supi Suomalaine
Maybe sony has made a secret deal with them to prevent bypassing securom?

Hardly likely, since cdrdao is gpl open source. :slight_smile:

> I couldn’t understand it either. I’d always understood that subject to hardware
> limitations a raw + subs read would either be raw + pq (dao16) or raw + pw
> (dao96) but what the changelog of cdrdao suggests (and my own tests seem to
> confirm) is that it’s reading raw + bytes 17 to 96 (rw subs only) and,
> presumably, leaving generation of the p & q subs to the writer (though
> accurately reproducing the r to w subs) with a dao96 write.

Actually mmc commands let you write P-Q or P-W and read P-Q, P-W or R-W.

> Perhaps an investigation of the cdrdao executable and/or the relevant
> cygwin dll by someone who knows what they’re about (which excludes me)
> may explain this oddity.

I had a quick look at the code and it seems that cdrdao can both read
(with --read-subchan rw_raw) and write (in cd-text mode) raw P-W subchannels.

Originally posted by spath
[B]Actually mmc commands let you write P-Q or P-W and read P-Q, P-W or R-W.

I had a quick look at the code and it seems that cdrdao can both read
(with --read-subchan rw_raw) and write (in cd-text mode) raw P-W subchannels. [/B]

Thanks spath. In fact, on reflection, I suspect that nero also uses the R-W command. Its Copy CD options include an option to “Read audio data with sub-channel” but there is no equivalent option to read data subs and nero can copy cd-text and kareoke cds but can’t copy securerom protected cds.

Like cdrdao it would seem that nero in dao96 mode can write raw P-W subchannels but can only read raw R-W subs.

Hmm, I’m not sure you got me right, so just to
be sure I repeat it :slight_smile: :
–read-subchan rw reads R-W
–read-subchan rw_raw reads P-W

Originally posted by spath
Hmm, I’m not sure you got me right, so just to
be sure I repeat it :slight_smile: :
–read-subchan rw reads R-W
–read-subchan rw_raw reads P-W

No I didn’t first time. :o

If -read-subchan rw_raw reads P-W then securerom/libcrypt should be possible. I’ll try again.

However, I wonder why the changelog states that only R-W is supported if P-W can be read with the rw_raw command. :confused:

> However, I wonder why the changelog states
> that only R-W is supported if P-W can be read
> with the rw_raw command.

Dunno, you should ask them (it’s in GenericMMC.cc around line 1700).

Well I’ve already joined the cdrdao mailing list and asked if it’s intended to support reading of the p & q subs in a future release but if you’re right reading of them is already supported. I’ll keep you posted when I get a reply (and then raise your question and see what the developer says).

Still, I’m still :confused:. You indicted the generic MMC (driver?); isn’t the generic MMC raw (driver?) necessary for a raw read with subs?

(Serves me right for posting on this forum, I guess, when I’m not qualified to understand the answers. :eek: :wink: )

From Andreas Mueller (the developer/programmer of cdrdao)-

"> Subject: Raw reading of p & q subchannel data
>
>
> I’ve noted that the latest version of cdrdao provides full support for reading and writing of raw r-w subchannel data but no support for raw reading of the p & q subchannels.
>
> This enables duplication of certain types of cds incorporating subchannel data (cd-text, kareoke and cd+g) but not all.
>
> Is it intended to support raw reading of p & q subchannel data with cdrdao in a future version?

I wanted to support it with the next release (but not 1.1.7 which comes
today and fixes license related issues). Actually, half of the work is
already done. The track images extracted with rw_raw sub-channel mode
already contain the PQ data. I’ll just have to modify the
generic-mmc-raw driver to use them."

Well this explains things and I guess we’ll just have to wait for 1.1.8.