Search options (Page 26 of 32)

Dremora already helped me identify the tool

anyway, aren't we just extracting the printed ring text on the CD in bytes and turning it back into readable ASCII text? because both texts are identical:

TRADEMARK ''SEGA''      PRODUCED BY or UNDER LICENSE FROM SEGA ENTERPRISES LTD.

I guess we should start looking at the pregap instead?

1337 paint skillz keep it coming

You were right about the 6 sectors, so I guess the write offset after the ring is 6x588 + (180-30) = +3678 vs +222 before (+3678 - 222 = +3456, a funny number ).

Anyway, it's weird that the offsets differ on some discs.. maybe they used a separate device to add the logo?...

and maybe all discs start at the same sector after combined offset correction? if so, then it would be easy to convert a redump dump to a complete one: just insert zeroes after the original dump data up to sector 297143, then 550 sectors of 55's and then the logo data (if this data is always the same, including the RAW bytes?).

Also, I'm a bit confused.. the 'logo' area, is it the same area that is visible at the end of the disc when you hold it in the light? It has the same Sega logo written on there.

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

Here's a WIP image..

http://rapidshare.com/files/129135106/mk2.rar.html

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

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

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

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).

http://forum.redump.org/viewtopic.php?id=2560

It appears that an exe was dissected to extract this 'serial' 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.

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.

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.

I'm just dumping one of the action replay psx discs I had laying around and surprisingly a lot of data is "hidden" behind the data track.. you'll have to use a trap disc to dump all the data on the disc. I'll also analyse the subchannels to make sure they don't contain anything special

edit: psxt001z reported the correct filesize, so make sure you check with psxt001z that all data is dumped (it could be hidden behind the data track) before posting