3,276

sarami wrote:
Novicami wrote:

It's a empty file

Test build
https://www.mediafire.com/file/eq80y20l … st.7z/file

Fixed, thank you!
https://mega.nz/file/xZETEZDK#W5aKQe8z1 … ex77ZWsjE8

3,277

@sarami: Thanks for confirming. Makes sense.  smile

ATAPI iHBS212 2 HL05 (+6) | LG BH16NS40 (+6) | Plextor PX-W4824TA (+98) | Plextor PX-708A (+30)

3,278

Novicami wrote:

Fixed, thank you!

Thanks, but misdetection still exists.

LBA 357, Check if the directory record length (114) is really correct -> incorrect. Fixed it to 54
LBA 1690, Check if the directory record length (128) is really correct -> incorrect. Fixed it to 67
LBA 1142, Check if the directory record length (112) is really correct -> incorrect. Fixed it to 51
LBA 1369, Check if the directory record length (114) is really correct -> incorrect. Fixed it to 54
LBA 1480, Check if the directory record length (152) is really correct -> incorrect. Fixed it to 91
LBA 3352, Check if the directory record length (128) is really correct -> incorrect. Fixed it to 67
LBA 523, Check if the directory record length (102) is really correct -> incorrect. Fixed it to 41
LBA 2219, Check if the directory record length (132) is really correct -> incorrect. Fixed it to 71

More test please if possilble.
https://www.mediafire.com/file/eq80y20l … st.7z/file

3,279 (edited by Novicami 2022-07-23 12:10:23)

sarami wrote:

Thanks, but misdetection still exists.
More test please if possilble.

I hadn't noticed that...obviously, I'm going to continue testing!

LBA 357, Check if the directory record length (114) is really correct -> incorrect. Fixed it to 54
LBA 1690, Check if the directory record length (128) is really correct -> incorrect. Fixed it to 67
LBA 1142, Check if the directory record length (112) is really correct -> incorrect. Fixed it to 51
LBA 1369, Check if the directory record length (114) is really correct -> incorrect. Fixed it to 54
LBA 1480, Check if the directory record length (152) is really correct -> incorrect. Fixed it to 91
LBA 3352, Check if the directory record length (128) is really correct -> incorrect. Fixed it to 67
LBA 2219, Check if the directory record length (132) is really correct -> incorrect. Fixed it to 71

https://mega.nz/file/dMciWQab#AKzje_w6i … EGKuqJeW1U

3,280

Sorry, fixed typo.
https://www.mediafire.com/file/eq80y20l … st.7z/file

3,281

It's better but no perfect ;-)

LBA 1480, Check if the directory record length (152) is really correct -> incorrect. Fixed it to 91

https://mega.nz/file/NMsWEKiI#rWnYen-g3 … Pc40YhifDs

3,282

More changed.
https://www.mediafire.com/file/eq80y20l … st.7z/file

3,283

It looks good now :
https://mega.nz/file/EFV0iLJQ#cK-qLKbBu … DfQP8mVgp0

3,284

I wanted to ask about RipGuard. Is blanking out the error sectors the only way to handle these? Like is there actual data that in theory could be dumped so they aren't eligible for redump?

NumberOfProgramChain: 30840
Detected irregular title number
Detected protection [MVSNRGFP]
Detected Anchor Volume Descriptor Pointer: LBA 3658991
Outputted to _xxxKey.txt

Error sectors range: LBA 15456 to 15487 = 32 -> Filled with 0x00
Error sectors range: LBA 96672 to 96719 = 48 -> Filled with 0x00
Error sectors range: LBA 98064 to 98111 = 48 -> Filled with 0x00

Should support for the /rr flag be added for dumping xbox and xbox 360 discs?

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,286

bikerspade wrote:

Should support for the /rr flag be added for dumping xbox and xbox 360 discs?

Added. Not test.
https://www.mediafire.com/file/eq80y20l … st.7z/file

sarami wrote:
bikerspade wrote:

Should support for the /rr flag be added for dumping xbox and xbox 360 discs?

Added. Not test.
https://www.mediafire.com/file/eq80y20l … st.7z/file

The read retry value I provided was ignored, perhaps it is hard-coded to always attempt no more than 5 retries?

D:\tmp\MPF_WIP_2.3-896\ISO\[XBOX] Halo 2 [TEST]>..\..\Programs\DiscImageCreator_test_20220807\DiscImageCreator.exe xbox H Halo2.iso 24 /q /rr 1000
AppVersion
        32 bit, AnsiBuild, 20220807T102634
CurrentDirectory
        D:\tmp\MPF_WIP_2.3-896\ISO\[XBOX] Halo 2 [TEST]
WorkingPath
         Argument: Halo2.iso
         FullPath: D:\tmp\MPF_WIP_2.3-896\ISO\[XBOX] Halo 2 [TEST]\Halo2.iso
            Drive: D:
        Directory: \tmp\MPF_WIP_2.3-896\ISO\[XBOX] Halo 2 [TEST]\
         Filename: Halo2
        Extension: .iso
StartTime: 2022-08-07T01:35:35-0500
Set the drive speed: 0KB/sec
DiskSize of [D:\tmp\MPF_WIP_2.3-896\ISO\[XBOX] Halo 2 [TEST]]
        Total:  4000650883072 bytes
         Used:  1785744601088 bytes
        ---------------------------
        Space:  2214906281984 bytes
         => There is enough disk space for dumping

Reading DirectoryRecord    2/   2
Reading Xbox DirectoryRecord
LBA[094240, 0x17020]: [F:ReadDVD][L:331]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
This sector is out of the ss ranges. Read retry (Pass 1/5)
LBA[094240, 0x17020]: [F:ReadDVD][L:331]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
This sector is out of the ss ranges. Read retry (Pass 2/5)
LBA 94240 is retry OK
LBA[094592, 0x17180]: [F:ReadDVD][L:331]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
This sector is out of the ss ranges. Read retry (Pass 1/5)
LBA[094592, 0x17180]: [F:ReadDVD][L:331]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
This sector is out of the ss ranges. Read retry (Pass 2/5)
LBA[094592, 0x17180]: [F:ReadDVD][L:331]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
This sector is out of the ss ranges. Read retry (Pass 3/5)
LBA[094592, 0x17180]: [F:ReadDVD][L:331]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
This sector is out of the ss ranges. Read retry (Pass 4/5)
LBA[094592, 0x17180]: [F:ReadDVD][L:331]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
This sector is out of the ss ranges. Read retry (Pass 5/5)
LBA[094592, 0x17180]: [F:ReadDVD][L:331]
        Opcode: 0xa8
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-64-00 = ILLEGAL_REQUEST - ILLEGAL MODE FOR THIS TRACK
Retry NG
EndTime: 2022-08-07T01:37:29-0500
BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,288

bikerspade wrote:

perhaps it is hard-coded to always attempt no more than 5 retries?

Fixed.
https://www.mediafire.com/file/eq80y20l … st.7z/file

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

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,290

bikerspade wrote:

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

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

sarami wrote:
bikerspade wrote:

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: http://forum.redump.org/topic/42894/ibm … -tycoon-2/

BW-16D1HT | PX-W4824TU | PX-W5224A | PX-760A | PX-712A | Plextor Premium | Pioneer 209DBK | TS-H352C | TS-H353A | Wii

3,292

bikerspade wrote:

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.

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.

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

3,294

Hi sarami, a month or so back a dic dump I submitted on behalf of CDO was been rejected, see - http://forum.redump.org/topic/44992/wip … 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).

All my posts and submission data are released into Public Domain / CC0.

3,295

user7 wrote:

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.

3,296

>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 http://forum.redump.org/topic/44992/wip … lightning/

All my posts and submission data are released into Public Domain / CC0.

3,297

user7 wrote:

see

Lizard wrote:

probably the dump is not correct.

I don't know why Lizard thinks of it.

3,298

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.

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.

3,299

ehw wrote:

Is there something we can do?

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

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


ehw wrote:

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.

3,300

sarami wrote:
ehw wrote:

Is there something we can do?

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

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