Hi all,

a while ago, I submitted a verification for http://redump.org/disc/42967/

The mould SID code IFPI 0703 is not correct, it should be D703 instead. This is from the disc I originally submitted, but in the meantime, I got myself an USB microscope, and under magnification you can see the difference.

Thank you!

Verifying http://redump.org/disc/91434/

Hashes and ring code are matching, new mould SID code, missing toolstamp.

Submission info:

Common Disc Info:
    Title: Age of Empires: Gold Edition
    Foreign Title (Non-latin): 
    Disc Number / Letter: (OPTIONAL)
    Disc Title: (OPTIONAL)
    System: IBM PC compatible
    Media Type: CD-ROM
    Category: Games
    Fully Matching ID: 91434
    Region: Germany
    Languages: ADD LANGUAGES HERE (ONLY IF YOU TESTED)
    Disc Serial: X00-20500 DE

    Ringcode Information:

Data Side Mastering Code (laser branded/etched): Sono press IC-6793/X00-20509 A
Data Side Mastering SID Code: IFPI L0 22
Data Side Toolstamp or Mastering Code (engraved/stamped): missing
Data Side Mould SID Code: IFPI 5814
Data Side Additional Mould: missing
Label Side Mould SID Code: missing
Write Offset: -12

    Barcode: 
    Error Count: 0
    Comments:

<b>Logs Link</b>: [Please provide a link to your logs here]
[T:VOL] AOE
<b>Game ID</b>: 0199 Artikelnr. X00-20500 DE (Disc), 0199 Artikelnr. X00-20503 DE (Jewel Case Back Inlay), X00-20501 (Manual), X00-10785 (Key Map)
<b>ID next to barcode</b>: 559-00072, BGX3958, *001BC916049X100607*, Date: 15-04-99, BC916049
<b>ID next to barcode (Alt)</b>: 559-00072, *001BD908141X100816*, Date: 19-02-99, BD908141

    Contents: 

Version and Editions:
    Version: 1.0b
    Edition/Release: Original

Extras:
    Primary Volume Descriptor (PVD):

0320 : 20 20 20 20 20 20 20 20  20 20 20 20 20 31 39 39                199
0330 : 39 30 31 32 31 30 30 30  30 30 30 30 30 00 30 30   9012100000000.00
0340 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 00 30   00000000000000.0
0350 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 00   000000000000000.
0360 : 30 30 30 30 30 30 30 30  30 30 30 30 30 30 30 30   0000000000000000
0370 : 00 01 00 00 00 00 00 00  00 00 00 00 00 00 00 00   ................

Tracks and Write Offsets:
    DAT:

<rom name="AOE (Track 01).bin" size="333313680" crc="66d944e8" md5="65799d2b4c1967689cbe0b881180eb43" sha1="b195c2f7375237540bd05fa5fc014cb1e526a6cf" />
<rom name="AOE (Track 02).bin" size="12112800" crc="f17b9323" md5="ea9df4aa9fdaab1147995f4e598396c7" sha1="bf663b309ac108d7fd417b95c37b6d1b27e372c7" />
<rom name="AOE (Track 03).bin" size="4266528" crc="601770a1" md5="c640403a03964f67d4ce4e7e38f2adc8" sha1="fe6efd92781267178e74324e23d1c9bb083f35e4" />
<rom name="AOE (Track 04).bin" size="9626736" crc="03a90b47" md5="d8ebb0a5e24aa4532e1e15089c6a599a" sha1="b48109e54e40bd3b4d3ddf6f270a34394a7d9985" />
<rom name="AOE (Track 05).bin" size="22473360" crc="13ed3dea" md5="e191dae2644844f99d94bc725b6bda65" sha1="00a5843840d252b8bcfd31806f6d5ef7ffa7b399" />
<rom name="AOE (Track 06).bin" size="24627792" crc="10cfd496" md5="345492483836b64ee7a89cd2eefef359" sha1="3164d0d8d107f666f9793e0327ef748e4ef38864" />
<rom name="AOE (Track 07).bin" size="37265088" crc="b7c5e54f" md5="27c0bb5a09763ba892caaa1727a93715" sha1="0535181d184897d195dac4dcb6ec9adf02d61aba" />
<rom name="AOE (Track 08).bin" size="27906480" crc="4bd59588" md5="cf06fd89c128bd345103809ef0e06321" sha1="4e7abd8850f68d73e0bab5c47c0f3ac2479f9bbf" />
<rom name="AOE (Track 09).bin" size="32810400" crc="acd87162" md5="899e6d47fc8e8ae9b6ee34b385862c66" sha1="7d633c52ae96ab652e91f45ac64a03c089bbe802" />
<rom name="AOE (Track 10).bin" size="33219648" crc="4bf52c2f" md5="8f01c9289e3d067278c281a39dccaed7" sha1="b87743d154f94ea5a3fc8b5a965765063ef74303" />
<rom name="AOE (Track 11).bin" size="33810000" crc="094bee6e" md5="98297824798bf39cdea30e988cc31581" sha1="197c90b3db511c63f981c6768f6e1c728516eeea" />
<rom name="AOE (Track 12).bin" size="30002112" crc="e95aeea3" md5="37a3ca1546dd711c67fc7430cc7ff20b" sha1="cb96e362da4b702c6d04e49c1560762d29ed8735" />
<rom name="AOE (Track 13).bin" size="32605776" crc="ed660967" md5="cda24c5c82a7b6e1abc30bd4f877d6e4" sha1="1a707c9c9758572040929a4f99a06505a9d96711" />
<rom name="AOE (Track 14).bin" size="30018576" crc="04e73b30" md5="f4663328aeea68ccf522dc4ec967d342" sha1="0eac8e5cb4596e0892d7e185fd3b5cc5276a4d9d" />
<rom name="AOE (Track 15).bin" size="16336992" crc="80387b06" md5="58723bbfaf7e27b806f5493e6bc19fd3" sha1="083a88868b2a7c633a293c46d9529d6e91070964" />

    Cuesheet:

FILE "AOE (Track 01).bin" BINARY
  TRACK 01 MODE1/2352
    INDEX 01 00:00:00
FILE "AOE (Track 02).bin" BINARY
  TRACK 02 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:01
FILE "AOE (Track 03).bin" BINARY
  TRACK 03 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 04).bin" BINARY
  TRACK 04 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 05).bin" BINARY
  TRACK 05 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 06).bin" BINARY
  TRACK 06 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 07).bin" BINARY
  TRACK 07 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 08).bin" BINARY
  TRACK 08 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 09).bin" BINARY
  TRACK 09 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 10).bin" BINARY
  TRACK 10 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 11).bin" BINARY
  TRACK 11 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 12).bin" BINARY
  TRACK 12 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 13).bin" BINARY
  TRACK 13 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 14).bin" BINARY
  TRACK 14 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00
FILE "AOE (Track 15).bin" BINARY
  TRACK 15 AUDIO
    INDEX 00 00:00:00
    INDEX 01 00:02:00

    Write Offset: -12

Dumping Info:
    Frontend Version: 3.3.3-d3993a48e44acb347ea7c7a60c8eec75fa88631b
    Dumping Program: Redumper v2025.07.14 build_631
    Date: 2025-08-31 11:53:59
    Parameters: disc --verbose --skeleton --drive=F:\ --speed=24 --retries=20 --image-path=C:\Temp\AOE --image-name=AOE
    Manufacturer: PLEXTOR
    Model: CD-R PX-W4012A
    Firmware: 1.07 (03/22/06 09:00)
    Reported Disc Type: CD-ROM
    C2 Error Count: 0

Logs: https://nx50670.your-storageshare.de/s/MAL8cWdcCeerX8a

I gave this a try on a couple of drives I have. I have two Optiarc drives, so I include both of them.

I was also trying this on my LG GH22LS30. Turns out I killed it. It got stuck at the first bruteforce stage, so I powercycled it mid-run. Which was a bad idea. The drive started to rapidly bang it's head against whatever wall is in the drive and refuses to read any disc since then, no matter if it is a DVD or a CD.

Well, at least I can say it died for science.

Thank you for your reply! I have an idea on how to do it with redumper... But I need more investigation for this protection. I know how to handle the "usual" ringed protections, but the ones with the audio tracks are especially tricky.

reentrant, I have a bunch of ring protected discs that have the broken sectors within multiple audio tracks.

Is cdarchive able to read audio sectors properly as well?

6

(3,536 replies, posted in General discussion)

F1ReB4LL wrote:

If you can cut the unneeded bytes and descramble everything with no errors, the errors count should be 0.

Was that related to the disc in question I dumped? If so, can you lead me to the steps how I can strip the unneeded bytes and manually descramble the file?

sarami wrote:

Request

  • Language and Region filter of dat file like no-intro

+1!

I have another suggestion: Is it possible extend the "My Dumps" page to allow downloading a .dat file that only contains the user's owned discs/dumps?

8

(3,536 replies, posted in General discussion)

Thanks sarami for your great support!!

Is it now safe to submit the DIC dump? Which comment should I choose regarding this weird sector 150? What about the error count -  "1" as reported by CD Manipulator and CloneCD or "0" as reported by DIC+edcchk?

9

(3,536 replies, posted in General discussion)

sarami, the dumps of cdtroimg and the scrambled DIC file differ. From what I can tell, DIC is missing the first 32 bytes of the image.

First few bytes of the DIC .scm image:
https://abload.de/img/dicscmrhd8k.png

First few bytes of the cdtoimg image:
https://abload.de/img/cdtoimgn8cv1.png

Trying to read the pregap threw lots of errors - log file and resulting dump available at https://www87.zippyshare.com/v/Xhoz9VMK/file.html

Is it possible that this is a disc with a mastering error instead of a copy protection?

Thanks for your help!

~celebi

10

(3,536 replies, posted in General discussion)

Nope, all sectors are mode 1.

11

(3,536 replies, posted in General discussion)

Uploaded test. http://www.mediafire.com/file/eq80y20l9 … st.7z/file

fixed: Skipped this error.

Thanks a lot, with this test version I was able to dump this disk. Interestingly the checksums doesn't match with either CD Manipulator or Clone CD.

And even more interesting is that edcchk hasn't detected an error in sector 150 (00:02:00) and just detected it as Mode 1 data sector.

12

(3,536 replies, posted in General discussion)

In any way plz upload SCM dump that HAS that faulty sector...

Sorry, the sector 150 I'm referring to is at 00:02:00.

What's the best way to obtain an .scm dump without DIC? Dumping with DIC fails so early that it doesn't create a .scm file. I tried with "cd", "data" and "audio" option.

13

(3,536 replies, posted in General discussion)

But READ12 (0xa8) can't read it. Perhaps READ CD (0xbe) is also same. It's weird...
Is this a protection? I don't know. Maybe iR0b0t or Jackal or reentrant know it?

I re-checked again with CD Manipulator and Clone CD, it seems that even those tools don't know how to handle this sector properly. Clone CD fills sector 150 with "55" while CD Manipulator fills the same sector with "00". Does that make any sense? Which tool should I trust more?

Would it be helpful to upload a subdump dump?

14

(3,536 replies, posted in General discussion)

I'm actually not completely sure that it's a copy protection... ProtectionID and similar tools don't detect it.

I *think* it's some sort of copy protection since the disc is in pretty good condition and I don't want to believe that's in an unintentional read error just at sector 150... Also look at the TOC, there's a small second and third track just a few seconds long...

UPDATE: Issueing /d8 doesn't help. However, subdump can read the sector without issues...

15

(3,536 replies, posted in General discussion)

Thanks for your reply. The issue persists with the latest update unfortunately.

Logs: https://www78.zippyshare.com/v/m5bq4qaz/file.html

16

(3,536 replies, posted in General discussion)

I have an issue with dumping "Anno 1602 - Im Namen des Königs". The disc dates back to 1999 and seems to use a copy protection that includes a broken/defective sector 150.

CD Manipulator is able to dump the disc (matching checksums with two different drives) by skipping sector 150.

DIC command:

E:\_Tools\Programs\DiscImageCreator.exe cd F D:\Redump\Anno 1602 - Im Namen des Koenigs (Germany)\Anno 1602 - Im Namen des Koenigs (Germany).bin 4 /c2 20 /ns /sf 

Playing around with the different copy protection related parameters doesn't help.

DIC error log:

LBA[000000, 0000000]: [F:ReadCDForSegaDisc][L:1104]
    Opcode: 0xa8
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-02-83 = MEDIUM_ERROR - VENDOR UNIQUE ERROR
lpCmd: a8, 00, 00, 00, 00, 00, 00, 00, 00, 01, 00, 00
dwBufSize: 2048

LBA[000000, 0000000]: [F:ReadCDForFileSystem][L:574]
    Opcode: 0xa8
    ScsiStatus: 0x02 = CHECK_CONDITION
    SenseData Key-Asc-Ascq: 03-02-83 = MEDIUM_ERROR - VENDOR UNIQUE ERROR
lpCmd: a8, 00, 00, 00, 00, 00, 00, 00, 00, 01, 00, 00
dwBufSize: 2048

All logs: https://www93.zippyshare.com/v/FsXrzNR5/file.html

Is there any way to fix this?

17

(35 replies, posted in General discussion)

Great tool and research!

Tool must be run as admin because it has some other functions like ripping sectors which require admin.

Does that mean that the tool has the ability to rip the DPM information from the CD/DVD itself?

18

(3,536 replies, posted in General discussion)

sarami, I cannot thank you enough!

With the latest test version skipping the 312 bit errors, I finally managed to get several (!) dumps of the previously bad disk matching the dumps I made with CloneCD using a different drive. So finally I have a good dump that will soon enter the redump database. Nice and clean 579 bad sectors, image perfectly working. Thanks again!

I'm very sure that my Plextor W5224 isn't great when it comes to uninententional C2 errors mixed with the Safedisc errors - it detected a few of the Safedisc errors with other bit counts and tried to re-read them too. It should be also noted that the Plextor had issues dumping that disc in CloneCD (random errors there too) while my cheap slimline drive always produced a good dump in CloneCD with the same disc.

I think I should get another Plextor model for safedisc discs in bad condition. If I remember correctly, Nexy reported issues with some Safedisc discs with that drive too - maybe it can only read the Safedisc discs in the first run if they are in perfect condition.

Thanks again!!

same here.

20

(3,536 replies, posted in General discussion)

Currently DIC is reporting various error counts - waiting for the current dump to complete with a higher re-read count. CloneCD always reports 579 errors for that disc.

So in general, header regenerated messages/sync errors are not harmful as long as I get matching checksums over multiple reads?

Thanks for your support man! (and sorry for asking all those (stupid?) questions tongue)

21

(3,536 replies, posted in General discussion)

Thanks, I'll give it a try.

=> The problem is that dic skips rereading if unintentional error is also 312.

How is the bit number for C2 errors calculated and how high is the chance that an unintentional error is exactly 312? Still improves the reliability compared to previous versions though...

EDIT: Btw, have you looked into mainError.txt from the bad disc I submitted? Assuming all unintentional C2 errors could be fixed, would this be a good or a bad dump? I don't know what those "header generated" messages mean.

22

(3,536 replies, posted in General discussion)

I dumped 5 safedisc discs, ranging from Safedisc v1.x to 4.6.

Logs: https://www.sendspace.com/file/l7lxjq

C2 error is always 312 bit.

23

(3,536 replies, posted in General discussion)

At least for one good safedisc disc I can confirm that *all* sectors with C2 errors are 312 bit.

Most of the sectors of my bad safedisc disc have 312 bit too, the random ones have random values. Logs of the bad disc attached. I'll try to confirm more good safedisc disks.

Logs of the bad disc after a full redump: https://www.sendspace.com/file/9i1ne5

24

(3,536 replies, posted in General discussion)

sarami, thanks for the new test version.

Just trying with another known good safedisc disk - I'll see if checksums match with "old" stable version and latest test version. Hold on - logs will follow. Then I'll see if the new test version can do something about the bad safedisc disc.

I'll post the logs of the bad disc too... maybe I can finally get a good dump without any unintentional C2 errors.

25

(3,536 replies, posted in General discussion)

I did a few more runs on that problematic disc - it seems that it is in a condition that makes it unusable for proper dumping. I get not only random C2 errors (that get fixed by the re-readings, so the new feature works as expected), but also sync issues. Damn.


sarami, thank you for the fast implementation of this feature request!