(50 replies, posted in General discussion)

Themabus, here's the first sector after the ring that I'm able to read (plextor reads it @ 297700, and there's no sector offset difference between trap disc > normal disc..) it has some extra bytes before the sync/header so I guess they should be included also?: http://www.speedyshare.com/936172809.html

But you say the MSF indicates that it's sector 297694.. that may be.. but I think this sector really is sector 297700 and it belongs @ offset 700190400?

The reason I 'predicted' the rest of the sector (including the sync/header) before these bytes is that I thought the drive cut off the rest of the sector and the bytes before the sync/header that you see in the file actually belong to a previous sector?

Would be nice if you could upload a fixed image cool


(50 replies, posted in General discussion)

Mortal Kombat II [EUROPE]

Looks like I made an error there? are you sure it starts @ 297694? that would mean that there the ring is 550 sectors long.. could you correct the image that I uploaded plz?


(50 replies, posted in General discussion)

Here's a WIP image..


mirror: http://www.megaupload.com/?d=JDVYNCDW

- The last sector I was able to read before the ring is sector 297143, so error sectors start at sector 297144.
- Ring is from 297144 - 297699 (possibly the real start is 297150, but there's no way to tell, except maybe a microscope lol)
- Unknown data seems to starts at sector 297700.. so far I managed to read it up to sector 328468, so the size of this unknown data is 30768 sectors.

What's missing:

- A fake TOC file that matches these sector ranges: http://redump.org/disc/2210/
- Subchannels (partial subs from the unknown data range are included in the archive, but since it doesn't contain any protection data I guess the same data is generated during burning, so it should be useless)

How it should be burned (in RAW DAO 96, using a tool that can burn illegal TOCs):

- Sectors 0 - 13536 should be the same as the dump:  http://redump.org/disc/2210/
- Sectors 13537 - 297143 should be audio (all zeroes)
- Sectors 297144 - 297699 should be data (burned as error sectors) or maybe it can be anything
- Sectors 297700 - 328468 should be data too I think (because there's a sync/header..)

It's pretty difficult to get an exact start and end position for the ring and the unknown data area because all drives give different results. But I guess it doesn't have to be 100% exact because the saturn drive propably won't be able to read the first and last sectors of it either.

What we need to find out:

- If the ring and the data after it are always the same amount of sectors and what the correct sizes are.
- If the location of the ring and the unknown data is always the same, or if it can be predicted in any way
- If this data is used for protection (if not, is there evidence of a wobble?)


(50 replies, posted in General discussion)

Here are the mk2 ring img and sub.. maybe I can still squeeze more sectors out of the cd, but it's gonna be tough...


Here are my first observations:

- Main channel data appears to start @ 297700 (maybe your discs do to if you go back more?)
- I managed to extract 30326 sectors of main channel so far, subchannel a bit less.
- CDReader is good for extracting multiple sectors at once, but it's unable to extract some of the first and some of the last sectors of the area. The D8 command seems more suitable, so maybe Truong can mod cdtoimg so it can extract sector ranges.
- Use px_d8 to read more sectors at the start and at the end (you can append them to the cdreader image using hex editor)
- px_d8 has more trouble reading sectors with subchannels enabled, for example: I can read sector 297700 without subchannels but not with.
- subchannels only contained read errors, no actual protection data (did several 100b extractions at different speeds and it only left me with some random errors at the end).

I'll try installing a different drive tomorrow to get some of the missing subchannels sectors and then construct an image with the unreadable sectors and ring area etc added (hopefully I can make it a burnable image so that someone with a saturn console can try to boot it).

It's possible that the saturns reads this data (at least the main channel), but I don't think it does it right from the first to the last sector, and possibly it only reads the user data.. so as long as the 595959 bytes are present in that range on the CD there's a chance it might work?


(50 replies, posted in General discussion)

ok.. I suppose 100b is always better than 001b and no real data is lost (only random errors).. so I'll do several 100b sub dumps, and clean those as much as possible


(50 replies, posted in General discussion)

I managed to rip the main channel data, from sector 297704, 30199 sectors long, but the subchannels are giving me problems.. I want to be sure that they don't contain any protection bits, but I can't get them cleaned 100% with cdgtool..  there are always some differences left in the crc bytes.. I already tried 100b and 001b, compared them, etc, but think we'll need a tool that rereads every sector a couple times, like psxt001z --libcryptdrv does...

Have you examined your subs for any possible protection data?


(50 replies, posted in General discussion)

Ok.. I'm dumping my one and only saturn disc (Mortal Kombat II) with audio trap disc..

do you have any information on the location of the ring?

My disc has readable sectors up to sector ~297000 (666 mb).. but I'm using ddump to skip past the unreadable ones (hope some will be readable after).. and there's no data except zeroes between the end of the game data and the unreadable sectors, so maybe it reached the end of the disc and I'm wasting my time hmm


(50 replies, posted in General discussion)

I do? yikes no, I don't hmm

Are they similar to PSX?

themabus, what do you make of this? - http://forum.redump.org/viewtopic.php?id=3349
xenogears' dumps in the last post should be identical to the other 2, right? or can it be a mastering difference again

Please try anyway.. I have no idea where else this game could originate from (the file was also included in an UG torrent but I think they have it from that board as well).

@MrX_Cuci, here's another cheap auction for II in case you're a collector or something, but I'm already getting it from marktplaats big_smile (to verify MrK's dump).. I guess you could save a lot on the shipping by telling him not to send the entire box.

http://cgi.ebay.nl/MORTAL-KOMBAT-2-pc-c … dZViewItem

I'm also still looking around for MK Trilogy for the PC but it's rare also (and there are multiple versions out there).

Over at this board a guy dumped the game "Mortal Kombat & Mortal Kombat II" - http://www.abandonsocios.org/foro/index … ;pid=58821

edit: check last post, I dumped and verified this game.. the dump can be found at the above link (image is in 2448, use isobuster to extract it to 2352 format and it will match).


(23 replies, posted in Fixes & additions)

I don't know sad


(23 replies, posted in Fixes & additions)

SecuROM games shouldn't even be in the database.. the images are useless because they're missing DPM info / maybe subchannels.. I think it's best to just remove them


(25 replies, posted in General discussion)

BD doesn't need preservation.. it doesn't belong here and hopefully it will never be added


(9 replies, posted in General discussion)


It appears that an exe was dissected to extract this 'serial' roll If that means that both the serial on the case and label and the serial in the exe filename are different, then I really don't see why SCPS-10008 needs to be there.. it could be just leftovers from old code that got compiled into the exe.

Anyway, I don't think there's any point in changing anything until the original version is dumped as well.

iR0b0t wrote:

well, this is just the shit about I talk here all the time, but nobody listen to me...

Maybe it's best to always use the serial on the label of the disc, and to list multiple serials in case several editions have the same checksums. And only list version numbers for different serial games in the database, not add them to the filename in the dat.

Anyway, I'm not gonna interfere with this. If anyone is gonna change stuff from now on, please make sure Dremora is aware of it, so that at least there's some sense in what's happening and more than 1 people are aware of the changes that are made.


(0 replies, posted in News)

Over a 1000 dumps added in just 2,5 months. Good job dumpers!


(23 replies, posted in Fixes & additions)

(No EDC) looks better imho, so I corrected the other 3

In the .cue that you posted all tracks are merged together, so the audio starts somewhere in the first file. We separate all tracks, so that's why our cue looks different.


(11 replies, posted in Fixes & additions)

http://img83.imageshack.us/img83/852/psogl20239ah.jpg lol


(11 replies, posted in Fixes & additions)


European demo discs have only the title though, and a bunch of text on the lower side of the disc explaining in various languages that it's a demo.


(11 replies, posted in Fixes & additions)

I changed Resident Evil 2, Final Fantasy VIII and Silent Hill demo filenames to (Demo)... I checked the cd covers of all 3 games and they didn't show Trial Version, Sneak Preview or Preview.. I think it's best to just name them (Demo) like the other game Demo's in the dat (Metal Gear Solid, Ape Escape, etc).


(11 replies, posted in Fixes & additions)

Then it should be called Honda Demo (Demo) tongue Honda alone isn't the games' name.. besides, there isn't even a full version of this game afaik


(11 replies, posted in Fixes & additions)

Honda Demo is the text on the cd afair


(5 replies, posted in Fixes & additions)

The last gap seems wrong.. does EAC give you the same? if it does, then could you try another drive?


(5 replies, posted in Fixes & additions)

Did you check the perfectrip .cue of the new dump to make sure the gaps are all exactly 2:00?