Redump Forum — ASUS and LG Drive Audio Tracks / Positive Offset Testing

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

2021-11-17T22:34:49Z

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):

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.

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

2021-11-17T22:01:10Z

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

2021-11-17T20:43:40Z

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:

.\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

2021-11-17T18:37:30Z

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

2021-11-17T15:05:09Z

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

2021-09-20T18:00:55Z

sarami wrote:

Tell me the drive name and firmware before a flash, plz.

The drive originally came with firmware v3.10.
Drive name? It is a BW-16D1HT/BLK/G/AS

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

2021-09-20T17:14:38Z

bikerspade wrote:

ASUS BW-16D1HT
90DD0200-B28000
Manufactured April 2021
Firmware v3.02

Tell me the drive name and firmware before a flash, plz.

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

2021-09-20T15:46:56Z

sarami wrote:

btw, what drive and os do you use?

ASUS BW-16D1HT
90DD0200-B28000
Manufactured April 2021
Firmware v3.02
OS: Windows 7 Home Premium

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

2021-09-20T15:30:37Z

bikerspade wrote:

I’ve run it 30 times so far,

Thanks. If data-shifted is really random, it will occur someday... btw, what drive and os do you use? Jackal reported that it occurred by ASUS (What ASUS?) and linux (What distribution?) http://forum.redump.org/post/93955/#p93955

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

2021-09-19T17:10:50Z

I’ve run it 30 times so far, and no bad dump yet. I had a batch file running it consecutively with 60 seconds to cool down between iterations. I don't think it's going to give me a bad dump at this point.

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

2021-09-17T22:04:59Z

sarami wrote:

@bikerspade
If you have time, continue to dump your +1176 disc by ASUS until the hash unmatches, and upload the unmatched logs, plz.

No problem, I will do that and report back.

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

2021-09-17T18:52:39Z

@bikerspade
If you have time, continue to dump your +1176 disc by ASUS until the hash unmatches, and upload the unmatched logs, plz.

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

2021-09-17T18:03:07Z

ssjkakaroto wrote:

... and there's no guarantee they're in good condition. My 760A is useless now (Servo failure with all discs) and both my Premium and 708A are only reliable with slow speeds.

totally agree, as newbie here, recently I bought 708A, 712A and 716A : all of them are with dead laser in different stages, i.e. 708A and 712A the laser is completely dead (it cannot read neither CD, nor DVD, actually 712A was able only once to read one particular CD, but obviously the laser is very very weak) and 716A cannot read CDs, still good for DVDs (but that's more or less useless).

However, at least for 708A and 712A there are replacement lasers available from China - in 1 month or so I will be be able to give feedback and tell if the replacement laser is as good as original, i.e. if they can read my favorite test CDs - those with Cactus protection, i.e. many C1/C2 errors pressed at factory.

So, bottom line, I wouldn't recommend buying 716A at all - as there are no replacement lasers for them. Currently, BW-16D1HT beats PX755/760 in most cases, because of the aforementioned in previous posts firmware bug. So, I guess, only safe bet are 708A and 712A, but if you're willing to replace the laser plus for me it is still an open question if the replacement laser is as good as the original. I ordered mine, but shipping from China takes forever...

Also, Plextor PX-5224 I bought has a fault:

http://forum.redump.org/post/94515/#p94515

luckily I found way to workaround its fault, but not how to fix it. So, at least for me, so far it turned it's kind of impossible to find second hand Plextor that in 2021 is actually still in fully working order.

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

2021-09-17T14:53:18Z

scsi_wuzzy wrote:

I hope for that reason alone we can get all the kinks worked out with the ASUS / LG drives. They seem to be better readers. That might just be because they're less aged and worn, but I suspect it's also just because they're newer technology.

There's another critical reason to use those drives: they're still being sold!
Finding a Plextor is getting more difficult by the day. The ones you can find on ebay cost a kidney and there's no guarantee they're in good condition. My 760A is useless now (Servo failure with all discs) and both my Premium and 708A are only reliable with slow speeds.

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

2021-09-17T14:03:26Z

bikerspade wrote:

with a PX-716UF and it threw many unrecoverable C2 errors

as far as I know there was at least one batch of PX-716, especially those used in USB enclosures, that had some issue with the laser on CDs and eventually they stop reading CDs altogether even after very light use. also, at the end of the post here:

http://forum.redump.org/post/95189/#p95189

I documented how PX-5224 that was reporting hundreds of C2 errors on the same discs after some more hours of use started to work, i.e. probably the laser "wake up" from the use instead die.