1

(2 replies, posted in Dumps)

In regards to the difference between TGXCD10311 R3D   MFD BY JVC and  TGXCD10311 R1D   MFD BY JVC, JVC discs often have the last three characters of the ringcode be slightly different even on dumping discs.

This is especially common on PC discs, but I see no reason why this shouldn't happen on PCE-CD discs.

For example: http://redump.org/disc/21148/

2

(5 replies, posted in Dumps)

Are you sure the toolstamp is "I1" and not "11"?

3

(24 replies, posted in Guests & account requests)

I'd just like to say that I'm disappointed by your behavior, iR0b0t.

While I do think a modicum of paranoia is appropriate for someone in your position, I'm fairly certain that your paranoia is misdirected in this case.

First of all, I want to make one thing perfectly clear:

I WANT "USA, Australia" TO BE ADDED AS A REGION ASAP.

To demonstrate why, let's look at all 18 PC games that are considered "World" dumps: http://redump.org/discs/region/W/system/pc

Now, I've been told elsewhere that "World", at least as No-Intro defined it, is "Japan, USA, Europe". Given the nature of PC stuff, I think "World" should mean "Asia, America(s), Europe".

Age of Mythology Disc 1 and 2: Originally dumped by Nexy as USA, then dumped by Mock. Should be "USA, Australia"

Baldur's Gate: The Original Saga Disc 1 and 2: Dumped by Pikmin as Australia, then dumped by Monocrom. "Australia, Korea" seems a bit specific, so maybe "Australia, Asia"?

Doom 3: Resurrection of Evil: "Regions dumped: USA, Europe, Korea". This is correct.

Grand Theft Auto IV (World) (En,Fr,De,Es,It) (Disc 2) was "USA, Europe", and was then dumped by Pietro, as Brazillian. It is my opinion that in this case, it should just stay "USA, Europe" with "Brazil" in the comments

Grandia II (Install Disc): It says in the comments field "USA + Australia".

Interstate '76 (Disc 1) (Install CD) was "Brazil", but then changed to "World". I don't exactly know what it should be. Jackal might know.

Quake 4 and Quake 4 (Bonus DVD): Was "Australia", then "Europe, Australia", and then "World". So I suspect this is "USA, Europe, Australia". I'd probably change this to "USA, Europe".

Quake II was "Brazil", then dumped by mock. So, "Brazil, Australia", which should probably be "USA, Australia" with "Dumped in Brazil" in the comments.

Red Faction (Disc 2) (Multiplayer Disc) is odd. 3 people have dumped it, and all of them had different disc 1s. Nexy dumped a US copy, Jackal dumped a Europe copy, and Doshin dumped a Australia copy. So, "USA, Europe"

SimAnt and SimLife were both dumped by Puff0rx as "Australia", then changed to world when I dumped an American copy.

SWAT 4 (Disc 2) is was originally Brazil, then dumped in Europe. I'd change this to "America, Europe" with "Brazillian copy" in the comments.

Unreal Tournament (Disc 2) (Extras) was "USA, Europe" until monocrom dumped it. In other words, it's using "World" correctly!

Xbox 360 Accessories 1.2 was added as "World". I don't know what to do with it.

Zork Nemesis: The Forbidden Lands (Disc 2) is undoubtably "USA, Australia". There are American and Australian versions of discs 1 and 3, but disc 2 is listed as "World"


I also own a copy of Marble Drop and Microsoft Flight Simulator 98 that matches Australian dumps. And I won't verify them until the "USA, Australia" region is added.

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.

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

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!

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.

9

(1,693 replies, posted in General discussion)

Fable: TLC is dumped correctly with this new update. Thank you.

10

(1,693 replies, posted in General discussion)

Logs
https://cdn.discordapp.com/attachments/ … Disc_1.zip

https://cdn.discordapp.com/attachments/ … Disc_1.zip

https://cdn.discordapp.com/attachments/ … ia_USA.zip

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"

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.

13

(1,693 replies, posted in General discussion)

I'd just like to point out that the most recent versions of DIC I tested (The stable one and test version 20181116 95206) still don't detect the SmartE protection on http://redump.org/disc/38957/.

I'm going to test and see if the dump DIC produces matches the DB version.  I doubt it will.

Edit: Nope. No it doesn't.

Also, there's this forom the EdcEcc.txt log:

LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060070, 0x0eaa6], MSF[13:22:70], mode 1 User data vs. ecc/edc doesn't match
LBA[060081, 0x0eab1], MSF[13:23:06], mode 1


EDIT2:

I'm getting a similar issue with what appears to be http://redump.org/disc/40523/. The PVD and file size is the same.

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

EDIT3:
What seems to be http://redump.org/disc/29992/ but doesn't match has SmartE detected.

LBA[000988, 0x003dc], MSF[00:15:13], mode 1
LBA[000989, 0x003dd], MSF[00:15:14], mode 1 User data vs. ecc/edc doesn't match
LBA[000990, 0x003de], MSF[00:15:15], mode 1 User data vs. ecc/edc doesn't match
LBA[000991, 0x003df], MSF[00:15:16], mode 1 User data vs. ecc/edc doesn't match
LBA[000992, 0x003e0], MSF[00:15:17], mode 1 User data vs. ecc/edc doesn't match
LBA[000993, 0x003e1], MSF[00:15:18], mode 1 User data vs. ecc/edc doesn't match
LBA[000994, 0x003e2], MSF[00:15:19], mode 1 User data vs. ecc/edc doesn't match
LBA[000995, 0x003e3], MSF[00:15:20], mode 1 User data vs. ecc/edc doesn't match
LBA[000996, 0x003e4], MSF[00:15:21], mode 1 User data vs. ecc/edc doesn't match
LBA[000997, 0x003e5], MSF[00:15:22], mode 1 User data vs. ecc/edc doesn't match
LBA[000998, 0x003e6], MSF[00:15:23], mode 1 User data vs. ecc/edc doesn't match
LBA[000999, 0x003e7], MSF[00:15:24], mode 1


EDIT4: More details here: http://forum.redump.org/post/66206/#p66206

You put "TOEE_INST" as the disc title. Where does it say that? Is that the volume ID? Or does the disc's label actually say that it is the install disc?

If you don't know what I'm talking about, just post a picture of the disc and I'll take care of it.

15

(1,693 replies, posted in General discussion)

sarami, do you think you could get your CSS tool to be able to detect RCE protection? Currently that CSS tool outputs all DVD-Video information needed except for RCE protection info. It would be great if we could get DIC/CSS to detect it without the need to use DVDDecrypter.

16

(7 replies, posted in General discussion)

iR0b0t wrote:

Right now its okay to not have it checked, but on the long term we should find a way to include it into the logs without having to run the dvd-decrypter.

I absolutely agree

17

(0 replies, posted in General discussion)

It has recently come to my attention that some visual novels were released in the UMD-Video format rather than on the standard PSP-game format. Games like these are called "UMD-PG" (which stands for "Players Game"

An example of this would be Aki No Urara No Akaneiro Shoutengai
http://datomatic.no-intro.org/index.php … amp;n=0351

With this in mind, I think we should add the UMD-Video category.

Besides, we're datting CD-i VIdeo discs, so we might as well dat standard UMD-Video discs as well.

Once the system gets set up, I'd be willing to moderate the platform.

EDIT: This seems to be a rather complete list of UMD-PG games: https://vndb.org/r?q=umd-pg;fil=;s=released;o=d;p=1

Many thanks to rockleevk for bringing this format to my attention

18

(3 replies, posted in Dumps)

Almost all added, I just need to check some barcodes for Wipeout and see if I should put a tab before "TESTCM11"

19

(3 replies, posted in Dumps)

Since nobody has bothered to add these verifications, and since I've been promoted to moderator, I'll add them myself.

20

(7 replies, posted in General discussion)

Okay. Serious question for everyone:

Does anyone care if people don't specifiy if discs have RCE protection?

Because DICUI doesn't specifiy if it has it or not.

I'm convinced that it's rare enough that we probably won't every run into one, and that the only reason we've marked it in some discs is because DVD Decrypter included it in their scan

I'd love to hear the insight of other people

21

(7 replies, posted in General discussion)

It seems as though I'm a mod now.

Thank you.

do_0m wrote:

Was there a third user in the nNASOS thread trying to implement their own version? I can't remember.


nNASOS is a thing.

https://cdn.discordapp.com/attachments/ … S_v1.8.zip

23

(66 replies, posted in General discussion)

F1ReB4LL wrote:
Jackal wrote:

That's just a technicality. If you create 2 different sets of dump files with different .cue and filenames, and 2 archives for a single disc, this will be a bigger issue than what we have now.

A single set, a single archive, just 2 cues.

Like, Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA).LD.cue with the tracks 1 and 2 and Official Sega Dreamcast Magazine Vol. 11 - February 2001 (USA).HD.cue with the tracks 3, 4 and 5. You can mount the LD to some virtual drive and work with it exactly like you would work with a normal GD inserted into a PC drive. Emu devs may support either running the HD cue only or some kind of auto-mounting the LD cue additionally when the HD cue is selected.


So like this?

My concern is that "Track 3" is actually "Track 1" in the HD cue. That'll get confusing fast.

24

(1,693 replies, posted in General discussion)

Test complete. The new dump with that test version of DIC produces a bin file with the exact same checksum as an older version of DIC, and it doesn't reread all those errors. Thank you very much.

25

(1,693 replies, posted in General discussion)

I think I found an issue with SafeDisc Lite discs (or at least with an undumped copy of MS Train Simulator I got recently). DIC recognizes the protection when using the /sf flag, and all the errors that show up are 312 bit, but when the last sector is dumped, DIC decides to try and reread all the sectors that have intentional errors. And when it reaches the maximum number of retries for one of those errored sectors, DIC doesn't cancel the dump like normal, but then proceeds to reread the next intentionally errored sector the same way. When the last sector is done, it just descrambles the .scm like normal.