<![CDATA[Redump Forum — Known cases where Asus dumps fail ?]]> 2023-09-29T10:51:28Z PunBB http://forum.redump.org/topic/50113/known-cases-where-asus-dumps-fail/ <![CDATA[Re: Known cases where Asus dumps fail ?]]> 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!

]]> http://forum.redump.org/user/63612/ 2023-09-29T10:51:28Z http://forum.redump.org/post/112206/#p112206 <![CDATA[Re: Known cases where Asus dumps fail ?]]> 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.

]]> http://forum.redump.org/user/63612/ 2023-09-20T08:49:54Z http://forum.redump.org/post/112007/#p112007 <![CDATA[Re: Known cases where Asus dumps fail ?]]> /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

]]> http://forum.redump.org/user/63146/ 2023-09-18T01:41:28Z http://forum.redump.org/post/111941/#p111941 <![CDATA[Re: Known cases where Asus dumps fail ?]]> 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]

]]> http://forum.redump.org/user/63612/ 2023-08-21T15:48:32Z http://forum.redump.org/post/111292/#p111292 <![CDATA[Known cases where Asus dumps fail ?]]> 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 ?

]]> http://forum.redump.org/user/63612/ 2023-06-14T19:58:46Z http://forum.redump.org/post/109987/#p109987