DiscImageCreator

[F1ReB4LL]

Uploaded test version.
- improved: Rewrote the C2 error recovering logic

Code: Select all

        /c2     Continue reading CD to recover C2 error existing sector
                        val1    value to reread (default: 10, min: 2, max: 255)
                        val2    first LBA to reread (default: 0)
                        val3    last LBA to reread (default: end-of-sector)

I don't understand the current logic, it rereads all the sectors now, not only the ones with C2 errors? Works very slow and ineffective. Took 6 hours, ended with the same bad results as before. DIC from 2013 dumps the same disc in 30 minutes with no errors. Why not to rollback to the old error correction, if it works fast and gives better results?

[sarami]

Updated.

Code: Select all

        /c2     Continue reading CD to recover C2 error existing sector
                        val1    value to reread (default: 255)
                        val2    0: reread sector c2 error is reported (default)
                                1: reread all (or from first to last) sector
                        val3    first LBA to reread (default: 0)
                        val4    last LBA to reread (default: end-of-sector)
                                val3, 4 is used when val2 is 1

----

it rereads all the sectors now, not only the ones with C2 errors?

As I already said in PM, the c2 error report of the drive isn't completely reliable as far as I see the log of A Murder of Crows, so I check all sectors if even one c2 error exists. But when val2 is "0", only rereads sector c2 error is reported.

Why not to rollback to the old error correction

The old logic saw the sector all-bytes matched for two consecutive as the correct sector, but it could get the incorrect sector all-bytes matched for two consecutive.
So my bad disc couldn't get the all recovered sector. Your disc is nothing but getting the correct sector by accident.

I will recheck --- b) Dump with "/c2 /q /p" parameters --- later again.

I confirmed that 0xd8 with 08(Main+C2+Sub) couldn't get the pregap sector properly if first track is the data.
If resolves this, when reads the pregap sector of the first track, it has to use 0xd8 with 02(Main+Sub).


EDIT:
Sorry. 20171102 version wasn't uploaded. Uploaded as 20171106. I confirmed my damaged disc is recovered all using this version.


EDIT2:

However, I have never had any sucess in trying to use two instances of DIC at once.

Please tell me the procedure in detail.

[battosai121]

Not Really sure what the problem is but on the newer version of this including the test version it errors out on dumping discs for me, but older version do work.

Code: Select all

LBA[268743, 0x419c7]: [F:GetLBAForSubChannelOffset][L:58]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRESS OUT OF RANGE
lpCmd: be, 04, 00, 04, 19, c7, 00, 00, 01, f8, 04, 00
dwBufSize: 2448
OK
Checking SubQ adr (Track)  1/ 1
Checking SubRtoW (Track)  1/ 1
Reading DirectoryRecord    5/   5

Set OpCode: 0xbe, SubCode: 1(Raw)
Checking SubQ ctl (Track)  1/ 1
[F:ProcessReadCD][L:1462] GetLastError: 87, The parameter is incorrect.

Please wait for 40000 milliseconds until the device is returned

[sarami]

Updated test version. Test and upload the log please.

[olofolleola4]

I want to start off by giving sarami and all contributors to DiscImageCreator kudos and a warm thank you for all the work you do!

I've experienced a bug, tested with the latest version and test version (no idea if it's present in earlier versions).
DIC doesn't recognize that The Elder Scrolls III: Tribunal has a SafeDisc 2.xx.xxx protection, and therefor it cannot get dumped properly (it founds a load of C2 errors, naturally).
I'll include the compressed archive with the files from the latest test version of DIC before I canceled the dumping of that disc.
Cheers!

[sarami]

Thx.
_volDesc.txt

Code: Select all

                                   :
              Length of Directory Record: 34
        Extended Attribute Record Length: 0
                      Location of Extent: 335260
                             Data Length: 2048
                 Recording Date and Time: 2002-10-31 16:31:47 -05:00
                              File Flags: 2 (Visible, Directory, Disassociated, File has't record format, Owner/Group ID has't, Final Directory Record)
                          File Unit Size: 0
                                    :

Code: Select all

========== LBA[000020, 0x00014]: Path Table Record ==========
         Length of Directory Identifier: 1
    Length of Extended Attribute Record: 0
                     Position of Extent: 335260
              Number of Upper Directory: 1
                   Directory Identifier: 
                                 :

This disc points 335260 sector as the position of root directory, but this sector is all zero byte, so dic can't read the directory record and can't detect the protect.
I think the correct position of root dir is 21 or 22 or 23 or 24.

Can Isobuster read the directory correctly?

[olofolleola4]

Thx.
_volDesc.txt

Code: Select all

                                   :
              Length of Directory Record: 34
        Extended Attribute Record Length: 0
                      Location of Extent: 335260
                             Data Length: 2048
                 Recording Date and Time: 2002-10-31 16:31:47 -05:00
                              File Flags: 2 (Visible, Directory, Disassociated, File has't record format, Owner/Group ID has't, Final Directory Record)
                          File Unit Size: 0
                                    :

Code: Select all

========== LBA[000020, 0x00014]: Path Table Record ==========
         Length of Directory Identifier: 1
    Length of Extended Attribute Record: 0
                     Position of Extent: 335260
              Number of Upper Directory: 1
                   Directory Identifier: 
                                 :

This disc points 335260 sector as the position of root directory, but this sector is all zero byte, so dic can't read the directory record and can't detect the protect.
I think the correct position of root dir is 21 or 22 or 23 or 24.

Can Isobuster read the directory correctly?

IsoBuster doesn't show any directory record at sector 335260, it's all zero byte.
I can see the start of a directory record from sector 20-->23.
If you need any screenshots or anything else, just ask for it

[F1ReB4LL]

https://redump.info/disc/45930/ and https://redump.info/disc/45931/ are undumpable with DIC (including the recent versions, as I understand) - https://www.sendspace.com/file/31jg9r
Digital Pinball: Necronomicon: Revelations was already reported before, though.

Also, please fix the .dat file generator for Subs Indexes dumps. It doesn't add Subs Indexes .bin files into the .dat anymore, that's not correct. Maybe worth to make a normal dat for normal bins and additional (Subs Indexes).dat for (Subs Indexes).bin files, then?

[sarami]

Digital Pinball: Necronomicon: Revelations was already reported before, though.

I showed the way to deal to him at that time. (try to use "/s 2" and/or "/f" or change the reading speed or change the drive)

This is definitely the problem of the drive(or disc) that returns the corrupted subchannel, but I don't know why the drive(or disc) returns such the corrupted those.
So I consider these options are enabled if there are some corrupted those.

It doesn't add Subs Indexes .bin files into the .dat anymore

Firstly, are "Subs Indexes" needed? I know that this is used for some pc-engine CDROM^2, but redump'org adopts "TOC Indexes".


BTW, is your pocket fighter recovered using the latest test version? If there is any of the problem, plz tell me.
I asked A Murder of Crows for testing too about ten days ago, but it seems he is busy, haven't reported yet.

[F1ReB4LL]

Digital Pinball: Necronomicon: Revelations was already reported before, though.

I showed the way to deal to him at that time. (try to use "/s 2" and/or "/f" or change the reading speed or change the drive)

This is definitely the problem of the drive(or disc) that returns the corrupted subchannel, but I don't know why the drive(or disc) returns such the corrupted those.
So I consider these options are enabled if there are some corrupted those.

While I could agree about Wangan here, Pinball subdump is errorless, so it's not the disc's fault.

It doesn't add Subs Indexes .bin files into the .dat anymore

Firstly, are "Subs Indexes" needed? I know that this is used for some pc-engine CDROM^2, but redump'org adopts "TOC Indexes".

I'm adding all the PCE (Subs Indexes) dumps as hidden entries, so these are needed. Will probably make them yellow/visible later, dunno, need to consult with iR0b0t.