201

(3,526 replies, posted in General discussion)

I doubt it'd work under Wine. It uses some really low level stuff to get the data off the medium...

202

(9 replies, posted in General discussion)

What's the value of EDC for such sectors: 0 or different than 0? Maybe value of 0 is a special case...
Are the sectors readable in simple imaging tools like IsoBuster?

203

(9 replies, posted in General discussion)

From code:

                    //
                    // 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)
                    }

What you're asking is if return 4 is in error path. Yes. EDC doesn't match for the sector. What does CDmage report?
So I think it's 1338 and 46113.

204

(3,526 replies, posted in General discussion)

It looks like D8 is more appropriate. BE seems to fail 6 sectors to recover from bad sync? Probably is a drive / firmware dependent...

Could you read sectors 341222 -> 341227 in BE mode but starting with 341222 (maybe seek to sector 341230 and start reading from 341222)? Dunno if this makes sense but it could test the drive how it reads sectors that failed in previous attempt.

205

(13 replies, posted in General discussion)

D8 for Safedisc is only to speed up ripping process. Erroneous sectors are read in scrambled mode and the drive does not verify EDC/ECC.

What is really important is C2 option that guarantees that dump is perfect, without it you're never sure if the dumps is correct or not...

206

(1 replies, posted in General discussion)

By default DIC re-reads at 4x speed. Probably that's why the errors were fixed. I'd try to read at 4x and compare the dumps. The dump should be good...

207

(13 replies, posted in General discussion)

AFAIR in DIC, if you omit /rc, dumping process will fail. You must use /rc. Faulty sectors will be replaced with 0x55. You would have to patch in sectors from different image...

208

(3,526 replies, posted in General discussion)

Ok, here are the DIC logs from http://redump.org/disc/37976/

Link: http://hotfile.mobi/fqj6g59
Pass: __http://redump.org/disc/37976/__

The key problem here is that there are two data tracks and the last data track has corrupted sync and is not picked up by edcecc. Also edcecc does not seem to repair sectors if header is different than 00 FF .. FF 00. In order to dump this game I modified edcecc to replace the sector with 55 pattern if sync is different than 00 FF .. FF 00...

Other games have the same protection pattern except for http://redump.org/disc/37856/ (you didn't list this game). In this case there's no 2nd data track but the corrupted sync headers are embedded into middle of the image. Also 1st track contain 2nd track pregap. My custom edcecc does not replace sectors in pregap area (there was a bug in 1st revision - watch out for this)...

Example: 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF 00 FF C0 02 97 21 66 16 7C B4 CF 98 2A C3 DF 7E 66 11

209

(3,526 replies, posted in General discussion)

DiscImageCreator.exe cd f: DISC 4 /rc /c2 20 /d8

And watch out for C2 errors
Always look at mainError file

If nothing pops up the dump should be good. Watch out for protected discs.

210

(5 replies, posted in General discussion)

DIC is correct. You have (dic_sub.txt)

LBA[004125, 0x0101d], Audio, 2ch, Copy NG, Pre-emphasis No, Track[02], Idx[00], RMSF[01:01:74], AMSF[00:57:00], RtoW[0, 0, 0, 0]

It means track 2 will start in 1min and 2sec.
1 min = 60*75 sectors
2 sec = 150 sectors

Sector count = 4650 sectors. 4650 sectors from end of track 1 starts track 2.
In cue you have: 01:02:00. Standard pregap is 00:02:00. If you substract one from the other it yields exactly 01:00:00 which is 60*75 sectors * 2352 = 10584000 = 0xA17FC0. This is the size of your block.

Look also at this: http://forum.redump.org/topic/10755/mastering-errors/

The CD is a very nice example of a poorly mastered disc....

211

(5 replies, posted in General discussion)

00 FF FF FF FF FF FF FF FF FF FF 00 01 D7 00 61
61 => suggests it's mode 1 track ^ 0x60 (scrambled pattern)

Why is the sector scrambled?
What's the track 2 pregap from CUE?

212

(3,526 replies, posted in General discussion)

Ok the problem with VOB is that DIC is not able to recognize the protection and any C2 errors that are part of protection are not replaced with 0x55. Could you add a command line switch to replace any C2 sector with 0x55?

At least we can defeat VOB this way. Right now it's impossible to come up with proper dump without manually editing the track.

EDIT: Please also put EdcEcc to github. I made some patches to it to fix a VOB protected track.

213

(3,526 replies, posted in General discussion)

After some even more deeper tests here are my results:
1) Audio tracks are properly offset corrected in D8 mode. In BE mode audio tracks are not offset corrected.
2) Data tracks: DIC seems to have problem with VOB Protect CD and D8 mode. I also tested a SafeDisc 1.00.026 and tracks are correctly dumped using both D8 and BE. For VOB discs I'm reripping data tracks in BE mode and the results are CloneCD compatible which I think is desired. In D8 mode VOB protected sectors have corrupted sync and header areas and DIC is not able to descramble them. OTOH in BE mode such sectors are replaced with 55 pattern. Maybe DIC should also replace such sectors with scrambled 55 pattern?

I have a Settlers IV CD that seems to expose another issue with D8 command. Some sectors (variable count) after C2 sector are not read correctly. I'll be investigating the issue later. But I think the conclusion is that D8 ripping is not reliable in case of C2 errors.

214

(3,526 replies, posted in General discussion)

After some deeper tests it seems that /d8 and /be return different data. Audio tracks in /be mode are shifted by 'combined offset' vs /d8 mode. I need to do some further tests but it looks like I'll be redumping everything...

215

(3,526 replies, posted in General discussion)

I think I found an undesired bahavior in descrambling code path. In function "DescrambleMainChannel" if "IsValidMainDataHeader" check fails the sector won't be descrambled. But I think it should be descrambled regardless of the result of the check. I have a CD that has an intentional C2 error in first 12 bytes of a sector and the contents of the sector don't match with /be mode.

EccEdc does not detect such sector as bad but IMHO it should. The end result is that there's scrambled data in output image.
Also if Combined Offset is < 0 such errorneous sector will not be reported to mainError file. The code in 'CheckAndFixMainHeader' does not seem to handle cases when Combined Offset < 0.

What do you think?

216

(13 replies, posted in General discussion)

If you put the link to JDownloader for example the file is downloaded...

217

(13 replies, posted in General discussion)

I have a Settlers IV game that is protected with SafeDisc. Is it possible that sectors are corrupted in more than one range? The ranges are:
1) 67 to 10066
2) 93024 to 93025
3) 275049 to 275050
4) 286368 to 286369
5) 303979 to 303980

I have 3 CDs with the same game (I bough the game 3 times). Each one of them has different combination of corrupted ranges:

CD1: 1 + 2 + 3 + 4 + 5
CD2: 1 + 2 + 4 + 5
CD3: 1 + 4 + 5

Safedisc v2.51.021

What to do with this stuff?

218

(3,526 replies, posted in General discussion)

Small fix for option /rc and /raw being impossible to choose...
Fixed bug with option /be not selectable

https://github.com/saramibreak/DiscImag … 441a5c7ba1
https://github.com/saramibreak/DiscImag … 8dd5992bda
^-^

219

(3,526 replies, posted in General discussion)

This should work: https://www.microsoft.com/en-us/downloa … x?id=51682

220

(3,526 replies, posted in General discussion)

I'm wondering what's so special in subdump that DIC can't do, are subdump's subchannel dumps reliable or is it just a different methodology which in the end is not 100% perfect?

From what I understand C2 bits only account for 2352 portion of disc sector. So the obvious question it how to reliably dump the subchannels?

I found such topic:
http://club.myce.com/f61/subchannel-issues-214939/

Listing the different protection schemes for the 8 subcoding channels:
Channel P: no protection - can't be fixed?
Channel Q: 16-bit CRC - who is computing this CRC, and compare the resulting value against what?
Channels R to W: RS - to protect the data in the subcoding channels R to W, a (24, 20) Reed-Solomon error correction code is used. To improve the burst error correction capability, 8 times interleaving is added to this error-correction system. The first two symbols in a PACK have additional protection with a (4, 2) Reed-Solomon error correction code.

As for P & Q - proprietary (Truman-IpseDixit) correction algorithms - do you know what's their algorithm?

221

(3,526 replies, posted in General discussion)

Yes, it's good. Thanks.

222

(3,526 replies, posted in General discussion)

Hi sarami,
   At first I'd like to thank you for such great tool. I was also writing a similar one on my own in the past but I see your one is much more powerful. So I though about dropping my tool and helping you with DIC. I have already made some fixes on my own in DIC and I don't want them to be lost. Is it ok for you to move the project to some place like github where we can easily sync our work?

223

(29 replies, posted in General discussion)

The source code is already released. If you're curious how it's done download .net reflector and load the assemblies into it. The code is not obfuscated and it's clearly visible how it's implemented. Having looked at it I'm pretty sure this project is based on a different project. There are two similarly looking function names: a100026e0 and a10002710. Naming convention is probably taken from some disassembler like IDA and the code is probably taken from HexRays and adapted to .net.

So I believe something happened at Nintendo and there was a leak of some x86 binary. The algorithm there is impossible to reverse engineer.

Code from GCMLENCa1.exe:

private void a10002710(regs reg, BinaryReader br, BinaryWriter bw, uint[] stack)
{
    reg.EAX = stack[(int) ((IntPtr) ((reg.ESP + 4) / 4))];
    reg.ECX = 0;
    reg.ESI = 0xadb5c;
    do
    {
        reg.EDX = 0;
        while (reg.EDX < 0x20)
        {
            reg.EAX *= 0x5d588b65;
            reg.EAX++;
            reg.ECX = (reg.ECX >> 1) | (reg.EAX & 0x80000000);
            reg.EDX++;
        }
        bw.BaseStream.Position = reg.ESI;
        bw.Write(reg.ECX);
        reg.ESI += 4;
    }
    while (reg.ESI != 0xadba0);
    br.BaseStream.Position = 0xadb9cL;
    reg.EAX = br.ReadUInt32();
    br.BaseStream.Position = 0xadb5cL;
    reg.ECX = br.ReadUInt32();
    reg.EDX = reg.EAX;
    reg.ECX = reg.ECX >> 9;
    reg.EDX = reg.EDX << 0x17;
    reg.ECX ^= reg.EDX;
    reg.EAX ^= reg.ECX;
    bw.BaseStream.Position = 0xadb9cL;
    bw.Write(reg.EAX);
    reg.EAX = 0xadb60;
    do
    {
        br.BaseStream.Position = reg.EAX - 4;
        reg.ECX = br.ReadUInt32();
        br.BaseStream.Position = reg.EAX;
        reg.EDX = br.ReadUInt32();
        br.BaseStream.Position = reg.EAX + 60;
        reg.ESI = br.ReadUInt32();
        reg.ECX = reg.ECX << 0x17;
        reg.EDX = reg.EDX >> 9;
        reg.ECX ^= reg.EDX;
        reg.ECX ^= reg.ESI;
        bw.BaseStream.Position = reg.EAX + 0x40;
        bw.Write(reg.ECX);
        reg.EAX += 4;
    }
    while (reg.EAX != 0xae340);
    this.a100026e0(ref reg, br, bw);
    this.a100026e0(ref reg, br, bw);
    this.a100026e0(ref reg, br, bw);
    stack[(int) ((IntPtr) (reg.ESP / 4))] = reg.EDI;
    bw.BaseStream.Position = 0xae384L;
    bw.Write(520);
    reg.ESP -= 4;
    stack[(int) ((IntPtr) (reg.ESP / 4))] = reg.ESI;
    reg.ESP += 4;
}

Still it's very nice quality work smile