1

(1,758 replies, posted in General discussion)

I have DVD9 disc and DIC reports following data:

========== SectorLength ==========
    LayerZeroSector: 2010896 (0x1eaf10)
========== PhysicalFormatInformation ==========
           BookVersion: 1
              BookType: DVD-ROM
           MinimumRate: 10.08 Mbps
              DiskSize: 120mm
             LayerType: Layer contains embossed data
             TrackPath: Parallel Track Path
        NumberOfLayers: Double Layer
          TrackDensity: 0.74â╩m/track
         LinearDensity: 0.293â╩m/bit
    StartingDataSector:  196608 (0x30000)
         EndDataSector: 1730300 (0x1a66fc)
    EndLayerZeroSector:       0 (0)
               BCAFlag: No
         MediaSpecific:

========== SectorLength ==========
    LayerZeroSector: 1533693 (0x1766fd)
    LayerAllSector : 3544589 (0x36160d)

Why LayerZeroSector is different in both cases?

Ok smile

I'm curious. Are you sure any sectors in range 633184-674720 aren't readable? Especially at the beginning and at the end?

633184 and 674720 are multiple of 32. What about sectors:
633184 + 1
...
633184 + 19

and

674720 - 19
...
674720 - 1

?

4

(1,758 replies, posted in General discussion)

Hi sarami. I have a safedisc protected disc and I want to report some weird info. Below is a list of C2 error counters from protected range:
240
264
288
312

Each of these vary by 24. I can confirm that this is correct info.

5

(3 replies, posted in New Dumps)

1295616 - 1271968 != 740 ?

6

(1,758 replies, posted in General discussion)

nightson: https://club.myce.com/t/difference-betw … eed/176851

Read about Plextor SpeedRead. But keep in mind that PlexTools is a true devil and better don't install it or your drive would go to shit...

7

(1 replies, posted in Verifications)

_Up_

8

(0 replies, posted in Verifications)

http://redump.org/disc/60157/

Mould SID Code: IFPI 9R44

http://redump.org/disc/60156/

Mould SID Code: IFPI 9R1R

http://redump.org/disc/60158/

Mould SID Code: IFPI 9R32

http://redump.org/disc/60481/

Mould SID Code: IFPI 9R80

Hashes match for all those...

9

(1 replies, posted in Fixes & additions)

Disc 1 = darksabre dump is corrupted. Your one is fine.
Disc 8 = both dumps are just fine. I saw darksabre logs and nothing suspicious is in them. Just different mastering code -> different protection range. It can happen!

10

(1 replies, posted in Verifications)

http://redump.org/disc/59944/

Mould SID Code: IFPI 9R76

Everything else matches 1:1

http://redump.org/disc/59945/

Mould SID Code: IFPI 9R17

Everything else matches 1:1

http://redump.org/disc/59940/

Everything else matches 1:1

11

(0 replies, posted in Verifications)

http://redump.org/disc/32406/

Everything matches 100%

http://redump.org/disc/32399/

Everything matches 100%

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.

14

(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?

15

(0 replies, posted in Verifications)

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

16

(5 replies, posted in New 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...

17

(5 replies, posted in New 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.

18

(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!

19

(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

20

(1,758 replies, posted in General discussion)

This example shows the power of DIC + Plextor drives smile

21

(1,758 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?

24

(1,758 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?

25

(1,758 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...