DiscImageCreator does not fix C2 errors on BW-16D1HT drive with firmware 3.10

[MrPepka]

Version I have latest test version

Describe the bug When DIC encounters a C2 error while dumping a disc, it does not try to fix it. This problem was previously present on the BH16NS40 drive, now it is present on the BW-16D1HT. The problem appeared after changing the firmware from 3.00 to 3.10 (I'm using this modded firmware from RibShark), in the earlier firmware repairing C2 worked fine. Since fixing C2 works in other programs (e.g. in redumper) I suspect that the DIC is trying to use the read cache command in this firmware, but the 3.10 firmware no longer supports this command. Is it possible to introduce a rule in the code so that the DIC does not use the read cache command when using firmware 3.10 for BW-16D1HT? If that's not where the problem is, then I have no idea where (I'm not a programmer)

[saramibreak]

I don't know the modified firmware. What can be done with that firmware?

[MrPepka]

RibShark wrote about this modded firmware on VGPC Discord. In short, he modified firmware 3.10 enough to enable lead-out reading without the cache trick. The firmware can be downloaded from this link - https://cdn.discordapp.com/attachments/429374270607720461/960431754357927946/ASUS-BW-16D1HT-3.10-WM01601-211901041014_MK_edited.bin (here is a link to a flasher that can flash the firmware - https://www.mediafire.com/file/8zujcivqfiidq7b/SDFtool+Flasher+%28v1.3.3%29.zip/file )

[MrPepka]

And about flashing this firmware, flash the 3.10MK firmware first - https://cdn.discordapp.com/attachments/351024247411441664/861691990835986490/ASUS_ODD_FW_Changer_-_ASUS_BW-16D1HT-3.10-MK.exe, and then flash this RibShark firmware

[saramibreak]

When DIC encounters a C2 error while dumping a disc, it does not try to fix it.

Is there logs?

[MrPepka]

I have that - https://mega.nz/file/Jyg1zDAL#VOpMUGtWaeozD74Ylnw1a5mIcdrbdtzBqyoT2H4cBP0 https://mega.nz/file/sjgiHA7I#UydGt6mtAzePib7QwBn5pjapq1cMXl1Q3wzShhJo594 The drive seems to give identical hashes for C2 errors, but I have the impression that the DIC tries to use the cache command in this drive, regardless of whether the drive's firmware supports this command or not (and the 3.10 firmware does not support the cache command). Giving identical data for C2 errors is not a feature of the drive firmware because, for example, the redumper corrects the C2 errors correctly on the same drive and the same firmware - https://mega.nz/file/8vQ1BJrL#tmdvJW8blaXNBI0PZV5rO9JEVLyqgjP0KCnwRtdbIvw

[saramibreak]

I have the impression that the DIC tries to use the cache command in this drive

It's no. The drive and firmware can read the lead-out correctly like plextor. DIC doesn't use the cache command in the firmware.

This drive (BW-16D1HT        3.10 WM01601SIK9QH28G165 ) can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 0]
This drive (BW-16D1HT        3.10 WM01601SIK9QH28G165 ) can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 1]
This drive (BW-16D1HT        3.10 WM01601SIK9QH28G165 ) can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 2]
This drive (BW-16D1HT        3.10 WM01601SIK9QH28G165 ) can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 4]
Checking reading lead-out -> OK

C2 error fixing function can be read correctly, but correct hash can't get forever? I'm not sure about the reason now.

[saramibreak]

DiscImageCreator_test.zip

• changed: transfer length

[MrPepka]

Fixed, thx