1,301

nightson wrote:

This particular disc outputs huge subError.txt file. Is it normal?

Not normal.

nightson wrote:

the subError.txt will differ every time even for the same disc.

Because of some random errors.

nightson wrote:

Why was the write speed set when I'm just reading the disc?

I don't know why too. I'd not cared about it. No problem you ignore it because dic don't use it.

1,302

sarami wrote:
nightson wrote:

This particular disc outputs huge subError.txt file. Is it normal?

Not normal.

There were no C2 errors though. Can it be considered as a good dump?

1,303 (edited by sarami 2018-04-22 05:04:25)

C2 errors detect main channel errors. SubQ channel errors is detected using crc16 but there are not these in SubP and RtoW.
About the main channel (bin, img), it can be considered as a good dump.

-----
Updated test version.
improved: /sf (supported BIG.DAT of PS2 cheat disc)

1,304

sarami wrote:

SubQ channel errors is detected using crc16 but there are not these in SubP and RtoW.

RtoW area has checksums when it has data there (CD-Text or CD+G), for other cases there's no point, since all the bytes should be the same, if any of the bytes differ - it's an error.

1,305 (edited by reentrant 2018-04-22 13:44:05)

In Sub Pack mode the device corrects R to W using RS codes. Too bad D8 doesn't support Pack & C2 neutral

1,306

F1ReB4LL wrote:

RtoW area has checksums when it has data there (CD-Text or CD+G)

Ah, yes. You are right. dic haven't coded it yet. I don't understand how to use crc6.

1,307 (edited by jhmiller 2018-04-23 21:36:17)

I have found 2 problems dumping Dreamcast games.

Dumping South Park Rally (Europe) http://redump.org/disc/50196/
DIC shows the OutputHash error:

Calculating hash: T-8112D-50 (Track 12).bin
Calculating hash: T-8112D-50 (Track 13).bin
[F:OutputHash][L:342] GetLastError: 2, The system can not find the specified file. 

End time: 2018-04-23(Mon) 21:36:50

The dump seems correct, but better check it.
Link to the DIC files:
https://mega.nz/#!tBUFGBpZ!mtSK8qO9e779 … p-BuSDmbtA

==================================================================

And when try to dump the NFL QB Club 2001 (USA) http://redump.org/disc/51190/
DIC attempt to dump but crash.

Checking SubQ adr (Track)  1/ 1
Checking SubRtoW (Track)  1/ 1
Reading DirectoryRecord    3/   3
Set OpCode: 0xbe, SubCode: 1(Raw)
Creating bin from 44999 to 549150 (LBA)  44999

Link to DIC files generated until the error:
https://mega.nz/#!kNtllBLD!aQf6Qbt2uT_C … qmoflIVYjo

I love my XKey, my WODE and my 3Key.
Cerrar MegaUpload sólo es el comienzo de la censura, será el fin de la libertad.
Nada es verdad, todo está permitido.

1,308

Not sure if this has been talked about yet, but xTMODx discovered a but in DIC when dumping PSX discs with high error counts. Unless using the /s flag it keeps dumping incorrectly. xTMODx do you still have those logs?

All my posts and submission data are released into Public Domain / CC0.

1,309

jhmiller wrote:

South Park Rally (Europe)

random error exists in track.

LBA[399572, 0x618d4]: Track[06]: Index is changed from [01] to [00] [L:885]
LBA[399722, 0x6196a]: Track[06]: Index is changed from [00] to [01] [L:865]
LBA[404655, 0x62caf]: Track[07]: Subchannel & TOC doesn't sync. LBA on TOC[414956, 0x654ec], index[01]
LBA[404655, 0x62caf]: Track[07]: TrackNum is changed [L:840]
LBA[414806, 0x65456]: Track[07]: TrackNum is changed [L:840]
LBA[414806, 0x65456]: Track[07]: Index is changed from [01] to [00] [L:885]
LBA[404653, 0x62cad]: P[00], Q[0106010105560089572839bf]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[06], Idx[01], RMSF[01:05:56], AMSF[89:57:28]}, RtoW[0, 0, 0, 0]
LBA[404654, 0x62cae]: P[00], Q[0106010105570089572983cf]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[06], Idx[01], RMSF[01:05:57], AMSF[89:57:29]}, RtoW[0, 0, 0, 0]
LBA[404655, 0x62caf]: P[00], Q[010701010558008957308e0d]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[07], Idx[01], RMSF[01:05:58], AMSF[89:57:30]}, RtoW[0, 0, 0, 0]
LBA[404656, 0x62cb0]: P[00], Q[01060101055900895731df5e]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[06], Idx[01], RMSF[01:05:59], AMSF[89:57:31]}, RtoW[0, 0, 0, 0]
LBA[404657, 0x62cb1]: P[00], Q[010601010560008957324baf]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[06], Idx[01], RMSF[01:05:60], AMSF[89:57:32]}, RtoW[0, 0, 0, 0]

It's solved if you try dumping for several times, perhaps.

jhmiller wrote:

The dump seems correct

I think so, too.

jhmiller wrote:

NFL QB Club 2001

Updated test version, but I don't know whether it's fixed or not. Plz test.

And
added: GC/Wii (support GCC-4247N and GCC-4160N)

1,310

sarami wrote:
jhmiller wrote:

NFL QB Club 2001

Updated test version, but I don't know whether it's fixed or not. Plz test.

Now DIC dump the game, but finish with the "OutputHash" error.

Calculating hash: NFL.img
Calculating hash: NFL (Track 3).bin
Calculating hash: NFL (Track 4).bin
Calculating hash: NFL (Track 5).bin
[F:OutputHash][L:348] GetLastError: 2, El sistema no puede encontrar el archivo especificado.

End time: 2018-04-24(Tue) 08:24:23

Now I'm trying again. When DIC finish, post the result.

I love my XKey, my WODE and my 3Key.
Cerrar MegaUpload sólo es el comienzo de la censura, será el fin de la libertad.
Nada es verdad, todo está permitido.

1,311

Updated. Disabled the incorrect sub desync.

1,312

Dump made with the last test version seems to be all ok.

Link to files:
https://mega.nz/#!xIlgzQaT!8q9UJebTaH14 … xikZ7ddnQQ

DiscImageCreator.exe gd g T-8115N.bin 8 /q

AppVersion
        x86, AnsiBuild, Apr 24 2018 19:24:28
CurrentDirectory
        D:\
WorkingPath
         Argument: T-8115N.bin
         FullPath: D:\T-8115N
            Drive: D:
        Directory: 
         Filename: T-8115N
        Extension: .bin
Start time: 2018-04-24(Tue) 14:53:40
[WARNING] /c2 option isn't set. The result of dumping may be incorrect if c2 error exists.
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 0]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 1]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 2]
LBA[045000, 0x0afc8]: [F:ExecSearchingOffset][L:110]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-24-00 = ILLEGAL_REQUEST - INVALID FIELD IN CDB
lpCmd: be, 04, 00, 00, af, c8, 00, 00, 01, f8, 04, 00
dwBufSize: 2448
Couldn't read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 4]
Checking SubQ adr (Track)  1/ 1
Checking SubRtoW (Track)  1/ 1
Reading DirectoryRecord    3/   3
Set OpCode: 0xbe, SubCode: 1(Raw)
Creating bin from 44999 to 549150 (LBA) 549149
Descrambling img (LBA) 504149/504150
Exec ""D:\EccEdc.exe" check "D:\T-8115N.img""
FILE: D:\T-8115N.img
Checking sectors (LBA) 504149/504149
[NO ERROR] User data vs. ecc/edc match all
Creating bin, cue (Track)  5/ 5
Calculating hash: T-8115N.scm
Calculating hash: T-8115N.img
Calculating hash: T-8115N (Track 3).bin
Calculating hash: T-8115N (Track 4).bin
Calculating hash: T-8115N (Track 5).bin
End time: 2018-04-24(Tue) 15:10:00
I love my XKey, my WODE and my 3Key.
Cerrar MegaUpload sólo es el comienzo de la censura, será el fin de la libertad.
Nada es verdad, todo está permitido.

1,313

sarami wrote:

- added: cue file of GD-ROM image

Out of curiosity, does it check for CATALOG, ISRC, FLAGS, CD-TEXT fields in GD mode? Very unlikely to see them there, but still smile

1,314

It only checks LDA. Do you know the GD-ROM these fields have?

1,315

No. But how will we know? Checking each .sub manually is a hard work.

1,316

user7 wrote:

Not sure if this has been talked about yet, but xTMODx discovered a but in DIC when dumping PSX discs with high error counts. Unless using the /s flag it keeps dumping incorrectly. xTMODx do you still have those logs?

yea finally i came to this, so here are the logs from the dump whit errors...

first dump using PX-712A with this command "dic cd i: dump 8 /c2"

https://www92.zippyshare.com/v/zFm4yhdo/file.html

<rom name="dump (Track 1).bin" size="222619152" crc="b56470c1" md5="d9216b8bfa6cc8b2e50733ca505e9c45" sha1="4d4ac76965a98d35db2a342d35cdf84781e4ddd2" />
<rom name="dump (Track 2).bin" size="176400" crc="46ec4749" md5="0f06439a8c3b5b45317de8ff57eb5f99" sha1="c9091cc16fce0476bfff2a0375466274030ad3cd" />
<rom name="dump (Track 3).bin" size="176400" crc="04870751" md5="71fd739808de47f41143b9bb637e2515" sha1="4e5564f9495c0e5bccfb4205b7103cd1248367d0" />
<rom name="dump (Track 4).bin" size="455041440" crc="b6e3447d" md5="ced858e5742690a195a12ac2a800d89a" sha1="733ac6091918e79098ed19bab080b7d0a79317cb" />

https://i.imgur.com/v74RztC.jpg



second dump using PX-712A with this command "dic cd i: dump 8 /c2 /s 2"

https://www8.zippyshare.com/v/giwB05KB/file.html

<rom name="dump (Track 1).bin" size="579471648" crc="d69cc14b" md5="d14b18d67b80a82048eaf8c5cddb31d7" sha1="23fb0f026864e5c7a2239c30ec675a7804110238" />
<rom name="dump (Track 2).bin" size="26641104" crc="2043a212" md5="19f131c97f5b58982782ade572863bb9" sha1="a80ff9a111217b94fdef968860046b29f778b870" />
<rom name="dump (Track 3).bin" size="39544176" crc="5e7447f2" md5="3983d8c423157f3021a0ca926a5a17e2" sha1="9f295039cc410b63668b2cd8f4ac725a61a72c7a" />
<rom name="dump (Track 4).bin" size="32356464" crc="f070454d" md5="32b46b97fdc55b6ccff99fcc1ed7ff97" sha1="32b149cbbae92462121b5c0e1f86adebc8052563" />

https://i.imgur.com/wV2mWmV.jpg



third dump using PX-716AL with this command "dic cd k: dump 8 /c2"

https://www108.zippyshare.com/v/ywfMQIhQ/file.html

<rom name="dump (Track 1).bin" size="579471648" crc="d69cc14b" md5="d14b18d67b80a82048eaf8c5cddb31d7" sha1="23fb0f026864e5c7a2239c30ec675a7804110238" />
<rom name="dump (Track 2).bin" size="26641104" crc="2043a212" md5="19f131c97f5b58982782ade572863bb9" sha1="a80ff9a111217b94fdef968860046b29f778b870" />
<rom name="dump (Track 3).bin" size="39896976" crc="6d2f46eb" md5="08f4af071109d0f56890c8a27139c3be" sha1="c51cf73f5323d01c58de2205c75400b051e5b075" />
<rom name="dump (Track 4).bin" size="32003664" crc="3f57dea6" md5="6c7f66c1e878b096ec067ffb23e6a160" sha1="e78cdcda6ef8af3374b5d9291a365ab388cc3243" />

the third dump also produced "dump (Subs indexes).*" files so i had the dump twice with same command but different hash

<rom name="dump (Subs indexes) (Track 1).bin" size="579471648" crc="d69cc14b" md5="d14b18d67b80a82048eaf8c5cddb31d7" sha1="23fb0f026864e5c7a2239c30ec675a7804110238" />
<rom name="dump (Subs indexes) (Track 2).bin" size="26641104" crc="2043a212" md5="19f131c97f5b58982782ade572863bb9" sha1="a80ff9a111217b94fdef968860046b29f778b870" />
<rom name="dump (Subs indexes) (Track 3).bin" size="32815104" crc="e69e6b20" md5="1b1570f5aa75ec53fbfb34690f9c4290" sha1="4fd36c4799361cc339b513fea92628bb63b49a51" />
<rom name="dump (Subs indexes) (Track 4).bin" size="39085536" crc="d2e1901a" md5="774a41621ac2e0c38ddadee295447efe" sha1="2c0282969171164b993639476774f58adbe4292e" />



fourth dump using PX-716AL with this command "dic cd k: dump 8 /c2 /s 2"

https://www106.zippyshare.com/v/WPmWflGS/file.html

<rom name="dump (Track 1).bin" size="579471648" crc="d69cc14b" md5="d14b18d67b80a82048eaf8c5cddb31d7" sha1="23fb0f026864e5c7a2239c30ec675a7804110238" />
<rom name="dump (Track 2).bin" size="26641104" crc="2043a212" md5="19f131c97f5b58982782ade572863bb9" sha1="a80ff9a111217b94fdef968860046b29f778b870" />
<rom name="dump (Track 3).bin" size="39544176" crc="5e7447f2" md5="3983d8c423157f3021a0ca926a5a17e2" sha1="9f295039cc410b63668b2cd8f4ac725a61a72c7a" />
<rom name="dump (Track 4).bin" size="32356464" crc="f070454d" md5="32b46b97fdc55b6ccff99fcc1ed7ff97" sha1="32b149cbbae92462121b5c0e1f86adebc8052563" />

1,317 (edited by sarami 2018-04-28 02:02:07)

xTMODx wrote:

here are the logs from the dump whit errors...

1st and 3rd dumps are bad because it fails to get the sub-channel.
2nd and 4th dumps seems good but there are some sub-channel errors in 2nd dump and main-channel errors in 4th dump.

Anyway, try the latest release version. And it is also valid to change the reading speed (e.g. 16x 24x).

F1ReB4LL wrote:

does it check for CATALOG, ISRC, FLAGS, CD-TEXT fields in GD mode?

Added.

And
added: GC/Wii (support GCC-4240N, 4243N, 4244N(not tested yet), 4246N(not tested yet))

1,318

DIC crash whit Dreamcast game Silver (Europe - Serial: T-15106D-06).

Link to the DIC files:
https://mega.nz/#!hN8DRTaD!41cLLwhZ7uY6 … y0QbAxNG1g

The first time, I get this error "Directory Record is over 16384" and then DIC crash:

AppVersion
        x86, AnsiBuild, Apr 27 2018 04:46:16
CurrentDirectory
        D:\Sistemas\Dreamcast\DC Dumper
WorkingPath
         Argument: T-15109D-06.bin
         FullPath: D:\Sistemas\Dreamcast\DC Dumper\T-15109D-06
            Drive: D:
        Directory: \Sistemas\Dreamcast\DC Dumper\
         Filename: T-15109D-06
        Extension: .bin
Start time: 2018-04-28(Sat) 19:29:52
[WARNING] /c2 option isn't set. The result of dumping may be incorrect if c2 error exists.
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 0]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 1]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 2]
LBA[045000, 0x0afc8]: [F:ExecSearchingOffset][L:110]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-24-00 = ILLEGAL_REQUEST - INVALID FIELD IN CDB
lpCmd: be, 04, 00, 00, af, c8, 00, 00, 01, f8, 04, 00
dwBufSize: 2448
Couldn't read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 4]
Checking SubQ adr (Track)  3/ 3
Checking SubRtoW (Track)  3/ 3
Directory Record is over 16384

In the following attempts DIC crahs after the "Checking SubRtoW (Track)  3/ 3":

AppVersion
        x86, AnsiBuild, Apr 27 2018 04:46:16
CurrentDirectory
        D:\Sistemas\Dreamcast\DC Dumper
WorkingPath
         Argument: T-15109D-06.bin
         FullPath: D:\Sistemas\Dreamcast\DC Dumper\T-15109D-06
            Drive: D:
        Directory: \Sistemas\Dreamcast\DC Dumper\
         Filename: T-15109D-06
        Extension: .bin
Start time: 2018-04-28(Sat) 22:15:01
[WARNING] /c2 option isn't set. The result of dumping may be incorrect if c2 error exists.
LBA[045000, 0x0afc8]: [F:ExecSearchingOffset][L:110]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-11-00 = MEDIUM_ERROR - UNRECOVERED READ ERROR
lpCmd: be, 04, 00, 00, af, c8, 00, 00, 01, f8, 00, 00
dwBufSize: 2352
Couldn't read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 0]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 1]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 2]
LBA[045000, 0x0afc8]: [F:ExecSearchingOffset][L:110]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-24-00 = ILLEGAL_REQUEST - INVALID FIELD IN CDB
lpCmd: be, 04, 00, 00, af, c8, 00, 00, 01, f8, 04, 00
dwBufSize: 2448
Couldn't read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 4]
Checking SubQ adr (Track)  3/ 3
Checking SubRtoW (Track)  3/ 3
I love my XKey, my WODE and my 3Key.
Cerrar MegaUpload sólo es el comienzo de la censura, será el fin de la libertad.
Nada es verdad, todo está permitido.

1,319

Changed: directory record size from 16384 to 65535

1,320 (edited by jhmiller 2018-04-29 10:39:12)

sarami wrote:

Changed: directory record size from 16384 to 65535

Thanks sarami, but why put a limit?
If another disc reaches that limit, again to change it.
Would not it be better not to limit it?

Edit:
With the test version "Apr 29 2018" continue to fail.

AppVersion
        x86, AnsiBuild, Apr 29 2018 11:16:14
CurrentDirectory
        D:\Sistemas\Dreamcast\DC Dumper
WorkingPath
         Argument: T-15109D-06.bin
         FullPath: D:\Sistemas\Dreamcast\DC Dumper\T-15109D-06
            Drive: D:
        Directory: \Sistemas\Dreamcast\DC Dumper\
         Filename: T-15109D-06
        Extension: .bin
Start time: 2018-04-29(Sun) 11:43:52
[WARNING] /c2 option isn't set. The result of dumping may be incorrect if c2 error exists.
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 0]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 1]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 2]
LBA[045000, 0x0afc8]: [F:ExecSearchingOffset][L:110]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-24-00 = ILLEGAL_REQUEST - INVALID FIELD IN CDB
lpCmd: be, 04, 00, 00, af, c8, 00, 00, 01, f8, 04, 00
dwBufSize: 2448
Couldn't read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 0, SubCode: 4]
Checking SubQ adr (Track)  3/ 3
Checking SubRtoW (Track)  3/ 3
Directory Record is over 65535

https://mega.nz/#!cBlTxJiZ!2GrC42BycUo9 … SXeuK6ZvBg

I love my XKey, my WODE and my 3Key.
Cerrar MegaUpload sólo es el comienzo de la censura, será el fin de la libertad.
Nada es verdad, todo está permitido.

1,321 (edited by sarami 2018-05-01 17:44:10)

jhmiller wrote:

but why put a limit?

Ecma-119 wrote:

Format of a Path Table Record

BP Field name Content
1 Length of Directory Identifier (LEN_DI) numerical value
2 Extended Attribute Record Length numerical value
3 to 6 Location of Extent numerical value
7 to 8 Parent Directory Number numerical value
9 to (8 +
LEN_DI)

Directory Identifier d-characters, d1-characters,
(00) byte
(9 + LEN_DI) Padding Field (00) byte

Parent Directory Number (BP 7 to 8)
This field shall specify as a 16-bit number the record number in the Path Table for the parent directory of the
directory.

16-bit = 0xffff = 65535

Added the code for flushing log. (Because almost all files are 0 size)

EDIT
improved: PS2 cheat disc (support the sub-channel of huge Lead-out )

EDIT (5/2)
added: check the region of PSX if /nl is used. Because Libcrypt is only used by PAL.

1,322 (edited by Kurems 2018-04-30 15:14:09)

Dizzy replied to my question about possible compatible USB Plextor drives.
So, it's a no-go.

Thanks.

1,323

https://mega.nz/#!RZkWxACJ!gllef6IbSF3_ … gL5j5TGbqo
https://mega.nz/#!sMFiRaAR!bpSobINe4Co6 … _bgfP_G-js

Sarami, why does it happen? Same drive, same command, lots of suberrors in the first case case (every sector is "fixed" due to sector shift?), 10 times less in the 2nd case. Maybe DIC should restart the dumping process when that happens? Or does it need to eject/insert the tray and swap again for a chance of a better dump?

1,324

Sarami, is there a command line option to probe cd/dvd drive for available drive speeds and then report to console?

would be useful for DIC-gui purposes (probe drive / populate gui with real usable drive speeds). currently seems like trial/error?
perhaps a "discimagecreator -ls" for list speeds option? wink

1,325

jhmiller wrote:

With the test version "Apr 29 2018" continue to fail.

Found a bug and fixed it perhaps.

F1ReB4LL wrote:

DIC should restart the dumping process when that happens?

Do you want to restart when how many errors are counted?

number78 wrote:

is there a command line option to probe cd/dvd drive for available drive speeds and then report to console?

Is this OK?

C:DiscImageCreator.exe ls f
AppVersion
        x86, AnsiBuild, May  2 2018 13:26:55
Start time: 2018-05-02(Wed) 13:37:16
ReadSpeedMaximum: 8468KB/sec (48x)
End time: 2018-05-02(Wed) 13:37:16