Redump Forum

Disc Preservation Community
https://forum.redump.info/

ASUS and LG Drive Audio Tracks / Positive Offset Testing

https://forum.redump.info/viewtopic.php?t=34174

Page 3 of 3

Re: ASUS and LG Drive Audio Tracks / Positive Offset Testing

Posted: Wed Nov 17, 2021 10:05 am
by scsi_wuzzy
I've been doing experiments in switching between using my Plextors and my WH14NS40 crossflashed to a BW-16D1HT for various rips. One thing that periodically comes up is the inability for the BW-16D1HT drive to dump some discs due to a "this drive can't read into lead out" message from DIC. I thought the /mr switch was meant to resolve this error by reading into the lead out by reading from the cache? However, for this zero offset disc I just recently tried to dump, even /mr wouldn't allow the disc to be dumped due to the "can't read into lead out" error.

Is there some other steps I'm supposed to be doing to dump such discs?

Re: ASUS and LG Drive Audio Tracks / Positive Offset Testing

Posted: Wed Nov 17, 2021 1:37 pm
by bikerspade
scsi_wuzzy wrote:I've been doing experiments in switching between using my Plextors and my WH14NS40 crossflashed to a BW-16D1HT for various rips. One thing that periodically comes up is the inability for the BW-16D1HT drive to dump some discs due to a "this drive can't read into lead out" message from DIC. I thought the /mr switch was meant to resolve this error by reading into the lead out by reading from the cache? However, for this zero offset disc I just recently tried to dump, even /mr wouldn't allow the disc to be dumped due to the "can't read into lead out" error.

Is there some other steps I'm supposed to be doing to dump such discs?
I've had the same problem with several discs, mostly audio CDs, but one of them I encountered today was a single-track data CD-ROM disc (an old clip art CD-ROM from 1995). Even if I have it retry the cache a thousand times, DIC is unable to get enough from the cache for it to proceed.

Re: ASUS and LG Drive Audio Tracks / Positive Offset Testing

Posted: Wed Nov 17, 2021 3:43 pm
by scsi_wuzzy
bikerspade wrote:I've had the same problem with several discs, mostly audio CDs, but one of them I encountered today was a single-track data CD-ROM disc (an old clip art CD-ROM from 1995). Even if I have it retry the cache a thousand times, DIC is unable to get enough from the cache for it to proceed.
I've had that happen before, but I also see this from some discs, where it doesn't even go through the process of trying to get a different buffer size:

Code: Select all

.\Programs\Creator\DiscImageCreator.exe cd F "ISO\test\test.bin" 8 /c2 5000 /ns /sf /mr
AppVersion
        x86, AnsiBuild, 20210701T212154
/c2 val2 was omitted. set [0]
/sf val was omitted. set [60]
/mr val was omitted. set [50]
CurrentDirectory
        D:\mpf
WorkingPath
         Argument: ISO\test\test.bin
         FullPath: D:\mpf\ISO\test\test.bin
            Drive: D:
        Directory: \mpf\ISO\test\
         Filename: test
        Extension: .bin
StartTime: 2021-11-17T14:47:00-0600
Set the drive speed: 1411KB/sec
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 0]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 1]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 2]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 4]
LBA[001686, 0x00696]: [F:ReadCDForCheckingReadInOut][L:801]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 04, 00, 00, 06, 96, 00, 00, 01, f8, 00, 00
dwBufSize: 2352
This drive can't read the lead-out
EndTime: 2021-11-17T14:47:01-0600
I wonder if it's 0 offset discs that do it? I wish I had been keeping a list of which ones do it, but I haven't, so I can't easily go back and check. I know this one is 0 offset according to the Plextor, though, so there's at least one 0 offset disc that does it.

Edit: It looks like it's a problem with the firmware I'm using. I updated to 3.10 a while back after a Sarami mentioned ripping with that version and I was trying to troubleshoot a disc that wouldn't dump. Looking at the DIC source code, though, it only flags drives running 3.00 and 3.02 as capable of reading the leadout via 0xF1. I'll probably just downgrade my drive back to 3.02, as I'd rather not modify DIC.

Edit2: I haven't tried the 0 offset disc again, but it looks like /mr works again after the downgrade.

Re: ASUS and LG Drive Audio Tracks / Positive Offset Testing

Posted: Wed Nov 17, 2021 5:01 pm
by RibShark
scsi_wuzzy wrote:Edit: It looks like it's a problem with the firmware I'm using. I updated to 3.10 a while back after a Sarami mentioned ripping with that version and I was trying to troubleshoot a disc that wouldn't dump. Looking at the DIC source code, though, it only flags drives running 3.00 and 3.02 as capable of reading the leadout via 0xF1. I'll probably just downgrade my drive back to 3.02, as I'd rather not modify DIC.

Edit2: I haven't tried the 0 offset disc again, but it looks like /mr works again after the downgrade.
F1h is not supported on 3.10, the command will return an error, it was disabled in that firmware.

Re: ASUS and LG Drive Audio Tracks / Positive Offset Testing

Posted: Wed Nov 17, 2021 5:34 pm
by scsi_wuzzy
RibShark wrote:F1h is not supported on 3.10, the command will return an error, it was disabled in that firmware.
I guess that explains why it's only listed as supported on 3.00 and 3.02. In any case, I had only updated to 3.10 as an experiment to see if a protected disc that failed on 3.02 would dump on 3.10. It didn't. So, 3.02 it is.

On a somewhat related note, has anyone done any experiments to see if any of the undumpable discs (due to lead-out issues) are dumpable on 3.00 vs 3.02? I assume it won't have any impact, but I guess it's possible that the cache structure was somehow changed between the two in a way that might have somehow alter when the /mr option fails...

Edit: This got me going on a side project. It looks like the Vinpower variant of of the WH16NS48 firmware (v. 1.D3), a firmware variant that's notable because it adds the ability to do Blu-ray quality scanning on SVC code NS40 LG drives, also supports 0xF1. Once I patched DIC to flag it as an 0xF1 capable model, it worked fine (at least for this test disc):

Code: Select all

StartTime: 2021-11-17T17:44:46-0600
CurrentDriveSize
        Total: 255402758144 bytes
         Used:  95840133120 bytes
        --------------------------
        Space: 159562625024 bytes
         => There is enough disk space for dumping
Set the drive speed: 1411KB/sec
This drive doesn't define in driveOffset.txt
Please input drive offset(Samples): 6
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 0]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 1]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 2]
This drive can read data sectors at scrambled state [OpCode: 0xbe, C2flag: 1, SubCode: 4]
LBA[297678, 0x48ace]: [F:ReadCDForCheckingReadInOut][L:801]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 04, 00, 04, 8a, ce, 00, 00, 01, f8, 00, 00
dwBufSize: 2352
This drive can't read the lead-out
But 0xF1 opcode is supported
========== Reading 297657 - 297677 INTO CACHE ==========
01 Cache LBA 297657, SubQ Trk 01, AMSF 66:10:57
02 Cache LBA 297658, SubQ Trk 01, AMSF 66:10:58
03 Cache LBA 297659, SubQ Trk 01, AMSF 66:10:59
04 Cache LBA 297660, SubQ Trk 01, AMSF 66:10:60
05 Cache LBA 297661, SubQ Trk 01, AMSF 66:10:61
06 Cache LBA 297662, SubQ Trk 01, AMSF 66:10:62
07 Cache LBA 297663, SubQ Trk 01, AMSF 66:10:63
08 Cache LBA 297664, SubQ Trk 01, AMSF 66:10:64
09 Cache LBA 297665, SubQ Trk 01, AMSF 66:10:65
10 Cache LBA 297666, SubQ Trk 01, AMSF 66:10:66
11 Cache LBA 297667, SubQ Trk 01, AMSF 66:10:67
12 Cache LBA 297668, SubQ Trk 01, AMSF 66:10:68
13 Cache LBA 297669, SubQ Trk 01, AMSF 66:10:69
14 Cache LBA 297670, SubQ Trk 01, AMSF 66:10:70
15 Cache LBA 297671, SubQ Trk 01, AMSF 66:10:71
16 Cache LBA 297672, SubQ Trk 01, AMSF 66:10:72
17 Cache LBA 297673, SubQ Trk 01, AMSF 66:10:73
18 Cache LBA 297674, SubQ Trk 01, AMSF 66:10:74
19 Cache LBA 297675, SubQ Trk 01, AMSF 66:11:00
20 Cache LBA 297676, SubQ Trk 01, AMSF 66:11:01
21 Cache LBA 297677, SubQ Trk 01, AMSF 66:11:02
22 Cache LBA 297678, SubQ Trk aa, AMSF 66:11:03 [Lead-out]
23 Cache LBA 297679, SubQ Trk aa, AMSF 66:11:04 [Lead-out]
24 Cache LBA 297680, SubQ Trk aa, AMSF 66:11:05 [Lead-out]
25 Cache LBA 297681, SubQ Trk aa, AMSF 66:11:06 [Lead-out]
26 Cache LBA 297682, SubQ Trk aa, AMSF 66:11:07 [Lead-out]
27 Cache LBA 297683, SubQ Trk aa, AMSF 66:11:08 [Lead-out]
28 Cache LBA 297684, SubQ Trk aa, AMSF 66:11:09 [Lead-out]
29 Cache LBA 297685, SubQ Trk aa, AMSF 66:11:10 [Lead-out]
30 Cache LBA 297686, SubQ Trk aa, AMSF 66:11:11 [Lead-out]
31 Cache LBA 297687, SubQ Trk aa, AMSF 66:11:12 [Lead-out]
-----------------------------------------------------
Cache SIZE: 31 (This size is different every running)
-----------------------------------------------------
Neat.

Has anyone tried the Vinpower version of the WH16NS58 firmware? If it supports 0xF1, I might switch my svc code NS50 drive over to that firmware so that it can do both Blu-ray scanning and scrambled rips.

Edit2: The Vinpower firmware for svc code NS50 drives (WH16NS58 v. 1.V5) does not support 0xF1. It just throws check conditions for "ILLEGAL_REQUEST - INVALID FIELD IN CDB." Bummer -- can't have a firmware on the newer version of the drives that will do both 0xF1 and quality scans.
All times are UTC
Page 3 of 3

Powered by phpBB® Forum Software © phpBB Limited