Redump Forum — Known cases where Asus dumps fail ?

Re: Known cases where Asus dumps fail ?

null@example.com (Nemok) — Fri, 29 Sep 2023 10:51:28 +0000

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!

Re: Known cases where Asus dumps fail ?

null@example.com (Nemok) — Wed, 20 Sep 2023 08:49:54 +0000

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.

Re: Known cases where Asus dumps fail ?

null@example.com (bikerspade) — Mon, 18 Sep 2023 01:41:28 +0000

/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

Re: Known cases where Asus dumps fail ?

null@example.com (Nemok) — Mon, 21 Aug 2023 15:48:32 +0000

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]

Known cases where Asus dumps fail ?

null@example.com (Nemok) — Wed, 14 Jun 2023 19:58:46 +0000

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 http://redump.org/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 http://redump.org/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 ?