826

(3,497 replies, posted in General discussion)

I don't know sg-raw, but the length is always 4098.

FormatCode: 00, Sendable:  No, Readable: Yes, FormatLength: 4098
========== DiscInformationFromPIC ==========
                DiscInformationIdentifier: DI
                    DiscInformationFormat: 01
             NumberOfDIUnitsInEachDIBlock: 08
                         DiscTypeSpecific: 00
    DIUnitSequenceNumber/ContinuationFlag: 00
           NumberOfBytesInUseInThisDIUnit: 20
                       DiscTypeIdentifier: BDO
                   DiscSize/Class/Version: 01
            DIUnitFormatDependentContents: 1101010000000000002ea1ff00100000002ea1fe0000000000000000000000000000000000000000000000000000000000000000
                                   Others: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004542010000000000ffffffffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

827

(3,497 replies, posted in General discussion)

Latest is here.

AppVersion
        x86, AnsiBuild, 20180619 20619

828

(3,497 replies, posted in General discussion)

https://github.com/saramibreak/DiscImag … r/releases
*2018-06-19
- fixed: Reading Volume Descriptor of DVD

F1ReB4LL wrote:

Kryoflux/Catweasel support?

no.

829

(3,497 replies, posted in General discussion)

Sorry, please delete 20180614

https://github.com/saramibreak/DiscImag … r/releases
*2018-06-18
- added: .dat for floppy
- changed: the way to get the timestamp again (Because it can't get well from old windows)
- fixed: disc.txt for xbox (added total size of xbox disc, fixed #2 of security sector range)
- fixed: misdetection of MCN before dumping
- fixed: transfer length of DVD/BD

830

(3,497 replies, posted in General discussion)

Uploaded 2018/06/18 test
----
This problem was that dic misdetected MCN before dumping.

disc.txt

========== OpCode[0xd8]: SubCode[8]: Track[19]: Check MCN and/or ISRC ==========
========== LBA[188295, 0x2df87]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P 00 00 00 00 00 00 00 00 00 00 00 00
    Q 02 D0 D0 D0 D0 D0 D0 00 00 01 19 01
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 00 00 00 00
    T 00 00 00 00 00 00 00 00 00 00 00 00
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 00
    MCN: [=0=0=0=0=0=00]

- fixed: misdetection of  MCN before dumping

But as you say, sub-q fixing algo is incomplete.

And, system time is buggy. I don't know why didn't get the time correctly. Does your pc work well?

29552/21/111 376:21:50
DiscImageCreator cd f sonic-cd-dino-dic-20180614-760a2\sonic-cd-dino-dic-20180614-760a2.bin 24 /c2 /q 

- added: error check

And
- added: .dat for floppy
- fixed: disc.txt for xbox (added total size of xbox disc, fixed #2 of security sector range)

user7 wrote:

Does this mean Jaguar CD is now dumpable?

Doc/Todo.txt

831

(11 replies, posted in General discussion)

I see.

Final question:
According to http://xboxdevwiki.net/Xbox_Game_Disc#S … 8SS.bin.29 ,
Security sector ranges actually exist 23 (xbox) or 21 (xbox360), but ss_sector_range.exe outputs 16 (xbox) or 2 (xbox 360).
Do you know what other ranges (7 of xbox or 19 of xbox 360) mean?

This is similar to SafeDisc and other PC protections where we skip bad sectors even if there may be some data readable.

ok, DIC adopts your thoughts about RingPROTECH, ProRing, LaserLock.

832

(11 replies, posted in General discussion)

No. Xbox1 discs can also have unprotected ranges.

I see. I checked the security sectors of Xbox1 again and found it true.

And I might find the problem of freecell. As far as seeing the source code, freecell skips reading all the ss ranges of xbox partition area and pads by zero.
But as you say, ss_sector_range outputs unprotected sectors range and these sectors are actually readable.
In a word, freecell skips their readable sectors which non zero data may exist.

its very unlikelly that readable ranges will contain usable data in them.

I confirmed some sectors in each sector range were readable and non zero byte. But I don't know if these non zero bytes are usable data or not.

I think dump tools should skip only unreadable sectors like the ring protect of CD.
Of course, If you say all sectors in sector range should be preserved by zero, I don't say anymore.

Anyway, http://forum.redump.org/topic/17899/xbo … neak-king/ of ajshell1,
it is necessary to check them in detail which bytes are different.

About Xbox 360, it needs to investigate why freecell creates a bad dump.

833

(11 replies, posted in General discussion)

iR0b0t wrote:

The second range is not protected, you can read it all the way through.

Yes. I confirmed it by DIC.

Isn't ss_sector_range listed unreadable sectors (16 ranges of XBOX and 1st range of XBOX 360) ?
What purpose the second range is listed?

834

(11 replies, posted in General discussion)

Enker wrote:

Somehow you got the old hashes that are missing the L1 video. I thought FreeCell supported XGD2 discs, but maybe it got broken in a newer version. hmm

If L1 video area isn't zero, I think it's a bug of ss_sector_range, not FreeCell.
http://forum.redump.org/topic/18199/xbo … s-problem/

@user7
I uploaded the latest DIC (20180614). I supported XBOX/XBOX 360 (except XGD3) in this version. If you are interested in newest version, plz test and report.

835

(3,497 replies, posted in General discussion)

*2018-06-14
- added: xbox command (support XGD2 of XBOX/XBOX 360)
- added: PIC.bin for BD based disc
- added: /74 option in swap command (for ring data of Sega Saturn)
- added: SESSION syntax in cue file
- changed: the way to get the timestamp
- changed: permit to continue reading if the disc is CD-R or CD-RW and c2 errors are over 10000
- changed: Plextor drives support only latest firmware
- fixed: /ms option (dumps leat-out of 1st session, lead-in of 2nd session and pregap of 1st track of 2nd session)
- fixed: TOC of multi session disc
- fixed: GetWriteOffset for ASUS
- fixed: sub-qchannel reading
- fixed: Reading directory record (incorrect data length of DVD)

836

(3,497 replies, posted in General discussion)

- added: xbox dumping
- added: PIC.bin for BD based disc
and http://forum.redump.org/post/61360/#p61360

psx-collector wrote:

With new version the disc just stops after about one minute but no more messages.

Please upload all txt files of 20180419 and 20180522

837

(3,497 replies, posted in General discussion)

Updated test version.
-added: /74 option in swap command (for the ring data of Sega Saturn)
-fixed: permit to continue reading if the disc is CD-R or CD-RW and c2 errors is over 10000.

Info from QPxTool
Encrypted Disc Key:
Player Key:
Decrypted Disc Key:

I don't know the detail of copyright raw, but is it really good to open those information?

839

(3,497 replies, posted in General discussion)

There's no problem in my pc.
Does this occur with only [PSX] RC Revenge? or PX-760?

This option would be extremely helpful for dumping old hard CD-Rs.

Without /c2, it reads until the end.

840

(3,497 replies, posted in General discussion)

The problem is that DIC was spitting out no C2 errors when some of the dumps were clearly bad...

It's possible that it's the bug of DIC, but I can't judge whether they're clearly bad or not without logs.
DIC merely uses the c2 error bits returned by the drive. I say several times, but c2 error handling of the drive can't completely be trusted, so I recommend using the disc of good condition as possible not to put the burden to the drive.

841

(3,497 replies, posted in General discussion)

ok, cp-talk is difficult for me, but I understood the swap command of dic is effective when reads huge lead-out.

swap
---
1. Insert the audio trap disc to a supported drive.
:
:
6. When dumping finished, the drive tray open automatically.
7. The drive tray close automatically after 3000 msec.
8. Read TOC and img is descrambled automatically.

and I may add below.
9. If option(/74) is specified, reads lead-out till the specified time.

Btw, does subdump uses crc6 to fix subR-W of CD+G?

psx-collector wrote:

Maybe it's possible to code an option to let you continue dumping process?

I have worry about spreading the c2 existing image.

reentrant wrote:

some very scratched discs

user7 wrote:

Disc was clearly scratched

Why not polish the disc?

842

(3,497 replies, posted in General discussion)

antimatter wrote:

I am trying to dump an IBM PC game with a Plextor PX-W4824TU and am getting this error:

Uploaded test version.

F1ReB4LL wrote:

They can be read on any drive that supports swapping

I confirmed getting the similar data. Scrambled data is almost all 0x59 or 0xa8.
If this is really data of the ring, does burned cd-r with this data works in sega saturn without hacking?

843

(3,497 replies, posted in General discussion)

Maybe they mean the multisessional discs?

Maybe so.

All the sectors after the user area are marked as 0xAA in the subs and are either empty data or empty audio sectors, they go upto the very end of the disc

Even if it is so, it is enough in 90 sec to preserve lead-out. If there are some data except empty and shifted data in lead-out, it's not already lead-out.
Saturn ring, I don't know the detail. At least, this ring can't be read unless someone hacks sega saturn.

PMCD

https://en.wikipedia.org/wiki/PMCD
http://www.riaj.or.jp/f/pdf/issue/ris/ris105.pdf
http://plexmaster.web.fc2.com/
https://av.watch.impress.co.jp/docs/20020603/dal56.htm
This is the old specification that only Japan? use.

How should the subs error correction work, IMO:

I'll refer to it.

844

(3,497 replies, posted in General discussion)

I checked multi-session disc.

plextor (0xd8)
lead-out of 1st session: all (6750 / 6750 sectors)
lead-in of 2nd session: part (6 /4500 sectors)
pregap of 1st track of 2nd session: part (137 / 150 sectors)

plextor (0xbe)
lead-out of 1st session: all (6750 / 6750 sectors)
lead-in of 2nd session: part (6 / 4500 sectors)
pregap of 1st track of 2nd session: all (150 / 150 sectors)

845

(3,497 replies, posted in General discussion)

Pregap/Lead-In sectors are read randomly, you can read the -5000...-1100 area a couple of times and get different sectors each time.

I understand reading is random, but even if reads the disc how many times, it is about 1900 that can get the sectors.

He preserves the last TOC iteration only (around 10-20 sectors) and the pregap.

We also need to determine how many sectors preserve because it is impossible to read all lead-in sectors.

READ_TOC(0x43) doesn't output the data area, though, only subs

Yes. It is valid if you permit not to preserve the main channel. (But I know you don't permit it.)

Lead-out sectors go upto the very end of the disc. If the main data area is small (a few megabytes), the lead-out would be 300 000+ sectors.

Yes Lead-out sectors/area exist upto the end of the disc, but acutually recorded data in the lead-out is 6750 (90 sec) + α sectors.

Why α?  http://www.itmedia.co.jp/news/0203/13/cdswhy_2.html

リードアウトは2分といわれていますが、実際の規格は1分36秒で、残りの24秒はマスター情報領域(PMCD)です。しかし、最近のドライブは1分36秒か、もっと短いものが増えている。

But
https://kotobank.jp/word/%E3%83%AA%E3%8 … 83%88-9710
http://yougo.ascii.jp/caltar/%E3%83%AA% … 6%E3%83%88

リードアウト領域には、90秒間の無音データが記録される。

https://astamuse.com/ja/published/JP/No/2001093150

第1セッションのリードアウト領域の長さは1分30秒と定められている。

I don't know which of 90 sec and 96 sec is correct, but I know almost all drives can't read lead-out and Lite-on can read 6750 sectors.

I think it should work another way, I'll try to describe it in the DIC thread.

I think subdump's logic is better/best, but it takes subdump very long time to dump the sub, so I can't use it. (In the first place, I don't know the subdump's logic because this is not open-source.)

846

(3,497 replies, posted in General discussion)

F1ReB4LL wrote:

And I've asked to add an automatic 1st pregap and TOC reading into DIC already, but you haven't added that yet

I checked the lead-in/out and pregap of 1st track once more.

Plextor
lead-in: part (about 1900 sectors)
pregap: all (150 sectors)
lead-out: part (100 sectors)

Lite-on (LH-18Axx, LH-20Axx, DH-20Axx)
lead-in: no
pregap: part (142 sectors)
lead-out: all (6750 sectors)

----
About lead-in:
As I told you, the lead-in can read using READ_TOC(0x43). Not only plextor but all drives can preserve it as the raw binary file like xbox preserves SS.bin, PFI.bin and DMI.bin.

I fixed now.

Jackal wrote:

it will still produce potentially bad dumps with missing data because there is no overread into lead-out?

Before dumping, dic checks if the drive can read lead-in/out or can't, so the combined offsets plus disc can't be dumped absolutely by BW-16D1HT.

This problem occured in my BC-12D2HT.
I confirmed this problem occured when 1st track is data.

Gyakuten Soeur http://redump.org/disc/46218/
Incorrect offset

========== TOC ==========
      Data Track  1, LBA        0 -    21601, Length    21602
                                              Total     21602
  :
  :
========== OpCode[0xbe]: C2flag[1]: SubCode[0]: Check Drive + CD offset ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF FF FF FF FF  FF FF FF 00 00 02 00 01   ................
0010 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0020 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
0030 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................
 :
========== Offset (Drive offset referes to [url]http://www.accuraterip.com[/url]) ==========
     Combined Offset(Byte) -24696000, (Samples) -6174000
    -   Drive Offset(Byte)     24, (Samples)     6
    ----------------------------------------------
           CD Offset(Byte) -24696024, (Samples) -6174006
    Overread sector: -10500

Sotsugyou: Graduation http://redump.org/disc/37145/
Correct offset

========== TOC ==========
     Audio Track  1, LBA        0 -     3269, Length     3270
      Data Track  2, LBA     3270 -    34254, Length    30985
     Audio Track  3, LBA    34255 -    47838, Length    13584
     Audio Track  4, LBA    47839 -    51545, Length     3707
     Audio Track  5, LBA    51546 -    69560, Length    18015
     Audio Track  6, LBA    69561 -    77006, Length     7446
     Audio Track  7, LBA    77007 -    83770, Length     6764
     Audio Track  8, LBA    83771 -    91448, Length     7678
     Audio Track  9, LBA    91449 -   100293, Length     8845
     Audio Track 10, LBA   100294 -   105623, Length     5330
     Audio Track 11, LBA   105624 -   112343, Length     6720
     Audio Track 12, LBA   112344 -   116705, Length     4362
     Audio Track 13, LBA   116706 -   121655, Length     4950
     Audio Track 14, LBA   121656 -   122262, Length      607
     Audio Track 15, LBA   122263 -   122917, Length      655
     Audio Track 16, LBA   122918 -   139483, Length    16566
     Audio Track 17, LBA   139484 -   146038, Length     6555
     Audio Track 18, LBA   146039 -   154293, Length     8255
     Audio Track 19, LBA   154294 -   162618, Length     8325
     Audio Track 20, LBA   162619 -   171904, Length     9286
     Audio Track 21, LBA   171905 -   181245, Length     9341
     Audio Track 22, LBA   181246 -   190922, Length     9677
     Audio Track 23, LBA   190923 -   198920, Length     7998
     Audio Track 24, LBA   198921 -   209266, Length    10346
     Audio Track 25, LBA   209267 -   218511, Length     9245
     Audio Track 26, LBA   218512 -   228376, Length     9865
     Audio Track 27, LBA   228377 -   236941, Length     8565
      Data Track 28, LBA   236942 -   267629, Length    30688
                                              Total    267630
 :
 :
========== OpCode[0xbe]: C2flag[1]: SubCode[0]: Check Drive + CD offset ==========
========== LBA[003270, 0x00cc6]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 73 5C 5D 8D 8D D7 57 2D  CD 9D D5 D9 EF 6A BC 5F   s\]...W-.....j._
0010 : 41 88 40 16 C0 42 9C 10  48 4C 76 C5 96 A3 5E 89   A.@..B..HLv...^.
0020 : 88 16 96 FE 9E 8C 24 44  3A F7 17 59 91 83 55 CA   ......$D:..Y..U.
0030 : D4 2C 24 6A EC 58 3A 89  E0 22 8C 46 BA CB 4A BC   .,$j.X:..".F..J.
0040 : 5C 0A C2 F0 26 B3 2D 86  AE A6 B8 0D C5 92 84 12   \...&.-.........
0050 : 9C 7E 9A D1 DA AB 6C 4C  1E F1 8C 33 52 C2 EA AE   .~....lL...3R...
0060 : B0 0F 47 35 83 20 16 AB  7D 87 59 F4 6C 30 5A E3   ..G5. ..}.Y.l0Z.
0070 : 0C 3E F2 E7 72 C1 EE C2  DE E9 A0 18 2E FD AB 76   .>..r..........v
0080 : 88 51 D1 8B 6B 2C 24 0F  49 BC 4E 97 12 99 BA A1   .Q..k,$.I.N.....
0090 : F8 1A A0 7B 48 53 06 8D  F2 9D FD CF 67 63 1D A2   ...{HS......gc..
00A0 : C2 9B 73 5B 15 8B 3F 17  60 36 90 40 3A C7 24 25   ..s[..?.`6.@:.$%
00B0 : AC 7C 1A D6 FC 5C 43 6E  A6 94 42 B9 A7 45 CD 84   .|...\Cn..B..E..
00C0 : 22 84 7E 94 57 2D FC 0A  D6 FF 66 A6 CC 0D E2 CE   ".~.W-....f.....
00D0 : 82 BE 8B 42 95 86 98 51  99 84 12 85 AB 54 08 74   ...B...Q.....T.t
00E0 : 4D 8D 9F 57 5A C9 8C 65  96 93 16 BB 18 00 79 C8   M..WZ..e......y.
00F0 : 2A C0 09 D7 01 95 CB 3D  85 E9 9B 58 3D 89 A2 EE   *......=...X=...
 :
 :
========== Offset (Drive offset referes to [url]http://www.accuraterip.com[/url]) ==========
     Combined Offset(Byte)  -7532, (Samples) -1883
    -   Drive Offset(Byte)     24, (Samples)     6
    ----------------------------------------------
           CD Offset(Byte)  -7556, (Samples) -1889
    Overread sector: -4

Anyway, I fix this problem.

Lead-in is perhaps yes, but lead-out is perhaps no.

LBA[186320, 0x2d7d0]: [F:ProcessReadCD][L:1654]
    Opcode: 0xbe
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE

If you buy this drive, I recommend updating to the latest firmware 3.03.

DIC uses 0xd8(READ_CDDA) to detect the offsets if plextor is used, and uses 0xbe(READ_CD with CDDA flag) if non-plextor is used.
Almost all drives return error (Illegal Mode For This Track) if 0xbe with CDDA is used. But some drives returns the offsets properly (UH12NS30, BC-12D2HT) using 0xbe.

                VendorId: ASUS    
               ProductId: BW-16D1HT       
    ProductRevisionLevel: 3.00

This drive is very weird.

========== OpCode[0xbe]: C2flag[1]: SubCode[0]: Check Drive + CD offset ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF FF FF FF FF  FF FF FF 00 00 02 00 02   ................
0010 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Definitely, this drive can't dump the scrambled image if subcode flag is 0, so the offsets is incorrect.

========== OpCode[0xbe]: C2flag[1]: SubCode[1]: Check Drive + CD offset ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 00 FF FF FF FF FF FF FF  FF FF FF 00 00 02 00 02   ................
0010 : 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Subcode flag 1 is ditto.

But if subcode flag 4 is used, this drive can dump the scrambled image and the offsets is correct.

========== OpCode[0xbe]: C2flag[1]: SubCode[4]: Check Drive + CD offset ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : A8 02 FE 81 80 60 60 28  28 1E 9E 88 68 66 AE AA   .....``((...hf..
0010 : FC 7F 01 E0 00 48 00 36  80 16 E0 0E C8 04 56 83   .....H.6......V.
0020 : 7E E1 E0 48 48 36 B6 96  F6 EE C6 CC 52 D5 FD 9F   ~..HH6......R...
0030 : 01 A8 00 7E 80 20 60 18  28 0A 9E 87 28 62 9E A9   ...~. `.(...(b..
 :
0900 : DF 2E D8 1C 5A 89 FB 26  C3 5A D1 FB 1C 43 49 F1   ....Z..&.Z...CI.
0910 : F6 C4 46 D3 72 DD E5 99  00 FF FF FF FF FF FF FF   ..F.r...........
0920 : FF FF FF 00 01 82 01 62  00 28 00 1E 80 08 60 06   .......b.(....`.
 :
========== LBA[000001, 0x00001]: Main Channel ==========
 :
0910 : F6 C4 46 D3 72 DD E5 99  00 FF FF FF FF FF FF FF   ..F.r...........
0920 : FF FF FF 00 01 82 02 62  00 28 00 1E 80 08 60 06   .......b.(....`.
========== Offset (Drive offset referes to http://www.accuraterip.com) ==========
     Combined Offset(Byte)    -24, (Samples)    -6
    -   Drive Offset(Byte)     24, (Samples)     6
    ----------------------------------------------
           CD Offset(Byte)    -48, (Samples)   -12
    Overread sector: -1
    SubChannel Offset: 0

I check the sector is really scrambled or not using msf and mode.

It would probably be better to block CD dumping (or add warnings) on drives without D8 (at least by default, without a special parameter)

I consider it.