Bleh I was wrong.. you can just use perfectrip for the psx one.. dunno about gc

here's the dump of my Front Action Replay disc for those interested:

it's almost identical to the cd codepatch 1.0 iso found here (some sectors are different, but the app is the same): … index.html

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


(15 replies, posted in General discussion)

Something tells me that Final Fight dump has all wrong gaps neutral unless of course the subchannels are like that


(6 replies, posted in Fixes & additions)

Someone else already fixed it a while ago.. it should be correct now


(11 replies, posted in General discussion)

If the difference on this track is only an offset difference, can't you use that track to determine the 'correct' offset correction?


(11 replies, posted in General discussion)

The descramble_cdda tool to descramble the data track (if you just select the complete d8 dump file and start descrambling it will stop extracting once it reached the proper data track size):

I tried comparing the amount of bytes in the pregap of my alone in the dark dump but it's different on each track, so there's no way to detect a reference.. sad


(11 replies, posted in General discussion)

You mean reading the entire disc in d8, then cut off the bytes in the first sector before the sync starts, then cut off the data track (it has to be descrambled anyway)?.. this should give the exact same results as our current method (and this is also how I dumped the dreamcast discs). Perhaps I'm just looking for a way to avoid the offset differences from mastering and finding the true reference.

Here's a tool that can extract all sectors in d8 mode:


(11 replies, posted in General discussion)

ps. of course it's possible that the detected offset of this disc is just wrong: maybe d8 gives a -306 offset.. I'm not at all comfortable with all the +0 write offsets .. Maybe the correct write offset just isn't showing.. I also have some IBM discs where the data track with d8 only shows the read offset and not the write offset (yet the old detection method gives me a write offset different than +0 on the audio tracks).. maybe these +0 discs just don't show the write offset using any method. How can we fix this?

Same for these discs: .. same gaps, same track sizes, +901 offset difference.. both discs show a +0 write offset.. I will see if there's another way to determine the correct write offset value (for instance the amount of data that is moved outside of the tracks).

In other words: how to find a reference that isn't there? tongue


(11 replies, posted in General discussion)

I noticed this earlier.. the only systems where the visible write offset really makes sense are PSX and Dreamcast.. in all the other systems, after correction,  the audio doesn't start exactly at the pregap, data gets moved into the next track's pregap, etc..

It would be nice to know if the d8 method gives the same offset correction on these discs, but I suppose it does.. there are propably multiple offset corrections needed, but we can only detect 2 of them (read+write)..

An 'intelligent checksum' would make more sense for these systems imho.. as Eidolon explained back then, you'll be ignoring the offset completely instead of assuming that our method of offset correction is the right one (I have no doubt that it is for PSX and Dreamcast, but I can't be sure about the other systems as a lot of dupe games don't have matching audio).. at least we could verify the integrity of the audio data then WITH matching checksums..

Maybe it would be possible to write an app that can determine the most likely original offset by comparing several dumps, for instance saturn ones? based on the following assumptions:

- No data gets moved outside of the track, unless the data starts exactly at pregap.
- If data gets moved outside of the track with the default offset correction, the amount of bytes outside of the track could indicate the additional offset correction needed (there are several psx discs where the last audio track has audio data up until the last byte.. if these bytes are also the last bytes on the cd, this means no data is cut off and it's a hint on what the proper offset correction should be).
- All tracks on a disc need the same offset correction (is the offset difference on saturn discs the same for all tracks? I remember that with IBM PC this usually isn't the case due to different mastering, different gap sizes etc)... this means that if we want matching audio offsets for all audio tracks, the pregaps should be ignored because the same games (but different system, version, region, etc) sometimes have different gaps?
- It is likely that one or more tracks start exactly at the pregap.

It's clear that offsets DO exist.. and that for PSX and DC they can be used as values to put the audio data back into the original position (usually exactly @ byte 352800 for one or more tracks on the discs).. I'm not sure if our method makes sense on the other systems though.

Are there any discs in the database that were released with multiple write offsets and where correcting both gives identical checksums for both discs (excluding dummy tracks)? Example: Doom for PSX.

The -30 is only to get the factory write offset, not the dumping value.. and we can't be sure about the -588.. just make sure you read it in d8 and the normal way without any subchannel reading. It should be ok then.

If the data track checksum is different then so is the volume serial number

Sorry dude, the "018200" and "018174" aren't related to the pregap size.. you should browse the first couple of sectors in normal mode and look for the same number (for instance "018200") as the px_d8 gives in sector 0..

The best way to figure out the sector correction is by using Truong's cdreader tool: …

Use 'View Sectors' to go to the first sector of the data track, then enable the 'Apply YB scrambling' box. This will scramble the header (the sync/header is now the same as the px_d8 output). Then you can determine the offset in sectors by looking for the sector with the same sync/header in cdreader.

It's not a real serial, it's just the creation date of the iso filesystem stored as a hash, so as far as I'm concerned they should only be used to tell apart dumps.

If it's the same as in the db then it must be correct smile

Sorry, but I said this before.. we don't need any volume serial numbers on unique entries.. only if there are several IBM PC dumps of the same game it makes sense to add these serials.


(9 replies, posted in General discussion)

Bleh.. he posted the same thread on no-intro.. Prototypes aren't released on original media so they're about as useful for our project as pirates


(6 replies, posted in Fixes & additions)

There's 3 different namings for this game in the database.. shouldn't there just be 1?

Bio Hazard (J) [SLPS-00222]
Bio Hazard (J) (v1.1) [SLPS-00222]
Biohazard 2 (J) (Disc 1) (Leon Disc) [SLPS-01222]
Biohazard 2 (J) (Disc 2) (Claire Disc) [SLPS-01223]
BioHazard 2 - Trial Edition (J) [SLPS-00999]
Biohazard 3 - Last Escape (J) (v1.0) [SLPS-02300]
BioHazard - Director's Cut (J) [SLPS-00998]


(3 replies, posted in General discussion)

They also never have any errors afaik, so no need to check I think I think these 4 sectors are definately not errors.. 2 of them xor to 0000 and both pairs are 5 sectors distance, this is common for libcrypt.. I think emulators don't circumvent libcrypt but it could very well be that there's an anti modchip protection that kicks in directly and also a libcrypt protection that doesn't work directly but only ingame..

How many sectors does japanese libcrypt contain? I suppose only these sectors contain protection?:

MSF: 09:38:58 Q-Data: 41 01 01 09 36 59 00 09 38 59 a3 ce
MSF: 09:38:63 Q-Data: 41 01 01 09 36 64 00 09 38 64 69 ac
MSF: 09:47:29 Q-Data: 41 01 01 29 45 30 00 09 47 30 7c fa
MSF: 09:47:34 Q-Data: 41 01 01 09 45 35 00 09 47 35 0f 08

could you add it again? hmm I deleted the libcrypt sectors information when I added the dump


(11 replies, posted in Fixes & additions)

Anti-modchip games are well known for having this protection, so it's pointless that every new dump gets set to 'unknown' anti-modchip status.. the same about all the libcrypt unknown games.. If there was a way for me to set all of them to 'no' after comparing to some protection lists I would have done it immediately, but it seems like Dremora is always too busy to do this neutral .. it's definately not a reason for you to mod your playstation..

I guess the data track offset fits in the same category of useless dump information, along with the NTSC libcrypt checking, 'error count' etc.. at the end none of this info is of any significance for the dump itself.. It just adds to the mess, because only a small portion of the dumps are actually checked..

Now dumpers are even checking the error count of PS2 cd images.. this madness has got to stop (nobody is ever instructed about these new fields.. Dremora just adds them and their usage isn't controlled).

I think I'm at the point where I no longer care about all the 'information' in the database.. only the datfile is important. To sum up the imho messy db fields:

- LibCrypt and Anti-modchip 'unknown' - nobody checks these anyway! The best thing you can do is just set them to 'No'.. and also make 'No' the default option when adding new games for anti-modchip games.. remove libcrypt for non-pal regions and demo's in current entries and for new dumps.. remove anti-modchip for non-ntsc games in current entries and for new dumps..
- Error count.. what's the use of including error count '0' anyway?? If a game has errors and you happen so notice, you can add it (also useful for SafeDisc games etc).. but there's absolutely no use in checking each new dumps - and of course nobody checks the old dumps anyway!
- Ring.. also no STANDARD on when (for which system) and how this info gets added.. some dumpers add it for PSX games (I don't blame them, they don't know what they're supposed to do).
- Also the 'Added' and 'Modified' fields are really useless to the public.. they should be at least hidden for normal users imho.. and the 'Added' and 'Modified' fields should be merged (once a dump gets modified, the added field becomes invisible)..
- Some members insisted on having a 'Shared' button, but they aren't using it.. will they ever use it or is this another useless piece of info?

Just my $0,02


(11 replies, posted in Fixes & additions)

Thanks, but how come you aren't added as a dumper for a lot of these games? (Syphon Filter 2, Spyro, etc)


(1 replies, posted in General discussion)

Unfortunately for you this is not a download site.. we only list checksums (so people can make correct dumps of their discs).. if you want the download images, try snesorama or extreme-games.

Topic closed


(25 replies, posted in General discussion)

I also think it's a good idea to split Games and Demo discs into separate dats..