<![CDATA[Redump Forum — [DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/topic/18041/dic-risks-of-nonplextor-cd-dumps/ Mon, 28 May 2018 05:04:13 +0000 PunBB 1.4.4 <![CDATA[Re: [DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/post/61102/#p61102 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.

]]> Mon, 28 May 2018 05:04:13 +0000 http://forum.redump.org/post/61102/#p61102 <![CDATA[Re: [DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/post/61101/#p61101 Even with the offset detection fixed, it will still produce potentially bad dumps with missing data because there is no overread into lead-out?

]]> Mon, 28 May 2018 05:00:05 +0000 http://forum.redump.org/post/61101/#p61101 <![CDATA[Re: [DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/post/61088/#p61088 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.

]]> Sun, 27 May 2018 17:42:27 +0000 http://forum.redump.org/post/61088/#p61088 <![CDATA[Re: [DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/post/61086/#p61086 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.

]]> Sun, 27 May 2018 16:10:14 +0000 http://forum.redump.org/post/61086/#p61086 <![CDATA[Re: [DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/post/61077/#p61077 BW-16D1HT - I think I'll buy this drive. Can it read lead-in and lead-out?

]]> Sun, 27 May 2018 09:16:50 +0000 http://forum.redump.org/post/61077/#p61077 <![CDATA[Re: [DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/post/61076/#p61076 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.

]]> Sun, 27 May 2018 08:54:47 +0000 http://forum.redump.org/post/61076/#p61076 <![CDATA[Re: [DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/post/61075/#p61075 +1

]]> Sun, 27 May 2018 07:26:22 +0000 http://forum.redump.org/post/61075/#p61075 <![CDATA[[DIC] Risks of non-Plextor CD dumps?]]> http://forum.redump.org/post/61074/#p61074 @sarami / others

It has come to my attention that some dumpers are using non-Plextor drives with DIC for their CD dumps.
The first issue that I see is the offset detection:
For this dump: http://forum.redump.org/topic/18020/add … 2002-demo/ DIC detects a write offset of -12.
But for this one: http://forum.redump.org/topic/18021/non … piel-demo/ it detects:

========== Offset (Drive offset referes to http://www.accuraterip.com) ==========
     Combined Offset(Byte) -24696000, (Samples) -6174000
    -   Drive Offset(Byte)     24, (Samples)     6
    ----------------------------------------------
           CD Offset(Byte) -24696024, (Samples) -6174006
    Overread sector: -10500

So I wonder if the -12 offset is even correct?

Other risks of course include incorrectly descrambled / cut off data. As soon as a disc has audio tracks or mastering errors, the results can no longer be trusted.

It would probably be better to block CD dumping (or add warnings) on drives without D8 (at least by default, without a special parameter) and also add a check to the DICUI GUI to only allow dumping in D8 mode? If you don't add such checks, then people might think that they can just use any drive to dump, and if these dumps are added without checking, the database might soon be riddled with bad dumps.

]]> Sun, 27 May 2018 07:02:17 +0000 http://forum.redump.org/post/61074/#p61074