(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

http://redump.org/disc/3033 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..


(6 replies, posted in General discussion)

Well, you could just check and compare the first and the last audio sectors (including the first couple lead-out sectors) to the IsoBuster sector browser output if you wanna be sure no data is cut off.


(6 replies, posted in General discussion)

I don't understand the question..

Does every audio track have to end in silence?

I don't think so..

and overreading only applies to the first and last audio sectors.. if the read offset is larger than the write offset I don't think you'll run into any problems where data is cut off etc.

Dremora has to give you dumper status so you can use the New Disc menu.. if you're verifying existing entries you can just post them in the forums in a single thread.

themabus wrote:

but if Vigi says it's ok, should be ok smile

No, no.. I also have no idea what's going on.. I'm just saying that the +760 offset makes more sense than the other one.

themabus wrote:

Vigi, can you help, please?, i'm totally lost on this, how can this happen? is it like tracks are physicaly on variable distance, wouldn't audio collide with datatrack when offset is negative, and what's between them, when offset is positive?

I don't know what causes it.. I only know that I have some IBM discs that show +30 in D8 on the data track and a different offset with the old method.. so I felt it was safe to conclude that the data track didn't show the write offset, but only the read offset.

ghostgecko wrote:

Detection method B gives a gap of 5:42 for track 2, and method C stalls and fails to complete. Result is the same on two separate drives. I will try a different disc later and see if I have any luck.

Ok.. then it's best to stick with method A.. I guess EAC isn't having any luck detecting the gap because it's a dummy track.. If you want to verify the existing dump you can just dump it with the 0.00 gap and add 352800 bytes at the start using a hex editor (if you need any help let us know).


yes, it should say 02.00 for the second track as well.. have you tried selecting a different gap detection method?.. also, there's a chance you first have to enter the correct offset correction before pressing the 'detect gaps' button..

if none of this works, you could either try a different drive if you have one OR you could try some other discs with audio tracks and hope that EAC detects the correct gaps on those..

I'm not sure what to make of this either.. are you sure you executed px_d8 without the subchannel command? so 'px_d8 d 0 0'.. if not, there's a chance the sector offset is reported wrongly.. Also, you have to disable subchannel reading in cdtool when reading the sector.

So if both px_d8 and cdreader were used without subchannel reading and it still gives you the same scrambled header in sector -1, the maths of 270+588-98 (I suppose you're sure the read offset is correct?) = +760 is correct

And is 1.00 also the gap that perfectrip reports?

And you should notice the sync/header in the track02 pregap output.. it indicates the same offset of +760 (if you're sure about the +588) for all drives! So it's best to use this value for dumping.. I have no idea why the isobuster offset is this big, but it may be a mastering error.. have you tried cdtool instead to read the same sector? or try going back -73 first and then one more (I also don't think that d8 will ever give you a write offset that isn't a full number in samples, but let's wait what themabus has to say on this)

The only time d8 and the classic method don't provide identical results is when the data track doesn't have a write offset (it will only show the read offset with d8) but the audio does... this time you see a sync/header in the track02 pregap scrambled data output which normally doesn't show, so for some reason you'll also have to use the sync position this time, like in the d8 method..

I just hope there aren't any other discs with the same problems.. the write offset for those might have been calculated wrongly already (if the scrambled data output has a sync/header it's best to use its position instead of the amount of scrambled data).

Well.. usually it's just a cheaper version of the game, rereleased by another label..

The problem with these budget releases is that they usually have a data track that's remastered.. essentially it contains the same data as the original version, but usually with some small modifications (if the filedates are newer than the release date of the original I think it's better to wait for the original version dump and see if it can be verified).. I also have some budget releases and I got mixed results.. Mortal Kombat 3 had exactly the same data as the original version, so I was able to verify it.

Yeah.. it's a mess.. this is why I think it's best to avoid as much budget releases as possible - they just add to the mess.. I also hope it won't get much worse

The difference between alone in the dark 1 appears to be an offset difference of 3604 bytes (or +901 samples).. also, in my dump, because the track data is shifted forward compared to your dump, each track starts with data from the previous track in the pregap sad

Maybe our current methods just aren't able to detect the real write offset of these older IBM discs that show +0 write offset? hmm

ps. do your AITD1 tracks also start with a click?

Also, I noticed that your trilogy dump has the same audio sizes as your budget dump.. have you compared the 2? It looks like for the trilogy one they just took the complete track of the original release, including the gaps and then just mastered them without any extra gaps..

I'm wondering what the best way would be to deal with these differences.. the 'intelligent checksum' comes to mind again... the disadvantage would of course be that we wouldn't be able to identify the real reference point (the position of the data before any mastering, like in PSX), but I doubt my original edition discs are the ones providing the real reference point, because your budget discs don't have data entering into the next track's pregap.

themabus wrote:

i've uploaded a small (200kb) track here:

could somebody compare it with the same track from Vigi's versin, please?

I don't think any of my AITD discs have PRE (only wipeout and some others, and I mentioned it each time in the comments).. I compared my aitd2 start to your file and they are different.. your dump has some data in the pregap and mine doesn't (also the data after the pregap starts with different bytes etc).

On another note, my alone in the dark dumps also come from a square black trilogy box (I also had a separate copy of AITD1 and it was identical).. I don't think the naming that you used is appropriate, because they should be identical to the normal versions (strangely enough your dumps don't match mine).. so my box just contained 3 jewel cases with the normal games with normal covers etc.. I'm not sure about yours.

And I don't know why these 2 http://redump.org/disc/2883/ + http://redump.org/disc/1706/ don't match.. could you upload a sample (.bin compressed in rar plz) of one of the audio tracks so I can compare?

I think we will run into this problem more often with IBM (same data track crc + different audio track crc's).. so maybe an "intelligent checksum" that only calculates the checksum of the data start and end is a better method for comparing audio tracks after all.

Also, it's possible that IBM discs have a +0 write offset on the data track but a different write offset on the audio tracks, so plz be sure to use the classic offset detection method!


(2 replies, posted in General discussion)

Ok, this is just a random thought, but I think it would be a nice addition to the site..

If it's possible to make an index of crc32 values of each track, the audio tracks can be marked with a green flag or a green V or something like that if the track exists in other dumps..

If you move the cursor over a track it already lights up... maybe it's possible without too much work to link to a new page that has a list of all games that include this track (or perhaps all tracks with the same size in bytes to identify possible bad dumps with cut off data)?

A lot of games share audio tracks, so this would be a nice way for us to verify that a dump is correct by comparing them to other games.

With certain drives it's possible to dump the high density area of a gd-rom disc using the escape eject button. The low density area (the first 2 tracks which are always visible) can be dumped the normal way (without hotswapping) on any drive using the cd dumping guide found here: http://redump.org/guide/cddumping/ .

Software needed:

- dctools, audio trap disc


The high density area (sector 45000-549150) can be dumped as follows:

- insert the audio trap disc (a disc with a hacked TOC of 99 mins audio, burn it with CloneCD or Alcohol).
- use 'startstop.exe driveletter 1' to stop the drive motor.
- use a pin to press the escape eject button, so the tray will eject (or remove the drive cover).. insert the gdrom and gently push the tray back (or put the drive cover back on).
- Now extract sector 44990 (to be sure that the offset doesn't cut off any data) - 549150 using CDRWin 'Select Sectors' with the following settings: CD Audio (2352), File Format INTEL, Error Recovery Abort, Audio Speed 1x, Read Retry Count 1.
- When it's done extracting, use 'ice.exe dumpfile.bin 44990 > ice.log.txt' to descramble, split the dump data and get the ice log file.

If everything went well, the dump is ready to be submitted.

If you get any errors during extraction or if your drive fails to read the gdrom disc after swapping, then this most likely means that your drive isn't suitable for dumping gdrom discs. Read the next post to see if your drive which drives are supported/unsupported.


(39 replies, posted in General discussion)

Dremora wrote:
Vigi wrote:

Which track from which game would you like?

Mortal Kombat Gold, track 53, first 150 sectors. TIA smile

I borrowed this game and I deleted the dump, so I don't have it anymore hmm

but I still have another game with audio tracks (who wants to be a millionaire) and plextor + escape eject also works fine for gdroms (just tested) yikes:O


(39 replies, posted in General discussion)

Dremora wrote:

but I want to compare them with gaps from Vigi's dump.

Which track from which game would you like?


When I used the lite-on to dump these gdroms I could see where the audio started because of scrambled data.. also, the data track in the high density area contains information about the track sizes.. you can view the toc of a dump with a tool called gdlister.. just get the toolkit from this page:  http://homepage.ntlworld.com/menace-59/ … oolkit.rar

Also, I noticed StateS is mentioned on this page.. http://homepage.ntlworld.com/menace-59/gd-rom_stuff/ perhaps he could tell us if it's him or just a guy with the same name? tongue

Removing Anti-modchip protection status from Europe region and removing LibCrypt status from USA: Could this be done plz (also in New disc menu)?.. they are useless for these specific regions anyway, and it will make the database better organized. There are just too many libcrypt unknown entries for no reason.

And I also believe it's safe to just put all games with unknown libcrypt and anti-modchip protection to 'No', and get rid of the 'Unknown' flag completely because it's just a useless flag and it won't be changed anyway unless somebody redumps (they are expected to check anyway!, at least for libcrypt) so if a redump shows that the current entry is wrong we can always change it again!!.

And even though I noticed that all Europe dumps have been set to No anti-modchip, I still think it would be better to just remove this status for this region.

It has always annoyed me how new dumps always get added with anti-modchip 'unknown' for all regions if the list of anti-modchip games is well-documented (and we are not asking dumpers to check for anti-modchip so only the widely known games are set to 'Yes' anyway!!.. the rest (almost 500 dumps and only growing) will always remain in the db as 'unknown' as nobody checks them anyway.. and for what? the anti-modchip data is not subchannel like libcrypt so there's really no point in forcing someone to check every single game to see if it has anti-modchip protection)..

as for for libcrypt, there are >350 'not checked' dumps and they aren't on any list of known libcrypt games.. it would be better to just set them to 'No' until proven otherwise like in court where you're not guily until proven otherwise tongue..

please support this thread if you agree with me!