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...

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).

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?

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

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:

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

Same sector with my LG drive using cdtool:

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...

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.

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).

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

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.

Regarding D8 scrambled reads... It's another thing left to be defined: What about drives which are unable to read data via D8 command? I think we can't just exclude all users with average drives from submitting dumps - instead I would suggest something like a dump quality measurement where too low quality levels exclude dumps from being added as first-time dumps.

About error correction - still waiting you on the IRC channel (or ICQ) to discuss the details and algorithms. IMO, discs should be dumped in scrambled form via D8, then descrambled via software (to bypass any firmware error correction). No C2 errors - good dump.

I already came over a CD (Al Unser, Jr. Arcade Racing) where a wrong bit is in subchannel data in one sector which is read as it is regardless what drive I used - meaning it really is on CD and not just a random error dropped in by the drive. I guess 1:1 preservation (which is aimed at redump.org AFAIK) should preserve this wrong bit, too. What's your opinion on this?

Data is on CD only if it's in disc sector viewer. If the disc has some signs or scrathes and the drive is not good you will get errors, so if you cannot dump properly a disc, there's nothing to preserve.
If this error is something really on CD and if we are talking about PC stuff it could be some kind of protection so it has to be dumped differently.

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

First I don't have the feeling the author would hand out the source (I didn't ask and might be completely wrong here) and second rewriting from scratch gives us the possibility to do everything as we think should be done.

By the way, there is a not so unimportant thing to consider when rewriting from scratch: Many drives are able to disable error correction when reading data sectors. I believe if e.g. one bit in user data is wrong (on pressed CD) but ECC/EDC is intact, the drive would correct the wrong bit. If those wrong bits really are on CD shouldn't it be considered to write them (wrong) as they are into the image file, i.e. disabling error correction when dumping? Ofcourse, when disabling error correction more than one read per sector would have to be performed to really get sure we got what's on CD - as EAC does with audio data.

I already came over a CD (Al Unser, Jr. Arcade Racing) where a wrong bit is in subchannel data in one sector which is read as it is regardless what drive I used - meaning it really is on CD and not just a random error dropped in by the drive. I guess 1:1 preservation (which is aimed at redump.org AFAIK) should preserve this wrong bit, too. What's your opinion on this?

Feltzkrone may I suggest that you go for Java command-line because in the future it would be easier to port the program to other OSs.

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

because in the future it would be easier to port the program to other OSs

Seconded. The only problem I have with this choice is that I'll have to familiarize myself with JNI which is used to glue native DLLs and the JVM together. But it shouldn't be too hard either and will make things easier in the end as Java does provide a lot of classes and functions to the programmer which are not available in Delphi 7. The critical point in this is that programs which require an installed Java runtime are not that widely accepted by the end users as native Win32 applications are (the same drawback goes for .NET). I'd like to see other opinions on this topic before committing myself to one or another.

I guess it would be sufficient to implement device enumeration and device access (send CDBs to a device and pass data buffer and data direction) in the native DLL. I don't have anything with to do with e.g. Linux, but I guess it shouldn't be a problem for some Linux programmer to build an analogous shared object (I think this is for Linux what DLLs are in Windows) which can be used then.