DiscImageCreator

[bikerspade]

If a track has an invalid ISRC code (example: "0@4010000000")

Does it means you have the weird disc? If yes, upload logs plz.

Logs attached here: /viewtopic.php?t=37220 … -tycoon-2/

[sarami]

If a track has an invalid ISRC code (example: "0@4010000000"), will that mean DiscImageCreator will not add it to the cuesheet?

Yes. I check it by the "IsValidSubQAdrISRC" function.

[yamboo-efi]

I don't know If it's really a bug. I'm trying to dump a ringed disc with audio tracks. After dumped it with CloneCD, opened the result with CDMage to see what files are affected. I put them in "ReadErrorProtect.txt" and dumped the disc with /sf flag.

They detect the files, and skip the bad sectors, but the in the resulting .bin not all skipped sectors are filled with 0x55.

Code: Select all

LBA[019811, 0x04d63], MSF[04:26:11], 2336 bytes have been already replaced at 0x55
LBA[019812, 0x04d64], MSF[04:26:12], 2336 bytes have been already replaced at 0x55
LBA[019813, 0x04d65], MSF[04:26:13], 2336 bytes have been already replaced at 0x55
LBA[019814, 0x04d66], MSF[04:26:14], 2336 bytes have been already replaced at 0x55
LBA[019815, 0x04d67], MSF[04:26:15], mode 1 User data vs. ecc/edc doesn't match
LBA[019816, 0x04d68], MSF[06:f9:12], bad msf
LBA[019817, 0x04d69], MSF[06:f9:12], bad msf
LBA[019818, 0x04d6a], MSF[06:f9:12], bad msf
LBA[019819, 0x04d6b], MSF[06:f9:12], bad msf
LBA[019820, 0x04d6c], MSF[06:f9:12], bad msf

The sectors with "bad msf" (019816 - 021554) contains random data.

The skipped range should be 19816-2134. Not all files are bad, but that is the whole range.

The real bad sectors are 19802-21412.

Also detected that "ReadErrorProtect.txt" need to ends with an empty line, if not end with it last line (filename) won't be parsed.

Logs: https://drive.google.com/file/d/1Dbb_pb … sp=sharing

[user7]

Hi sarami, a month or so back a dic dump I submitted on behalf of CDO was been rejected, see - /viewtopic.php?t=39073 … lightning/

The logs for a dump of Blue Lighting can be found here - redumped with the latest DIC build (it still has the same rejected hashes as the previous dump) https://archive.org/download/bluelightning-jag-cd

Interestingly, the hashes are different than those of the redumper app (logs for which are also present in this archive entry).

[sarami]

Interestingly, the hashes are different than those of the redumper app (logs for which are also present in this archive entry).

Mastering Code is different. Simply, it's another version? I'm not sure.

[user7]

>Mastering Code is different. Simply, it's another version? I'm not sure.

Different than in redump, but that is not what i'm talking about. The DIC dump is considered bad - see /viewtopic.php?t=39073 … lightning/

[sarami]

see

probably the dump is not correct.

I don't know why Lizard thinks of it.

[ehw]

Hey sarami, I think I found a bug or two.

We're dumping GD-ROMs with DIC and we're noticing that when we get any sort of seek error while dumping, it continues to have seek errors for the rest of the dump, usually on every sector or so. When this happens the drive slows to a crawl and never seems to get faster again. I thought that it might've had something to do with the disc itself but it seems to be random.

Code: Select all

DiscImageCreator.exe" gd G "SONIC2T-708a\SONIC2T.bin" 12 /c2 1000
AppVersion
        32 bit, AnsiBuild, 20220707T220452
/c2 val2 was omitted. set [0]
CurrentDirectory
        D:\Sazpaimon\Downloads\VGPC GD-Rom Dumping Kit
WorkingPath
         Argument: SONIC2T-708a\SONIC2T.bin
         FullPath: D:\Sazpaimon\Downloads\VGPC GD-Rom Dumping Kit\SONIC2T-708a\SONIC2T.bin
            Drive: D:
        Directory: \Sazpaimon\Downloads\VGPC GD-Rom Dumping Kit\SONIC2T-708a\
         Filename: SONIC2T
        Extension: .bin
StartTime: 2022-08-22T11:06:39-0400
Set the drive speed: 2116KB/sec
DiskSize of [D:\Sazpaimon\Downloads\VGPC GD-Rom Dumping Kit\SONIC2T-708a]
        Total: 14000516493312 bytes
         Used:  5671329619968 bytes
        ---------------------------
        Space:  8329186873344 bytes
         => There is enough disk space for dumping
This drive supports [OpCode: 0xd8, SubCode: 0]
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking SubQ adr (Track)  3/ 3
Checking SubRtoW (Track)  3/ 3
Reading DirectoryRecord    2/   2
Set OpCode: 0xd8, SubCode: 8(Raw)
Creating .scm from 44999 to 549150 (LBA) 431408 LBA[431409, 0x69531] Detected C2 error 847 bit
LBA[439363, 0x6b443]: [F:FlushDriveCache][L:220]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[439364, 0x6b444]: [F:FlushDriveCache][L:220]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE
LBA[439364, 0x6b444]: [F:FlushDriveCache][L:220]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-00 = MEDIUM_ERROR - NO SEEK COMPLETE

This occurs with a TS-H353A and PX-708A, which was recently confirmed to read GD-ROMs as well. This is occurring on our Sonic Adventure 2 GD-ROM, Sonic Adventure 2 The Trial GD-ROM, and a copy of Flag to Flag. So it doesn't seem unique to a particular disc or drive...

It seems to occur randomly. I was able to dump Sonic Adventure 2 alright without seek errors occurring. If it finishes dumping when it encounters seek errors, it does affect the final output (which still gets descrambled)
https://i.imgur.com/RBM3Zqa.png

Is there something we can do? Let me know if you need more logs/info.

Also, somewhat unrelated to dumping GD-ROMs, I'm noticing that DIC will still descramble and generate images if it encounters "This sector is data, but sync is invalid" errors. I'm not sure why, DIC doesn't reread these sectors that were read with sync issues. DIC retries when it encounters C2 errors, but not these kind of errors. When these errors occur, it results in detectable errors in the final dump. I know some games can be mastered with intentional errors, but what about a scenario where the drive is at fault? Couldn't DIC compensate by rereading sectors that spawn an error for sanity checks?

Here's an example we encountered. We were dumping a CD-R of "Arcade's Greatest Hits Williams" for the PSX. DIC was able to dump the entire disc and correct any C2 errors. But the EccEdc log still reports errors. We dumped the disc twice and there are unique errors in each dump, despite the dump finishing. Here are the logs:
https://www.mediafire.com/file/1042qzolb28tcnp/Arcade's+Greatest+Hits+Williams+PSX_logs.zip/file
https://www.mediafire.com/file/sq7jnsy0rwlov79/Arcade's+Greatest+Hits+Williams+PSX+[DUMP+2]_logs.zip/file

I've encountered issues like this on other drives, even Plextor drives. I think when this occurs its due to the drive itself, or the adapter if one is used. But can DIC do something in scenarios like this? Couldn't it just reread the sector again if it encounters a sync error and see if it still occurs?

Hope this helps.

[sarami]

Is there something we can do?

You can use /f flag. This is used to control "FlushDriveCache" function.

Code: Select all

        /f      Use 'Force Unit Access' flag to delete the drive cache
                        val     delete per specified value (default: 1)

If you use "/f" (no value), app call "FlushDriveCache" per sector.
If you use "/f 1", app calls "FlushDriveCache" per sector.
If you use "/f 2", app calls "FlushDriveCache" per 2 sectors.
If you use "/f 3", app calls "FlushDriveCache" per 3 sectors.
:
:
If you use "/f 10000", app calls "FlushDriveCache" per 10000 sectors.

Couldn't DIC compensate by rereading sectors that spawn an error for sanity checks?

I'll consider it. But sync is corrupt for some protection and bad mastering discs. App can controls rereading when the protection flag (/sf /ns) is used, but it can't judge if the disc is bad mastering or not.

[ehw]

Is there something we can do?

You can use /f flag. This is used to control "FlushDriveCache" function.

Code: Select all

        /f      Use 'Force Unit Access' flag to delete the drive cache
                        val     delete per specified value (default: 1)

If you use "/f" (no value), app call "FlushDriveCache" per sector.
If you use "/f 1", app calls "FlushDriveCache" per sector.
If you use "/f 2", app calls "FlushDriveCache" per 2 sectors.
If you use "/f 3", app calls "FlushDriveCache" per 3 sectors.
:
:
If you use "/f 10000", app calls "FlushDriveCache" per 10000 sectors.

That worked, thanks! We're doing some more experimentation with GD-ROMs and GD-Rs with various drives so will keep you updated if I find more issues with these...