DiscImageCreator (Page 16 of 141)

You shouldn't use the /i option to dump normal discs, this option is ONLY to dump certain PCE CD discs with non-standard yet valid ISRCs. By doing so will get lots of fictitious ISRCs and therefore an invalid cue.

Example:
http://redump.org/disc/28248/

The use of that option doesn't make sense at all for you because anyway you are double-checking the possible CATALOG/ISRC/DCP... flags with PR.

Edit: minor bug detected in the x86, AnsiBuild, May  5 2014 00:11:05 version. When the disc has TOC vs. subcode desync, the normal cue (TOC in priority) has filenames with the '(Subs indexes)' string.

PR can rip either to CD+G bin/cue (raw image with interleaved subcode data in non-deinterleaved form, like Alcohol 120% images or created by the 2352to2448 themabus' program and CDG instead of AUDIO in the cuesheet) or to ccd/img/sub.

When only ccd/img/sub is selected PR will append an artificial lead-out in the image and in the the subcode. This is avoided by ripping simultaneously to normal bin/cue or to CD+G.

I mean to extract that way the subcode data to have at least clean R-W data. Format would be the classic ccd/img/sub.

MrX_Cuci, upload the created .sub file as well. Without that, sarami won't be able to see what is wrong exactly and generated that Failed to analyze the subchannel. error.

Something weird which perhaps confuses DIC, the xxx68 frames (as seen in Subcode Analyzer) contain non-standard Q-frames. F2:17:01 instead of the minute:second:frame of the given track.

TOC of CD-i discs is something "special".

MrX_Cuci:
discimagecreator.exe audio y: TOC -5000 -75

And post the created .sub file to analyze that weird TOC.

These CD-i discs confuse many drives...

At first sight... actually no starting position of track 1 is defined by the TOC. Only is defined that the first track is 2 (A0), second track is 2 (A1) and lead-out starts at AMSF 08:24:00 (A2), but no actual entry for track 1.

So I guess that to rip these CD-i discs is needed to rip everything from AMSF 00:02:00 until the last pre-lead-out sector, ignoring what TOC (except the lead-out position of course) and subcode say. But even so subcode has to be analyzed just to detect possible CATALOG fields and other flags encoded and add them in the written cue.

And when ripping these discs the written cue has to contain the CDI directive instead of MODE2/2352 .

Should be trivial to analyze the filesystem contained and rip these discs properly, only rip everything from AMSF until the last pre-lead-sector, determinate if the disc contains CATALOG and so on and write the cue with CDI instead of MODE2/2352. Sample of the first 17 sectors of two CD-i discs, which contain the CD-i signature.

http://www.mediafire.com/?3yenqq3mewqchx0

improved /p option

/p option should rip the pregap always, no matter if first track is audio, data or AMSF 00:02:00 is/isn't marked as index 00 by the subs. Currently it refuses to extract the pregap of that miniCD bundled with Tenbu Mega CD Special because AMSF 00:02:00 isn't marked as index 00.

Detected a bug when dumping a PCE CD game and reproduced by two different users who own the same disc, axisleon and F1ReB4LL:

http://forum.redump.org/topic/13861

Version used, the latest, that one with these hashes:

CRC32: 90bdbe17
MD5: e0b49e8aedb8e099d8f9a09c3f939e3c
SHA-1: b82c57d7fa02318e22d22a96c5a88eeeb74c3a72

Description of the issue: track 12 is completely in scrambled form. After removing the first 77 (audio) sectors, descrambling the data track and restoring the 77 audio sectors hashes are the expected ones:

CRC32: 01098cf1
MD5: aa9f2c8f79a2462911560b7275b1bcee
SHA-1: b246986e66b0f6c3561a5e7ea1f918f68f4c0437

Subcode dump of that disc got by subdump:

http://www.mediafire.com/?s1v9d5fmaqtta

Logs:

https://www.mediafire.com/?e8jejtucj7h8uon

This looks weird and likely is the problem:

    Data Sector, LBA   3365- 38271 (0x00d25-0x0957f)
    Data Sector, LBA  72512-    -1 (0x11b40-0xffffffff)

No one will use nowadays CDRWin to burn a bin/cue image with the CDG directives, but a ccd/img/sub image and CloneCD. Or simply mounting that image which double as the original CD, but including fully error free subcodes.

Speaking of cuesheets...

http://www.mediafire.com/?9h9cb8k4ic4512n

http://redump.org/disc/24412/

http://redump.org/disc/24412/cue/

Multiple indexes aren't added. Could you see this and fix it?

No, they aren't different.

MrX_Cuci's problem is a fictitious index created, likely by random errors in the Q subcodes not properly ignored and therefore a fictitious index is created. MrX_Cuci, you don't use the /i option anymore, right?

CATALOG 0000000000000
FILE "Track 01.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 00 00:00:00
    INDEX 01 14:57:08

Should be simply:

CATALOG 0000000000000
FILE "Track 01.bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00

Regarding that Neo·Geo CD game, problem is the reverse: multiple and real indexes encoded in the subcode not added to the cuesheet. For burning/mounting the ccd image this shouldn't be a problem, subcode is here and will double as the original disc, but for mounting/burning/using this via the cue file is a problem, because the game expects multiple indexes not present and game won't work.

Anyway, a fully error free subcode dump to analyze it, just in case that you need a clean subcode to analyze this disc:

http://www.mediafire.com/?32h85e2x65v11bl