Hmmm....will look into all of those. we are working heavily on the next release.

You can verify your ROMS with a ROM manager like ClrMamePro. It does involve a few steps.

You need to download ClrMamePro. There are two versions available. An install version and also a standalone version. They work exactly the same so it's whatever you prefer.

Then you need to download the executable from the MAME main site (mamedev.org) under Downloads | Previous Releases (m37b5b.zip--it's a 32-bit executable and does NOT run on 64-bit PC's--time to fire up that old PC). Unpack the files, then run "mame.exe -listinfo > 36.dat" from a command prompt. 36.dat can be named anything really. This creates a DAT file for use with ClrMamePro. For 0.106 they changed the -listinfo parameter to -listxml but it's the same command.

Then you would need to follow one of the many tutorials out there that explain it much better and have well documented steps especially for MAME ROMS.

If a game works in one emulator doesn't mean it will work in the other. Like ADVMAME which is based on MAME 0.106 where as MAME4ALL is based on MAME 0.37b5. If you look at the Donkey Kong (dkong.zip) you'll see they are completely different ROM files and/or file names in the zip.

When you run the emulator it looks for those specific ROM files in the game set and if they don't exist it will crash. Also they can only run games specific to that version. For example MAME4ALL being an older version doesn't have Lunar Battle so I can NOT take the 0.106 ROM set of that game and run it with MAME4ALL because it doesn't even know that game exists.

EDIT: Just another bit of information that might help when verifying ROMS. A DAT file is a file that lists the exact ROM files each set needs to run a game. It will check every file in directories you specify looking for a match, even if it's named wrong it can match it up on the CRC value.

I don't know exactly what version it changed in but for MAME4ALL being older there's an option to support inverted CRC values. If that's not checked ClrMamePro reports missing files from 0.37b5. Back in the day they flagged 'No Dump' ROM files with the inverted CRC value. They don't do that anymore with newer versions.

You can also verify the ROM files for one game at a time too. With the command "mame -verifyroms game_name". (i.e. - mame -verifyroms dkong.zip). It will report any issues with the set. It's a pretty handy command for a quick and dirty check for the onesie-twosie files.

@mholgaten - that scraper sounds really handy. Will the CRC check be on the whole set? Like using TorrentZip on the game set zip file and comparing the CRC? Just zipping files alone depending on the utility will have different CRC's hence TorrentZip for a consistent CRC.

MAME files are specific and stick to the 8.3 naming rule with no spaces. They have to be named exactly what that build of MAME calls for.

Ok, that's really cool. I wonder if that can be simplified a little because it seems like it could get messy. There's a site (I don't think I can name it here) but they use TorrentZip that creates the same CRC for a zip file. If any of the files are off it will not be the same CRC obviously. That's how they create Torrents that are consistent for download when you join the hive. I think CRC32 checks are like 1 in 4 billion to duplicate and with multiple files in a zip I am sure it's higher. I think SHA-1 checks are theoretically infinite. Don't quote me on that.

Maybe you could check the CRC of the game set vs. each ROM file.

The other issue (I only really know MAME) is there's 3 types of zips. Split-Merge, Non-Merged and Merged. All are valid ways to run the games but one requires the parent set and/or possibly the BIOS files. The BIOS files can be included as part of a set or they can be separated out. My question is which way are files are being checked. If you're doing split-merge you need to look to the parent for part of the files unless you're doing merged sets then everything is contained in the one file. It seems like you have to set a standard so everyone is one the same page.

Split-merge = Parent/child relationship. All files in COMMON to a game and it's clones are contained in the parent game and the child game only contains files specific to it's version. You need the parent game with the child or if it's only the parent game then your good to go. (Most commonly used; smallest space usage).

Merged = All files needed to run a game in one zip. This includes all parent games and all clones. (Fewest files but you get all the games, clones, bootlegs, etc. whether you want them or not).

Non-Merged = Each game in one zip. All parent games and clones have there respective files to run a standalone game. (HUGE use of space doing it this way--my 0.37b5 set goes from about 2 or 3GB to around 15GB).

Then you still need the BIOS files which may or may not be part of the set. Like Metal Slug requires neogeo.zip in addition to the game files merged or un-merged with any of the set types.

I know most sites use split-merge on MAME ROMS because it's a much smaller footprint and obviously a smaller download. Then you can use a ROM Manager to make non-merged sets etc. if you want from the downloaded split-merge set.

Also I remember reading something about zero byte files and empty directories causing problems with the CRC but the TorrentZip creator was able to fix the issues I believe. It's actually a handy program for making consistent zips.

Yeah I was just throwing out the different ways they can be zipped and possible complications. The part I am not understanding is take for example the game 1942. There is 3 versions/sets 1942.zip, 1942a.zip and 1942b.zip. Now depending on which method you're using (split-merge, non-merged and merged) what exactly are you scanning for to match files? Any of these 3 methods are valid and will run the game but all 3 will have different files in the zip package.

1942.zip could contain all the files in a merged set (Set 1, Set 2 and Set 3) but alternately it could be spread across 3 files if you're using split-merge. What file (filename?) are you scanning to say whether a game set has all the files?

I personally use the non-merge because I only have a few hundred games which is pretty small (about 200MB) and I only want one game per file so when you see 1942b.zip it's one game and the parent file isn't needed because all needed ROM files to run the game are merged into one.

An alternative would be split-merge. If I wanted to play 1942b.zip (Set 3) with a split-merge set I would need 1942.zip (parent) AND 1942b.zip (child) for one game and it would list it as 2 games because it's a "by-product" of needing the parent file.

I might be missing the bigger picture but how are you going to scan ROM files that can be located in one or more zip files to verify if a set is complete? You would have to make an assumption, for this to work, that everyone is using split-merge or one of the other set types?

I hear what you're saying and I think it's going to be an awesome tool.

Most folks will probably be dumping split-merge sets (how they are downloaded on almost all sites as a whole set). If you run a verify to validate ROM files against split-merge sets as non-merge sets it will fail with missing files as the parent file will contain part of the ROM files.

Here's a pic that might help:

https://www.flickr.com/photos/58342955@N05/14197659441/

In split-merge the clone contains a SINGLE ROM which is ROM 6 in the example. If you're grouping as non-merge it will contain FIVE ROMS, ROM 1, ROM 2, ROM 3, ROM 4 and ROM 6. The kicker is the file name will be EXACTLY THE SAME but the scraper will fail the verify and report errors unless your scanning for a specific set type. One way (split-merge) has only one file in the zip package and the other way (non-merge) has 5 files in the zip package but both are the same game just a different set type. Remember the ROM files have to be grouped/zipped in one of the 3 methods and the names are specific for the set as well as the ROM files contained within.

The alternative as a merged set also poses a problem because it would list one file for all versions and variants as 1942.zip. If you scan for the non-merge set 1942a.zip it will fail because it doesn't exist. It's been merged with the parent file. Even though the game is there and will run fine but the scraper will report an error or download nothing because it thinks the game file doesn't exist.

I am close if I am missing your point on how it would work. This doesn't seem like it will work unless you go all in like you were saying and will be verifying all 3 set types.

Ok, well that makes sense. I suppose eventually you have to settle on one type only or implement all 3. It seems almost impossible to check for all 3 types now that I think of it due to the simple fact if you have a "conglomeration" of the 3 sets (some merged, some non-merged and some split) it would confuse the heck out of the scraper.

Unless the set type is chosen before scraping. A future feature! :)