DiscImageCreator doesn't retry C2 errors properly when dumping GD-ROMS with /c2 (var1) 0 or /c2 (var1) 1 using a compatible drive #146
Comments
|
Hey there, thanks for looking into it. https://hiddenpalace.org/Sonic_Adventure_(Jun_8,_1999_prototype) The one on the site is based on an old BBA dump when the disc was in better shape back in 2008. We didn't make these attempts in DIC public because we haven't gotten a good dump in anything yet. The old dump is free from any errors (we checked the EDC/ECC data). Let us know if you want to see the raw dumps with DIC and DCDumper so far. We save every attempt. :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Version
20220707T220452
Describe the bug
Note: These errors seem to occur on any drive that natively supports C2 retries (like the PX-708a, PX-760a, etc). This occurs with the "gd" command, VGPC audio trap disc (549150 sector TOC), and any GD-ROMs with slight defects (small scratches, etc). Even though TSST drives are recommended, you absolutely can dump these discs with certain Plextors, and it should be encouraged because of the ability to do C2 and scrambled reads.
When using /c2 (var1) 0 (default behavior):
DiscImageCreator is substituting sectors in the .scm with $00 upon rereading discovered C2 errors when dumping with a compatible drive when the second parameter in the /c2 command is set to 0 (which is default for Plextors). For some reason, the drive will only reread each c2 error exactly once, and will always return the same crc32 value (0xbe97ce3f). DIC never successfully retries a c2 error at all. For example, here are the first five c2 errors for this dump:
This is what DIC tries to do. It only does exactly one attempt per c2 error, returning the same crc32 value for each (because the value is based off of a completely 00'd out sector):
When using /c2 (var 1) 1 (read from beginning to end of sector):
If the /c2 command's second variable is set to 1 instead (which rereads the entire disc from the beginning up to where the error occurs), DIC seems to try to correct sectors that aren't even marked for correction, causing the .scm to have MORE errors after the c2 "retries" than before it retries anything. DIC marks the sectors in the beginning of the c2 error log as its creating the .scm file correctly, but as it steps through the beginning of the HD layer (45000). it randomly starts to "correct" sectors that never reported any errors. For instance, we saved a copy of the .scm file after it finished dumping and saved another copy after the c2 errors were retried and ran a ECC/EDC checker that we made ourselves, and we determined that there were more errors in the .scm file after DIC had retried the c2 errors than before. See the attached logs for comparison, but to give you an idea:
In the dump attempt where /c2 (var 1) 1 is used, it marked sector 470916 as the first sector for correction. However, running the .scm after DIC retries the C2 errors in a program to check for ECC/EDC errors in a scrambled dump, there are errors at Sector 90000 which weren't present in the version of the .scm before retries were made. Sector 90000 (20:02:00 0x64ef450) has an error that was caused by the c2 retries according to the .scm file. This sector doesn't appear marked as an error in the c2 error log file. For this sector, it reports this:
But since it returned the same crc32, it didn't do any rewrites. So why did it change in the .scm after the retries?
LBA[089999, 0x15f8f]: to[090000] All same crc32. No rewrite
LBA[090000, 0x15f90]: to[090001] All same crc32. No rewrite
LBA[090001, 0x15f91]: to[090002] All same crc32. No rewrite
Ultimately, regardless of what happened in both dumps, despite there being clear c2 errors that were uncorrectable, DIC still descrambled and provided an output anyway.
Screenshots
/c2 (var1) 0 output scm comparison:
This is an image of a comparison between the .scm before DIC retries the sectors with marked c2 errors, and after it retries. Notice how after DIC retries the sector, its all filled with $00.
/c2 (var1) 1 output scm comparison:
This is an image of a comparison between the .scm before DIC retries the sectors with marked c2 errors, and after it retries every single sector starting from 45000. Notice how despite the DIC log file (included below) says that the first c2 error is at sector 471267, there is a difference at sector 90000. The scm before the c2 retries is correct at this sector, the scm after the c2 retries is wrong. Nothing in any DIC log indicates sector 90000 was an issue, so I don't know why this happened:
Disc title
Sonic Adventure - E3 Trial Edition (GD-ROM)
Disc ringcode
Mastering Code: MK-51015-0101 1MM1 C 96
Mastering SID Code: IFPI L223
Toolstamp or Mastering Code: (BLANK)
Mould SID Code: (BLANK)
URL
Tell me the link to get the disc.
Rare disc, can't be obtained easily. Issue is caused by some small surface damage on the disc. These issues can occur on any GD-ROM we think.
Log file
DIC Log Files:
Dump 2 (/c2 var2 is 0): https://www.mediafire.com/file/ggq5w2cptivlj72/sa+e3+dump+2+-+c2+var2+is+0.7z/file
Dump 1 (/c2 var2 is 1): https://www.mediafire.com/file/c9i70ztepfd0qqh/sa+e3+dump+1+-+c2+var2+is+1.7z/file
ECC/EDC logs for Dump 1 (/c2 var2 is 1), on a copy of the scm before c2 retries, and on a copy of the scm after c2 retries which contains more errors: https://www.mediafire.com/file/ymx0mxbbv47lgtm/sa+e3+dump+2+-+eccedc+scans+before+and+after+c2+retries.zip/file
The text was updated successfully, but these errors were encountered: