search

superg / redumper

Low level CD dumper utility
GNU General Public License v3.0
216 stars 19 forks source link

HL-DT-ST - BD-RE BP40NS20 does not support DATA_C2_SUB or DATA_SUB_C2 but DATA_C2 & DATA_SUB #105

Closed smesgr9000 closed 9 months ago

smesgr9000 commented 9 months ago

I own an BR drive which does not allow DATA_SUB_C2 or DATA_C2_SUB. In both configurations the following error occurs:

[LBA: 100] SCSI error (SC: CHECK CONDITION, SK: ILLEGAL REQUEST, ASC: INVALID FIELD IN CDB)

but works fine in both DATA_SUB or DATA_C2. Thus I was wondering if it would be possible to read every sector twice and combine the data. As a proof of concept i hacked the current git:

diff.txt

as a result my dump run ended without an error - but I'm still unsure if it worked:

redumper v2023.12.30 build_LOCAL [Dec 30 2023, 21:33:14]

arguments: --drive-type=GENERIC --drive-sector-order=DATA_SPLIT --drive-read-method=BE --drive-pregap-start=-135 --verbose

drive path: /dev/sg1
drive: HL-DT-ST - BD-RE BP40NS20 (revision level: ML04, vendor specific: 00091114V8C3TD5902)
drive configuration: GENERIC (read offset: +667, C2 shift: 0, pre-gap start: -135, read method: BE, sector order: DATA_SPLIT)
drive read speed: <optimal>

current profile: CD-ROM

image path: .
image name: dump_231230_234812_sg1

*** DUMP

disc TOC:
  track 1 {  data }
    index 01 { LBA:      0, MSF: 00:02:00 }
  track A {  data }
    index 01 { LBA: 262095, MSF: 58:16:45 }

warning: unsupported drive read method
[LBA:   -135] subcode desync (shift: +1)

media errors: 
  SCSI: 0
  C2: 0
  Q: 273

*** PROTECTION (time check: 873s)

warning: incomplete dump detected, using available dump size
protection: N/A

*** REFINE (time check: 1s)

*** SPLIT

correcting Q... done

final TOC:
  track 1 {  data }
    index 00 { LBA: [  -150 ..     -1], length:    150, MSF: 00:00:00-00:01:74 }
    index 01 { LBA: [     0 .. 262092], length: 262093, MSF: 00:02:00-58:16:42 }
  track A {  data }
    index 00 { LBA: [262093 .. 262094], length:      2, MSF: 58:16:43-58:16:44 }
    index 01 { LBA: 262095, MSF: 58:16:45 }

warning: TOC / QTOC mismatch, track index 01 (track: 1, LBA: 0 <=> -1)
warning: TOC / QTOC mismatch, nonexistent track in QTOC (track: A)

final QTOC:
  track 1 {  data }
    index 00 { LBA: [  -150 ..     -2], length:    149, MSF: 00:00:00-00:01:73 }
    index 01 { LBA: [    -1 .. 262092], length: 262094, MSF: 00:01:74-58:16:42 }

analyzing... done (time: 14s)

data disc detected, offset configuration: 
  LBA:   -136 ->   -135, MSF: 00:00:15, count:  16260, offset: -667
  LBA:  16123 -> -10110, MSF: 07:47:15, count:      1, offset: +15425326
  LBA:  16123 -> -10110, MSF: 07:47:15, count:      1, offset: +15425414
  LBA:  16123 ->  16125, MSF: 03:37:00, count:      9, offset: -667
  LBA:  16132 -> -10110, MSF: 07:47:15, count:      1, offset: +15430410
  LBA:  16132 -> -10110, MSF: 07:47:15, count:      1, offset: +15430498
  LBA:  16132 ->  16134, MSF: 03:37:09, count:  43514, offset: -667
  LBA:  59646 ->   -150, MSF: 00:00:00, count:      1, offset: +35160141
  LBA:  59646 ->  59648, MSF: 13:17:23, count: 202447, offset: -667

non-zero  TOC sample range: [   -88200 .. +154110684]
non-zero data sample range: [     -667 .. +153937145]

disc write offset: +0

warning: incomplete pre-gap (session: 1, unavailable: 15/150)
checking tracks
done

writing tracks
warning: descramble failed (LBA: [0 .. 262092])
done

CUE [dump_231230_234812_sg1.cue]:
CATALOG 0000000000000
FILE "dump_231230_234812_sg1.bin" BINARY
  TRACK 01 MODE0/2352
    INDEX 01 00:00:00

*** HASH (time check: 22s)

dat:
<rom name="dump_231230_234812_sg1.bin" size="616442736" crc="a56faf79" md5="50b44c5cd4a54e6fab11736905aa4a81" sha1="841cceeab016546c340f112cf8bcf9117ff98807" />

*** INFO

CD-ROM [dump_231230_234812_sg1.bin]:
  sectors count: 262093
  mode1 sectors: 262093

  REDUMP.ORG errors: 0

ISO9660 [dump_231230_234812_sg1.bin]:
  volume identifier: CPQSMST423
  PVD:
0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 31 39 39                199
0330 : 39 30 35 31 34 31 35 35  37 35 34 30 30 30 31 39   9051415575400019
0340 : 39 39 30 35 31 34 31 35  35 37 35 34 30 30 30 30   9905141557540000
0350 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   0000000000000000
0360 : 31 39 39 39 30 35 31 34  31 35 35 37 35 34 30 30   1999051415575400
0370 : 30 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   0...............

*** SKELETON (time check: 2s)

* [100%] hashing complete                                                        
* [100%] creating skeleton                          

*** END (time check: 4s)

is there a good way to check if subcode yielded some useful information?

superg commented 9 months ago

Unfortunately it didn't work at all: warning: descramble failed (LBA: [0 .. 262092]) As this is data disc, most likely all your output sectors are zeroed, that's why you get this descrambling warning. I'm not sure if the reason is your changes or it's the drive issue. I've never seen a drive that can do DATA_SUB and DATA_C2 separately, but cannot do DATA_SUB_C2 or DATA_C2_SUB order, there might be something else at play here.

As a first step for you I would suggest to use --drive-sector-order=DATA_SUB, do a full dump and see if you get descrambling warning. If you don't - you've got legit dump without C2 support but if your disc is not too scratched, it might be just fine. When you specify the sector order, it's sent to drive, but it's up to the drive to honor that or not, drive might ignore or return something unexpected and we don't know that. If you don't get descrambling errors, at least that guarantees that DATA channel is good.

I also want to mention that right now I am in a middle of GENERIC drive dumping rework that will improve overall support and do more meaningful diagnostics. Another thing that I plan after this is an automatic drive tester command that will intelligently try all sector order combinations / sector types / C2 offsets / leadin / leadout / cache and will output detail drive report. Depending on your use case you might want just to wait a little bit ;)

smesgr9000 commented 9 months ago

hm i think you are right. I did a redump with only DATA_SUB and the same error message occured. Afterwards I did compare both .subcode files. Alot of zeros and later some "@". There are some minor differences between both dumps some bits here and there are neither @ nor zero on both dumps differ.

   Visuel HexDiff v 0.0.53 by tTh 2007                             dec   7bits  
12060512   00 40 00 40 00 00 40 40 00 00 00 23 00 40 40 00     @ @  @@   # @@
12060528   00 00 00 00 00 00 00 00 00 00 00 40 00 40 40 40               @ @@@
12060544   00 40 00 40 00 40 00 40 00 00 00 00 00 40 40 00     @ @ @ @     @@
12060560   00 40 00 00 00 40 00 00 40 40 40 00 00 00 00 40     @   @  @@@    @
12060576   00 40 00 00 00 00 00 40 00 00 00 00 00 00 00 40     @     @       @
12060592   00 00 00 00 00 00 00 40 00 00 00 40 00 40 40 40           @   @ @@@
12060608   00 40 00 40 00 00 40 40 00 00 00 00 00 40 40 40     @ @  @@     @@@
12060624   00 00 00 00 00 00 00 00 00 00 00 40 00 40 40 40               @ @@@
12060640   00 40 00 40 00 40 00 40 00 00 00 00 00 40 40 40     @ @ @ @     @@@
12060656   40 40 40 40 40 40 40 00 40 00 00 40 00 00 00 40    @@@@@@@ @  @   @
12060672   00 40 00 00 00 00 00 40 00 00 00 00 00 00 00 40     @     @       @
12060688   00 00 00 00 00 00 00 40 00 00 00 40 00 40 40 40           @   @ @@@
** dump_231230_234812_sg1.subcode                   29495520 12060512  40%      
12060512   00 40 00 40 00 00 40 40 00 00 00 b3 00 40 40 00     @ @  @@     @@
12060528   00 00 00 00 00 00 00 00 00 00 00 40 00 40 40 40               @ @@@
12060544   00 40 00 40 00 40 00 40 00 00 00 00 00 40 40 00     @ @ @ @     @@
12060560   00 40 00 00 00 40 00 00 40 40 40 00 00 00 00 40     @   @  @@@    @
12060576   00 40 00 00 00 00 00 40 00 00 00 00 00 00 00 40     @     @       @
12060592   00 00 00 00 00 00 00 40 00 00 00 40 00 40 40 40           @   @ @@@
12060608   00 40 00 40 00 00 40 40 00 00 00 00 00 40 40 40     @ @  @@     @@@
12060624   00 00 00 00 00 00 00 00 00 00 00 40 00 40 40 40               @ @@@
12060640   00 40 00 40 00 40 00 40 00 00 00 00 00 40 40 40     @ @ @ @     @@@
12060656   40 40 40 40 40 40 40 00 40 00 00 40 00 00 00 40    @@@@@@@ @  @   @
12060672   00 40 00 00 00 00 00 40 00 00 00 00 00 00 00 40     @     @       @
12060688   00 00 00 00 00 00 00 40 00 00 00 40 00 40 40 40           @   @ @@@
   dump_240101_093649_sg1.subcode                   29495520 12060512  40%

edit: Additionally at the end (last 1%) there are some "80 c0 80 80 80 80 80 c0 80" patterns

superg commented 9 months ago

Subchannel will always be different due to not having enough redundancy there, this is expected and there is a way (crc16) to tell whether subchannel frame is valid or not.

superg commented 9 months ago

Unclear what to do here.