1
clrmame Discussion / Re: clrmame 0.7.0 released
« on: 28 April 2026, 17:28 »
ok found it...will send you a quick build for a check
- 15 May 2026, 14:26
- Welcome, Guest
News:
The new forum is online, hope you enjoy it!
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
clrmame Discussion / Re: clrmame 0.7.0 released
« on: 28 April 2026, 07:13 »
Perfect, thanks, I will look at it later today....
3
clrmame Discussion / Re: clrmame 0.7.0 released
« on: 28 April 2026, 06:16 »Older link showing. I change it to v070. Anyone see this. Just change it from your browser, Be ok.
The link should be fine....reload the page / cache cleaned
4
clrmame Discussion / Re: clrmame 0.7.0 released
« on: 28 April 2026, 06:14 »
I try to repeat that scenario...0.7.0 had no changes regarding to "missing but fixable" though....but surely I will have a look
..or do you have a repeatable scenario which can be zipped up ;-)
..or do you have a repeatable scenario which can be zipped up ;-)
5
clrmame Discussion / Re: clrmame 0.6.3
« on: 27 April 2026, 07:21 »
Well, if it lists missing files, you're missing files. It's easy as that :-)
If you have them in your collection, backuppath or addpath, they get added and won't appear anymore as missing.
If you'd have a complete clean MAME collection, no red or orange items are listed. You'd only see the root item "0.287 (mame0287)" and no sub items.
There are context menu options which allow to hide the orange and red entries though, but by default they are not enabled.
"Complete clean" means that no problems were found for your current selection of options. If you e.g. only scanned a few sets by using modifiers/filters, it does not necessaily mean you have all the files...it only means "for your selected filters - it's ok".
So, unless you're using the default options and nothing is shown in the tree...you're done...anything red/orange -> you have some issues.
If you have them in your collection, backuppath or addpath, they get added and won't appear anymore as missing.
If you'd have a complete clean MAME collection, no red or orange items are listed. You'd only see the root item "0.287 (mame0287)" and no sub items.
There are context menu options which allow to hide the orange and red entries though, but by default they are not enabled.
"Complete clean" means that no problems were found for your current selection of options. If you e.g. only scanned a few sets by using modifiers/filters, it does not necessaily mean you have all the files...it only means "for your selected filters - it's ok".
So, unless you're using the default options and nothing is shown in the tree...you're done...anything red/orange -> you have some issues.
6
clrmame Discussion / Re: clrmame 0.6.3
« on: 27 April 2026, 05:58 »
>The why is because I do not know what I am doing
well...the readme.md file explains all modules and what they do and what the options do and I hope the previous post already cleared some things up.
>I still get some warnings when I run scanner
Well, then open the warnings....click on the + symbol before the listed items to expand the tree and see what is wrong with the machines....
well...the readme.md file explains all modules and what they do and what the options do and I hope the previous post already cleared some things up.
>I still get some warnings when I run scanner
Well, then open the warnings....click on the + symbol before the listed items to expand the tree and see what is wrong with the machines....
7
clrmame Discussion / Re: clrmame 0.6.3
« on: 26 April 2026, 15:11 »
ok..let's start...with 2 minor things:
- clrmame 0.7.0 is out :-)
>and then creates a mame287.xml file
You don't need this. You can simply let clrmame's XML/EXE simply point to your mame.exe file. When you specify no additional parameters, -listxml is automatically used. The advantage is that you can simply reuse this setting when your mame binary gets updated.
Now what you did....
- The next step you're trying is to use the rebuilder to rebuild your 287 chd/roms update set to a new folder. Why? The output will be the same as the input after rebuilding.
- When you used the scanner, you used your old 286 collection as rompath and you scanned it with a 287 data basis...of course it will show you files with warnings since romsets change with each MAME version.
So let's start over:
Rebuilder: It takes anything valid from a given input and creates all matching (hash compare against currently loaded data) instances in the specified output. It does not produce fully complete sets. If one file is shared by like 1000 sets, you get 1000 sets with that file. They still may require more. Yes, the rebuilder can be used to add "an update pack" to an existing collection, but then the output should point to your existing collection. Mainly the rebuilder is used to convert data from one emulator to another, or to see what a bunch of messy folders have which can be reused and so on. If you use it as an adder, be sure that you're using the same data basis for scanner/rebuilder and the same merge mode.
Scanner: The scanner is the main module, it scans your roms and sample paths and is able to fix nearly every problem it finds. Surely it cannot magically create missing files out of nowhere, but you can use add paths and the backup path to make it look file files which it then automatically adds to the right place. So when you simply added your "287 update pack" files as an add path, you would simply run the scanner.
So, you should go with the scanner, define an addpath (it's in the modifiers tab), let the rompath point to your rompath(s), check which merge mode you prefer, keep fix issues disabled for now and hit scan.
Then take a look at the tree output. you can expand the items to see what is wrong with the files. If your update pack in your addpath is a good one, you shouldn't see any red X marked sets, the orange ! sets will most likely indicate missing but fixable files (fixable because it found the files in your add path).
When you enable the fix issues option and do another scan, it will try to fix all listed issues, i.e.
- rename wrong named archives/roms/disks
- unneeded files will be moved to backup
- missing but fixable files are copied from the addpaths and backup (optionally when incl. as add path is ticked)
- optionally matched files from addpath/backup are removed
Now imagine you'd have one folder where you always put your update packs and you'd use XML/Exe pointing to your mame binary, then updating mame is just one click the next time.
- clrmame 0.7.0 is out :-)
>and then creates a mame287.xml file
You don't need this. You can simply let clrmame's XML/EXE simply point to your mame.exe file. When you specify no additional parameters, -listxml is automatically used. The advantage is that you can simply reuse this setting when your mame binary gets updated.
Now what you did....
- The next step you're trying is to use the rebuilder to rebuild your 287 chd/roms update set to a new folder. Why? The output will be the same as the input after rebuilding.
- When you used the scanner, you used your old 286 collection as rompath and you scanned it with a 287 data basis...of course it will show you files with warnings since romsets change with each MAME version.
So let's start over:
Rebuilder: It takes anything valid from a given input and creates all matching (hash compare against currently loaded data) instances in the specified output. It does not produce fully complete sets. If one file is shared by like 1000 sets, you get 1000 sets with that file. They still may require more. Yes, the rebuilder can be used to add "an update pack" to an existing collection, but then the output should point to your existing collection. Mainly the rebuilder is used to convert data from one emulator to another, or to see what a bunch of messy folders have which can be reused and so on. If you use it as an adder, be sure that you're using the same data basis for scanner/rebuilder and the same merge mode.
Scanner: The scanner is the main module, it scans your roms and sample paths and is able to fix nearly every problem it finds. Surely it cannot magically create missing files out of nowhere, but you can use add paths and the backup path to make it look file files which it then automatically adds to the right place. So when you simply added your "287 update pack" files as an add path, you would simply run the scanner.
So, you should go with the scanner, define an addpath (it's in the modifiers tab), let the rompath point to your rompath(s), check which merge mode you prefer, keep fix issues disabled for now and hit scan.
Then take a look at the tree output. you can expand the items to see what is wrong with the files. If your update pack in your addpath is a good one, you shouldn't see any red X marked sets, the orange ! sets will most likely indicate missing but fixable files (fixable because it found the files in your add path).
When you enable the fix issues option and do another scan, it will try to fix all listed issues, i.e.
- rename wrong named archives/roms/disks
- unneeded files will be moved to backup
- missing but fixable files are copied from the addpaths and backup (optionally when incl. as add path is ticked)
- optionally matched files from addpath/backup are removed
Now imagine you'd have one folder where you always put your update packs and you'd use XML/Exe pointing to your mame binary, then updating mame is just one click the next time.
8
clrmame Discussion / Re: clrmame 0.7.0 released
« on: 25 April 2026, 13:04 »
DjDiabolik: erm..no, the link is correct and working...maybe you need to clean your cache....
Bad A. Billy: well, the mameworld post holds the download link and the link to the readme...that's enough :-)
Bad A. Billy: well, the mameworld post holds the download link and the link to the readme...that's enough :-)
9
clrmame Discussion / clrmame 0.7.1 released
« on: 24 April 2026, 15:51 »
2026-04-28 clrmame V0.7.1 released
https://mamedev.emulab.it/clrmamepro/binaries/clrmame_v071.zip
https://mamedev.emulab.it/clrmamepro/binaries/readme.html
fixing johnIV's finding regarding fix-missing...thanks John!
2026-04-24 clrmame V0.7.1 released
Core:
- fixed: dir2dat: fixed broken 'archive as files' option
- fixed: cmdline, not always load/save settings.xml from application folder
- fixed: cmdline, when using relative paths, they are not always relative to the current directory (cmdline version) or application folder (ui version)
- misc: rewrote wrong named machines fixing. Clearer handling should also sort out all known rare edge cases which were fixed. Also it reports all found instances of wrong named machines (e.g. chd folder and archive)
- misc: updated ZipArchive to 5.0.1/zlib-ng 2.3.3 zip operations are way faster
- misc: updated cli11 to 2.6.2
- misc: updated bit7z to 4.0.11
UI:
- misc: changed the way the tree gets refreshed, maybe this solves the rare "no tree" refreshing issue
https://mamedev.emulab.it/clrmamepro/binaries/clrmame_v071.zip
https://mamedev.emulab.it/clrmamepro/binaries/readme.html
fixing johnIV's finding regarding fix-missing...thanks John!
2026-04-24 clrmame V0.7.1 released
Core:
- fixed: dir2dat: fixed broken 'archive as files' option
- fixed: cmdline, not always load/save settings.xml from application folder
- fixed: cmdline, when using relative paths, they are not always relative to the current directory (cmdline version) or application folder (ui version)
- misc: rewrote wrong named machines fixing. Clearer handling should also sort out all known rare edge cases which were fixed. Also it reports all found instances of wrong named machines (e.g. chd folder and archive)
- misc: updated ZipArchive to 5.0.1/zlib-ng 2.3.3 zip operations are way faster
- misc: updated cli11 to 2.6.2
- misc: updated bit7z to 4.0.11
UI:
- misc: changed the way the tree gets refreshed, maybe this solves the rare "no tree" refreshing issue
10
clrmame Discussion / Re: Odd clrmamepro behavior - wrong named sets in Arcade64
« on: 04 April 2026, 15:00 »
You're welcome.
The general thing is that any file rom/chd file which doesn't appear in the loaded xml is "unneeded". So scanning some huge selection (like MAME) with a small dat (like arcade64) marks anything unneeded which is not part of arcade64....
Unknown sets are then also passed through a routine to see if this might just be a renamed set...which not necessarily be 100% right...(the new clrmame is a bit better there but there were some edge cases recently which still cause a bit of headache...).
So...better keep collections separated, don't try to mix
The general thing is that any file rom/chd file which doesn't appear in the loaded xml is "unneeded". So scanning some huge selection (like MAME) with a small dat (like arcade64) marks anything unneeded which is not part of arcade64....
Unknown sets are then also passed through a routine to see if this might just be a renamed set...which not necessarily be 100% right...(the new clrmame is a bit better there but there were some edge cases recently which still cause a bit of headache...).
So...better keep collections separated, don't try to mix
11
clrmame Discussion / Re: Odd clrmamepro behavior - wrong named sets in Arcade64
« on: 04 April 2026, 13:18 »
So it was confirmed that Arcade64 xml output is only a subset (arcade based, working, etc) of MAME's xml output
If you scan MAME rompaths with that subset, it will find sets which are "wrong named". Actually they are "unneeded" (coming from their name) but such sets are then checked if they might be just renamed. The heuristic checks the hashes, checks if the found matches and the rom count might indicate a wrong named set and reports that.
....and of course: you should switch to the new clrmame ;-)
If you scan MAME rompaths with that subset, it will find sets which are "wrong named". Actually they are "unneeded" (coming from their name) but such sets are then checked if they might be just renamed. The heuristic checks the hashes, checks if the found matches and the rom count might indicate a wrong named set and reports that.
....and of course: you should switch to the new clrmame ;-)
12
clrmame Discussion / Re: Odd clrmamepro behavior - wrong named sets in Arcade64
« on: 04 April 2026, 08:53 »
I've exported the arcade64 xml via -listxml from its exe...and I assume you used that export (or directly from its exe) in clrmamepro.
Now when I look at the rather small xml (well, I was expecting that since it only holds arcade stuff), I don't see machines like
25pacman
3super8
4roses
etc... but I do see
20pacgal
spk306us
cpokerpk
Since you have the first mentioned ones on you HD (from official MAME) but scan with a xml database which doesn't have them, clrmamepro checks if it's just a renamed set...and correctly reports them.
Question would be (and I've done that on the thread on the Mameworld forum) if it is wanted behaviour that Arcade64's xml output does not list such sets which official MAME lists....
Either way, mixing collections with different databasis is not a good idea.
Now when I look at the rather small xml (well, I was expecting that since it only holds arcade stuff), I don't see machines like
25pacman
3super8
4roses
etc... but I do see
20pacgal
spk306us
cpokerpk
Since you have the first mentioned ones on you HD (from official MAME) but scan with a xml database which doesn't have them, clrmamepro checks if it's just a renamed set...and correctly reports them.
Question would be (and I've done that on the thread on the Mameworld forum) if it is wanted behaviour that Arcade64's xml output does not list such sets which official MAME lists....
Either way, mixing collections with different databasis is not a good idea.
13
clrmame Discussion / End of month...where is a new release :-)
« on: 25 March 2026, 19:44 »
Well well well...you have to be a bit more patient, however it seems that some nice things happen:
- planning to change the way how wrong named machines are handled a bit which resolves some weird rare constellation problems plus reduces the needed code
- ZipArchive was updated to 5.0.0 which allows using zlib-ng instead zlib as basis for zip compression and some tests show some really great improvements. Just a quick rebuild with 'rezip' (3.20 gb of zip files, unpack files individually to temp, recompress (deflate, best) to a new folder) takes around 10:48 minutes on the test hd based system...with zlib-ng as basis this shrinks to 04:47 minutes.....
So....there are some things going on.....
- planning to change the way how wrong named machines are handled a bit which resolves some weird rare constellation problems plus reduces the needed code
- ZipArchive was updated to 5.0.0 which allows using zlib-ng instead zlib as basis for zip compression and some tests show some really great improvements. Just a quick rebuild with 'rezip' (3.20 gb of zip files, unpack files individually to temp, recompress (deflate, best) to a new folder) takes around 10:48 minutes on the test hd based system...with zlib-ng as basis this shrinks to 04:47 minutes.....
So....there are some things going on.....
14
clrmame Discussion / Re: Question clrmame 0.6.3 folder handling
« on: 17 March 2026, 17:23 »
Samples have no hashes provided in the datfile/mame -listxml output, so you can't rebuild them and fix missing won't either.
So you need to manually copy the sample set buckrog to buckrogn
So you need to manually copy the sample set buckrog to buckrogn
15
clrmame Discussion / Re: Question clrmame 0.6.3 folder handling
« on: 14 March 2026, 17:46 »
Samples: Samples are stored in samples paths, so they will be separate in any case from the rom archive. They do follow merge modes though, so if you use standalone sets, you will also use standalone sample sets. All official samples can be found on progetto's sample page. However, samples don't have hash values, so they can't be rebuilt or things like name check won't work. There are dats for samples out there with hashes, but I don't know if they have any parent/clone relationship mentioned.
So if you miss samples, you need to look out for sample sets which belong to the sample folder.
A "could not access (archive name) error" can be caused by several things. This is usually thrown when opening a e.g. zip archive fails. This may be that it is restrictly opened elsewhere or being scanned by virusscanner at that point in time and such 3rd party access simply blocks opening the file. Or it can be caused by bad archives. You will wonder how many bad structured archives are out there in the internet. If structures are bad it does not necessarily mean that you can't unpack the data successfully. So indeed a good thing is to re-compress them to a new archive which usually fixes such issues.
If you get randomly appearing "could not access" errors, I more think that other tasks (virusscanners, torrents, etc...) block access. Unlikely but possible is of course something beyond that like a flakey network connection (when using network drives), bad drivers, memory or disk corruption....but as I said...very unlikely.
....you might also check if reducing the used threads has an impact on your results. Maybe your system doesn't like too many parallel file access activity.
So if you miss samples, you need to look out for sample sets which belong to the sample folder.
A "could not access (archive name) error" can be caused by several things. This is usually thrown when opening a e.g. zip archive fails. This may be that it is restrictly opened elsewhere or being scanned by virusscanner at that point in time and such 3rd party access simply blocks opening the file. Or it can be caused by bad archives. You will wonder how many bad structured archives are out there in the internet. If structures are bad it does not necessarily mean that you can't unpack the data successfully. So indeed a good thing is to re-compress them to a new archive which usually fixes such issues.
If you get randomly appearing "could not access" errors, I more think that other tasks (virusscanners, torrents, etc...) block access. Unlikely but possible is of course something beyond that like a flakey network connection (when using network drives), bad drivers, memory or disk corruption....but as I said...very unlikely.
....you might also check if reducing the used threads has an impact on your results. Maybe your system doesn't like too many parallel file access activity.
16
clrmame Discussion / Re: Question clrmame 0.6.3 folder handling
« on: 05 March 2026, 20:10 »
yeah.....I had that once when during scan the window was completely covered by a different window. Actually no idea what is causing the missing redraw here....and actually I can't repeat it
Resizing the window a bit will redraw everything....maybe I add some forced redraw at the end of a scan or so...but as long as I can't repeat it....hard to say where this is coming from
Resizing the window a bit will redraw everything....maybe I add some forced redraw at the end of a scan or so...but as long as I can't repeat it....hard to say where this is coming from
17
clrmame Discussion / Re: Question clrmame 0.6.3 folder handling
« on: 05 March 2026, 08:42 »
if you have a setup where you have a folder for chds and one for the rom archives, you need to setup 2 rompaths like
c:\mame\roms;c:\mame\chds
If you have just one folder which holds subfolders for chds and also contains archives for the roms, you only need 1 rompath like
c:\mame\roms
Keep the storing method in mind: rompath\setname\file 1... file n and rompath\setname.zip (or .7z) holding file 1 ... file n.
Chds are stored decompressed (they are compressed containers on their own), so this follows the 1st method e.g. c:\mame\roms\area51\area51.chd
and roms are normally kept in archives, so this follows 2nd method: c:\mame\roms\area51.zip
Using patterns as described before is for more complex rompath setups....
The difference between standalone and nonmerged is actually that "standalone" is really a standalone representation of a set, i.e. you only need that one archive (and maybe chds) and can it with MAME. Nonmerged had that same idea nearly 30 years ago but in the meantime MAME added bios and device dependencies...so they are not included. For clrmame, I actually killed nonmerged before since it doesn't really make that much sense since it's something in the middle...not really standalone....but a MAMEDev convinced me to bring it back for some other purposes.....
c:\mame\roms;c:\mame\chds
If you have just one folder which holds subfolders for chds and also contains archives for the roms, you only need 1 rompath like
c:\mame\roms
Keep the storing method in mind: rompath\setname\file 1... file n and rompath\setname.zip (or .7z) holding file 1 ... file n.
Chds are stored decompressed (they are compressed containers on their own), so this follows the 1st method e.g. c:\mame\roms\area51\area51.chd
and roms are normally kept in archives, so this follows 2nd method: c:\mame\roms\area51.zip
Using patterns as described before is for more complex rompath setups....
The difference between standalone and nonmerged is actually that "standalone" is really a standalone representation of a set, i.e. you only need that one archive (and maybe chds) and can it with MAME. Nonmerged had that same idea nearly 30 years ago
but in the meantime MAME added bios and device dependencies...so they are not included. For clrmame, I actually killed nonmerged before since it doesn't really make that much sense since it's something in the middle...not really standalone....but a MAMEDev convinced me to bring it back for some other purposes.....18
clrmame Discussion / Another visitor, stay a while....
« on: 04 March 2026, 20:34 »
Well...pretty busy with real life work at the moment, so not really much development on clrmame at the moment.
I've fixed some commandline based relative path issues and got 2 bugfinder's machine name fixing issues on the list.....plus some 3rdparty libs update...nothing really with high prio or breaking stuff...
Hopefully I find some time in the next weeks to switch to new Visual Studio, clean up code, etc...profiler....etc.....etc...open source...etc..etc...
While being busy I saw https://www.commodore.net/category/c64-ultimate and have to say...wow...I love what I see there.
Actually I followed the story behind it and all the stuff about buying the Commodore brand and was a bit sceptical in the past...but it looks so great. Anyone already using it?
Start of cheap begging
Just in case you are rich or you are a group of people and you say "hey, we used clrmame since decades and that old grumpy guy needs a part from his youth back", or you actually own Commodore now....
That basic beige one..I'd fall in love with....if you're in a donation mood, contact me ;-)
End of cheap begging
I've fixed some commandline based relative path issues and got 2 bugfinder's machine name fixing issues on the list.....plus some 3rdparty libs update...nothing really with high prio or breaking stuff...
Hopefully I find some time in the next weeks to switch to new Visual Studio, clean up code, etc...profiler....etc.....etc...open source...etc..etc...
While being busy I saw https://www.commodore.net/category/c64-ultimate and have to say...wow...I love what I see there.
Actually I followed the story behind it and all the stuff about buying the Commodore brand and was a bit sceptical in the past...but it looks so great. Anyone already using it?
Start of cheap begging
Just in case you are rich or you are a group of people and you say "hey, we used clrmame since decades and that old grumpy guy needs a part from his youth back", or you actually own Commodore now....
That basic beige one..I'd fall in love with....if you're in a donation mood, contact me ;-)
End of cheap begging
19
clrmame Discussion / Re: clrmame 0.6.3
« on: 04 March 2026, 17:15 »
ok...so here we go:
exprraidbl (clone of exprraid):
<rom name="5b" merge="cz07.5b" size="16384" crc="686bac23"....
<rom name="5b" merge="cy-17.5b" size="256" crc="da31dfbc" ....
now actually that would mean that the parent has cz07.5b and 17.5b files with different hashes (and names), fine.
"exprraidbl", a clone, now reuses such files from the parent...but maps both to "5b" as "local name", so if you would have a "standlone" set, you have a problem since you don't know which of the 2 files should form the 5b file. But that's for standalone only.
Split merged sets won't have neither of the 2 and full merged ones have the merge names on root level and no in subfolders.
So, if you ask me, I'd say the name should be changed since -when you look at a standalone set (totally standalone, no parent/clone relationships, devices, bios, all dependencies included), you'd have a problem.
But yeah, for all other merge modes it does not play a role.
Coming from the MAME preservation perspective I wonder however, do you really have 2 ICs label 5b on that clone pcb?
exprraidbl (clone of exprraid):
<rom name="5b" merge="cz07.5b" size="16384" crc="686bac23"....
<rom name="5b" merge="cy-17.5b" size="256" crc="da31dfbc" ....
now actually that would mean that the parent has cz07.5b and 17.5b files with different hashes (and names), fine.
"exprraidbl", a clone, now reuses such files from the parent...but maps both to "5b" as "local name", so if you would have a "standlone" set, you have a problem since you don't know which of the 2 files should form the 5b file. But that's for standalone only.
Split merged sets won't have neither of the 2 and full merged ones have the merge names on root level and no in subfolders.
So, if you ask me, I'd say the name should be changed since -when you look at a standalone set (totally standalone, no parent/clone relationships, devices, bios, all dependencies included), you'd have a problem.
But yeah, for all other merge modes it does not play a role.
Coming from the MAME preservation perspective I wonder however, do you really have 2 ICs label 5b on that clone pcb?
20
clrmame Discussion / Re: clrmame 0.6.3
« on: 04 March 2026, 07:22 »
Do you have the xml for that available? I need to look at the xml to say what is actually the best way to go there.
Since the warning comes from initially reading in the xml, so before actually thinking about full/split/whatever merging.
So I think it shows something like (dummy values)
name 5b crc32 0x12345678
name 5b crc32 0x87654321
But that would clearly be wrong. You have identical filenames on the same archive/folder or machine level with different hashes..... -> inform the devs
if it is something like
name 5b crc32 0x12345678
name 5b crc32 0x87654321 merge 5b
then it would mean the set is a clone and the 2nd 5b is shared with the parent...so in a folder/7z/zip they would never be in the same archive or at least not on the same path level. So yeah...would be ok then, storing wise.
So....can you send me the xml please?
Since the warning comes from initially reading in the xml, so before actually thinking about full/split/whatever merging.
So I think it shows something like (dummy values)
name 5b crc32 0x12345678
name 5b crc32 0x87654321
But that would clearly be wrong. You have identical filenames on the same archive/folder or machine level with different hashes..... -> inform the devs
if it is something like
name 5b crc32 0x12345678
name 5b crc32 0x87654321 merge 5b
then it would mean the set is a clone and the 2nd 5b is shared with the parent...so in a folder/7z/zip they would never be in the same archive or at least not on the same path level. So yeah...would be ok then, storing wise.
So....can you send me the xml please?