Can someone please explain why cmpro says that epr-5211.74 is missing from zoom909.zip? According to the XML produced by mame, this is a "merge" file that can be found in buckrog.zip under the filename "5208.58".

When a mame audit is done on zoom909.zip, it passes audit. This file is not needed for correct mame operation, yet cmpro believes otherwise. This is one of many files that cmpro incorrectly lists as missing when doing scans.

If my romset is wrong, I am happy to add these "missing" files.... but if not, it would be really great if cmpro could be mofidied to correctly report missing files.

It's not a bug, it's simply based on the fact that clrmamepro doesn't use the 'merge' information since it was not accurate at all in the past. clrmamepro builds up valid and strict parent/clone relationships and it's also strict on that.
Each file has to be present, so if a parent/clone relationships uses different names for the same file (which shouldn't happen anyway to quote Nicola but it's used rather commonly, so blame the devs...), you need both files.
The discussion about these 'double-files' is as old as MAME and the majority of users like the cmpro way better since it gives you a more accurate look at the single splitup sets.



Roman Scherzer

Who says you need both files? The fact is, that that the file exists in the parent rom, and mame is able to determine that the parent rom contains the needed file. If you say that the accuracy of the filename is questionable, you would have to agree that the other sha1, md5, and crc data is not in doubt.

At the very least, cmpro should have an option to omit these erroneous "missing" files from its report. The files are not-needed for correct operation of mame. These files are just a waste of space.

>The files are not-needed for correct operation of mame. These files are just a waste of space.

See...and that's the point. We don't talk about correct operation of MAME here. Don't mix mame-loading-rom-accuracy with set-accuracy. MAME loads the files from nearly any place and doesn't care about mixed up sets at all. It loads the files where it finds them, even without caring about names.

If you like it that way, you won't need to check for romnames, romname case etc... in fact you can stick with mame's verifyroms check then. clrmamepro on the other side does strict checking on set definitions. This includes names, and to quote Nicola again: Different files-different names, equal files-equal names. If they're listed differently they're handled differently.
There are a lot other stuff which is effected in an equal manner....like these fake clones 'natodefa' etc.

Live with it. This behaviour won't change....and for the diskspace note: If you got several gigabyte of useless baddumps and not working files on your harddisk you don't have to care about 10 kbyte of double-files. Ask the MAMEdevs how they care about diskspace issues...


Roman Scherzer

Can you give an explanation for the way your software behaves for the following:
jdreddb.zip
candance.zip
calspeda.zip
vaportrp.zip
gauntd24.zip
wotwc.zip
galpanib.zip
natodefa.zip

Most (if not all of the above) contain files that have identical filenames, crc's, and sha1 values to the parent... and these files show the contents as "merge" files. Why do you create archives that contain these un-necessary files?

Already told you about the 'fake clones' in the last reply.

These are 100% identical clone sets (compared to the parent). And again clrmamepro goes for accuracy and the number of sets on your disk matches the number of sets (when using split or unmerged sets) listed in the datfile.


Roman Scherzer

> Already told you about the 'fake clones' in the last reply.

At least you are happy to admit that these files are not needed by calling them "fake clones". Another example of INCORRECTLY listing files as missing. You say you believe in accuracy? Why differentiate between the files in these "fake clones" and other parent relationships? If you say you have had this discussion many times over, perhaps there is some logic in what people have said and it may be worthwhile to add the ability to supress clrmamepro's erroneous reporting of missing files that are not at all missing?

Why is it that clrmamepro "knows better" than the emulators it is designed to support, and better than maws, and better than romcenter, and better than advscan .... It seems to know better than everyone else other than you Roman.

Yes, I am passionate about this, because I believe you are wrong on this point. By your own admission, this has been discussed in the past. Why not include an option to do what people want, and provide accurate scan reports that match with the emulators that your software was designed to support.

Working with datfiles always ends up in an interpreation of the given data. You can't compare the emulator romloading techniques with the plain data dump. If you do so in case of MAME e.g. you won't need any cleansing of sets, since MAME's loading mechanisms nearly don't care about anything. It loads files where it find files. That's the reason why it finds the mentioned double files. It doesn't care about names, it simply looks for checksums in the parent and clone sets. So in fact, MAME doesn't rely on the "merge" attribut at all, it was just added for the output of the database to support other utilities (it happened long after clrmamepro hit the place in 1997). Besides it was too often too wrong in the past, so I wonder how many people would have complained if clrmamepro actually used that flag. Telling me I should include what people want is really a joke, since what do you think clrmamepro is all about. In the last 9 years it grew because of all the included userrequests.

Mentioning MAWS is totally useless, since it's just a reporting www side which takes the -listxml output.

Rommanager is a MIRC script...skip that...ah..you fixed your post to Romcenter. Well...Romcenter uses Logiqx' datutil for a MAME import and that tool converts the -listxml output to a romcenter datfile format....Logiqx overwrites the names in that case. Besides you can't compare tools since they all do their interpretion of scanning files. All got the same output: Valid romsets which will be loaded in the chosen emulator.

MAME's database output is a mess. It lists files twice, it got wrong parent/clone relationships, it even lists set relationships (equally named roms with different checksums for example) which get killed when you fully merge them. It also got parentroms listed as nodump while the clone got a valid checksum, so when fully-merging them there is a chance to kill the good file as well.
There are countless things which are just plain wrong and can lead to problems and clrmamepro lists these stuff while importing (datfile errors-> show common / show all) and fixes them, so the final database is an interpretation of the original one. No way around it and people are happy because it prevents them from loosing files. Also MAMEDevs are happy since they detect the errors in their structures and usually they fix them for the next version.

The 'double-files', aka 'merge' tags which differ from their romname....MAME stands for accuracy and tries to keep the original PCB IC name as romname. Using the 'merge tag' name will kill the original filename. Of course you will gain a little bit diskspace but when it comes to MAME, diskspace doesn't matter. I did a quick check and you will gain 0.14% (yes zero dot one four not 14) for the current MAME without counting chds and using not-compressed values. Even MAMEDevs got different views on this, I keep it with Nicola Salmoria: "Different Files - Different Names, Equal Files - Equal Names" - i.e. the MAMEdevs on their side should already provide a correct naming.

To sum it up. The scans ARE accurate and keep the original chosen names and -when it comes to identical sets like natodefa- it keeps the original number of sets. Don't mix emulator-loading-mechanisms with rom-audit-mechanism. These are two different things. Although to keep another user happy, I may add an option which will optionally use some lazy merge option which relies on the mergetags for the double-files...but don't whine when MAME puts out wrong tag names again and you will end in wrong sets.


Roman Scherzer