You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
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
@sarami: Thanks for confirming. Makes sense. 
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
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 71It's better but no perfect ;-)
LBA 1480, Check if the directory record length (152) is really correct -> incorrect. Fixed it to 91It looks good now :
https://mega.nz/file/EFV0iLJQ#cK-qLKbBu … DfQP8mVgp0
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 0x00Should support for the /rr flag be added for dumping xbox and xbox 360 discs?
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
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-0500perhaps it is hard-coded to always attempt no more than 5 retries?
If a track has an invalid ISRC code (example: "0@4010000000"), will that mean DiscImageCreator will not add it to the cuesheet?
If a track has an invalid ISRC code (example: "0@4010000000")
Does it means you have the weird disc? If yes, upload logs plz.
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/
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 msfThe 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.
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).
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.
>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/
see
probably the dump is not correct.
I don't know why Lizard thinks of it.
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 COMPLETEThis 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.
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.
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 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...
Redump Forum → General discussion → DiscImageCreator
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.