Page 42 of 354
Re: DiscImageCreator
Posted: Fri May 23, 2014 11:37 pm
by sarami
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.
Re: DiscImageCreator
Posted: Sat May 24, 2014 7:22 am
by pablogm123
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.
Re: DiscImageCreator
Posted: Sat May 24, 2014 12:28 pm
by sarami
source code
Code: Select all
////////////////////////////////////////////////////////////////////////////////
//
// 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.
Re: DiscImageCreator
Posted: Mon May 26, 2014 11:25 am
by sarami
fixed: check CD+G per track (for WonderMega Collection)
added: /m option (for WonderMega Collection)
Re: DiscImageCreator
Posted: Wed May 28, 2014 11:33 am
by pablogm123
http://www.mediafire.com/?zyggub7owugg48q
Test of a PS1 disc with LibCrypt protection.
https://redump.info/disc/355/
To check what DIC does regarding the modified subcode frames, they are mentioned in the DB entry.
Re: DiscImageCreator
Posted: Thu May 29, 2014 7:49 am
by sarami
Shouldn't I fix the subcode automatically?
Re: DiscImageCreator
Posted: Thu May 29, 2014 11:36 pm
by pablogm123
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.
Re: DiscImageCreator
Posted: Fri May 30, 2014 1:09 am
by sarami
added: /n option (for PlayStation LibCrypt disc)
added: disclog for PCE disc (1st, 2nd sector of the 1st data track)
Re: DiscImageCreator
Posted: Sat May 31, 2014 2:44 pm
by pablogm123
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.
Re: DiscImageCreator
Posted: Sat May 31, 2014 7:33 pm
by Nexy
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.