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