MrX_Cuci wrote:

App crash with latest WIP. I tried it three times. Perfect rip dumps the disc fine. Logs: https://www.dropbox.com/s/w8mh60gald22x9v/logs.7z There also seems to be a CUE sheet problem in latest build. See here: http://forum.redump.org/topic/13887/mis … ide-rally/

Does two problems happen in the same disc? In either case, please upload all created file except bin, img.

pablogm123 wrote:

Multiple indexes aren't added. Could you see this and fix it?

I hadn't supported at multiple indexes in track 1 until now.
Fixed probably. (Because I don't have a disc that is multiple indexes in track 1.)

sarami wrote:

Fixed probably. (Because I don't have a disc that is multiple indexes in track 1.)

Many Neo Geo CD games have multiple indexes for track 1, it's a protection scheme.

F1ReB4LL wrote:

Many Neo Geo CD games have multiple indexes for track 1, it's a protection scheme.

Oh, I see. To test, I think that I want to buy some disc before long big_smile .

The CUE sheet probleem seems to be affected by data only tracks. I dumped three different discs all the same problem. Seems to be a bug in latest WIP only.

I'll upload the files of the problematic disc that crashes the app.

405 (edited by MrX_Cuci 2014-05-17 21:10:07)

MrX_Cuci wrote:

I'll upload the files of the problematic disc that crashes the app.

I gave the disc another go. No crash now, but keeps spinning at a certain point. Jackal already dumped that disc, so I suppose the disc itself is bad and that causes the app. to crash. *EDIT* Did another go with PR. Dump is fine....weird.

406 (edited by pablogm123 2014-05-17 21:11:26)

sarami wrote:

Oh, I see. To test, I think that I want to buy some disc before long big_smile .

Many Saturn games contain multiple indexes as well, if you are interested.

http://redump.org/disc/5045/
http://redump.org/disc/17022/
http://redump.org/disc/29087/
http://redump.org/disc/4206/
http://redump.org/disc/5052/
http://redump.org/disc/5270/
http://redump.org/disc/4916/
http://redump.org/disc/8726/
http://redump.org/disc/29009/
http://redump.org/disc/25221/
http://redump.org/disc/23663/
http://redump.org/disc/25254/

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

407 (edited by MrX_Cuci 2014-05-17 23:09:46)

One of the discs with CUE sheet problem. (all stuff you requested) https://www.dropbox.com/s/s2y915eplvcvm … Problem.7z

pablogm123 wrote:

Many Saturn games contain multiple indexes as well, if you are interested.

Thanks. But I have already multiple indexes in track 2, 3, 4... (Nanatsu no Hikan, pc-fx disc etc.)
If your introduced disc is cheap, maybe I'll buy. big_smile

MrX_Cuci wrote:

The CUE sheet probleem seems to be affected by data only tracks

This is a big hint. Fixed.

409 (edited by sarami 2014-05-21 12:19:36)

pablogm123 wrote:

These CD-i discs confuse many drives...

At first sight... actually no starting position of track 1 is defined by the TOC. Only is defined that the first track is 2 (A0), second track is 2 (A1) and lead-out starts at AMSF 08:24:00 (A2), but no actual entry for track 1.

So I guess that to rip these CD-i discs is needed to rip everything from AMSF 00:02:00 until the last pre-lead-out sector, ignoring what TOC (except the lead-out position of course) and subcode say. But even so subcode has to be analyzed just to detect possible CATALOG fields and other flags encoded and add them in the written cue.

And when ripping these discs the written cue has to contain the CDI directive instead of MODE2/2352 .

Should be trivial to analyze the filesystem contained and rip these discs properly, only rip everything from AMSF until the last pre-lead-sector, determinate if the disc contains CATALOG and so on and write the cue with CDI instead of MODE2/2352. Sample of the first 17 sectors of two CD-i discs, which contain the CD-i signature.

http://www.mediafire.com/?3yenqq3mewqchx0

added: CDI directive

F1ReB4LL wrote:

Many Neo Geo CD games have multiple indexes for track 1, it's a protection scheme.

I bought a disc (kof97, that is including index 99 in track 1) and I confirmed it that dic wrote mutiple indexes for track 1 in cue.

other
added: output a list of file in 3DO disc. (using the code of http://kaele.com/~kashima/games/3do_dir.html)
improved: SubQ of adr 2(=EAN sector)(if adr is correct but EAN data is wrong, fixed it.)
fixed: log (hash of .img)

Updated EccEdc.exe
added: analyze header from [16] to [19]

Speaking of EccEdc.exe... what does regarding the situation I am going to describe?

This is an old bug of CDmage. If the two copies of the subheader of a mode 2 form 1/form 2 sector vary, CDmage will report falsely this as error. Wrong (as maximum can be reported as warning or whatever, not as error itself), because user data matches the stored EDC/ECC, so there is no corruption.

Screenshots of an affected data track.

10 errors reported by CDmage, the last one (actual and expected, disc contains no EDC in form 2 sectors and audio tracks) and the first nine ones, errors as real as Mickey Mouse is.

http://i.imgur.com/YBeeuNz.png

Same data track checked by a much modern program based on the code of ECM. Much more detailed and real error reporting, no errors real as Donald Duck.

http://i.imgur.com/wehUR4M.png

«Normal» sector:

http://i.imgur.com/7cVE6pQ.png

«Weird» sector:

http://i.imgur.com/SjjS1nC.png

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

axisleon wrote:

DIC v.20140518 read HDA slowly and easy to fail, back to old v.20120707

fixed: transfer length
fixed: c2 error fix logic

about edccchk
oh.. I didn't know this tool. it is recommended than my tool in the error report.

412 (edited by pablogm123 2014-05-24 22:56:18)

I asking how handles EccEdc.exe those sectors where copies of subheader differ. No error (because EDC/ECC match the expected), only warning (due to mismatching copies of subheader) or false error (what CDmage does)? Ideally, should be reported as warning.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

source code

////////////////////////////////////////////////////////////////////////////////
//
// Check if this is a sector we can compress
//
// Sector types:
//   0: Literal bytes (not a sector)
//   1: 2352 mode 1         predict sync, mode, reserved, edc, ecc
//   2: 2336 mode 2 form 1  predict redundant flags, edc, ecc
//   3: 2336 mode 2 form 2  predict redundant flags, edc
//
static int8_t detect_sector(const uint8_t* sector, size_t size_available) {
    if (
        size_available >= 2352 &&
        sector[0x000] == 0x00 && // sync (12 bytes)
        sector[0x001] == 0xFF &&
        sector[0x002] == 0xFF &&
        sector[0x003] == 0xFF &&
        sector[0x004] == 0xFF &&
        sector[0x005] == 0xFF &&
        sector[0x006] == 0xFF &&
        sector[0x007] == 0xFF &&
        sector[0x008] == 0xFF &&
        sector[0x009] == 0xFF &&
        sector[0x00A] == 0xFF &&
        sector[0x00B] == 0x00 &&
        sector[0x00F] == 0x01 && // mode (1 byte)
        sector[0x814] == 0x00 && // reserved (8 bytes)
        sector[0x815] == 0x00 &&
        sector[0x816] == 0x00 &&
        sector[0x817] == 0x00 &&
        sector[0x818] == 0x00 &&
        sector[0x819] == 0x00 &&
        sector[0x81A] == 0x00 &&
        sector[0x81B] == 0x00
        ) {
        //
        // Might be Mode 1
        //
        if (
            ecc_checksector(
            sector + 0xC,
            sector + 0x10,
            sector + 0x81C
            ) &&
            edc_compute(0, sector, 0x810) == get32lsb(sector + 0x810)
            ) {
            return 1; // Mode 1
        }

    }
    else if (
        size_available >= 2336 &&
        sector[0x10] == sector[0x14] && // flags (4 bytes)
        sector[0x11] == sector[0x15] && //   versus redundant copy
        sector[0x12] == sector[0x16] &&
        sector[0x13] == sector[0x17]
        ) {
        //
        // Might be Mode 2, Form 1 or 2
        //
        if (
            ecc_checksector(
            zeroaddress,
            sector + 0x10,
            sector + 0x10 + 0x80C
            ) &&
            edc_compute(0, sector + 0x10, 0x808) == get32lsb(sector + 0x10 + 0x808)
            ) {
            return 2; // Mode 2, Form 1
        }
        //
        // Might be Mode 2, Form 2
        //
        if (
            edc_compute(0, sector + 0x10, 0x91C) == get32lsb(sector + 0x10 + 0x91C)
            ) {
            return 3; // Mode 2, Form 2
        }
        else {
            return 4; // Mode 2, No EDC (for PlayStation)
        }
    }

    //
    // Nothing
    //
    return 0;
}

In case of mode2 disc, if a subheader and edc matches, no error. Otherwise error.

Ideally, should be reported as warning.

I think so, too.

fixed: check CD+G per track (for WonderMega Collection)
added: /m option (for WonderMega Collection)

http://www.mediafire.com/?zyggub7owugg48q

Test of a PS1 disc with LibCrypt protection.

http://redump.org/disc/355/

To check what DIC does regarding the modified subcode frames, they are mentioned in the DB entry.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

pablogm123 wrote:

http://www.mediafire.com/?zyggub7owugg48q

Test of a PS1 disc with LibCrypt protection.

http://redump.org/disc/355/

To check what DIC does regarding the modified subcode frames, they are mentioned in the DB entry.

Shouldn't I fix the subcode automatically?

For LibCrypt protected discs, of course that absolutely not. At least the modified frames (only que Q subframes). Later I will post a sample of a subcode from that disc fully cleaned and with the expected modified Q subframes.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

added: /n option (for PlayStation LibCrypt disc)
added: disclog for PCE disc (1st, 2nd sector of the 1st data track)

http://www.mediafire.com/?7jiiwwp6r8qh7lb

Fully clean subcode of Wip3out (Europe) (En,Fr,De,Es,It) without random errors and with the expected modified frames (curiosly, being a disc produced by Sony DADC pregaps are Philips style), so that you can examinate it. As far I know, actual contents of the modified frames isn't actually important for this protection in a real console as long as the calculated CRC-16 doesn't match the stored Q-CRC16.

Any chance of smartly detecting these frames and do not repair them? Or at least the already implemented option but affecting only RMSFs 03:xx:xx and 09:xx:xx, the known positions of these modified frames.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

420 (edited by Nexy 2014-06-01 01:34:18)

No, do not "clean" subcode data, unless you want to work on adding subcode dumping like subdump does. This takes a long time and F1ReB4LL already explained the process to you I think.

Errors are often intentional, LibCrypt, SecuROM.

Only CDI subchannels r-w can be fixed because of a real checksumming algo used and not lame crc.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

421 (edited by sarami 2014-06-02 16:46:27)

pablogm123 wrote:

Or at least the already implemented option but affecting only RMSFs 03:xx:xx and 09:xx:xx, the known positions of these modified frames.

Improved at above. (change option /n -> /l)
added: xxx_infolog.txt (for no error log)

422 (edited by pablogm123 2014-06-02 02:52:53)

discimagecreator.exe cd g: Wip3out 8 /c2 1000 4096 8 /l

No success.

http://www.mediafire.com/?6brdaaafxn78ew8

http://i.imgur.com/VSikrJS.png

http://i.imgur.com/8LqYCrQ.png

These modified frames. And once modified the new CRC-16 is XORed with 0080.

43012    09:33:37    41 01 01 09 31 33 00 09 13 37 63 09    8f60
43017    09:33:42    41 01 01 09 11 42 00 0d 33 42 15 c2    e948

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

sorry, I didn't write the subcode for LibCrypt...
re-fixed. But data is incorrect probably. Please test...

Much better. Expected intentional errors (32) + 9/10 false ones due to either corrupted RMSF/AMSF or CRC-16. I am wondering if would be possible to create an algorithm to smartly detect these sectors and leave them untouched, as XOR every frame of this range with 0x0080 and 0x8001 (I mean try both possibilities, not literally XOR with 0x0080 and the got data XOR with 0x8001) to undo the initial XOR operation, if the new CRC-16 matches now the rest of the Q-Frame, is a Libcrypt frame and shouldn't be altered.

Main page gives the tips, posted below.

http://www.mediafire.com/?u213sekbnonirdf

2 bits from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
2 bits from both MSFs are modified, original CRC-16 is XORed with 0x8001.
Either 2 bits or none from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.

Wip3out is the third case, because certains frames have no MFSs altered and CRC-16s are recalculated and XORed with 0x0080.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

- improved: SubQ of adr 3(=ISRC sector)(if adr is correct but ISRC data is wrong, fixed it.)

pablogm123 wrote:

2 bits from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
2 bits from both MSFs are modified, original CRC-16 is XORed with 0x8001.
Either 2 bits or none from both MSFs are modified, CRC-16 is recalculated and XORed with 0x0080.
Wip3out is the third case, because certains frames have no MFSs altered and CRC-16s are recalculated and XORed with 0x0080.

I don't have a LibCrypt disc. So, it would help me if someone could test the 1st/2nd case.