I am pretty sure that it's a fault of DIC handling transfers via USB/IEEE-1394, at least with certain enclosures. CDTool, PerfectRip and the «unnameable» works nicely with my PX-W4824TU, and this drive is just an externalized PX-W4824TA.

How many value is "MaximumTransferLength" of PX-W4824TA/PX-W4824TU?My drive(PX-755SA) is 00010000(65536) bytes.Please paste drivelog of STORAGE ADAPTER DESCRIPTOR.

C2 switch for GD-ROM ripping does work now, but unfortunately the dumped .sub is invalid (contains non-sense data). Without C2 switch the .sub is valid and the extra frame is no longer present. Anyway, the actual dump (with/without C2 error reporting) matches the expected.

The same one for main channel / 8, because there are 2352 bytes for main channel and 294 bytes (one bit per byte of main channel) for C2 pointers. And this way will proceed PF if you enter 0 as c2 read offset correction bit(s).

In case of Plextor drive, how many is the values of c2 read offset correction bit(s)?

-An option (for the -rall and -rgd modes) so that the C2 pointers are used only for purely informative purporses, without absolutely re-reads, like the old PerfectRip does. I mean the program will read and dump into a .c2/.c2e file the raw C2 pointers provided by the drive, but won't re-read anything marked as bad by the C2 pointers. This way I will know if a rip is good (no further action required) or bad: to resurface and clean the CD until getting 0 C2 errors, to try another drive, to try another read speeds or simply replace the CD if nothing works to get a flawless dump without re-reads. Of course, the log file should report if the dump was flawless or not flawless.

-The suggestion posted above applied to the -ra mode as well. And I would like that you could implement offset correction for the -ra mode: it would apply, as default option, the standard one defined by the AccurateRip database plus the possibilty of override it via the add parameter implemented in the -rall mode.

The possibility to set different read speeds for the initial read and the readings. For example, initial read at 24x speed and re-reads at 4x speed.

I coded it. c2 option val3.

Rewrite the -ra module so this tool can act as a CDTool replacement to dump as audio (D8 or audio trap disc) any range that the user desires with subcode and C2 error reporting (outputting both as .sub and .c2e files), adding the possibility to correct the offset (with the possibility to override the standard one). This module should support Plextor and non-Plextor drives and could be useful to dump the high density of DC games.If a Plextor drive is used, D8 command and order is Main+C2+Sub.

As described in the MMC spec (http://www.t10.org/ftp/t10/drafts/mmc4/mmc4r02f.pdf),READ_CD does not allow any FUA bit at all, so if this reading method is chosen thenflushing tricks are needed. However, other MMC commands like READ10 (0x28) andREAD12 (0xA8) support the FUA bit.

>F1ReB4LLI examine that fixes per a byte.By the way, is there an offset for c2 error byte?If an offset exists, is it different every drive?

>Nexy>>Sometimes it will just abort with a drive not ready error.If possible, please tell me the procedure to let it reappear in detail.>>The hashing takes ages too, unoptimized routines there? Will you improve themPlease tell me the good open-src library.

>pablogm123>> override the automatic offset correctionIt will add at next wip.>> drive's cacheTested my drive. My 755sa don't support fua on 0xd8 cmd. I don't know why that is.Therefore, even if I coded it, I can't test it that its code is correct.