redump.info Forum

I've been recently spending some time on a small number of Mega CD and Saturn discs, and discovered that 1 out of my 12 discs did not match any redump hashes using DIC and my Asus BW-16D1HT 3.02.

For that particular disc however, the old isobuster/EAC method and a +667 offset Pioneer BD drive allowed me to get matching results with https://redump.info/disc/8167/, a +1644 write offset disc.

So far, the disc with the highest positive write offset that I've successfully dumped with the Asus is https://redump.info/disc/17715/ with a +1362 write offset.

If I understand this correctly, the failure is only due to the Asus' maximum positive write offset tolerated value, somewhere between +1362 and +1644, and not due to the read method at least in this case.

What do you think ?

Using 0xf1 opcode for retrieving cache through the /mr command in DIC allows to get the last 21 sectors of the last track and a varying number of sectors in the lead-out, most of the time 10 to 15 sectors.

It seems to work fine for different positive write offset discs :
+0    ->    9 lead-out sectors    (= 0 lead-out samples required / 5292 available)
+18    ->    16 lead-out sectors    (= 18 lead-out samples required / 9408 available)
+19    ->    12 lead-out sectors    (= 19 lead-out samples required / 7056 available)
+925    ->    11 lead-out sectors    (= 925 lead-out samples required / 6468 available)
+1362    ->    12 lead-out sectors    (= 1362 lead-out samples required / 7056 available)

But for the highest positive write offset value disc :
+1644    ->    1 lead-out sector    (= 1644 lead-out samples required / 588 available)

That's why the dump fails in this case.
I still don't know what the maximum write offset is for the BW-16D1HT.

Please correct me if I'm wrong.

NB :
I noticed that the very last lead-out sector sometimes shows a strange MSF like :
...
31 Cache LBA 270416, SubQ Trk aa, AMSF 60:07:41 [Lead-out]
32 Cache LBA 270417, SubQ Trk aa, AMSF 60:07:42 [Lead-out]
33 Cache LBA 270418, SubQ Trk aa, AMSF 56:21:06 [Lead-out]

In the case of the +1644 disc, the last sector of the last track also shows a lead-out SubQ :
...
19 Cache LBA 088950, SubQ Trk 12, AMSF 19:48:00
20 Cache LBA 088951, SubQ Trk 12, AMSF 19:48:01
21 Cache LBA 088952, SubQ Trk aa, AMSF 19:48:02
22 Cache LBA 088953, SubQ Trk aa, AMSF 18:41:24 [Lead-out]

/mr is unreliable. It can sometimes return garbage bytes in the last 24 bytes. Use RibShark’s 3.10 firmware which eliminates the need for /mr

bikerspade wrote:/mr is unreliable. It can sometimes return garbage bytes in the last 24 bytes. Use RibShark’s 3.10 firmware which eliminates the need for /mr

I'll try this firmware when I have time. Thank you.

The modified firmware with direct lead-out reading allowed me to solve the issue I had with this particular high positive offset disc and get a dump that matches the one in the database. Provided there's no regression introduced, this firmware is a major step forward, thanks to Ribshark!