1,151

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.

1,152

sarami wrote:

BTW, is your pocket fighter recovered using the latest test version? If there is any of the problem, plz tell me.

Well, it is effective, yes - https://www.sendspace.com/file/79klox (but you should set the 1024 rereads by default, like it was in 2013 version, not 255). And something should be done with the subchannels as well, Pocket Fighter tracks 32 to 34 have wrong sizes and wrong gaps. 2013 version detects the gaps properly.

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

1,153 (edited by sarami 2017-11-22 09:34:39)

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.

1,154

sarami wrote:
F1ReB4LL wrote:

you should set the 1024 rereads by default

Changed to 1000.

I'd vote for 4096 smile Sometimes it needs many rereads to fix the error.

sarami wrote:

I asked A Murder of Crows for testing too about ten days ago, but it seems he is busy, haven't reported yet.

Works for him.

Post's attachments

Whizz [T-9514HP-01172 A] Redump (New).7z 1.71 mb, 16 downloads since 2017-11-26 

You don't have the permssions to download the attachments of this post.

1,155 (edited by sarami 2017-12-01 19:26:51)

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)

1,156

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? I have a PX-716A.

1,157

*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'

"I definitely understood the plextor drive has -1 sector offset about C2 error"

Could you explain it?

1,159

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.

Is it the case just for sector with LBA 10000 or for all sectors >= 10000. It's really weird...

1,161

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.

1,162

I have tried to dump a Dreamcast game with this new release of DIC.

First load the audio trap disc.
Stop the drive and change the audio trap disc for the Dreamcast game.

With my Plextor PX-755A the DIC seems to freeze here (I stop the process after 1 hour or waiting):
D:\Sistemas\Dreamcast\DIC\Release_ANSI>DiscImageCreator.exe gd p T-1250M\T-1250M.bin 8 /c2 /q
AppVersion
        x86, AnsiBuild, Dec 10 2017 17:54:51
/c2 val1 is omitted. set [4000]
/c2 val2 is omitted. set [0]
CurrentDirectory
        D:\Sistemas\Dreamcast\DIC\Release_ANSI
WorkingPath
         Argument: T-1250M\T-1250M.bin
         FullPath: D:\Sistemas\Dreamcast\DIC\Release_ANSI\T-1250M\T-1250M
            Drive: D:
        Directory: \Sistemas\Dreamcast\DIC\Release_ANSI\T-1250M\
         Filename: T-1250M
        Extension: .bin
Start time: 2017-12-10(Sun) 12:23:15
Set the drive speed: 1411KB/sec
This drive supports [OpCode: 0xd8, SubCode: 1]
This drive supports [OpCode: 0xd8, SubCode: 2]
This drive supports [OpCode: 0xd8, SubCode: 8]
Checking SubQ adr (Track)  1/ 1
Checking SubRtoW (Track)  1/ 1
LBA[045000, 0x0afc8]: [F:ExecReadGD][L:1252]
        Opcode: 0xbe
        ScsiStatus: 0x02 = CHECK_CONDITION
        SenseData Key-Asc-Ascq: 03-02-8d = MEDIUM_ERROR - VENDER UNIQUE ERROR
lpCmd: be, 04, 00, 00, af, c8, 00, 00, 01, f8, 00, 00
dwBufSize: 2352
Retry 1/10 after 10000 milliseconds
Reading DirectoryRecord    8/   8
Set OpCode: 0xd8, SubCode: 8(Raw)


With the unit TS-H353A only get errors.

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,163 (edited by ajshell1 2017-12-11 00:40:09)

I've noticed a problem with DIC.

I recently got a copy of Madden 2005 Collector's Edition http://redump.org/disc/20599/

This is a dual-layer disc.

However, DIC doesn't recognize this, and only dumps one layer.

This isn't a problem with the disc, as Isobuster can extract an .iso that matches the database.

I've tried it with my TSST TS-H353B and my ASUS BW-12B1ST a, with identical results.

1,164 (edited by sarami 2017-12-14 04:12:43)

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.

1,165

sarami wrote:
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.

The logs for the game in question are included in this link (plus some other games)

https://mega.nz/#!q0AHkZbb!V5rOwzZSe4pH … rz-ic_I-ec

I've dumped Xenosaga 1 with DIC before, and it dumped just fine. So I don't know what the issue is.

1,166

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

1,167 (edited by reentrant 2017-12-14 17:14:29)

Here's a function in one of my old tools for reading DVD TOC:

DWORD Device::readDVDTOC(DiscInfo & discInfo) {
    typedef struct DVD_SESSION_INFO {
        DVD_DESCRIPTOR_HEADER h;
        DVD_LAYER_DESCRIPTOR d;
    } DVD_SESSION_INFO;

    MMCCdb cdb;
    RtlZeroMemory(&cdb, sizeof(MMCCdb));

    CDIO_MMC_SET_COMMAND(cdb.field, CDIO_MMC_GPCMD_READ_DVD_STRUCTURE);

    cdb.field[6] = 0; // Layer 0
    cdb.field[9] = sizeof(DVD_SESSION_INFO);

    DVD_SESSION_INFO dvdSessionInfo;
    RtlZeroMemory(&dvdSessionInfo, sizeof(dvdSessionInfo));

    DWORD retVal = runMMCCommand(&cdb, getMMCCommandLen(cdb.field[0]), (PUCHAR)&dvdSessionInfo, sizeof(dvdSessionInfo), SCSI_MMC_DATA_READ);
    if (!retVal) {
        ULONG layerZeroStartLsn = Utils::swapBytesUlong(dvdSessionInfo.d.StartingDataSector);
        ULONG discLenLsn = 0;

        if (dvdSessionInfo.d.NumberOfLayers) {
            if (dvdSessionInfo.d.TrackPath == 1) {
                // Opposite Track Path - Single Lead-In / Out (the same information is returned for all layers)
            }
            else {
                // Parallel Track Path - Dual Lead-In / Out
            }

            ULONG layerZeroLsnEnd = Utils::swapBytesUlong(dvdSessionInfo.d.EndLayerZeroSector);
            if (!layerZeroLsnEnd) {
                DEBUGPRINTWE(L"Unsupported DL DVD Disc found!\n");

                return ERROR_UNSUPPORTED_TYPE;
            }
            
            ULONG layerZeroLsnLen = layerZeroLsnEnd - layerZeroStartLsn + 1;

            ULONG layerOneLsnEnd = Utils::swapBytesUlong(~dvdSessionInfo.d.EndDataSector) & 0xFFFFFF;
            ULONG layerOneLsnLen = layerZeroLsnEnd - layerOneLsnEnd + 1;

            discLenLsn = layerZeroLsnLen + layerOneLsnLen;
        }
        else {
            ULONG endDataLsn = Utils::swapBytesUlong(dvdSessionInfo.d.EndDataSector);

            discLenLsn = endDataLsn - layerZeroStartLsn + 1;
        }

        if (!retVal) {
            SessionInfo sessionInfo;
            sessionInfo.firstTrackNo = 1;
            sessionInfo.lastTrackNo = 1;

            sessionInfo.sessionStartLsn = 0;
            sessionInfo.sessionEndLsn = discLenLsn;

            sessionInfo.sessionStartMSF = 0;
            sessionInfo.sessionEndMSF = discLenLsn;

            if (dvdSessionInfo.d.NumberOfLayers) {
                discInfo.dualLayerDVD = TRUE;
            }

            TrackInfo trackInfo;
            trackInfo.indexNo = 1;
            trackInfo.trackNo = 1;
            trackInfo.trackAdr = 0;
            trackInfo.startAddress = 0;
            trackInfo.endAddress = discLenLsn;
            trackInfo.trackFormat = DATA_MODE_FORMAT_MODE1;

            sessionInfo.tracksSub.push_back(trackInfo);

            discInfo.discToc[1] = sessionInfo;
            discInfo.hasPvd = TRUE;
        }
    }
    else {
        retVal = Helpers::printSystemMessage(__FILE__, __LINE__, retVal);
    }

    return retVal;
    
    /*DWORD bytesReturned = 0;
    DWORD retVal = 0;

    DVD_READ_STRUCTURE dvdReadStructure;
    dvdReadStructure.BlockByteOffset.QuadPart = 0;
    dvdReadStructure.SessionId = 0;
    dvdReadStructure.Format = DvdPhysicalDescriptor;
    dvdReadStructure.LayerNumber = 0;

    typedef struct DVD_SESSION_INFO {
        DVD_DESCRIPTOR_HEADER h;
        DVD_LAYER_DESCRIPTOR d;
    } DVD_SESSION_INFO;

    DVD_SESSION_INFO dvdSessionInfo;
    RtlZeroMemory(&dvdSessionInfo, sizeof(dvdSessionInfo));

    if (DeviceIoControl(iDeviceHandle, IOCTL_DVD_READ_STRUCTURE, &dvdReadStructure, sizeof(DVD_READ_STRUCTURE), &dvdSessionInfo, sizeof(dvdSessionInfo), &bytesReturned, NULL)) {
        ULONG endLayerZeroLsn = Utils::swapBytesUlong(dvdSessionInfo.d.EndLayerZeroSector);
        ULONG sectorStartLsn = Utils::swapBytesUlong(dvdSessionInfo.d.StartingDataSector);
        ULONG discLenLsn = endLayerZeroLsn - sectorStartLsn + 1;

        if (dvdSessionInfo.d.NumberOfLayers) {
            discLenLsn *= 2;
        }

        SessionInfo sessionInfo;
        sessionInfo.sessionStartLsn = sectorStartLsn;
        sessionInfo.sessionEndLsn = discLenLsn;

        discInfo.discToc[1] = sessionInfo;
    }
    else {
        retVal = Helpers::printSystemMessage(__FILE__, __LINE__);
    }

    return retVal;*/
}

cdb.field[6] = 0; // Layer 0 -> Maybe try 1 here?
dvdReadStructure.LayerNumber = 0; // Or 1 here?

What do you think? At least DIC should error out if such disc is encountered as no one wants wrong checksums in the DB.

1,168

Supported PTP and DL disc.

I tested the new version and there's one problem with ripping disc with uncorrectable C2 errors:

Need to reread sector: 260512 rereading times:   10/  10
bad all. need to reread more

After that DIC exits. Is it possible to continue execution even if there are C2 errors (I know the image will be bad but I'm aware of it)?

Is your C2 algorithm using C2 bits to select bytes which are good / bad and rereads until there are no C2 bits set (making use of C2 bits from previous rereads)?

1,170

reentrant wrote:

Is it possible to continue execution even if there are C2 errors (I know the image will be bad but I'm aware of it)?

It's possible.
https://github.com/saramibreak/DiscImag … dforCD.cpp
Change the Line 1640:

throw FALSE;

to

break;

or comment out 'throw FALSE;'

But is it really uncorrectable errors? Please try the default times (4000).

reentrant wrote:

Is your C2 algorithm using C2 bits to select bytes which are good / bad and rereads until there are no C2 bits set (making use of C2 bits from previous rereads)?

Yes. It's checked by the func 'ContainsC2Error' of the Line 1630.

1,171 (edited by reentrant 2017-12-16 12:40:59)

Ok, thx for the info.

I also read somewhere that changing reading speed could help recover bad sectors. If the cd is spinning at low speed the head might loose position of the track when it tries to read scratched area. When the disc spins faster the head has less chance to loose position of the track because it "hovers above scratch for shorter time".

Maybe this could also be implemented. What do you think?

1,172

I agree. Low speed may not be good.
http://forum.redump.org/post/56911/#p56911

ref.
http://www.ippinkan.com/magazine/magazine_2013-3.htm

取り込みに使うCD-Rドライブは、本来24-48倍速という高速でCD-Rを回転させます。この速度になるとディスクは、「自らのジャイロ効果」で安定します。ジャイロ効果で安定して回転するディスクを支えるための「主軸(ベアリング)」は、高回転時に安定するように「がたつきを大きく(大きめのクリアランス)で設計されます。クリアランスの大きいベアリングを低速で回すと、ディスクの振れが大きくなります。ディスクは高回転で回す方が安定し、読み取りエラーが少なくなる。

I don't know the detail about the hardware, but this article may be reliable.

1,173

What areas does DIC read for DC? 0...leadout and 45000...leadout? Maybe worth to read the 24941...38689 ringcode area as well? Ringcode area goes as a 2nd session with its own TOC (HD area is a 3rd session).

1,174

What areas does DIC read for DC? 0...leadout and 45000...leadout?

dic reads from 45000 to 549150 using gd command.

Maybe worth to read the 24941...38689 ringcode area as well?

Tried. It seems these area has the mode 2 sector.

Post's attachments

gd_ringtest.7z 567.42 kb, 22 downloads since 2017-12-16 

You don't have the permssions to download the attachments of this post.

1,175

Have you ever tried to test every sector from 0 to 44849 to find out, which sectors are readable? GD-ROM format is badly documented even in the official SEGA docs. I have "GD-ROM Format Basic Specifications Ver. 2.14 " and "GD-ROM Format Specification Details Ver. 1.32" and they don't even mention the lead-in area for the security zone, the doc says sectors 24600...24940 and 38690...39352 are the 'mirror' (unreadable) areas, but that's not correct, the secutity (ring) area has its own lead-in, it goes before the sector 24941, sectors 24825...24940, I think, but can't say for sure where does it exactly start, since it's hard to read the sectors before 24853 on my drives (but 24853 to 24940 are clearly the security area TOC sectors).
The doc mentions the lead-in area for the HD zone, which contains 6675 sectors and goes before the HD zone, so it _should_ be in the sectors 38175...44849, then, but that means it starts in the 2nd unreadable 'mirror' zone, so I don't understand anything smile

The HD zone starts not at 45000, btw, but at 44850, sectors 44850...44999 contain the 3rd track's pregap.