1

(1,167 replies, posted in General discussion)

Supported PTP and DL disc.

2

(1,167 replies, posted in General discussion)

My DL disc

             TrackPath: Opposite Track Path
        NumberOfLayers: Double Layer
          TrackDensity: 0.74μm/track
         LinearDensity: 0.293μm/bit
    StartingDataSector:  196608 (0x30000)
         EndDataSector: 15995449 (0xf41239)
    EndLayerZeroSector: 2224591 (0x21f1cf)

Your log

                 TrackPath: Parallel Track Path
            NumberOfLayers: Double Layer
              TrackDensity: 0.74μm/track
             LinearDensity: 0.293μm/bit
        StartingDataSector:   196608 (0x30000)
             EndDataSector:  1702255 (0x19f96f)
        EndLayerZeroSector:        0 (0)

I had thought all of the DL disc is 'Opposite Track Path', but this DL disc has 'Parallel Track Path'. I understood DIC can't dump 'PTP' and 'DL' disc. I don't know how to fix this now.


jhmiller wrote:

With my Plextor PX-755A the DIC seems to freeze here (I stop the process after 1 hour or waiting):

Some changed. http://www.mediafire.com/file/eq80y20l9 … or_test.7z
I have PX-755SA too, but my 755 can't get the scrambled sector when dumps the HDA of GD-ROM using the audio trap disc, so I can't test. (In the case of my PC, if doesn't use the audio trap disc, dic can dump the HDA till 79:59:74. I don't know why.)

And I changed VS2015 to VS2017. Please download and install the redistributable package. https://aka.ms/vs/15/release/VC_redist.x86.exe

3

(1,167 replies, posted in General discussion)

ajshell1 wrote:

I've noticed a problem with DIC.

Please log. Does this occur in all your DL discs or only this disc? I tried my DL disc but dic could recognize the second layer.

4

(1,167 replies, posted in General discussion)

All sectors.

It's really weird...

c2 error offset is perhaps same as main channel offset. To confirm this, it needs to test by the large offset disc (over 588 samples) and its disc has c2 error.

5

(1,167 replies, posted in General discussion)

If the plextor drive is requested LBA 10000 using 0xd8, drive returns the data as follows.
- main channel depends on the combined offsets.
- c2 is LBA 9999. (offset is -1)
- sub channel is LBA 10000. (offset is 0)

It was easy to find the offset about main and sub because there are the msf in these data. But there isn't the address in c2.

6

(1,167 replies, posted in General discussion)

*2017-12-10
- added: Reading path table & directory record of GDROM HD Area
- added: Reading joliet file system (if iso9600 didn't read)
- added: Writing the hash of the toc vs. subs desync disc and the scrambled main channel (.scm file)
- added: Argument of /f option (to delete the drive cache per specific value)
- changed: Rename _sub.txt to _subReadable.txt
- fixed: Dumping of GDROM (didn't work from 2017-08-18)
- fixed: 1st sector of the pregap sector has invalid index of the subchannel
- rewrote: Recovering C2 error (only plextor. not support no-plextor drive now)
            => I definitely understood the plextor drive has -1 sector offset about C2 error.

Egen wrote:

Whenever I've used DIC, I've always received a message that C2 errors are not set and that if any exist, the rip could be inaccurate. Should I do anything about this?

use '/c2'

7

(8 replies, posted in General discussion)

General 'Photo CD' is yes.

If first sector of the pregap sector has incorrect index (e.g. 40), dic has fixed by incorrect value (e.g. 1). Because dic fixes the  value of current sector seeing the value of previous sector. In case of the first sector of the pregap sector, it should be fixed by seeing the next sector.
This will be fixed until tomorrow.

Vay_sub.txt

LBA[104783, 0x1994f]: P[00], Q[010701015427002319082083]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[07], Idx[01], RMSF[01:54:27], AMSF[23:19:08]}, RtoW[0, 0, 0, 0]
LBA[104784, 0x19950]: P[00], Q[01080101542800231909cd0f]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[08], Idx[01], RMSF[01:54:28], AMSF[23:19:09]}, RtoW[0, 0, 0, 0]
LBA[104785, 0x19951]: P[ff], Q[010800000173002319107bfd]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[08], Idx[00], RMSF[00:01:73], AMSF[23:19:10]}, RtoW[0, 0, 0, 0]

Vay_subError.txt

LBA[104784, 0x19950]: Track[07]: SubQ[14]:Idx[40] -> [01], L:[399]
LBA[104784, 0x19950]: Track[07]: SubQ[15-17]:PrevRel[8577, 01:54:27], Rel[149, 00:01:74] -> [8578, 01:54:28], L:[668]

This is a random error. Please use '/s 2' and/or change the drive speed.

10

(8 replies, posted in General discussion)

F1ReB4LL wrote:

Ringcodes are useful for predicting possible undumped revisions.

And PVD is useful too. Why isn't there PVD field in psx db?

Some fixed for non plextor drive. Plz try the latest test version if possible.

Because these programs dump the data sector as data sector (0xbe mode), but dic dumps the data sector as audio sector (0xd8 mode), then audio sector is descrambled to data sector.

13

(1,167 replies, posted in General discussion)

Thanks. Whizz matches the db. It seems there isn't problem about the c2 error recovering. I'll upload the src code to github in the near future.

Sometimes it needs many rereads to fix the error.

Yes. The 3do disc of Schrodinger was needed over 6000 rereading.


EDIT
http://forum.redump.org/post/56215/#p56215
I bought 'Der korsar' and confirmed this disc had the intensional c2 errors in 'CORSAIRS.PRT' and '_SETUP.DLL'.
Also I confirmed 'Fort Boyard Millenium' hadn't the intensional c2 errors.


About the corrupted subchannel

http://redump.org/disc/45930/ and http://redump.org/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.

improved /f option

        /f      Use 'Force Unit Access' flag to delete the drive cache
                        val     delete per specified value (default: 1)
escarlata wrote:

LBA[311865, 0x4c239]: [F:ProcessReadCD][L:1450]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 05-21-00 = ILLEGAL_REQUEST - LOGICAL BLOCK ADDRE
SS OUT OF RANGE

It seems your drive doesn't support reading lead-out.

This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 1, Su
bCode: 0]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 1, Su
bCode: 1]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 1, Su
bCode: 2]
This drive can read a data sector at scrambled mode [OpCode: 0xbe, C2flag: 1, Su
bCode: 4]
OK

This is bug. scrambled dumping isn't supported too. Please use the recommended drive.

15

(1,167 replies, posted in General discussion)

F1ReB4LL wrote:

And something should be done with the subchannels as well, Pocket Fighter tracks 32 to 34 have wrong sizes and wrong gaps.

_sub.txt

LBA[267511, 0x414f7]: P[ff], Q[01330101007100592861320e]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[33], Idx[01], RMSF[01:00:71], AMSF[59:28:61]}, RtoW[0, 0, 0, 0]
LBA[267512, 0x414f8]: P[ff], Q[01330001007200592862ab6c]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[33], Idx[00], RMSF[01:00:72], AMSF[59:28:62]}, RtoW[0, 0, 0, 0]
LBA[267513, 0x414f9]: P[ff], Q[013400000173005928635d76]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[34], Idx[00], RMSF[00:01:73], AMSF[59:28:63]}, RtoW[0, 0, 0, 0]
LBA[269088, 0x41b20]: P[ff], Q[013401001901005949636c7d]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[34], Idx[01], RMSF[00:19:01], AMSF[59:49:63]}, RtoW[0, 0, 0, 0]
LBA[269089, 0x41b21]: P[ff], Q[01350000007300594964bb09]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[35], Idx[00], RMSF[00:00:73], AMSF[59:49:64]}, RtoW[0, 0, 0, 0]
LBA[269090, 0x41b22]: P[ff], Q[0135000001720059496544d9]{Audio, 2ch, Copy NG, Pre-emphasis No, Track[35], Idx[00], RMSF[00:01:72], AMSF[59:49:65]}, RtoW[0, 0, 0, 0]

This is simply the random errors of subchannel, not be related to c2 error. It's a little difficult to fix it of the boundary of track. I'll fix it if possible.
The result will change if the reading speed is changed.


EDIT
Uploaded the test version (20171122).

olofolleola4 wrote:

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

Supported reading joliet.

F1ReB4LL wrote:

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?

F1ReB4LL wrote:

Btw, why not add the .scm image checksum into the _disc.txt file as well (not only .img)?

Added.

F1ReB4LL wrote:

you should set the 1024 rereads by default

Changed to 1000.

16

(1,167 replies, posted in General discussion)

olofolleola4 wrote:

The Elder Scrolls III: Tribunal

There are 3 file systems in disc (iso9660, Romeo ?, Joliet).
Ref: https://www.isobuster.com/help/file_systems

I confirmed there are the root directory record in 69 sector of joliet, but there aren't it in iso9660... originally, there should be it in 24 sector but this sector has all zero byte.
dic reads only iso9660 now. So if it can't read iso9660 properly, it should read joliet. Please wait until fix it.

F1ReB4LL wrote:

I'm adding all the PCE (Subs Indexes) dumps as hidden entries, so these are needed.

I'll divide the toc and sub indexes.

I wanted to know "FLAGS DCP" was valid or not, but you judged it as valid. IMO, you should leave the fact that FLAGS DCP is changed per 4 sectors to comment if this flags are irregular.

Anything will be fine. But the db already had been overwritten by your dump... so plz tell me the result of mode 0 only.

19

(1,167 replies, posted in General discussion)

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.

This is usually used.

subdump -i <DriveLetter>: -f <subfile> -mode 6 -rereadnum 25 -speed 4 -flushspeed 4 -fix 2

But this time, please also try "-mode 0" "-mode 1" "-mode 2" "-mode 4" "-mode 5".
The value of "-rereadnum" "-speed" "-flushspeed" is left to you.

_sub.txt

LBA[000000, 0000000]: P[ff], Q[61010100000000000200113f]{ Data,      Copy OK,                  Track[01], Idx[01], RMSF[00:00:00], AMSF[00:02:00]}, RtoW[0, 0, 0, 0]
LBA[000001, 0x00001]: P[00], Q[61010100000100000201ab4f]{ Data,      Copy OK,                  Track[01], Idx[01], RMSF[00:00:01], AMSF[00:02:01]}, RtoW[0, 0, 0, 0]
LBA[000002, 0x00002]: P[00], Q[410101000002000002024cf3]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:02], AMSF[00:02:02]}, RtoW[0, 0, 0, 0]
LBA[000003, 0x00003]: P[00], Q[41010100000300000203f683]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:03], AMSF[00:02:03]}, RtoW[0, 0, 0, 0]
LBA[000004, 0x00004]: P[00], Q[41010100000400000204e1b0]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:04], AMSF[00:02:04]}, RtoW[0, 0, 0, 0]
LBA[000005, 0x00005]: P[00], Q[410101000005000002055bc0]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:05], AMSF[00:02:05]}, RtoW[0, 0, 0, 0]
LBA[000006, 0x00006]: P[00], Q[61010100000600000206bc7c]{ Data,      Copy OK,                  Track[01], Idx[01], RMSF[00:00:06], AMSF[00:02:06]}, RtoW[0, 0, 0, 0]
LBA[000007, 0x00007]: P[00], Q[61010100000700000207060c]{ Data,      Copy OK,                  Track[01], Idx[01], RMSF[00:00:07], AMSF[00:02:07]}, RtoW[0, 0, 0, 0]
LBA[000008, 0x00008]: P[00], Q[61010100000800000208921a]{ Data,      Copy OK,                  Track[01], Idx[01], RMSF[00:00:08], AMSF[00:02:08]}, RtoW[0, 0, 0, 0]
LBA[000009, 0x00009]: P[00], Q[61010100000900000209286a]{ Data,      Copy OK,                  Track[01], Idx[01], RMSF[00:00:09], AMSF[00:02:09]}, RtoW[0, 0, 0, 0]
LBA[000010, 0x0000a]: P[00], Q[410101000010000002103e59]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:10], AMSF[00:02:10]}, RtoW[0, 0, 0, 0]
LBA[000011, 0x0000b]: P[00], Q[410101000011000002118429]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:11], AMSF[00:02:11]}, RtoW[0, 0, 0, 0]
LBA[000012, 0x0000c]: P[00], Q[410101000012000002125a98]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:12], AMSF[00:02:12]}, RtoW[0, 0, 0, 0]
LBA[000013, 0x0000d]: P[00], Q[41010100001300000213e0e8]{ Data,      Copy NG,                  Track[01], Idx[01], RMSF[00:00:13], AMSF[00:02:13]}, RtoW[0, 0, 0, 0]

ctl/adr(41) is changed to 61 per 4 sectors. It's weird. Please check by subdump.

22

(1,167 replies, posted in General discussion)

Thx.
_volDesc.txt

                                   :
              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
                                    :
========== 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?

23

(1,167 replies, posted in General discussion)

Updated test version. Test and upload the log please.

To: iR0b0t
BTW, why isn't there "Errors count" in "NEC PC Engine CD - TurboGrafx-CD" ?

25

(1,167 replies, posted in General discussion)

Updated.

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


iR0b0t wrote:

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:

ajshell1 wrote:

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

Please tell me the procedure in detail.