C2 error fixing bugs

[MrPepka]

Version Using latest test version

Describe the bug I tested the latest test version of DIC and to be honest there is still something wrong with fixing C2 bugs. DIC no longer crashes when trying to fix these bugs, but the DIC itself doesn't seem to even try to fix these bugs. After the dump is complete, when DIC is supposed to fix C2 errors, instead of doing that, it just loads the number of attempts to fix these errors until it is finished (for example, if I set the first parameter of the /c2 command to 20, DIC loads these 20 attempts and then claims that more attempts are needed, if I set it to 5000 it gets 5000 attempts and does it fast enough that you can see that DIC is not really trying to fix these errors in any way). The problem, of course, only occurs in the LG drive (BH16NS40), it works fine on Plextor Second thing. When I set the C2 offset manually, for example, 295 and set the /s 2 command, the drive does not detect C2 errors, but bad sectors are still damaged (ECCEDC detects at least 2 errors, although DIC says there are no C2 errors), I skip that with the /s 2 command, regardless of the set speed, CD dumping takes far too long (even several hours). For comparison, the Plextor PX-712A needs several minutes to dump the disc with the /s 2 command Log file https://mega.nz/file/EvpA3bQA#yatNCf-UQUUsgo4C6g09KMnKewOHYh_M_yBzoQrkqSs

[MrPepka]

I've just discovered that when I dump the Settlers: Dziedzictwo Królów game disc (SafeDisc disc) it tries to fix the C2 errors (the number of retries goes slower than other discs where the number of retries runs out quite quickly), but still the DIC doesn't try to fix the errors C2

[saramibreak]

I tested many times and understood that LG/ASUS drive (0xf1 is used) can't reread to infinity. Minimum is 500 or so, Maximum is 2000 or so. This value varies every time. If rereadings are beyond this value, the drive always returns same hash.

[MrPepka]

Um, I don't think we understood each other. I did not write about reading from the cache, only about re-reading the sectors where the C2 error is (in order to fix this error). The DIC does not fix these C2 errors in the LG drive, it only very quickly counts the number of retries to read the sector with the C2 error, and then claims that they could not be repaired. This function works in other programs like redumper so it's a problem with DIC

[saramibreak]

See zzz_c2Error.txt

The DIC does not fix these C2 errors in the LG drive, it only very quickly counts the number of retries to read the sector with the C2 error

Yes, because same hash (0x4043f7be) is generated eternally.

[MrPepka]

Then why redumper is able to fix C2 errors on LG but not DIC? The re-read value is usually 20 by default for me. Can something be done about what you write or is it some kind of firmware limitation?

[saramibreak]

I tested many times and understood that LG/ASUS drive (0xf1 is used) can't reread to infinity. Minimum is 500 or so, Maximum is 2000 or so. This value varies every time. If rereadings are beyond this value, the drive always returns same hash.

• changed: rereading logic DiscImageCreator_test.zip

[MrPepka]

It works :D Thank you very much for the fix