I own a copy of Age of Empires III. The ringcode and offset are different from the existing dump, but the PVD and size are the same.

It has SmartE, I've had a bunch of issues with it.

Much like what I experiencec with http://redump.org/disc/38957/, a DIC dump and a CDManipulator dump with an ASUS BW-12B1ST a produce different results. However, With Fable TLC, the CDManipulator dump actually produced a dump that matched the DB, while DIC didn't.

In this case, neither match the DB. Knowing this, I decided to compare all three files at a binary level.

Here are all the differences between the CDManipulator dump and the DB dump.
https://cdn.discordapp.com/attachments/ … nknown.png
https://cdn.discordapp.com/attachments/ … nknown.png
https://cdn.discordapp.com/attachments/ … nknown.png
https://cdn.discordapp.com/attachments/ … nknown.png

My DIC dump also has those differences, but it differs from the CDM dump in 10 other tiny differences:
The first is https://cdn.discordapp.com/attachments/ … nknown.png
the last is https://cdn.discordapp.com/attachments/ … nknown.png
There are 8 others, and they are all like that. I think this is the source of those problems, from the EdcEcc file:

LBA[059462, 0x0e846], MSF[13:14:62], mode 1
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059462, 0x0e846], MSF[13:14:62], 2336 bytes have been already replaced at 0x55
LBA[059473, 0x0e851], MSF[13:14:73], mode 1


Also, I have found a similar issue with http://redump.org/disc/29992/. Unlike AOE3, DIC actually detects the SmartE on this one. However it still has a difference:

https://cdn.discordapp.com/attachments/ … nknown.png
https://cdn.discordapp.com/attachments/ … nknown.png

Somehow, the DIC dump and the CDManipulator dump are the same.

2 (edited by reentrant 2019-01-03 01:53:33)

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.

Post's attachments

Descramble_CDDA.rar 173.46 kb, 2 downloads since 2019-01-03 

EccEdc.rar 105.34 kb, 1 downloads since 2019-01-03 

You don't have the permssions to download the attachments of this post.

Reults for AOE:
Descrambling creates .BIN file that matches the DIC output file. This hash is not changed by fixex.
<rom name="Age of Empires III (USA) (Disc 1).bin" size="711948048" crc="8ad354f3" md5="509e0c024f0c9d0811bbe5463488e550" sha1="ef19bff2950d279662d86c67e3b808339b6fece9" />

"[WARNING] Number of sector(s) where 2336 byte is all 0x55: 10
    Sector: 59463, 59464, 59465, 59466, 59467, 59468, 59469, 59470, 59471, 59472, "


Results for Marine Mania:

Descrambling creates a bin file that does not match the DIC output file or the CDManipulator file (since those two are identical). This hash is not changed by fixex, and it does not match the DB either.
Results: Zoo Tycoon 2 - Marine Mania (USA).bin  02cf52f2  806caadeaa06b5ccabee1a55ab414650  519428b5e8af102c7df6bfb50357de85c5ffd747


"[WARNING] Number of sector(s) where reserved byte doesn't zero: 10
    Sector: 989, 990, 991, 992, 993, 994, 995, 996, 997, 998, "

Just for laughs, I decided to give Fable TLC the same treatment, and it actually ended up with the checksum that is currently in the DB


"[ERROR] Number of sector(s) where user data doesn't match the expected ECC/EDC: 10
    Sector: 60071, 60072, 60073, 60074, 60075, 60076, 60077, 60078, 60079, 60080,
10 unmatch sector is replaced at 0x55 except header"

Just make sure your dumps have 10 errors, otherwise it's a bad dump. You could also use CDM or CloneCD. The only difference with DIC should be in those 10 sectors. The last 2336 bytes should be 0x55 bytes.

5 (edited by reentrant 2019-01-03 09:09:59)

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.

Post's attachments

CDArchive.rar 193.69 kb, 1 downloads since 2019-01-03 

You don't have the permssions to download the attachments of this post.

Sarami recently released a new test version of DIC. It dumped Fable TLC with a proper checksum, so I dumped the other two discs with it as well.

And wouldn't you know it, my CDManipulator dumps match the new version's dumps. And CDArchive doesn't give me any errors after scanning them.

With that in mind, I've uploaded my logs here.

With Jackal's permission, I'll adopt these checksums as the proper dumps.

Post's attachments

Age of Empires III (USA) (Disc 1).zip 1.57 mb, 2 downloads since 2019-01-03 

Zoo Tycoon 2 - Marine Mania (USA).zip 1.64 mb, 3 downloads since 2019-01-03 

You don't have the permssions to download the attachments of this post.

I also just found what appears to be a copy of http://redump.org/disc/40817/ in my undumped stash. Lets see what happens with this one:

EDIT: It matches!

ajshell1 wrote:

Sarami recently released a new test version of DIC. It dumped Fable TLC with a proper checksum, so I dumped the other two discs with it as well.

And wouldn't you know it, my CDManipulator dumps match the new version's dumps. And CDArchive doesn't give me any errors after scanning them.

With that in mind, I've uploaded my logs here.

With Jackal's permission, I'll adopt these checksums as the proper dumps.

Do you have the ringcodes for your dumps? They are prolly mastering differences. I don't see how different dumps from the same disc could cause differences? I mean, the only way it could mess up is if one dump has more than 10 errors?

AOE3 ringcodes:

Mastering: X11-35585    +    + EE30701
Mastering SID: IFPI L028
Mould SID: IFPI 1013
Toolstamp: A06


Marine Mania:

Mastering Ring: X12-79925 (RM.P1) 01
Mastering SID: IFPI LW87
Mould SID (on the label side for some reason): IFPI 4W22

Could you try to dump both discs on a non-plextor drive with CDM or CloneCD and see if you can get matching dumps with 10 errors?

AOE3

I have a CDManipulator dump from a non-Plextor that I made before sarami made that new test version of DIC. The output file is the same as the DIC test output: <rom name="Age of Empires III (USA) (Disc 1).bin" size="711948048" crc="c73cda1d" md5="d96384105d76ee424450667a10051a20" sha1="6bbc88a888e31b2244c4206e5db318d71cfc380f" />

ZT2:MM
I also have a CDMDanipulator dump made before that new DIC test version. However, the CDManipulator dump, the old DIC dump, and the DIC test dumpa all produced the same output:
<rom name="Zoo Tycoon 2 - Marine Mania (USA).bin" size="745708656" crc="dd68e1f5" md5="9f8608f4043c9d2fa8fd1af2d3ab63d8" sha1="70ebba53880bea328b02eee69b89a6897c1bf836" />

With this in mind, I'm getting the feeling that the dump of AOE3 disc 1 in the DB is definitely errored. Also, the person who dumped that copy of disc 1 didn't bother to dump disc 2 or 3.

I'm not so sure about Marine Mania though. I'd like to see if darksabre76 can redump his copy, and see what he got.

The thing is, the ringcodes are all different, and we checked the AOE3 dump and it has 10 errors and the data seemed fine. The data differences are not in the error sectors but around them. So I guess you should add both your dumps as (Alt).