You are not logged in. Please login or register.
Redump Forum → Posts by Nemok
OK those issues are now fixed.
The program gets further but fails at checking subQ address for each track :
LBA[088444, 0x1597c]: [F:ReadCDForCheckingSubQAdr][L:1076]
Opcode: 0xbe
ScsiStatus: 0x02 = CHECK_CONDITION
SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 01, 59, 7c, 00, 00, 01, f8, 01, 00
dwBufSize: 4896Indeed subchannel is zeroed. So pack mode never really was supported even if a dump in this mode could be started. Fine.
Also discovered today :
- Discs with data and audio tracks cannot be dumped anymore using ribshark. DIC throws errors like this one:
LBA[083296, 0x14560]: [F:ReadCDForCheckingSubRtoW][L:1283]
Opcode: 0xbe
ScsiStatus: 0x02 = CHECK_CONDITION
SenseData Key-Asc-Ascq: 03-11-05 = MEDIUM_ERROR - L-EC UNCORRECTABLE ERROR
lpCmd: be, 00, 00, 01, 45, 60, 00, 00, 01, f8, 01, 00
dwBufSize: 2448- DIC often fails to get write-offset on first attempt.
Nemok wrote:Pack mode without /c2 is still broken.
It's not broken. LG/ASUS does not support the pack mode.
How to explain this ? Were previous DIC releases wrong about it ?
For anyone that still tries to get the best DPM approximation possible.
I have written a small bash script program that moves the DPM content into an old format MDS container (convert). This allows manual editing of the DPM values with Advanced MDS editor 0.5.5 and BWA edit 1.1 since these are incompatible with what the latest Alcohol releases create. The edited DPM content may then be put back inside its new format container (rebuild).
Raw mode with /c2 is fixed.
Pack mode without /c2 is still broken.
At least with my setup, the latest release is completely unusable: getting c2 errors on every sector, and a warning that the drive does not support subchannel pack mode, while the 20230909 release had no problem (bw-16d1ht + ribshark firmware + sata to usb adapter).
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!
/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.
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]
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 ?
Hello reentrant
Having also tried cdarchive for a cd, some 'ranges' appear to be missing. I was able to visually identify 4x25=100 'spikes' on the graph drawn by alcohol, but the program only saw 34 according to the ranges count. The 'data' values clearly differ from the example you had given when approaching one 'area' :
DPM Data: 0 1550 -1 1304
DPM Data: 0 1600 1 1305
DPM Data: 0 1650 1 1306
DPM Data: 1 1700 15 1321
DPM Data: 0 1750 17 1338
DPM Data: 0 1800 4 1342
DPM Data: 0 1850 1 1343
There's a second positive 'sector density difference' right after the first one here, so that could partially explain the issue? A resolution of 1 value every 50 sectors used by the high precision sampling is way more likely to have this case.
Maybe you already fixed it since the thread was created. By the way, have you found how to patch a MDS file?
Redump Forum → Posts by Nemok
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.