826

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

827

(3,488 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)

828

(3,488 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

829

(3,488 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?

831

(3,488 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.

832

(3,488 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.

833

(3,488 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?

834

(3,488 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?

835

(3,488 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.

836

(3,488 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)

837

(3,488 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.)

838

(3,488 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.

843

(3,488 replies, posted in General discussion)

Some fixed.

 /ms

It works now, but the lead-in of 2nd session can't read.
If /ms isn't used, dic skips reading 6750+4500+150=11400 sectors.
(6750 [1min30sec] is the lead-out of 1st session . 4500 [1min] is the lead-in of 2nd session. 150 [2sec] is the pregap of 1st track of 2nd session.)

844

(3,488 replies, posted in General discussion)

                             Data Length: 4294967295
                 Recording Date and Time: 2010-01-06 04:59:56 +00:00
                              File Flags: 0 (Visible, File, Disassociated, File has't record format, Owner/Group ID has't, Final Directory Record)
                          File Unit Size: 0
                     Interleave Gap Size: 0
                  Volume Sequence Number: 1
               Length of File Identifier: 13
                         File Identifier: ARCHIVEPAX.GZ

Is this file really over 4GB size?

845

(3,488 replies, posted in General discussion)

iR0b0t wrote:

It would require that all dumpers run XBC just to get this info.

I see, thx.

Uploaded test version.
-added: dumping PFI.bin and DMI.bin (all DVD based disc)

And uploaded a batch file for xbox. (run dic, ss_sector_range and FreeCell)
Please modify the path and drive letter individually.
http://www.mediafire.com/file/em1qbnh4i … mp.7z/file

846

(3,488 replies, posted in General discussion)

Uploaded test version.
-added: support xbox security sector dumping (needs kreon's drive)

DiscImageCreator.exe xbox <driveletter> <filename>

@Admin or Moderator
Why xbox preserves the hash of Physical Format Information (PFI) and Manufacturing Information (DMI) in comments?
All DVD based disc (gc/wii, ps2 etc) have PFI and DMI but there isn't the hash in comments except xbox.

ajshell1 wrote:

As long as a proper Plextor is used, will it make a difference if that flag is or isn't used?

No difference, but some ide-usb controller can't get the drive name, so user who uses such a controller needs this flag.

847

(3,488 replies, posted in General discussion)

Uploaded in test branch.

*2018-05-22 test
- added: swap command (This is for non-Plextor drive)
- added: ls command (This shows maxium drive speed in command-line screen)
- added: Support PS2 unlicensed disc (needs to use /sf. This protect looks like a safedisc)
- added: GC/Wii dumping drive (support GCC-4160N, 4240N, 4243N, 4247N)
- added: Check subQ adr and RtoW before dumping of GD-ROM
- added: Check if PSX PAL or not (for /nl)
- added: Output .dat file for BD-ROM
- changed: Rereading the sector if crc16 of subQ is currupt, not rmsf or amsf
- changed: Disable beep except disc dumping command (cd, dvd etc.)
- fixed: Checking error of subQ track
- fixed: Reading path table record of GD-ROM (support path table size is over 2352)
- fixed: dumping CD-i ready (not unscramble the pregap sector)

848

(3,488 replies, posted in General discussion)

jethro_napoleon wrote:

there are two BD drives listed under the CD (media). Can these models dump CDs correctly?

If you already have these drives, please try. If not so, try this http://forum.redump.org/post/60603/#p60603 using the drive you have now.

849

(3,488 replies, posted in General discussion)

Some fixed.

usurper wrote:

Isnt that a disc with those nasty read errors?

There aren't intentional c2 errors and edc/ecc errors.

850

(3,488 replies, posted in General discussion)

F1ReB4LL wrote:

Solution 2

Added this, but still buggy, I think.

How to use

1. insert the audio trap disc to a supported drive.
2. run (stop spinning disc) -> DiscImageCreator.exe stop [DriveLetter]
3. use a pin to press the escape eject button, so the tray will eject (or remove the drive cover).
4. insert the disc and run -> DiscImageCreator.exe close [DriveLetter] or gently push the tray back (or put the drive cover back on).
5. run (start dumping scrambled img) -> DiscImageCreator.exe swap [DriveLetter] foo.bin [DriveSpeed(0-72)]
6. when dumping finished, the drive tray open automatically.
7. The drive tray close automatically after 10000 msec.
8. Read TOC and img is descrambled automatically.

F1ReB4LL wrote:

get weird DIC dumps

Also added this in cd command.
http://forum.redump.org/post/60437/#p60437