Ripping guide for Mixed-Mode CDs with data sectors in Track 2 pregap

[ssjkakaroto]

Unless he's interested to modify PerfectRip (which is written on Delphi) instead of writing everything from scratch.

... I have already finished the thin JNI DeviceIO DLL for Win32/SPTI and used it successfully in Java (plain dump of all sectors of a disc using READ CD CDBs). First I'll need to read and interprete TOC properly, I'll care about that until weekend, so I guess we won't lose any time when waiting (with knowledge exchange) until then. ...

I'm glad you went that way, because PerfectRip has that gap issue and didn't gave consistent results even when there were no C2 errors.

[Feltzkrone]

A little update on this topic: I will first concentrate on dumping discs as F1ReB4LL suggests, need to get hold of a scratched CD (I think some bullshit early 90s audio CD which I have plenty of and a nail will do) in order to verify that the D8 command I found out probably returning subchannel data and C2 error pointers really does it. For anybody interested here is the CDB: D8 00 XX XX XX XX YY YY YY YY 08 00, where X = starting LBA and Y = number of sectors.

Would be nice if anybody could confirm this, I just increased the value at the second last position until the drive returned C2 pointers and subcode. As mentioned before, I personally prefer reading subchannel data aswell because there might be data to be preserved but not possible with CUE format, such as pause styles and MCN and ISRC interleaving and "errors" actually on disc.

By the way, this "document" is the only one found with Google which is at least telling a little about the D8 command. In fact it tells you how things where done back in 1995...
http://www.isomedia.com/homes/isomedia/ … aq_37.html

Nevertheless, once finished D8 ripping, which might take a few weeks due to proper handling and file output, I will extend the program to work with MMC-compliant and Accurate Stream capable (= no jitter) drives as good as possible (= as good as with IsoBuster + EAC, but a bit better regarding pregap detection).

[themabus]

hi Feltzkrone
i can confirm that Plextor Premium return 294 additional bytes with this parameter,
so it pretty much looks like c2
d8 command is described in SCSI-2 Command Reference Manual
but it does not list those options beyond 3, maybe in some later revisions,
but then i'd guess very few devices would support this

[Feltzkrone]

Thanks for testing the command. I'm afraid I run into bigger problems right now: PX-716A returns inconsistent subchannel data between the mentioned D8 and normal READ CD commands.

D8 on PX-716A using my tool, viewing .sub file with HxD:

Code: Select all

000D3C20  00 00 00 00 00 00 00 00 00 00 00 00 41 01 00 02  ............A...
000D3C30  00 35 00 02 02 35 6F FE 00 00 01 00 00 00 00 00  .5...5o.........
000D3C40  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
000D3C50  00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00  ................
000D3C60  00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00  ................
000D3C70  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................

READ CD on same sector (still PX-716A) using cdtool:

Code: Select all

00000000000000000000000041010002  ............A...
0035000202356FFE0000000000000000  .5...5o.........
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................

Same sector with my LG drive using cdtool:

Code: Select all

00000000000000000000000041010102  ............A...
0035000202356FFE0000000000000000  .5...5o.........
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................
00000000000000000000000000000000  ................

Note how the dump using LG drive looks fine and how the dumps using PX-716A using D8 and normal READ CD command differ (look at those 01s and especially the INDEX = 00 values). If you XOR the first 0x30 bytes from the D8 dump with the second 0x30 bytes you get the same 0x30 bytes as using PX-716A along with READ CD. By the way: The results are 1:1 reproduced, even if medium removed and re-inserted.

This is very strange and in my opinion there are only two possibilites:
1. The LG drive cleans the data (maybe using the Q channels 16 bit checksum)
2. PX-716A does some hocus pocus or has problems when reading subs
2a. With D8 possibly the second 0x30 bytes act as error pointers (???)
2b. With READ CD those errors are partially cleaned, as INDEX is still returned as 00 instead of 01

Any ideas how to handle this properly? Ofcourse the dumping tool might make use of the 16-bit CRC value as generating Q channel data like it -should- look like, calculate CRC for that data and compare CRC with returned CRC. If there's a match and the returned data is suspicious, take the generated instead. I personally don't like recovery methods like these but if nobody else has an idea 1) what might be the reason for this strange behaviour and 2) how to handle it properly I wouldn't know what to do.

Thanks in advance.

EDIT: Perhaps this behaviour is related to Rocknrom's PerfectRip gap/index problem (here) as my PX-716A returns the very same (wrong) data with both subchannel mode 001b and 100b. I guess what Plextor returns here -should- really be handled as errors, since I would have to write index changes on the dumped sector aswell if the data would be taken seriously.

EDIT2: I have done a dump using PerfectRip and it doesn't produce any wrong INDEX entries, but look at this log extract...

Code: Select all

Info    | 22:50:52 | Pause found: 410200000300001555597822
Error   | 22:50:52 | Error while burst reading sectors: 071590 to 071615 (15:54.40 to 15:54.65)
Info    | 22:50:52 | Retrying with 1 sector reads from: 071590 (15:54.40)
Error   | 22:50:53 | Error reading sector: 071609 (15:54.59)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector (ignoring): 071609 (15:54.59)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector: 071610 (15:54.60)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector (ignoring): 071610 (15:54.60)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector: 071611 (15:54.61)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector (ignoring): 071611 (15:54.61)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector: 071612 (15:54.62)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector (ignoring): 071612 (15:54.62)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/02/81 - Unknown sense key code combination
Error   | 22:50:53 | Error reading sector: 071613 (15:54.63)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/15/00 - Random positioning error
Error   | 22:50:53 | Error reading sector (ignoring): 071613 (15:54.63)
Error   | 22:50:53 | Sense hex (key/ASC/ASCQ): 03/15/00 - Random positioning error
Info    | 22:50:53 | 1 sector reads were ok, setting back to burst reading from: 071616 (15:54.66)
[...]
Info    | 22:53:48 | Total corrupt Q subcode blocks: 233
Warning | 22:53:48 | Replaced sector: 071609 (15:54.59)
Warning | 22:53:48 | Replaced sector: 071610 (15:54.60)
Warning | 22:53:48 | Replaced sector: 071611 (15:54.61)
Warning | 22:53:48 | Replaced sector: 071612 (15:54.62)
Warning | 22:53:48 | Replaced sector: 071613 (15:54.63)
Info    | 22:53:48 | Reading process completed successfully.

The sectors PerfectRip replaced (because it couldn't read them) are fully readable with CDTool. And please take a look at the Q subcode error count. I guess these come from exactly the strange subchannel data that I've read before.

[Rocknroms]

Do you invert cdtools sector views while posting? I ask because the different one above is LG and bot plextor are the same.

[Feltzkrone]

No, I didn't made any mistake while posting the dumps and Plextor ones are not the same: There are three 01s in the D8 dump (channels R-W) where in the READ CD dump are 00s. The only mistake I made is that XORing as explained does NOT result in Plextor's READ CD result but in LG's one. Tonight I will burn a test CD with some data on subchannels R-W and read that one out using D8 - should give some clue about what Plextor really returns on D8 as I don't have trust anymore that it really returns raw subchannel data for P-W. I deeply hope that it's a fault in my interleaving code but I don't believe so.

EDIT: If everything goes bad, a plain D8 dump wouldn't be sufficient. The proposed C2 reporting still needs a check and for now returned subchannel data doesn't look like being proper and as themabus set D8 along with code 08 can be guessed not to be supported by all D8-capable drives. I'm afraid we run into real problems here and have these variants:

1. We can choose between D8/08 and D8/02 for either receiving C2 pointers or correct subchannel data, the first one probably not supported by all drives.
2. If we go for D8/02 immediate re-read with normal READ CD command (and C2 pointer selection) might return the wanted C2 pointers, but only if the drive caches data, so this method is pretty unsafe IMO - but how to get C2 pointers for our D8-read data then?
3. As for audio sectors I believe READ CD pretty much should return the same data as D8 - shouldn't we switch to plain READ CD (+C2+SUB) after receiving the first audio sector with D8?
4. Are C2 pointers really needed when reading data sectors using D8? Wouldn't descrambling, calculating ECC/EDC and re-reads (maybe multiple times like EAC) on ECC/EDC differences between stored and calculated data be sufficient?

[F1ReB4LL]

You provide too less details about the performed commands. What was the subs reading mode? 001? 010? 100?

Also, you won't be ever able to get the proper subchannels dump this way - the subchannels dumping tool should be standalone, because taking a complete dump takes hours (and you should get at least 2x confirmations on at least 2 different drives to get a somewhat reliable result).

[Feltzkrone]

you should get at least 2x confirmations on at least 2 different drives to get a somewhat reliable result

Agreed for this. But the same argument (that it will take hours to properly dump sub-channel data) might be used for claiming that reading subchannel data (and give susicious positions -one- re-read) along with main channel data on a regular dump is a good thing, because you save at least one complete dump of the disc (in order to read sub-channel). Btw. as subs reading mode I have used 001b.

However, the problems I've written about led me to the decision to first concentrate on helper classes and conversion routines etc. so that later changes or extensions of the utility won't be such an annoyance to do (the main code can be kept clean better the more lower-level stuff is moved to separate classes). This additionally will help non-coders to read and understand the main code i.e. what the utility does.

Just to inform you that work is still in progress...