Sorry, haven't been log in for quite a while.

Fortunately the download link has been updated already.

Concerning batch processing: You could probably use the win bat/cmd language to process all the files, but everytime I try to reactive my old dos skills it usally takes me longer to code around all the legency problems (odd syntax, long filenames, special characters etc) than do it manually or find better way to do.

In this case I used a dir printer to wirte down all the filepaths/names to a textfile and used excels' textprocessing features to build the commandlines.

Thx for the reply. Any hints how to use it?

Injector 0.1b

usage: injector.exe binfile [injectfile]

I assume 'binfile' is the file to be patched. But what's the injectfile? Where do I get it? Is it the same for all affected tracks?


Nevermind, found out my self

C:\tools>injector.exe "Lagnacure (Japan) (Track 1).bin"
Injector 0.1b

Injecting Lagnacure (Japan) (Track 1).bin...

fixing ecc.........(OK)

You've had 1 injection today... don't worry, it only hurts Neo.

No injectfile needed to fix the track, now matches the dat perfectly. One last question though. I moved and unpacked all non-matching files to a temp dir. I want to write a little batch to do the job in one stike. Is it save to run injector on non-affected files or should I sort them out beforehand?

I have been ón a hiatus from disc collecting for a while but now I back in business.

I scanned my old psx-collection (from last year) with the current datfile and noticed that most of  the "*(track 01).bin" files  won't match anymore, leaving me with gigs of incomplete dumps. I read up and undestand this is due to an unnecessary repair step in the old dumping guide with is now omitted. I wonder my self whether it is possible to 'auto-undo' those faulty fixes or if there is an other way to redeem my old files.


(3 replies, posted in General discussion)

To sum it up: It's a project to collect INFORMATION about proper (aka as best as it can be) preserved optical media and how to achieve them. Mainly due to legal issues, SHARING of the actual dumps is not part of the project, and you won't find a single game to download here. But there are some other ongoing projects providing bittorrent downloads. See the above links for further informations.


(2 replies, posted in General discussion)

The word 'dump' is usally used in the IT-language for an exact, untouched copy, e.g. a memory-dump is a exact copy of your computers RAM (or part of it) safed to a file for future reference.

When dealing with optical media, unfortunatly there are 1000s of ways to make a copy of it. You could just copy all the files from a cd to your hdd and install/run the game from there.

You could burn the files back to a blank disk and that could be considered as a copy as well. You could delete unneeded files, alter files to crack protections, edit media-files to reduce size etc and burn them back to a disc. Again, that could be considered as a 'copy', but in fact that would be a custom version of the source media, also called a 'Rip'.

To get an almost 1:1 copy, you could use your favorite burning-tool and create an image from your orginal disc. But since the devoloper of the cd-standard never though about the need for bit-identical copies, you will probably always get different results. Esp. when dealing with audio-tracks two users will never get the same result using normal image-tools. Google for 'pregap'.

This is where the redump-project comes in. They developed a guide to make sure you will get consistent results when backing up a disc.

You now might wonder with it's called 'REdump'. I don't for sure, but almost all discs has already been dumped in the past but must be dumped again (aka redump) from the original disc to fit the projects quality guidelines.

Sharing of the actual disc-images is not part of the project, but there are some side-projects providing bittorrent-downloads.

Haldrie wrote:

Hm...ok now that I think about it a little more I guess it wouldn't hurt. I'm just seeing way too much stuff around here with people wanting to make this more "emulator friendly" when that was never what this started out to be in the first place but yes I guess a CRC of the sbi file is possible since the site generates the checksums for the cue files as well. I just wish Dremora (or someone here that can program) would make something that can inject the SBI data in to a generated CloneCD sub file for people like me who want to burn the images and run them on the real system.

Indeed,  directly onthefly injection of  the subchannel-data when mounting/burning a dump would be the best solution, but until someone comes up with way to use them, we are stuck to the sbi-files and therefor should be referenced in the dats.

Just like some MAME versions ago, where you need to use some special files (xor tables) to break protection of CPS3 games. Ofcourse MAME had references to those files in it's internal database. Now that MAME can emulate the protection itself without the need to 'crack' it, the xor-tables arn't needed anymore and has been removed from the rom-db.

Haldrie wrote:

I can see where everyone is going with this and I think many people here have lost track of what this project's actual goal is. We are trying to collect accurate checksum data from disc based games for the purpose of making a database to be used to check games that people may get by whatever means. Emulation of the dumps SHOULD NOT be considered when thinking of new ways to improve the database only the accuracy of the information displayed here. The dats are there simply as a quick way to check many images at once and and the sbi files that are downloadable are generated on the site when dumpers post LibCrypt data using a script created for the site. The only modification to the cue files that are posted in the dumps are the file names and that can very easily be done without downloading a new cue.

Sorry, but I still don't understand the problem you have with this small and simple addition.

AFAIK, providing the subchannel-data where needed is already mandatory when submitting a dump of a protected game. Thus this data is already stored in the db and viewable on the disks' page. There would be no improvement/change to data and/or the dumping/submitting procedure at all, it just means to alter the 'create-dat-script' to include the crc-hashes of the sbi-files.

Above said, I can't think of a reason why incorperating the sbi in the dats would harm the goal of the project.

It too think including the 'official' crcs of the sbi-files would be a nice ideal. It won't hurt filesize and would make the dump more 'complete'. Maybe you always get different sbi's, but why not use the ones availble here as a reference? I think hardly anyone creates these files by theirself, I even don't know how to create them and don't care because I can get them here.

Having the sbi-files in the games' archive would also help to avoid confusion when a partiular game won't run in an emulator. Is it because it's copyprotected and therefor needs a sbi-file, or simply because the emulator doesn't support that game yet or maybe it does need a special config? Without any hint, you first have to look up infos about the game...

There are some ways to check a dump agains the database.

a) To quckly check files you dumped by yourself (using the guide), use some kind of hash-calculation-tool like 'hashtab' and then lookup the game in the db

b) When you downloaded a dump somewhere off the web in a compressed format, open up the archive in winrar. There's a colum with the crc-values of the contained files. Again, lookup the game in the db.

c) If you have a bunch of files to check, get the latest dat-file and let clrmame do the work for you.

d) When you got an archive with z7 and ape files in it, you first need to convert them back to the native bin/cue-format. Lookup (Un)pack-iso on google.

e) If you have a dump with just a single bin-file, you most likely need to split it off first. Somewhere here in the forum there's a guide how to convert images from various sources to redump ones.


(43 replies, posted in General discussion)

cHrI8l3 wrote:

topkat, idea is effective but it's deffinately too much job with editing those files, everything must be done manually, and you're loosing original file naming and cues, personally I would not want such mess... smile

Yupp, that's why I trashed that idea

Still a nice sideeffect was to be able to easily audit sets with clrmame without prioror (de)compressing forth and back. Hopefully someone will come up with a solution with the best of both worlds...


(43 replies, posted in General discussion)

I had some though about space-saving as well. Since there are quite a lot of redundancies across variuos dumps, merging ala MAMEs' parent/clone-relationships came to my mind. Finally I did a testrun with Ace/Air Combat.

First I renamed each track to it's crc32-hash, eg. 'cfbe8182.bin'. Then I looked at a recent mame-dat and created a corrosponding merged dat-file for the mentioned game. After that I altered the cue-files to reflect the crc-filenames. With its' 60+ tracks per version it was quite an insane task. As a last step, I fired up clrmame and rebuild a merged set with the created dat-file. After torrentzip, the final filesize was around 1/3 of the individual archives. Quite nice I think.


- Good compression ratio
- Shareable archives due to torrentzips' consistent filehashes
- Compression duration is quite small


- Manual editing/creating of merged dats
- Altered/New cue-files needed
- Manual hunt down identical files arcoss game version can be a insane task
- No emulator/frontend support yet?!
- Hard to tell files apart with only the crc-filenames


- What to do with files identical across multiple games (eg. the Capcom dummy track)
- How to handle multi disk games?

Sadly, due to the hugh amount of manual editing, I lost interest and deleted all my work. If anyone is interested, I could redo an example...

Quite impressive!

Assuming an approx. price per game of 5 €, I think it will end up in the 2k - 3k range. To much for the most of us, I think, sadly..


(25 replies, posted in General discussion)

Any progress in splitting up the dats?

I would really appriciate that. Like TOSEC, there should be dats for games, demo, coverdisc etc.  For the large sets like psx the games folder should be further divided into regions (usa, asia, pal). As my collections grows, messing around with 500+ gb of data in clrmame isn't fun.


(27 replies, posted in General discussion)

But Winrar for instance gives me different results on different system. Tested with same settings, but once on a  Turion Laptop with 2 Gig RAM and once with an old first gen. Pentium 4 with 512 MB. Torrentzip was specially developed with this aspect in mind, even an old Pentium 1 system should give you same results. I guess  I will do some tests to proof 7zip.

If someday Daemon Tools will support compressed audio, this would be the perfect solution.

Sotho Tal Ker wrote:

Those people should try it instead of praying. big_smile

It has been discussed several times, but sadly they are not so open minded for new ways....


(27 replies, posted in General discussion)

So, if 2 peole have the same dump and run it through packiso, they will get bit for bit identical output files no matter what computer/os they use? I'm a member of a well know retro gaming torrent tracker, and the 'masters' over their always pray that the only way for two people to get same checksums it to use torrentzip. Especially a 'torrent7zip' tool were called impossible due to 7zip not beeing able to produce identical files (and a too lousy source code to make it do so).

I noticed the recently added PS3-Dumps to the db and wonder what has happed with the allmighty supposed to be unbreakable copyprotection of bluray-disks. I mean, BD (aside from PS3) isn't big in the market yet, but you could already find db-rips/images everywhere around the net. So, what's happend? I think I missed something.


(2 replies, posted in General discussion)

nkay smile

Browsing through my old psx discs I found a pirated copy of rollcage, don't know anymore where I get it from. It's seems to be a professinal pressed disk with silver surface and printed label. It was packed in a standard jewelcase with the orignal (but resized) rollcage-artwork. If memories serves right, it worked on a unmodded psx, but I could test it on my unmodded ps2 if desired. Must be one of those mighty 'hong kong-silvers'. It also has a ntsc/pal-intro to switch between 50/60hz. Should we dump such releases as well?


(14 replies, posted in General discussion)

Not a language-related suggestion, but I didn't want to open a new thread:

I noticed that multi-disk-titles are now organized as one set in the dats, like:

Final Fantasy VII (E) (Disc 1) [SCES-00867]

I think it would be better to either remove the disk-number-tag completely:

Final Fantasy VII (E) [SCES-00867]

or replace it with a number-of-disc-tag:

Final Fantasy VII (E) (3 Disks) [SCES-00867]

What do you think?


(5 replies, posted in General discussion)

It was just a idea, but now I see the problem. Browsing the db I noticed some titles with same IDs, but actually diffenrent hashes, so even when two people seems to have the same game (with identical IDs), they actually may not be the same, but different releases, pressing, re-releases ot what ever...

Proper CD-Dumping and preserving is really a hell of work. Introduced back in the early 80's as audio-only media., the CDDA was never meant to be a data storage. Time passed by, and over and over again new extensions to the orginal specs were invented, cd-rom. cd-i. mixed mode, multisession and so on..

No to mention some crazy nonstardard formats like the jaguar-cd (multisession, with data encoded in audiotracks (!) ). (BTW, is the any known way to dump these?)


(5 replies, posted in General discussion)

I think the mods and/or the common dumpers should decide, but here my 2 cent about it:

In gerenal it's the best if you have a disk without any errors. But maybe someone has the same disk, but with different damaged tracks, so in the end we could compile a complete, errorfree enty in the db/dats.

Since there are not so many german dumpers, it could be difficult/expensive for them to get some german titles in perfect condition, in this case it could be helpful to dump a disk as far as you can, and somebody else does the missing tracks.

This could also helpfull for some of the exotic japanise/asian titles, which are even harder to get in a dumpable condition.

After collecting all the needed infos here in the forum, the disk could be saved in the db.

But, as mentions, some of the stuff/usual dumpers should decide.


(9 replies, posted in General discussion)

Sorry for the late replay. had some problem with my pc (IE constantly crashes when opening the forum sad ) Now using Firefox!

@ norman

Yupp your're right, it was a game with the 'Capcom Dummy Track' (silence), so I guess it would be different with normal tracks. But let's forget about this image vs dump stuff and do some work..

I made some new dumps of my PAL games:

Cybertiger [SLES-02370]
Army Man Operation Meltdown [SLES-02855]
Simpson Wrestling [SLES-03401]

What to do next?


(9 replies, posted in General discussion)

Ok, please get me right, I think this is a great project, esp. regarding the masses of rips (mp3, re-encoded waves and such crap) floating around...

I just though as theses images-formats are able to handle the latest copy protection, it should be possible to get exact dumps. But probably I'm complete wrong wink

I will now testrun your guide with some of my discs and when I 'mastered' the techniqes, I will send in some additions to the db!

One more question: Do the so called 'Platinum Editions' have the same Game-ID as the original releases? Are there any known differences between an original release and the later pubilshed 'Platinum Editon'? (aside from different artwork)

Eg. Resident Evil 2 (G) (Disc 1) (Leon Disc) [SLES-00974] is listed as Platinum, but I own the original release with the same SLES-No. Still I was able to get a dump matching the hashes of the listed Platinum.


(9 replies, posted in General discussion)

Thanks a lot for the infos!

Dremora wrote:

Yes, you're right, EDC is error detection code located in each sector, but some old games are missing it from Form 2 sectors, therefore it's not impossible to fully check them for errors. Moreover, if dump which is missing EDC in Form 2 sectors is written to the disc not in RAW mode, EDC will reappear, so dump made from such copies will have different checksums. These images are spread over the internet, so always check EDC status before asking for a patch wink

I guess you mean 'it's not possible to fully check them for errors' ?!

Is this the issue of the old mastering equicment from Sony producing EDC with wrong reported values? Somewhere I read about this topic and years ago everbody though that this was the copy protection, but as far as I understand this was just a manufacturing failure.

Dremora wrote:

Try dumping one and the same disc with audio tracks on two different drives in CCD, then compare checksums - you'll be surprised  For more info read here and in our dumping guide.

Your are talking about that offset-thing, right?!

OK, here is what I did:

As mentioned, I followed the dumping guide and dumped a game (with audio track) of my collcetion that was already in the DB  The hashes matched. After that i created an image using the latest Alcohol 120 %. Then I mounted both, the dump (via the cue-file) and the mds-image from Alcohol to a virtual drive. To compare both, I used a programm named CD-R Verifier. Here's the resault

- The Mounted dump and the mounted image seems to be identical
- Neither of the both match the orignal disc
- Burned back to a CD-R, it neither match the dump, nor the image and of cause not the orginal (maybe a burner and/or software issue)

As far as I know, the programm reads every bit of a given disc and calculates a checksum. So, if the checksums of the two discs match, the should be (bit)-identical.

Due to low on storage space I deleted the whole test files, but now I got a new hd and will repeat the tests again. Furthermore I will test if it is possible to get a proper dump for the mounted image along with some other tests...

BTW: Is there some kind of recommondation for a good cd-drive? ATM i'm using a LG GSA-4166B along with a small army of different other cd/dvd-readers and writers. Some older drives seems to have better have error corrections capatibilies than the LG. Is that Plextor Premium everbody used to talk about, really that good? It's still cost around 100 €, that's a little fortune for a 5 year old drive...


(9 replies, posted in General discussion)

Hello everybody!

I'm new to this project and want to contribute soon.

I have some PAL-Games lying around (original, of course) that arn't in the db yet.

Before I start dumping I have a few question:

1) What exactly is EDC? I guess it's something like "Error Detection Code'? As far as I know, the PSX doesn't use bad sectors for copy protection, what's the deal with EDC and PSX-Games?

2) There are some disc with a data track (track 1) and an audio-track (track 2) with an length of 03:32:00. The crc of the audio-track is 7976083e. The same track occurs among different games, e.g.

- Breath of Fire IV (E) [SLES-03552]
- Music - Music Creation for the PlayStation (E) [SLES-01356]
- Dino Crisis (E) [SLES-02207]

and some others. The track actually has no audio in it, it seems to be completly zero (silence). What's the propuse of this track?

3) Why not simply use some kind of image-format (like alcohol or clonecd or the like) instead of the tricky and time-consuming dumping-process? I dumped a game already in the db, and got matching hashes. Then I created an image using the lates DT of the same game. Afer that, I compared both, the dump and the image, and they seem to be identical. I you are interesset, I can post some details.

4) Before dumping I check discs with VSO Inspector, an freeware disc-testing app. On every discs, there are some errors in the first sectors (0 - 16). Is this the area where the copy protection is stored? Nevertheless I got perfect dumps with the same hashed as stated in the db, so i guess that's normal?!

Hope these question aren't too stupid smile