DiscImageCreator

[Nexy]

Today I get another weird error

Code: Select all

Descrambling data sector of img(LBA) 320662/320662
Creating bin, cue, ccd(Track)  1/ 2[F:CreatingBinCueCcd][L:980] GetLastError: 8,
 Not enough storage is available to process this command.

Creating bin, cue, ccd(Track)  2/ 2
End -> 2013-11-10(Sun) 14:58:10

There is 114GB free on the drive.

[sarami]

GetLastError: 8

"storage" is not hard disc but memory.

[Nexy]

ok but I had like 5GB free memory at the time... weird =]

[sarami]

http://www.mediafire.com/download/u0olo2c51f2qv13/

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.

improved ripping GD-ROM
  added "-rgd" command for HD area (integrated "-ra", "-dec", "-split")
  c2 error option don't test. (Because my drive(TS-H352C) don't support C2 error report.)

If a non-Plextor drive is used, BE command and autodetect if the drive uses Main+C2+Sub (NEC based for example) or Main+Sub+C2 (Mediatek bases for example).

I don't support it yet.

[pablogm123]

Tested successfully to dump a new PS1 disc in pristine condition (so no C2 error expected). discimagecreator.exe -rall g: 8 "Die Hard Trilogy (Japan).bin" c2 750 4096 8

One suggestion regarding USB/IEEE-1394 drives: it seems that these drives sometimes require more or less 8 KB or lower transfers so that they can work OK, specially when C2 error reporting is enabled. You could add an option to limit the transfers to a maximum of 3 sectors for compatibility reasons: (2352 bytes +294 bytes +96 bytes)*3 = 8226 bytes.

val2: value to fix a C2 error (default: 65535): a little exaggerated and overkill as default value to dump discs with no errors or just a few of errors, even that can crash the app when splitting the dumped track. As default value 16384/32768 would be more reasonable values.

[sarami]

http://www.mediafire.com/download/u0olo2c51f2qv13/

If a non-Plextor drive is used, BE command and autodetect if the drive uses Main+C2+Sub (NEC based for example) or Main+Sub+C2 (Mediatek bases for example).

coded it.

val2: value to fix a C2 error (default: 65535)

fixed at 32768

[pablogm123]

C2 support doesn't work OK for the new option to dump Dreamcast discs, drive used is a PX-W4824TU (which is supported correctly by DIC currently), the very best drive I own to dump Dreamcast games combined with an old Samsung 10x CD-RW as audio trap disc. DIC just aborts the read process silently, no error reported.

Code: Select all

D:\Redump\DIC>discimagecreator.exe -rgd g: 8 HD.bin c2 750 4096 8
OS
        MajorVersion: 5, MinorVersion: 2, BuildNumber: 3790
AppVersion
        x86, Ansi build
BuildDate
        Nov 15 2013 03:38:00
Current dir
        D:\Redump\DIC
Input File Name
         path: HD.bin
        drive:
          dir:
        fname: HD
          ext: .bin
Start -> 2013-11-14(Thu) 22:40:16
Allocating memory for C2 error: 4096/4096

D:\Redump\DIC>

Without C2 error reporting enable the dump is fine (matched hashes) and write offset of high density zone properly autodetected. A minor bug: the dumped subcode contains an extra frame from the pregap of track 3.

Code: Select all

Offset(Drive offset data referes to http://www.accuraterip.com)
     Combined Offset(Byte)   -736, (Samples)  -184
    -   Drive Offset(Byte)    392, (Samples)    98
    ----------------------------------------------
           CD Offset(Byte)  -1128, (Samples)  -282
    Need overread sector: -1

Disc used to test:

https://redump.info/disc/23397/

Logs and subcode dumped: https://www.dropbox.com/s/sna8w046qu3uaxq/23397.7z

[sarami]

http://www.mediafire.com/download/u0olo2c51f2qv13/

C2 support doesn't work OK for the new option to dump Dreamcast discs

probably fixed it. (I can't test.)

A minor bug: the dumped subcode contains an extra frame from the pregap of track 3.

fixed it.

regarding USB/IEEE-1394 drives

I'll consider it

[DJoneK]

I've been using a Plextor drive on a USB enclosure forever and haven't had an issue until recently.  I had to tweak the default memory for c2 from 65535 to 1024.  Haven't tried a higher value than that, but most of the disc I dump don't need c2 error correction.  Usually, when they have c2 issues, it just goes on forever without actually fixing anything.  I just stick to good discs, lol.

But yea, that was more of a memory problem than USB limitation I guess.

My system:
Win 7 64bit
4gb RAM
PX-W5224A

[pablogm123]

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.

Logs and subs: https://www.dropbox.com/s/qruxbz9hdwe0s … No%20C2.7z

My current wishlist:

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