Little tool to scan and rebuild MAME (https://www.mamedev.org/) machine sets.
(c) 2022 - 2024 Roman Scherzer
This software is freeware.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
For (c) and licence information of the used 3rd party tools, please refer to the bottom of this document.
Another clrmame?
Well, actually you might know that I started clrmame(pro) in 1997. Back then the MAME world was different, the C++ world was different. clrmamepro grew over decades while MAME added things like using crc32, md5, sha1, merge modes, chds, devices, xml and so on. And then there were other projects which also wanted to use clrmamepro for their purposes and so lots of requests were added.
The downside of this: Maintaining the code is pretty tough. I'm pretty bored looking at that old code basis, so it is time for something new. It feels a bit like 1997 again, code something for me, for fun. It's fun again to see that 'modern' C++ and 3rd party tools make life way easier. Less options, faster, no MS Windows specific coding, complete new ideas how to keep data in memory or how to handle different merge modes. Maybe some people will enjoy it as much as I do.
For now, the scanner and rebuilder focus is on the core, not the UI. It's fine for using them on let's say one or two setups which more or less cover the use cases of MAME, i.e. MAME's -listxml and MAME's -listsoftware machine collections. They can be handled rather conveniently with the UI versions.
A real profiler which gives you better overview over several setups is planned.
So, if you're not bored yet, read on.
You as the user are responsible what you do, especially when it comes to removal of files or enabled fix options. If you use a wrong setup and e.g. scan folders on your system which have nothing to do with the files from the loaded xml holding the machine definitions, they are marked as unneeded and get removed.
You use this software on your own risk. If you don't use the program in a right way, the chance of data loss is given. I highly advice you to double check your settings before you do a fix operation or work with removal operations and of course: no backup - no mercy. I'm not responsible for any kind of data loss which may be caused by using this software.
There is no install wizard. You simply unpack the archive holding several files, including this readme. It's recommended to use an own folder to store the unpacked files. The folder should NOT be UAC protected (like e.g. C:\program files). Use e.g. D:\clrmame or something similar. The reason is that the programs create some folders or the settings.xml file where the exe files are placed. In an UAC protected folder you'd need administration rights for this.
The package currently contains two exe files. One for the UI version and one for the commandline version or clrmame (currently a rebuilder and Scanner collection). Each exe file can run on its own, the only shared files are the settings and the 7z.dll which is required for 7z archive support.
The tools are built for users which are familiar with MAME. You might read/hear terms which are commonly used in the MAME environment when it comes to storing machine sets. You should als be aware that playing/using machine sets in MAME is something else than auditing them. A machine which was scanned without errors doesn't necessarily work in MAME, e.g. due to missing or incomplete emulation. Also keep in mind that machines in MAME often need dependency machines (parent, bios and/or device machines).
I know clrmamepro for years or I don't care about further reading, so how can I quickly dive into the tools?
If you want an user interface, you run clrmameUI.exe. Currently you can select either a scan or a rebuilder module via a tab control at the top of the window.
You need to fill in some mandatory information:
Scanner:
Rebuilder: Run rebuilderUI.exe and fill in / select the following:
XML / EXE - you need to enter a full filename of the datfile you want to use or point to a MAME executable plus list its export function. e.g. "F:\MAMEEmu\mame.exe -listxml" or "c:\temp\266.xml"
Input Paths - you need to enter your input path. If you use multiple ones, separate them by ;
Output Path - you need to enter your output path.
Backup Path - you need to specify a backup folder.
Mode - specify your preferred merge mode for the output files
Compress - specify your preferred compression type for the output files
Hit the Rebuild button and wait till the result is shown.
The scanner runs through the specified rom and sample paths and checks the files in there. You should follow one of the following storing methods for your rom/sample machine sets:
rompath\machineName\rom file 1...n for decompressed sets
rompath\machineName.zip (or .7z) for compressed sets, where the archive holds
rom file 1..n`
In case of pattern usage (see below) you can use:
rompath\pattern\machineName\rom file 1...n for decompressed sets
rompath\pattern\machineName\machineName.zip (or .7z) for compressed sets,
where the archive holds rom file 1..n
Disk files (.chd) are always stored decompressed and also follow the storing
method rompath\machineName\disk file 1...n or
rompath\pattern\machineName\disk file 1...n
Same applies to the sample folder. If you don't specify a sample folder, samples won't be scanned.
The scanner can detect unneeded files, wrongly named files (case sensitive), missing files. Files can be rom files, sample files and chd files or the archive themselves holding rom and sample files. Wrong sized files or files with hash differences are handled as unneeded.
Unless you use the fix options, you can safely scan your folders. Nothing will be touched in that case.
Beware: Any file which does not represent a file specified in the loaded xml file is handled as unneeded. This is also valid for files from the xml which don't follow the storing method. However, the scanner is able to see if it is not in place and moves it there. Generally any unneeded file (which is not just wrongly placed) will be put to the backup folder.
The scan operation is divided into several phases where it e.g. scans the single files, collects information about preferred storing paths or updates the missing information. Finally a fixing phase (when enabled) is done and in the end it generates an output. Fixing is done in-place whereever possible. When a new machine set needs to be generated or a wrongly placed one is moved, the scanner tries to use the best place for it. This only plays a role when you use more than one rompaths or you use patterns.
The scanner creates an output report file in its scan folder which shows which issues were detected. In case of an enabled fix option, fixed problems are not listed, so the report will only hold remaining problems. A fixdat is also created in the fixdat folder. A fixdat is a xml file (which can be used inside the scanner/rebuilder or clrmamepro which only holds missing items. Typical use of such a file is to share it with other people and they help you to find the missing files for you. If you're using the UI version, the report file is visualized in a tree like output.
What can you do about missing files in the report? Well, first of all you need them somewhere. The scanner can't magically create missing files out of nothing. However, it can find files for you. The scanner by default looks up missing files inside your collection and it also looks in the specified backup folder if you got the "Incl. as Add Path" option enabled (--ba). So if a file was removed in the past and gets needed again in the future, it will be found. Additionally you can specify 'addpaths' which then will be included in the search for missing files. Files inside the backup and addpaths won't be removed if a match was found and added to the rompath.
The scanner has two scan modes. The 'new scan' loads the xml file and scans all machines in your paths. The second mode ('scan') tries to reuse scan information and limits the scan to the machines which had issues previously. The information can only be used if the settings and underlying xml data are the same. So a typical method when a new MAME is out, you do a full new scan (underlying xml data is new, so no choice anyhow). After that you may have some missing files here and there. If you want to scan again, you can use the second scan method and it will be way faster since it will only rescan the machines which had problems before.
The rebuilder analyzes each file (or file in an archive) in the input folder and tries to match each file's hash/size against the loaded database. Each found match (there can be multiple, think e.g. of a file which is shared by 10 machines) will be added to the output folder. There it uses the correct file name and machine name. Optionally, rebuilt files (and empty folders) are removed from the input folder. If your input folder holds an archive with an archive or chd inside, this inner archive is unpacked to your temporary folder. Such temporary files are removed at the end of a rebuilding process. By default the system's temporary folder is used. You can alter the temporary folder by modifying the "TempFolder" entry in settings.xml. This can be very useful if your system's temporary folder is on a slower disk. Selecting a custom temporary folder can have a positive effect on rebuilding speed.
By default, the rebuilder matches files by crc32/sha1 and size. There is an option (-s, --sha1) which allows you to select between no sha1, input, output and both sha1 checks. Enabling one sha1 mode is of course slower since it needs additional time for decompressing the archived data and the actual hash calculation. Surely it's more accurate. In case there are different sha1 values for one crc32 specified in the datfile and you disabled the input sha1 check, it will take the sha1 value into account, too.
This rebuilder is also able to rebuild CHD files (from version 3 onwards). For such files, the sha1 information from the CHD header is used for a match.
If you already have an existing archive/folder in the destination, the matched file is added but only if the file itself does not exist there. If there is an existing file but it does not match the right hash, this existing file is moved to the backup folder and the found match replaces it in the rebuilder destination. The backup folder needs to be specified.
This rebuilder can also identify source archives which already match an output machine completely. If the destination does not exist yet, such archives are copied directly.
The rebuilder runs through various phases. First it loads the datfile, checks source/destination paths for existance and builds merge mode views. Then it runs through the input folder. Be patient, this can take some time depending, especially if you scan lots of files. After that the output is checked. If no output exists or contains not many files, this should be very fast. An optimize phase is next and -if possible- the rebuilder then copies archives which can be copied directly. Finally, the actual rebuild is done and in the end a cleaning step is performed.
The following commandline options are used in the scanner and the rebuilder.
-x, --xml: Here you specify your used xml file which holds your databasis. This option is mandatory. See below for the supported types of XML files.
--bp, --backuppath A backup folder which is used in case when an output file already exists and differs from the one which will replace it. The existing file will be put in the backup folder. There it uses a similar path as in the output and it uses the same storage method (compressed or plain file). For the scanner, unneeded files which are not part of the loaded data will also be placed in the backup folder and during the scan. The backup folder is also scanned (but not touched) for possible fixing of missing files in the rompaths.
-m, --mode: Your preferred output merge mode. See below what the 3 modes are. This is an optional setting, default value is split. You can use split, full or standalone.
-p, --pattern: With this option you can specify an output pattern. Basically a path information which is put in between the output folder and the machine name. See below for examples.
-f, --filter: Here you can specify a regular expression on the machine name. When you prefix your filter with "xp:" you can also use an xpath expression to filter on anything inside the xml. You only need to care that your xpath selects a machine node in the end. In general, only matching entries from the loaded xml will then taken into account during rebuild. This is optional and no filter is the default value. Use a prefix of "file:" and you can list a textfile path which holds single entries (one per row) to limit your entries.
-l, --loglevel: Specify the detail level of the output. By default this is set to info. You can use err, warn, info or trace where the latter one additionally lists source file and rebuild information. info shows you a little progress bar here and there and gives you some updates when reading folders. If you redirect your ouput, progress bars and updating file counts are not visible.
To use the scanner, you need to use the "scan" keyword.
The scanner allows the following additional commandline parameters:
--rp, --rompath The path(s) where you store your roms and disks (chds). This is a required option. Rompaths have to exist, can't be a subpath of rom/sample/backup or addpaths.
--sp, --samplepath The path(s) where you store your samples. If not specified, samples are not scanned and not reported as missing. Multiple sample paths can be separated by semicolon (;). Machines inside the sample path follow the same storing rules (merge mode, placement) as in roms in the rompaths). Samplepaths can't be a subpath of rom/sample/backup or addpaths.
--ap, --addpath An optional setting where you can specify one or more paths which are used to find missing items from your rompaths. Addpaths are not touched, so a found matching item is not removed but copied/added to your rompath. Addpaths can't be a subpath of rom/sample/backup or addpaths.
-s, --sha1: For the scanner this is only a flag and when set, files are not only matched by crc32 and size but also by sha1. This usually requires a decompression of archived files to memory to calculate the sha1 hash on the data which in the end results in a slower scan operation.
-n, --new: When setting this flag, the scanner will always do a new scan, i.e. it scans all files in the paths and not only the ones which had an issue in a previous scan. A new scan is also done if no previous data is available, even if this flag is not set.
--fm, --filtermode: Your preferred filtermode. It specifies how machines which do not matched your filter expression are handled. By default this value is set to soft. You can use soft or hard. In soft mode, such unmatched machines are simply ignored. In hard mode, they are marked as unneeded.
--fix: Setting this flag will enable the actual fixing phase after the scan. If not specified, no files will be altered, moved or even deleted.
--um, --unneededmask: If you want to ignore specific files which are found as unneeded, you can use a regular expression here to skip such files.
--ba, --backupasaddpath: If enabled, the backup folder is also searched for missing entries (like add paths).
--ar, --addpathremove: If enabled, files which can be added to your rompath via addpaths (or backup, see --ba) will be removed. This refers to all matching files. If there is a matching file (no matter if it is used for fill in a missing file in the rompath or it already exists there) in the add/backup paths, it will be removed from its origin (add/backup path). Removal of files is only done when --fix is enabled, too.
To use the rebuilder, you need to use the "rebuild" keyword.
The rebuilder allows the following additional commandline parameters:
-i, --input: The rebuilder input folder(s). This/These folder(s) are checked for matching data. This option is mandatory and the folder(s) has/have to exist. Multiple paths need to be separated by semicolon (;).
-o, --output: The rebuilder output folder. In this folder, the matched data is copied/moved to. This option is mandatory. If the folder does not exist, it will be created. Note: When using -r, --recursive, the rebuilder output path can't be a subfolder of any of the rebuilder input path(s).
-c, --compress: This defines your preferred output compression method. This is an optional setting. Default is zip which keeps your files in zip archives. You can use zip, rezip, 7z or none. The latter one would keep your machines decompressed. rezip will always recompress the destination files and a direct copy of archives is not performed.
-d, --delete: With this option, rebuilt input files are removed. Be warned, they are gone! If the last file from an input archive or folder is removed, this archive/folder is also removed. Deletion is optional and disabled by default.
-s, --sha1: This would turn on or off additional sha1 matching of input and/or output files. Enabling it will be slower but more accurate. Default is input. You can use none to turn on simple crc32/size checks, input to do sha1 checks on the input file only, output to do sha1 checks on a possibly existing output file only and both which is identical to input and output. -s none is the fastest mode but keep in mind, depending on the files you're scanning, you may run into crc32 matches where in fact the sha1 would not match.
-r, --recursive: Turn this on if you want to run through your input folder and all of its subfolders.
-u, --uselinks Default is none. hard or sym are possible other values. Turn this on if you want to generate a filesystem hard or sym link instead doing a file copy operation. This takes place when copying archives 1:1, copying chds or copying single unpacked files from a source to the target. Keep in mind that there are limitations to the use of links in general and based on its type. This includes volume restrictions and access rights.
Currently three types of xml files are supported:
MAME -listxml XML output which holds machines (devices, bios) with roms, disks and samples.
MAME -listsoftware XML output which holds a software list collection, i.e. several machines with roms and disks for several software lists (e.g. a2600 machines, c64 machines and so on)
MAME software list XML. Such files can typcially be found in MAME's hash folder. They hold machines with roms and disks for one specific software list.
You can create a xml file by running MAME from the commandline interpreter and
redirect its output, e.g. mame.exe -listxml >266.xml.
The UI versions also support specifying a binary plus the export parameter
directly, so you can e.g. enter c:\mame\mame.exe -listsoftware in the
scanner or rebuilder xml input field.
When loading an input file you might see some warnings. For a standard MAME -listxml you e.g. see sample specific warnings. It's mainly about sample relationships from machines to a sample parent machine which is not available in the XML. Such sample-only sets are generated automatically so that the assignment is correct again. Similar warnings exist for the use of samples which aren't available in the sample parent set. This is also fixed internally.
The four things you need to specify are
Scanner:
Rebuilder:
Examples:
Load a MAME -listxml xml and scan from f:\roms:
clrmame.exe scan -x e:\MAME\244.xml -rp f:\roms -bp c:\backup
Load a MAME -listxml xml and scan and fix all issues from f:\roms and f:\samples
clrmame.exe scan -x e:\MAME\244.xml -rp f:\roms -sp f:\samples --fix -bp c:\backup
Load a MAME software list xml and rebuild from C:\Users\FooBar\Downloads to
f:\softwarelists\a2600_cas:
clrmame.exe rebuild -x e:\MAME\hash\a2600_cass.xml -i C:\Users\FooBar\Downloads -o f:\softwarelists\a2600_cass -bp c:\temp
Load a MAME -listxml xml and rebuild from f:\roms and all its subfolders to
f:\mame\roms:
clrmame.exe rebuild -x e:\MAME\244.xml -r -i f:\roms -o f:\mame\roms -bp c:\temp
Load a MAME -listxml xml and rebuild from f:\roms and all its subfolders to
f:\mame\roms and remove all rebuilt files:
clrmame.exe rebuild -x e:\MAME\244.xml -r -i f:\roms -o f:\mame\roms -d -bp c:\temp
Rebuilding is more or less a copy operation of files. If we talk about CHDs, we even talk about huge files. If your input and output folders are on the same ssd/hd, you will create pretty much I/O traffic. Ever tried copying (not moving) a multi GB file on one and the same hd? It usually crawls. So be aware of this before you try to rebuild a complete MAME collection from one folder to another.
Scanner speed can differ. It depends on how many files you have, which media you use to store data and of course your memory/cpu power. Keep in mind that e.g. for a current MAME the scanner has to check over roughly 40000 files. A modern system can keep a full scan in diskcache so that a second run will be way faster than an initial one.
For the rebuilder you can define how the output should be stored. Either compressed (currently as zip) or decompressed as files and folders.
Create decompressed output: -c none
Create zip archives: -c zip
Create 7z archives: -c 7z
Alway recompress zip archives: -c rezip
The scanner determines the compression mode by looking at your existing collection. It sees if you use decompressed, zip or 7z machines and uses this as its default. If no automatic determination is possible, it uses zip.
There is another option to modify the output by defining some patterns which
can be used to add additional folders to the output: -p sub1/sub2/sub3
This will add three level of sub folders to the given rebuilder output root or scanner rom/sample paths. Assuming you specified e:/temp as output folder, your machine sets will then be placed in e:/temp/sub1/sub2/sub3. While folder separator characters (/ ) are allowed, . or .. are not possible to be used here.
Way more interesting are predefined patterns which can be used with the -p command. You can use:
Example:
You want to split up your collection by manufacturer and by year:
-p #MANUFACTURER#/#YEAR#.
You want to split up your collection by something which is nearly identical to
clrmamepro's system default paths: -p #BIOSSPLIT#
If you're not happy with the prefix names (e.g. #device), you can alter them in the TypeNames elements in settings.xml
If you're loading a software list collection datfile, you automatically have a pattern of #SOFTLIST# active internally as top level. For scanning a sofware list collection it would mean that you don't need to specify a pattern and you only need to setup one rompath which points to the parent of the 3do_m2, 32x, a2600, etc. folders.
A merge mode defines how your stored mechanines are bundled. Some machines share a parent / clone relationship which is specified in the underlying datfile. Depending on the chosen mode, such machines can be merged together.
We differ between:
split (default) - Clone machines will only hold the files for the specific clone, while the shared files stay in the folder/archive of the parent machine. Parents or machines without any parent/clone relationship exist as they are. Indicator for a machine rom/disk to be part of the parent set is the merge attribute in the xml data. There can be clones which are 100% identical to their parent machine. In such a case the clone does not exist, only the parent does.
full - Clone archives/folders don't exist (so you only have them for the parent sets or sets which don't have a parent/clone relationship). The clones are kept inside the parent archive/folder, too. They however use subfolders in there, named after their machine name. So for example '10yard85' is a clone of '10yard'. Only '10yard' exists and inside the archive or folder you have the roms of the parent on top level and a subfolder named '10yard85' with the roms of the clone. Subfolders only exist in compressed sets. MAME can't detect files in decompressed sets, so for decompressed modes (-c none), the folders are flat, i.e. there are no clone subfolders. Be aware that in case of a hash collision (same filename within a parent/clone relationship but different hashes), you will only have one file. For CHDs which are always stored in a decompressed way, the same applies.
standalone - If you want to have one archive/folder which holds all needed files for a machine, this is the mode you want. It will not only include the parent files for a clone machine but also all other dependencies like bios and devices. Each are kept in subfolders named after their machine (device/bios) name (similar to the 10yard85 example above). If using decompressed sets, they are stored in a flat folder, i.e. no subfolders exist.
If you load a datfile which doesn't have any parent/clone relationships you can ignore the merge mode since it won't affect your output.
With the -f, --filter option you can filter the loaded XML to a subset of
machines. You define a regular expression which is matched against the
machines name. So for example if you only want to rebuild or scan "pacman", you
can simply add:
-f pacman
If you want to rebuild all machines which start with 'pac', you can write:
-f pac.*
For filtering only pacman and outrun, you'd write: -f pacman|outrun
Using xpath filterings gives you more power. To use it, you need to prefix the filter string with "xp:", otherwise it's the regular expression filter and your xpath expression needs to select software, machine or game elements.
Filtering a -listsoftwarelist output by only taking the Commodore software lists into account:
xp://softwarelist[contains(@description, 'Commodore')]/software
You love Commodore and Atari, well, you can filter on them:
xp://softwarelist[contains(@description, 'Atari') or contains(@description, 'Commodore')]/software
Filtering a -listxml output by selecting machines which have a baddump disk:
xp://machine[disk[@status='baddump']]
Filtering a -listxml output by selecting machines which have preliminary emulation status and Taito as manufacturer:
xp://machine[driver[@emulation='preliminary'] and manufacturer='Taito']
You can also use a textfile which holds one plain machine name per row to filter your xml. In this case you need to prefix the filter string with "file:"
With the filter mode, you define how unmatched machines are handled. By default, unmatched machines are ignored. The scanner won't take them into account when looking for fixable missing files either. The hard filter mode is different. Beware: When setting filter mode to hard, machines which do not match your filter are handled as unneeded in the scanner!
If you want to skip specific files/folders which are marked as unneeded you
can use unneeded masks. So if you e.g. want to ignore unneeded SL or CHD
folders in your rom and sample paths you can use
^.*\\(CHD|SL)$
settings.xml is created / loaded on startup which allows you to alter some settings. The UI also stores all kind of data here. You can change the default pre-strings for the -p command #TYPE# and #BIOSSPLIT# values. So e.g. you can change #default to 'StandardSets' or similar. Only valid path characters are allowed. Illegal values won't be accepted and the defaults are used again. You can also specify a temporary folder here which is used for temporary decompression purposes (e.g. when an archive is in an archive) or when data needs to get recompressed.
The scanner UI is a pretty simple and hopefully easy to use user interface which can be used if you don't want to spend time with the commandline version. It is divided in 3 main parts. The left side holds the options, the right side will be filled with the scan results in a tree like view. At the bottom messages are logged. Scanner result and log can be resized either by resizing the window or you can resize vertically them them by moving the mouse between
Options:
If you want to find out more about the meaning of the single options, check the
belonging commandline options description. Typically you have combo boxes which
allow entering rom/etc path names. Browse buttons to the right allow picking
files and folders from a dialog. If the browse button contains ... and a + it
supports picking multiple paths and it appends your selection to the already
existing one. A button labeled with a X clears the input. Holding SHIFT while
clicking removes all entries in the combo box. The combo boxes store
the last 5 previously selected unique inputs.
The XML / Exe input is a bit enhanced over the pure commandline -x option. It
supports the import of XML data from a MAME binary. So you can define e.g.
c:\mame\mame.exe -listxml or c:\mame\mame.exe -listsoftware and the scanner
tries to export the data to its export folder and uses the xml file from there.
It names the file after the crc32 of the exe file plus the used command. As
soon as the binary changes, it will run another export, otherwise it will load
the already exported xml data. You can safely remove files from the export
folder from time to time. If you're on Linux/Wine, then you can also use the
direct import (via -listxml or -listsoftware) from a Linux based MAME binary.
There is a wrapper script (wrapper.sh) included which is required to export
the data. You need to do a "chmod +x ./wrapper.sh" on it once.
Switching the XML/EXE combo box tries to restore the previously used option settings for now chosen xml/exe. So you can switch between some kind of profiles for different underlying xml data.
There is a small reset button at the top right of the XML/EXE combo section. This removes all entries from the XML list which don't exist anymore. Another reset button is at top of the paths secions. This clears all entries in the combo boxes below.
Log: The log list at the bottom lists all kind of information during the scan. Different colors are used to show the log levels. Errors (e.g. when a file operation fails) are marked red and at the end of the scan you also get the information if there were errors. You can alter the width of the columns. The log window has a context menu which allows you to enable/disable autoscrolling or copy the listed data to the clipboard.
Scan Result: The tree like output will be filled at the end of a scan (unless it was cancelled) and shows what issues were found during the scan. The output is sorted by software list + machine description. A context menu is available which gives you various option to show/hide information. You can decide what you want to see/hide: completely missing machines (so you don't have a single rom/disk/sample for it), partly issued machines (e.g. some files are missing or wrong named, etc), complete machines (100%, all files are there) and empty machines (MAME has a lot of machines which are more for internal MAME use and don't have any roms/disks/samples). You can also define what information is printed out on rom/disk/machine level. So for example you can list entries with the manufacturer or year, too. Or for roms you can also show size or sha1. Copying data to the clipboard is also available.
The rebuilder UI is a pretty simple and can be helpful if you prefer clicking instead of using a commandline. It is divided in 2 main parts. The upper side holds the options and at the bottom messages are logged. The rebuilder window can be resized where the log window will follow the horizontal and vertical resize.
Options:
If you want to find out more about the meaning of the single options, check the
belonging commandline options description. Typically you have combo boxes which
allow entering rom/etc path names. Browse buttons to the right allow picking
files and folders from a dialog. If the browse button contains ... and a + it
supports picking multiple paths and it appends your selection to the already
existing one. A button labeled with a X clears the input. Holding SHIFT while
clicking removes all entries in the combo box. The combo boxes store
the last 5 previously selected unique inputs.
The XML/EXE input is a bit enhanced over the pure commandline -x option. It
supports the import of XML data from a MAME binary. So you can define e.g.
c:\mame\mame.exe -listxml or c:\mame\mame.exe -listsoftware and the
rebuilder tries to export the data to its export folder and uses the xml file
from there. It names the file after the crc32 of the exe file plus the used
command. As soon as the binary changes, it will run another export, otherwise it
will load the already exported xml data. You can safely remove files from the
export folder from time to time. If you're on Linux/Wine, then you can also use the
direct import (via -listxml or -listsoftware) from a Linux based MAME binary.
There is a wrapper script (wrapper.sh) included which is required to export
the data. You need to do a "chmod +x ./wrapper.sh" on it once.
Switching the XML/EXE combo box tries to restore the previously used option settings for now chosen xml/exe. So you can switch between some kind of profiles for different underlying xml data.
Log: The log list at the bottom lists all kind of information during the scan. Different colors are used to show the log levels. Errors (e.g. when a file operation fails) are marked red and at the end of the scan you also get the information if there were errors. You can alter the width of the columns. The log window has a context menu which allows you to enable/disable autoscrolling or copy the listed data to the clipboard.
UI:
Core:
UI:
Core:
Core:
UI:
Combined rebuilder/scanner in one commandline and one UI version, let's name it clrmame for now
Core:
UI:
Core:
UI:
UI:
Core:
UI:
Core:
Besides of the -in my opinion- way better code, worth mentioning is:
On the other hand I of course understand if users start to moan "but it does not have feature x and y", "it does not support datfile type z" and so on. Yes this is the case but currently I don't want to implement requests which might be used by 1% of the users. Time will tell what comes next.
In this state of the project it is closed source, mainly due to the use of the full version licence of ZipArchive.
There are definetly plans for the future to get open source. Currently there are discussions about some licences (e.g. free version of ZipArchive is currently GPL)
Things I'm interested in:
Things I'm not interested in:
If you found something spooky, have problems, feel free to use the clrmamepro forum: https://www.emulab.it/forum/index.php?board=6.0
If you're totally happy with it, feel free to donate ;-) https://mamedev.emulab.it/clrmamepro/#donate
ZipArchive Library 4.6.9 Copyright (c) Tadeusz Dracz
Currently using the 'full version' licence. Making the product currently closed source.
Bit7z v4.0.8 Copyright (c) 2014-2024 Riccardo Ostani
https://github.com/rikyoz/bit7z/blob/master/LICENSE
MPLv2 License
You can obtain a copy of the MPLv2 License here https://mozilla.org/MPL/2.0/
7z.dll is used which is part of the 7-Zip program. 7-Zip is licensed under the GNU LGPL license. You can find 7-zip including source code at https://www.7-zip.org
CLI11 2.4.2 Copyright (c) 2017-2024 University of Cincinnati, developed by Henry Schreiner under NSF AWARD 1414736. All rights reserved.
https://github.com/CLIUtils/CLI11/blob/main/LICENSE
Redistribution and use in source and binary forms of CLI11, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
pugixml 1.14 Copyright (c) 2006-2024 Arseny Kapoulkine
https://github.com/zeux/pugixml/blob/master/LICENSE.md
MIT License (MIT) (see below)
SpdLog 1.15.0 Copyright (c) 2016-2024 Gabi Melman.
https://github.com/gabime/spdlog/blob/v1.x/LICENSE
MIT License (MIT)
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
CSHA1 2.1
100% free public domain implementation of the SHA-1 algorithm by Dominik Reichl dominik.reichl@t-online.de