I use clrmamepro to audit NES files with no success: the data file used is from Complete_(TOSEC-v2007-03-14_CM).zip, all nes files are marked unneeded. While I copy the data file which is from romcenter2.71, clrmamepro pops out an "Encounted an improper argument" error.

You need to turn on NES header support in Settings->Headers. And you should prefer datfiles in xml or clrmamepro format which already got the needed nes header reference in its datfileheader


Roman Scherzer

> You need to turn on NES header support in Settings->Headers. And you should
> prefer datfiles in xml or clrmamepro format which already got the needed nes
> header reference in its datfileheader
>
>
> Roman Scherzer
>
Turned on the NES header with the same result. the dat file begins as this:

clrmamepro (
name "Nintendo Famicom & Entertainment System - Games - [NES]"
description "Nintendo Famicom & Entertainment System - Games - [NES] (TOSEC-v2007-02-14)"
category "Nintendo Famicom & Entertainment System - Games - [NES]"
version 2007-02-14
author etabeta
)

game (
name "!Mario (2000-11-19)(Dokokalaki)(Jp)[h][Super Mario Bros.]"
description "!Mario (2000-11-19)(Dokokalaki)(Jp)[h][Super Mario Bros.]"
rom ( name "!Mario (2000-11-19)(Dokokalaki)(Jp)[h][Super Mario Bros.].nes" size 40976 crc 2e2bf112 md5 b1a0e41cfd30c1d61de3b7900232de59 )
)

maybe it is for some older version of clrmamepro. but I can't find a new xml format dat file for NES.

You have to ask the datfile author which checksums are listed in the datfile.
Including or excluding the header (excluding would be correct)....and then of course you have to know how your files look like at the moment (with or without headers).

It works perfectly if you have
a) a nes file with a nes header
b) turned on nes header support
c) a datfile which lists the files' checksums without header information and size for the headerless data

The tosec datfile looks like if it took the full file for checksum calculation...which means you need exactly the same file (= same header). A NES file looks usually like: a changeable header + unchangeable romdata. So it's not that clever to include the changeable header into the crc32 calculation....




Roman Scherzer

I had a look at the listed Mario file...

The checksum listed in the datfile is calculated with the header. So you need exactly this file. You don't need any header support in this case simply because the datfile doesn't support the headerless files.

So if you have exactly THIS file in your rompath with a different name, cmpro's name check will find and correct it. Of course the general storing method is used:

rompath\setname\file 1...file n for decompressed sets
rompath\setname.zip (.7z/.rar) for compressed sets

So maybe your rename issues were based on the fact that you're scanning decompressed files which you didn't store correctly.


Roman Scherzer

All the files I have are *.nes files since NES game normally contains only one file and is relatively small. I don't know of NES header info before so I did a few experiments.

I use nestopia's edit iNES header feature to change Battle City (1985-09-09)(Namco)(Jp).nes header info of NTSC to PAL and save it, then compare the saved to the original, only one byte was changed. So I think the nes file does have header info.

Then I calculated the md5 of Battle City (1985-09-09)(Namco)(Jp).nes and compare it to the game info of Tosec's dat:
game (
name "Battle City (1985-09-09)(Namco)(Jp)"
description "Battle City (1985-09-09)(Namco)(Jp)"
rom ( name "Battle City (1985-09-09)(Namco)(Jp).nes" size 24592 crc f599a07e md5 cd4fe2e78df0696dbe652f02c19541a1 )
)
Identical. The dat is built with header info. So the problem should be neither in the nes file nor the dat file.

Then I zipped the Battle City (1985-09-09)(Namco)(Jp).nes to Battle City (1985-09-09)(Namco)(Jp).zip. Scan shows the number of missing files decreases by one. So it seems that clrmamepro does not check any file out of zip to find missing roms.

You don't follow the official storing methods. If you work with not-compressed sets you need to store them in subfolders.

Again:

rompath\setname\file 1...file n for not archived sets (and in your case n = 1 since the sets all got only 1 rom)
rompath\setname.zip (.7z/.rar) for archived sets.

In your example datfile you got a set named
"!Mario (2000-11-19)(Dokokalaki)(Jp)[h][Super Mario Bros.]"
with a rom named
"!Mario (2000-11-19)(Dokokalaki)(Jp)[h][Super Mario Bros.].nes"

So you either put an archive in your rompath or you create a subfolder "!Mario (2000-11-19)(Dokokalaki)(Jp)[h][Super Mario Bros.]" in your rompath and you put the rom "!Mario (2000-11-19)(Dokokalaki)(Jp)[h][Super Mario Bros.].nes" into this subfolder.

Of course the rebuilder could do that for you automatically but the better way is to keep them compressed.


Roman Scherzer

You are right. I put all files into add path, ticked all fix options and did a new scan, then clrmamepro rebuilt all the recognized games automatically. Thank you.

To be picky: This is not rebuilding ;) It's fixmissing which takes the files from an addpath.
The rebuilder (prefered method) is using either drag'n drop into the scanner or using the rebuilder module.


> You are right. I put all files into add path, ticked all fix options and did a
> new scan, then clrmamepro rebuilt all the recognized games automatically. Thank
> you.
>



Roman Scherzer

> To be picky: This is not rebuilding ;) It's fixmissing which takes the files
> from an addpath.
> The rebuilder (prefered method) is using either drag'n drop into the scanner or
> using the rebuilder module.
>
Will they get the same result when the output directory is empty?

Not necessarily since they are totally different types of ways to add files.

The Rebuilder takes every file (or file in an archive) it a given sourcefolder (or drag'n drop or addpaths), matches its checksums against the database and creates any instance of the match in the destination with the correct name.

Fixmissing is toggled when a rom is not found and looks into rompath(s), backup folder and addpaths if it finds the missing file there. The quick lookup is done by only looking at the correct setname (or clone/parent setname). So fixmissing most likely won't find the file if it got a completely different setname (unless you got an extra fixmissing option enabled which will check each file...but this will slow down the scanning process).

So the prefered method is to use the rebuilder to add files to the collection.


Roman Scherzer

Thank you for the explanation!