1

(0 replies, posted in Dumps)

http://redump.org/disc/42393/

Mastering Code: www.takt.com.pl    takt s.c.    1002025 IDG-PCWK-11/B-2000    takt s.c.
Mastering SID Code: IFPI LK96
Mould SID Code: IFPI 9R21
Write Offset: -153
Edition: Bundled with PC World Komputer 12/2000

Hashes match.

Fixex is based on EdcEcc and it's has weird logic. It doesn't fix Marine Mania properly. These 10 sectors should be filled probably with 0x55 sectors. I think this tool should be stopped from being used because it causes issues like this.

To check which sectors are good / bad use my 2nd tool:

CDArchive.exe -x i -d "C:\Redump\IBM PC" -t "C:\Redump\EccLog.txt" ""

"C:\Redump\IBM PC" should contain directories with bin/cue files inside.

Example:
C:\Redump\IBM PC\American Conquest - Fight Back (Europe)\American Conquest - Fight Back (Europe).bin
C:\Redump\IBM PC\American Conquest - Fight Back (Europe)\American Conquest - Fight Back (Europe).cue

If there are any errors they will be written into EccLog.txt

Error codes:

typedef enum SectorType {
    // Correct
    SectorTypeNothing = 0,
    SectorTypeMode0 = 1,
    SectorTypeMode1 = 2,
    SectorTypeMode2Form1 = 3,
    SectorTypeMode2Form2 = 4,
    SectorTypeMode2 = 5,

    // Extra Valid
    SectorTypeMode1ReservedNotZero = 10,
    SectorTypeMode2FlagsNotSame = 11,
    SectorTypeFill55 = 12,

    // Error
    SectorTypeMode1BadEcc = -1,
    SectorTypeMode2BadEcc = -2,
    SectorTypeNonZeroInvalidSync = -3,
    SectorTypeZeroSync = -4,
    SectorTypeUnknownMode = -5,
    SectorTypeBadMsf = -6,
    SectorTypeScrambledZero = -7,

    // Extra Error
    SectorTypeFill55Invalid = -10,
    SectorTypeInvalidSectorSequence2 = -11,
    SectorTypeInvalidSectorSequence3 = -12,
    SectorTypeInvalidSectorSequenceN = -13,
} SectorType;

Correct images would not give any error codes, except for discs with mastering issues, but this is another story.

This tool is a result of some hardcore work with burning discs in raw mode and testing in PX760 device which data combination gives errors and which is fine. All the logic is coded here.

Jackal: your statement should be correct. But I'm trying to figure out why all the tools are failing on this one.

How to solve this issue:
1) Take the scm file. Manually descramble it via Descramble_CDDA.exe.
2) Use my hardcore eccedc with fixex command. It accepts cue. The resulting bin file should be correct.

For protected discs the result of high-level read commands like 0xBE or other cannot be trusted because there's 2nd layer of error correction (EDC, ECC) and the hardware might use it to mask correct data and thus produce bad output. I have seen discs like that. Also some devices go haywire when you attempt to read protected sectors and return some weird junk.

4

(66 replies, posted in General discussion)

So if data / track hashes stay the same, what's the problem with emu devs, can't they just generate the cues internally on the fly?

5

(0 replies, posted in Dumps)

http://redump.org/disc/24538/

Mastering Code: GM Records    0401657009    CLIN5B Colin 05    CDPROJEKT
Mastering SID Code: IFPI LT58
Data Side Mould SID Code: IFPI Z931
Cover Side Mould SID Code: IFPI Z942

My disc has different mastering codes but apart from that everything matches 1:1

6

(5 replies, posted in Dumps)

> All models? or only 716A?
PX 716 and 760 affected. I don't have any other plextors to test.

> Always same pattern? Club Saturn has ... F0 F0 F0 00 00 00 0F 0F 0F 0F ...
Yes, it's this pattern. Exactly 24 bits are bad.

Keep in mind I have seen discs protected with SafeDisc which gave (288+24 = 312 C2 errors) - ajshell case. Out of those 312 C2 errors 24 bytes are spurious and should not be counted. This is weird. I know.

Did t....p method return any C2 bits?

When I compared bad data returned by my PX drives and correct data returned by non-PX drives, not all bytes marked as C2 were bad. Sometimes some bytes were good. This could be the case with your disc...

7

(5 replies, posted in Dumps)

This is known bug in Firmware of Plextor drives. 24 C2 errors in pattern: F0F0F0 0F0F0F.
I have tons of such discs. It cannot be fixed by rereading.

The algorithm is to use different drive and issue DIC data command and patch original image with data read from the other device. There's no other way.

You have to use /c2 on the other drive to be sure. I use 2 different drives, and after making sure the data is equal on both I patch the image.

8

(49 replies, posted in General discussion)

Wow, I forgot about this topic wink

If you're using version from 23th reply in this thread specify cue path as last argument!

9

(0 replies, posted in Fixes & additions)

http://redump.org/disc/5762/

I didn't dump it, just found more info on the net...

Region: Czech,Hun,Pl,Sk
New barcode

10

(1,693 replies, posted in General discussion)

This example shows the power of DIC + Plextor drives smile

11

(1,693 replies, posted in General discussion)

00 FF FF FF FF FF FF FF FF FF FF 00 01 82 00 61

When you XOR with 0x60 you get 1 = Mode 1. It makes sense.
All other sectors are mode 2?

Ok ^-^

Is it safe to assume those tools produced proper track 1? PSX games don't have mastering errors?

14

(1,693 replies, posted in General discussion)

sarami: It's going in a good direction but to speed things up you could also code sector range extraction from those discs. It's way faster to read specific 'n' sectors than entire cd, and merge command that merges single sectors - just like CDArchive does.

celebi:

========== OpCode[0xd8]: SubCode[0]: Check Drive + CD offset ==========
========== LBA[000000, 0000000]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : 5C 7A B9 E3 32 C9 D5 96  DF 2E D8 1C 5A 89 FB 26   \z..2.......Z..&
0010 : C3 5A D1 FB 1C 43 49 F1  F6 C4 46 D3 72 DD E5 99   .Z...CI...F.r...
0020 : 00 FF FF FF FF FF FF FF  00 FF FF FF FF FF FF FF   ................
0030 : FF FF FF 00 01 82 00 61  00 28 00 1E 80 08 60 06   .......a.(....`.
0040 : A8 02 FE 81 80 60 60 28  28 1E 9E 88 68 66 AE AA   .....``((...hf..
0050 : FC 7F 01 E0 00 48 00 36  80 16 E0 0E C8 04 56 83   .....H.6......V.
0060 : 7E E1 E0 48 48 36 B6 96  F6 EE C6 CC 52 D5 FD 9F   ~..HH6......R...
0070 : 01 A8 00 7E 80 20 60 18  28 0A 9E 87 28 62 9E A9   ...~. `.(...(b..
0080 : A8 7E FE A0 40 78 30 22  94 19 AF 4A FC 37 01 D6   .~..@x0"...J.7..

I don't like this lines:
0020 : 00 FF FF FF FF FF FF FF  00 FF FF FF FF FF FF FF   ................
0030 : FF FF FF 00 01 82 00 61

D8 reads ok, but 'higher level' read commands fail. So my conclusion is that there's something either with Header or ECC/EDC.
It looks like these devices don't like such patterns?

15

(1,693 replies, posted in General discussion)

By saying sector 150 you mean:
A: Sector with MSF 00:02:00
B: Sector with MSF 00:04:00

Some tools start sectors numbering from 0 and some from 150...
In any way plz upload SCM dump that HAS that faulty sector...

16

(1,693 replies, posted in General discussion)

That 'data' command looks ok.

To be 100% sure I would look at the resulting image under hex editor and cut end / paste start sectors to match 'cd' image if there are some inconsistencies. Or maybe this is not necessary at all.

17

(1,693 replies, posted in General discussion)

ajshell1: I have a weird theory. My Plextor on some discs with offset -153 gives me C2 errors with 24 bad bits (I know this is firmware bug). You on the other side have discs with 288 bits. When you add both you get 312 = value valid for SafeDisc. I think you might be experiencing similar bug but with different "pattern"...

Could you rip with non plextor drive and data command and /c2?

18

(49 replies, posted in General discussion)

Here's is some info for DVD and BD (correction codes): http://citeseerx.ist.psu.edu/viewdoc/do … p;type=pdf

DVDs have RSPC code and can contain bad sectors but this has to be done in factory. I don't know if home devices can burn discs with incorrect correction codes...

19

(1,693 replies, posted in General discussion)

Or the fix is to force /sf flag even when protection wasn't found.

20

(49 replies, posted in General discussion)

I'll look at it during the weekend. Should be possible...

21

(49 replies, posted in General discussion)

I used HxD Hex Editor. It's a simple copy & paste app. You don't have to use it anymore (use new CDArchive).

22

(49 replies, posted in General discussion)

231096 - 230946 = 150 = 2sec = pregap. Try to lower it by few hundred sectors. DIC dump is bugged if error range crosses tracks & pregap area...

23

(49 replies, posted in General discussion)

_Maki wrote:
reentrant wrote:

Run EdcEcc with fixex command. It will replace them with 0x55 and retry...
I have OptiArc 7290.

LBA[230940, 0x3861c], mode 1
LBA[230941, 0x3861d], mode 1
LBA[230942, 0x3861e], mode 1
LBA[230943, 0x3861f], mode 1
LBA[230944, 0x38620], mode 1
LBA[230945, 0x38621], mode 1
LBA[230946, 0x38622], This sector has invalid sync
LBA[230947, 0x38623], This sector has zero sync
LBA[230948, 0x38624], This sector has zero sync
LBA[230949, 0x38625], This sector has zero sync
LBA[230950, 0x38626], This sector has zero sync
LBA[230951, 0x38627], This sector has zero sync
LBA[230952, 0x38628], This sector has zero sync
LBA[230953, 0x38629], This sector has zero sync
LBA[230954, 0x3862a], This sector has zero sync
LBA[230955, 0x3862b], This sector has zero sync
LBA[230956, 0x3862c], This sector has zero sync

Why those sectors are bad? I think EdcEcc will fix also this:
LBA[230946, 0x38622], This sector has invalid sync

I can introduce another command fixex2 which would fix sectors in specific range...


Hey thanks, that helped! Time to reextract those sectors...

I don't really know why those sectors are bad. It happened when I dumped it with /frs and /fre.
Every sector after that range has bad sync. You can see it in the original _EdcEcc.txt

Maybe I blanked it too close to the second track?

What are the values of parameters:  /frs and /fre? Only sectors inside range should be bad. Try smaller range (maybe it cannot cross tracks, dunno).

I uploaded new CDArchive that accepts cue path as argument for -m (merge mode). Sectors are merged to correct track file now.

24

(49 replies, posted in General discussion)

Run EdcEcc with fixex command. It will replace them with 0x55 and retry...
I have OptiArc 7290.

LBA[230940, 0x3861c], mode 1
LBA[230941, 0x3861d], mode 1
LBA[230942, 0x3861e], mode 1
LBA[230943, 0x3861f], mode 1
LBA[230944, 0x38620], mode 1
LBA[230945, 0x38621], mode 1
LBA[230946, 0x38622], This sector has invalid sync
LBA[230947, 0x38623], This sector has zero sync
LBA[230948, 0x38624], This sector has zero sync
LBA[230949, 0x38625], This sector has zero sync
LBA[230950, 0x38626], This sector has zero sync
LBA[230951, 0x38627], This sector has zero sync
LBA[230952, 0x38628], This sector has zero sync
LBA[230953, 0x38629], This sector has zero sync
LBA[230954, 0x3862a], This sector has zero sync
LBA[230955, 0x3862b], This sector has zero sync
LBA[230956, 0x3862c], This sector has zero sync

Why those sectors are bad? I think EdcEcc will fix also this:
LBA[230946, 0x38622], This sector has invalid sync

I can introduce another command fixex2 which would fix sectors in specific range...

25

(49 replies, posted in General discussion)

It would be easier if I implement in CDArchive cue file support so that sectors are merged in the right track.
I can do it over weekend...