You are not logged in. Please login or register.
Redump Forum → Posts by reentrant
40GPB is way too much even for best Plextors: PX760 or PX716. Keep in mind that the dumping software might not support your exotic Plextor and it might not support D8 command. List of supported drives:
PX-760, PX-755, PX-716, PX-714, PX-712, PX-708, PX-704, Premium2, Premium, PX-W5224, PX-4824, PX-4012 (PX-714, PX-704 can't test it enough.)
Could you post here a sub file made with another tool: CloneCD or Alcohol. I want to see what's in the subs...
LBA[001559, 0x00617], Data, Copy NG, Track[01], Idx[01], RelTime[00:20:59], AbsTime[00:22:59], RtoW[Zero, Zero, Zero, Zero]
LBA[001560, 0x00618], Data, Copy NG, Track[01], Idx[01], RelTime[00:20:60], AbsTime[00:22:60], RtoW[Zero, Zero, Zero, Zero]
Should be audio, not data. That explains shifted tracks. There must be a bug somewhere. Always use the newest build...
Post image_sub.txt somewhere. It compresses well, maybe it would fit in attachment.
It's Ring PROTECH and it's very heavy disc to dump in terms of difficulty. You need at least 2 drives to dump it. A Plextor and something else with good reading capabilities like Sony OptiARC. If you want to start dumping I suggest you start with something less evil...
Normally it's protected by Ring PROTECH. What's Sysiphus?
Nvm. Everything ok 
Yes, but I know in advance which sectors are bad and ideally the drive shouldn't touch such sectors at all to speed up the process as much as possible...
I have a small idea related to dumping protected discs with Plextors. We all know when it comes to dumping LaserLock or RingProtech Plextors are not the best choice. Other drives perform better in this field. How about specifying in command line sector ranges that should be failed (replaced with 0x55). It would greatly improve dumping speed. Missing data can later be patched-in to the image (patching is always necessary in case of Plextors).
RingProtech requires one sector range
LaserLock requires 12 sector ranges
Maybe comma delimited argument is good enough like: /fl 100-200,300-400
What do you think?
SectorType EDC::detectSector(ULONG lsn, PUCHAR sector, SIZE_T sectorSize, SectorType & sectorType, BOOL & isEdcAndMsfValid) {
isEdcAndMsfValid = FALSE;
if (sectorSize == CDIO_CD_FRAMESIZE_RAW) {
if (sector[0x000] == 0x00 && 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) { // Sync (12 bytes)
MSFAddress referenceMsf = MSFAddress(lsn) + CDIO_PREGAP_SECTORS;
MSFAddress sectorMsf;
BOOL isMValid = StringUtils::asciiByteToUchar(sector[0x00C], sectorMsf.iMinute);
BOOL isSValid = StringUtils::asciiByteToUchar(sector[0x00D], sectorMsf.iSecond);
BOOL isFValid = StringUtils::asciiByteToUchar(sector[0x00E], sectorMsf.iFrame);
if(!isMValid || !isSValid || !isFValid || referenceMsf != sectorMsf)
return SectorTypeBadMsf;
if (sector[0x00F] == 0x01) { // Mode (1 byte)
if (sector[0x814] == 0x00 && sector[0x815] == 0x00 && sector[0x816] == 0x00 && sector[0x817] == 0x00 &&
sector[0x818] == 0x00 && sector[0x819] == 0x00 && sector[0x81A] == 0x00 && sector[0x81B] == 0x00) { // Reserved (8 bytes)
if (isEdcAndMsfValid = edcCompute(0, sector, 0x810) == get32Lsb(sector + 0x810)) {
sectorType = SectorTypeMode1;
}
if (isEdcAndMsfValid && eccCheckSector(sector + 0xC, sector + 0x10, sector + 0x81C)) {
return SectorTypeMode1; // Mode 1
} else {
return SectorTypeMode1BadEcc; // Mode 1 (Safedisc etc)
}
} else {
if (isEdcAndMsfValid = edcCompute(0, sector, 0x810) == get32Lsb(sector + 0x810)) {
sectorType = SectorTypeMode1;
}
if (isEdcAndMsfValid && eccCheckSector(sector + 0xC, sector + 0x10, sector + 0x81C)) {
return SectorTypeMode1ReservedNotZero; // Mode 1 (Reserved not zero)
} else {
return SectorTypeMode1BadEcc; // Mode 1 (Safedisc etc)
}
}
} else if (sector[0x0F] == 0x02) { // Mode (1 byte)
if (sector[0x10] == sector[0x14] && sector[0x11] == sector[0x15] && sector[0x12] == sector[0x16] && sector[0x13] == sector[0x17]) { // Flags (4 bytes)
if (isEdcAndMsfValid = edcCompute(0, sector + 0x10, 0x808) == get32Lsb(sector + 0x10 + 0x808)) {
sectorType = SectorTypeMode2Form1;
}
if (isEdcAndMsfValid && eccCheckSector(zeroAddress, sector + 0x10, sector + 0x10 + 0x80C)) {
return SectorTypeMode2Form1; // Mode 2 Form 1
}
if (isEdcAndMsfValid = edcCompute(0, sector + 0x10, 0x91C) == get32Lsb(sector + 0x10 + 0x91C)) {
sectorType = SectorTypeMode2Form2;
return SectorTypeMode2Form2; // Mode 2 Form 2
} else {
isEdcAndMsfValid = TRUE;
sectorType = SectorTypeMode2;
return SectorTypeMode2; // Mode 2
}
} else {
return SectorTypeMode2FlagsNotSame; // Mode 2 (Invalid flags)
}
}
return SectorTypeUnknownMode;
} else if (sector[0x000] || sector[0x001] || sector[0x002] || sector[0x003] ||
sector[0x004] || sector[0x005] || sector[0x006] || sector[0x007] ||
sector[0x008] || sector[0x009] || sector[0x00A] || sector[0x00B] ||
sector[0x00C] || sector[0x00D] || sector[0x00E] || sector[0x00F]) { // Fix for invalid scrambled sector in data track
return SectorTypeNonZeroInvalidSync;
} else {
return SectorTypeZeroSync;
}
}
return SectorTypeNothing;
}This is my function to check for proper sector's MSF + checks if EDC is correct...
I noticed one issue with DIC and data command. For example when I dump a block of sectors from sector A to B, A != 0 and if a read error sector occurs (/rc is on) DIC incorectly inserts MSF field of header. It looks like DIC inserts MSF field based on number of sectors read but it should insert MSF based on absolute sector position inside CD...
Also EccEdc lacks one of check that CDmage has. It doesn't verify sector MSF. For example I overwritten contents of sector 1 with contents of sector 0 and EccEdc didn't report anything. CDmage reported 1 error. This check is useful in case of protectors like RingProtech where drive might fail to sync at correct sector and it will read different one instead. Happened to my only once so far...
sarami, thx for the switches.
My patch to EccEdc screwed something? The new version shoule be used with checkex command with cue as a parameter. Otherwise it does not know what is data and what is audio. It's more precise but if invoked with check command it would output just like that...
Savagesteel: I think none of them. You just have to issue 0xD8 command.
sarami: We probably will never get specification of SecuROM. I spoke to Jackal once and he gave me a nice tool (CDGTool) that is able to clean subs and it's clearly visible which sectors are part of SecuROM and which are just badly read. The tool detects single bit errors and compares it with CRC. The rest should be inspected manually. You can apply another layer of processing in which you check data if single bit error occured in CRC. After those two passes you are left with high probability SecuROM sectors. There are 3 types from what I have seen:
1) Error in RM and error in AM (2 errors)
2) Error in RS and error in AS (2 errors)
3) Error in RF and error in AF (2 errors)
I think I have also seen a mix of 1 and 2 or 3 (there were 2+ errors). Have you seen this tool? It's very useful if you want to cross validate the result from DIC and CDTool (which will not correct any errors).
Sarami, please add a switch to skip processing Q sub (I want to get rid of CDTool).
Sarami: In function IsValidIntentionalSubSector I see limits on LBA. Are you really sure that such errors are only present in that range? What would happen if I had a sector outside that range?
Maybe you could add a switch to remove the limits from LBA 0 till end of the disc?
Yes. What drive is it?
This is for BE command:
CDFLAG::_READ_CD::_SUB_CHANNEL_SELECTION sub = CDFLAG::_READ_CD::Raw;
_tcsncpy(szSubCode, _T("Raw"), sizeof(szSubCode) / sizeof(szSubCode[0]));
if (pExtArg->byPack) {
sub = CDFLAG::_READ_CD::Pack;
_tcsncpy(szSubCode, _T("Pack"), sizeof(szSubCode) / sizeof(szSubCode[0]));
}
SetReadCDCommand(pExtArg, pDevice, &cdb, type, 1, c2, sub, FALSE);
OutputLog(standardOut | fileDisc, _T("Set read command: %#x, subcode reading mode: %s\n"), lpCmd[0], szSubCode);For D8 command it's slightly different. If you want Packed subs with D8 command you have do skip C2 error reporting:
if (pExtArg->byC2 && pDevice->FEATURE.byC2ErrorData) {
_tcsncpy(szSubCode, _T("Raw"), sizeof(szSubCode) / sizeof(szSubCode[0]));
SetReadD8Command(pDevice, &cdb, 1, CDFLAG::_PLXTR_READ_CDDA::MainC2Raw);
}
else {
_tcsncpy(szSubCode, _T("Pack"), sizeof(szSubCode) / sizeof(szSubCode[0]));
SetReadD8Command(pDevice, &cdb, 1, CDFLAG::_PLXTR_READ_CDDA::MainPack);
}AFAIK D8 is incompatible with packed mode. BE is. Use /be pack to enable packed mode subs extraction. No need for PerfectRip
Dumping multi track CDs is very tricky and you cannot be sure if it went ok unless you have one of the Plextors. Is it too much for you to get one of the Plextors drives?
sarami: Could you check this dump: http://redump.org/disc/34750/
I have it and I cannot match data track... Are you sure those 822 sectors are correctly replaced with 0x55 pattern?
RingProtech: Maybe when first bad sector occurs (N), attempt to read K sectors at position (N+100). If all K sectors are read then you're after bad area. If there's still error read sectors at position (N+200) and so on till you find good area. Once good area is found, read backwards and find first good sector (N+X). Now you know what bad area spans from N till N+X. Fill it with error pattern...
I have two RingPROTECH games and one LaserLock. it should work for them considering there's only 1 bad errored area...
Confirmed invitation. What I did with this commit is that now the tool is able to parse CUE files and according to that it checks data tracks if all the sectors in it are proper. I also took into account case where sync sectors are allowed at the beginning and at the end of track but not in the middle ('cnt_SectorTypeZeroSync'). The tool handles VOB Protect just fine.
Support for SecuROM in which there's different mode sector at end of data track is not handled ATM...
Sarami I still cannot commit to EdcEcc (permission denied)
sarami: If you're reading this add me to the EccEdc project on GitHub. I have rewritten EccEdc to have some nice features (for protected discs) and now I want to commit the changes...
I doubt it'd work under Wine. It uses some really low level stuff to get the data off the medium...
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?
Redump Forum → Posts by reentrant
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.