Redump Forum — Adding extra information to DATs

Re: Adding extra information to DATs

null@example.com (GBK666) — Fri, 20 Aug 2010 12:58:47 +0000

maybe you should work together with wickerwolf and his emu x application and maybe also with me and my timeless-gaming.com website database project

Re: Adding extra information to DATs

null@example.com (Macarro) — Fri, 20 Aug 2010 07:13:46 +0000

Yes, I also have the same idea yesterday just before I went to bed. I'll try to check if there are games with the same CRC in the first track but I think I'm going to use the sum of all the CRCs because I want to be sure about the singularity of the key.

Re: Adding extra information to DATs

null@example.com (velocity37) — Thu, 19 Aug 2010 23:48:16 +0000

Ack, I just thought of something that destroys my idea. If an entry is deleted, everything will be shifted. You can still work with the idea of creating your own indexes, though, it just won't be perfect.

One that I can think of off of the top of my head that definitely won't have any collisions is "(sum of track filesizes)_(sum of track CRC32s)". This will survive name changes (so long as you exclude the CUE) but not hash changes. It'll still be a lot better than using track 1 hashes, though.

Come to think of it, that would be an incredibly efficient way to detect dupes in the db.

Re: Adding extra information to DATs

null@example.com (Macarro) — Thu, 19 Aug 2010 21:15:04 +0000

Thanks, velocity37. I'll check it this weekend, it will be fast and convenient.

Re: Adding extra information to DATs

null@example.com (velocity37) — Thu, 19 Aug 2010 19:37:08 +0000

As far as I can tell, the entries in each DAT are sorted chronologically. The topmost game in each DAT is the first dumped, with the latest dumps being at the bottom. Presumably the DATs are generated by the server going through an ascending autonumber field in the database.

It would be trivial to add an index to each entry based on its position in the DAT. All you'd have to do is go through the file line by line and enumerate an integer for each entry, inserting an additional field like to your liking.

Re: Adding extra information to DATs

null@example.com (Macarro) — Thu, 19 Aug 2010 18:53:44 +0000

I convert the DAT file to XML using DatUtil because I prefer this format to work on it. CRCs are right but there is a CRC for each track of the original disc. I would like to have just a single key.

Thanks to your post I'm using right now the CRC32 of the first track and everything works fine but I still have to check if there are games with the same CRC32 on that first track. Maybe there are games with the same game code but different audio tracks...

Regards.

Re: Adding extra information to DATs

null@example.com (HwitVlf) — Wed, 18 Aug 2010 23:05:35 +0000

The database you are working on is a huge undertaking! I hope it goes well since the info would be great to have.

Redump's dat files do include the CRC32s for each track. Maybe you are running the dat files through a converter of some sort that is stripping some of the the information? I know RomCenter strips everything except the name, size and crc32 when you 'import' Redump's dat file.

Adding extra information to DATs

null@example.com (Macarro) — Wed, 18 Aug 2010 16:21:39 +0000

I've been working in a personal project about extra material for games (screenshots, covers*, savegames, etc...) for a while. I store all the extra material renamed to an unique alias for each game extracted from the DAT files. This way I can forget problems related to name changes, this kind of works if done by projects like yours.

For MAME I'm using standard 8 letter alias and for No-Intro games I'm using ROM's CRC32. Unfortunately I've noticed you don't store this kind of information in your DATs. Could you please add this information to the DATs; you already have Disc number id in your online database wich will be perfect; it shouldn't be too difficult (I think) and it will help a lot projects like mine.

Here are some examples of my current progresses (maybe the project will be made public someday but it still needs a lot of work to be done):

Kind regards and thanks in advance.