DiscImageCreator (Page 134 of 141)

Try to reduce the retry count from 5000 to 20 if the app really hangs.

Sarami is it possible for DIC to properly dump DVDs that have data in two layers? I am referring to this disc
http://redump.org/disc/8324/
One user investigated the topic with this game on DSC TCRF and it turned out that the disk with this game in the redump is incorrectly dumped (below the user's quote):
"After some assisted investigating, it appears that a properly-dumped copy of Offroad Fury 4 is so rare that the one in redump's database is actually an incorrectly-dumped one containing no data from the second layer.
Upon further investigation, it seems that all copies ever printed and sold on store shelves ever, used a very poor mastering method.
Basically, the game stores the "movies" folder on the second layer, but uses a strange custom programming to treat the second layer as a second filesystem that's designed to be not visible on computers.   Unmodified ISOs play videos despite you not being able to see them - the data is there, but you can't see it, only the PS2 can.
I couldn't view the videos for the longest time, causing a built in video skip feature to activate, because I was repacking the ISO to test debugging features.  Computers can't see the second layer so I was unintentionally stripping the video files off the ISO.  This is also why the internal build on HiddenPalace has the second layer seperate most likely, and why adding the videos back fixes the issue.
I'm adding this fact to my documentation along with more technical info about it for the eventual TCRF pages (coming soon in 2999)"
Would you research this topic? This is a beta version that seems to be properly dumped
http://redump.org/disc/70926/
http://redump.org/disc/70927/

Quick update to this issue, i've managed to dump the disc correctly (matching isobuster/clonecd/other drives dumps) using the three flags /np /nq /nr instead of the single /ns flag, and then manually extracting the SecuROM sectors from the .sub file, as Jackal instructed me how to do it with "psxt001z --libcrypt" command.
I've added a SILVER.CD2_logs.zip file to the previous mega link if you want to check the logs, it might be useful for you, or at least i hope so.

Due to "/be pack", _mainError.txt is so big size. This option is not need for Plextor.

Hi sarami,

I think I found a bug in DIC.
I have this CD-R audio CD.

DIC logs

DIC determines an incorrect track 1 / track 2 boundary.
This is what IsoBuster shows for the disc.

DIC produces the following:

<rom name="PGS - Promo Disc (USA) (Track 1).bin" size="25552128" crc="169df37b" md5="e3428a7bb35692ea9625202190220206" sha1="42da4a8b5171e1b3b66a0511611ac2671e402b13" />
<rom name="PGS - Promo Disc (USA) (Track 2).bin" size="28602672" crc="42f4fccc" md5="1c2daf66fa7b437808da638622c8bdf4" sha1="60d20f2c386c74531dd12c8b91ad174e92690d1f" />

FILE "PGS - Promo Disc (USA) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "PGS - Promo Disc (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 01 00:00:00

This is what I think DIC should produce instead:

<rom name="PGS - Promo Disc (USA) (Track 1).bin" size="25199328" crc="f6d1e0ec" md5="35e6f50c3e0ec2628dd14ee3495600ff" sha1="4b3312cfd071c7010d4a3c6949216ffad764bfc2" />
<rom name="PGS - Promo Disc (USA) (Track 2).bin" size="28955472" crc="92541dae" md5="11a72eb9f5c78491d5af695711379466" sha1="46372e3a0fabea96d0ee9e3620fddb47f0dbb60e" />

FILE "PGS - Promo Disc (USA) (Track 1).bin" BINARY
  TRACK 01 AUDIO
    INDEX 01 00:00:00
FILE "PGS - Promo Disc (USA) (Track 2).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

LBA 10714 belongs to the track 2 but I think DIC takes it as a part of track 1 and just goes 150 sectors deeper than needed
similar issue is LBA 23025, it's part of lead-out if you carefully pay attention

That fixed the problem with this disc. Thank you!

Logs

A relatively recent dump of a particular PCECD disc (Metamor Jupiter) produced a bad track split, where the hashes for track 15 and track 16 are incorrect.

Good:

Size       CRC-32      MD5                                 SHA-1
7215936    fef20b14    2693317a11581563a98f9a9e72b45afc    526e924a854386551b61132530554e09ca451351
1782816    45e68246    e04fcddf7ca970d7145150f75a3f87e3    9582d51f818c8b2199cca857d73436050294969e

Bad:

Size       CRC-32      MD5                                 SHA-1
7213584    b4c98d36    b60e8342f0e91616643f05148e7ea8af    65be947f99c19bee9de86c50e6b5998f074d75e7
1785168    f43f7f32    03269f4c740f5682cd16af5327e3ec5d    af1343106597a462eed5d0f9a99109ac92f03a54

Here are the logs: http://forum.redump.org/misc.php?action … download=1

The checksum for the total img file (074a677b) was correct.
Any ideas what could have caused DIC to produce a bad dump of these two tracks?

sarami, LBA 047437 belongs to track 15. First of all, standard says that if track or index ends with Q without positional information it belongs to the current track, not to the next one. I'm too lazy to search through it but trust me.
Next, check P values from your subchannel decode, P[00] for LBA 047437 shows that it belongs to the previous track.
The dump in DB is correct.

I understand your point that P change is not always an indicator of a track change, no objections here. However this is supplemental thing here.

Main problem is that Mode 2 Q (MCN) @ LBA 47437 separates track 15 and track 16. Here are the reasons why MCN should always belong to the previous track:

1. When playing the music, ordinary audio CD player plays it from left to right, MCN/ISRC frames repeat each 1/100 frames and are informational. Current track number is stored as a current state of audio player and it switches only when it changes in in Mode 1 Q which will happen after the MCN/ISRC as current track information is not stored in Mode 2 or Mode 3 Q.

2. New track always starts from Mode 1 Q. I think I saw that somewhere in rainbow books, unfortunately I cannot find it right now. Although this statement is implied throughout documentation, for instance open MMC-3 working draft page 26:
"4.2.3.4.3 ADR=3 (0011b) – Mode-3 Q"
"The ISRC may only change immediately after the Track Number (TNO) has been changed."

I understand you're trying to do some guesswork based on 150 standard gap size or even establishing that P is shifted 1 sector for each track so start is always shifted in relation to that or something but that is unsafe.

https://github.com/saramibreak/DiscImag … g/20230201

*2023-02-01
- added: support the c2 offset of the plextor 712A or newer
- added: change the default path of the driveOffset.txt file on linux
- added: fix subQ using next subQ when crc does not match by index 0
- added: /d option (hash sha224, sha256, sha384, sha512)
- added: /sk for dvd
- changed: do not use the combined offset in .c2
- changed: set mode using LBA 11
- changed: remove printing directory from .dat output file on linux
- fixed: forgot .raw hashing
- fixed: failed to read directory record when record size is more than the max transfer length (only GD-ROM)
- fixed: check subchannel of lead-in of the 2nd session
- fixed: cue indexes when there is index 2 or more in track 1
- fixed: detecting ARccOS

It has supported for just one year now (20220201).

        /vrfy   Check non-zero byte in the lead-out and pregap of 1st track (Only Audio CD)
                        val     0: audio cd can be read without offset (default)
                                1: audio cd can be read with offset
                                    and select 'y' then read without offset or select 'n' then not read
                                2: logs are only generated with offset

Why not report as a bug if it is really true?