Please login or register.

Login with username, password and session length
Advanced search  


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.

Messages - Roman

Pages: [1] 2 3 4 5 6 ... 139
clrmame Discussion / Re: sort by description
« on: 12 July 2020, 21:15 »
The switch indeed switches to and sorts by description. There is currently no option to show setnames and sort by description or vice versa.

Well, a set is a collection of roms and/or samples and/or chds. So there are e.g. sets which only consists out of chds. If you don‘t have the chd, the set appears as missing. Even when you dont scan for chds since that switch would produce the missing chd message not the missing set message. You can fool cmpro if you create an empty folder for the chd to avoid missing set messages for chd only sets.

clrmame Discussion / Re: sort by description
« on: 12 July 2020, 19:52 »
Do you mean the scan results tree or the actual setinformation window. There you actually have a checkbox to switch between set name and description. So what exactly do you want to get sorted by description?

Good to hear it is working 😁
Regarding your question: unneeded files are moved to the backup folder when being fixed. If the fix option is not enabled you should have something like a copy to or move to context menu option for all listed sets. At least if I remember that correctly. Cant check at the moment.

Special torrent7z etc: do they really need to be different? Currently cmpro uses the settings from settings/compressor/7z. The 7z exe doesnt care about extensions. Maybe it works right away with torrent7z.

Cmpro supports headers by using xml definitions where you can specify rules how checksums are calculated. Maybe a new header definition can be easily created for exif. I will check if I find the link to the xml header documentation.

Update: here is the link https://mamedev.emulab.it/clrmamepro/docs/xmlheaders.txt

Thanks for the info. I will have a look at it again after my holiday

No Im just asking if you know that both sets are fully 100% ok and cmpro still wants to rename the files in a new scan. Or was it just during a first scan. It looked weird what it is doing but in the end both sets were ok and cmpro doesnt show another rename here and there prompt.

Now Im on vacation 😁. So it still happens when you got both (the mame one and the softwarelist one) fully correct?

Yeah I think we're talking a bit in circles. But I can't stop showing the important difference of a "disk" and a "rom"

A "disk" element is used explicity for chds (so a compressed container holding specific kind of binary data where hashes are for the uncompressed data in. Actually you also have hashed for meta information).
A "rom" element is for any kind of binary data as is (i.e. not a container and the hashes are for the file itself).
All roms of a set are usually compressed together in an archive (which then represents the set) while chds are kept outside of the archive. Such rules aren't made by clrmame...it's all based in the MAME world.

You can't simply use chdman within the rebuilder or something to compress files like you do with a zip.
Different media (CD/DVD/HD/ect) require very specific and different additional parameters. Take a look at its commandline options for createld or createhd....there you need to specify sector sizes, inputstartframes etc etc.
The rebuilder rebuilds roms only. It informs the user about valid chds though but in the public build ( ;-)) it won't move the chd from source to destination

To make a long story short:

If you want to use chds for isos, fine, then the datfile should use disk elements.

This behaviour will not change.
chd -> disk xml element, no flag which changes this, no nothing. Sorry.

"Let's say I have a zip file, game.zip, which holds game.iso"

Ok..then you simply have a zipped up iso...the zip stores the compressed iso and also a crc32 for the file in its structures. So a valid datfile for this would hold a "rom" entry with the crc32 which can also be found when looking at the zip structures. For the sha1 value you can use common sha1 tools to calculate the sha1 from the iso file (not the zip).

"Let's now say that I take game.iso and convert it to game.chd."
Well. That means that you use chdman.exe!!! A simple rename of the extension is not what will work. A chd is a totally different format. In case you only renamed it from .iso to .chd you try to fool cmpro and reading it will fail since internally it will say that the chd file is not a valid file.

"If I scan /ROMs/ with a No-Intro dat, it will tell me that game.chd is an unneeded file"
Different cases could happen:
- the datfile doesn't hold "disk" elements...since it was designed for handling isos which are handled as a "rom"
- if you converted the file using chdman, then the datfile should list the sha1 which chdman reports when running an info command on it
- if you did not convert the file and just renamed it, well, then most likely cmpro tried to read it as chd, while it's not a chd and failed.

"Really all I want is for ROMs/game.chd to scan as a valid file."

Again...you need to follow the general rules: Either your datfile uses a "disk" element and the name/sha1 belong to a real chd (compressed with chdman) or you use a "rom" and the name/crc32/sha1 belong to any binary file

"Bonus points if the rebuilder gets an option to compress to chd."
No, since creating chds is the job for chdman.

I'm still not sure if you are aware of MAME's chdman tool which is reposible for packing data into a chd. It requires general information about the raw data you're trying to compress. Sectorsizes, etc..etc..

It's up to the datfile authors to define how the sets should look like. If nointro likes to store iso files 'as-is'. Then they're absolutely right to use a rom xml element and the hashes belong to that iso. Surely this iso can be zipped/rared/7z...but NOT put in a chd.
If nointro dat authors like to convert the isos into CHDs they will adjust the datfiles.

Again, I don't see anything which cmpro has to change here.

...besides of this...the datfile authors should be aware what the belonging emulators actually can handle. If emulators can only work with iso files it wouldn't make any sense to store them in chds and make dats for this....CHD is coming from the MAME universe...there might be a couple of emulators which can handle chds but globally it's still a rare format.


Beware...this is just a very early test!
You should use a new separate installation for it (going back from it would kill your set compression settings (like rebuilder pack type etc) at the moment, so better use a fresh install ;-) )

By default you of course got rar/7z/zip support.....You can add additional ones by editing cmpro.ini and add/modify:

Packer_ZIP_Alias = .cbz
Packer_RAR_Alias = .cbr
Packer_7Z_Alias = .cb7

The alias settings allow multiple values separated by space, so e.g. Packer_ZIP_Alias = .cbz .jar .war

If you find anything weird, collect and post the quirks....I will look at it after my holiday...

Did I say "do not expect anything anytime soon"? Well....looks like I was wrong...

I did some restructuring of the packer code and actually cmpro is now able to handle anything which is "like 7z/rar/zip" based.
And all at the same time. So cbz, cbr, cb7 isn't a problem....and of course you can think of jar, war etc as well.... ;-)

So where is it? Well, of course I want to test it a bit more so I can't promise if I put out a nightly before my holiday....

A chd file is a compressed hunk of data, i.e. it compresses all kind of data (diskimages, dvdimages, floppyimages, laserdisk data, etc). It stores a chd header with all kind of information and the compressed data. See it like an archive like zip or rar.

The sha1 given in the datfile is the sha1 which chdman (the tool which can create chds/unpack chds, etc) calculates over the uncompressed data. This sha1 is stored in the chd header. Pretty much the same what a zip archive tool does. There it stores the CRC32 of the decompressed file in the zip structures.

So if it comes to any hash, it's always the hash of the decompressed data...and of course this hash is listed in the dat and this is the hash which clrmamepro checks against the file. Quick way is a look up in the structures, slower way is a blockwise decompress, calc the hash and compare it.

I still don't fully understand what your real idea is (most likely you're asking for a pretty obvious thing which chdman simply already does).
Again: "disk" elements refer to chdman-compressed data. There won't be any new flag which "to look inside the chd header". cmpro does that already which each chd file / disk entry. If your "any rom extension" data is compressable with chdman then nothing stops you.

Sorry but I don't get it.

".chd" is the default extension for files which are listed as "disk" element in the datfile. Normally it's listed in the datfile without the extension.
Like <disk name="99bottles" sha1="0b874178c8dd3cfc451deb53dc7936dc4ad5a04f" region="cdrom" index="0" writable="no"/>

The given sha1 is not the sha1 of the file since a chd acts as a container (like  zip/7z/rar). The sha1 value is the internal, decompressed sha1 which is stored in the chd header for example.

I don't see any work here for cmpro....or I don't understand what you mean ;-)

Played around but wasn't able to build up a scenario yet which leads to the problem...*sigh* do you use split or full merged sets by the way?

Does it still happen when you got both sets (MAME and softwarelist) fully complete and correctly named?

1) folders are supported. They need to be listed in the datfile though. So instead of rom name="1346b.cpu-u25" size="2048" crc=".... you got rom name="my_sub_folder/1346b.cpu-u25" size="2048" crc="....

2) yeah, definetly the better way to simply understand zip and cbz as an alias for it and handling both.....need to think about it a bit...

3) compression settings can be setup in the rar/7z tabs of settings->Compressor. For zip you can define the compression level in cmpro.ini (Packer_Zip_CompressionLevel = 9)

since holiday is just some days away, don't expect anything anytime soon ;-)

Thanks for the files. I've did some tests and yes it works pretty fine and easy when .zip is simply replaced with .cbz alias (same for rar/7z)
What would be more interesting is when you want to support both .zip/.cbz at the same time. So for example rebuilding to .cbz but reading .zip files etc...
That'd require some additional coding since you a) somehow need to define what the prefered writing alias is and b) there are some checks which need to run through all alias then.

Since it's nearly holiday time, I put it on my to do list....but yes, in general it seems to be not too much work....

well....MAME uses the identical rom as mpc800manager-2.40.rom in its mpc800 set....so it's part of MAME and it's reused with a different name in the softwarelist bbc_rom....

I wasn't able to repeat the rename behaviour yet...but will play around a bit......

hmmm.....if it's just a real zip or a real 7z or a real rar then there might be a chance with some kind of extension alias (tell cmpro that .zip is .cbr). That would be relatively easy I guess....

The problem might be that the used libraries might have additional tests on the filename extension (especially when it comes to split archives...but they might not play a role here). If the files are not only renamed but also used different identifiers inside the archive structure...well..then you might face another problem

I will check what's possible.....do you have some example files by the way?

clrmame Discussion / cmpro 4.037a released
« on: 22 June 2020, 18:31 »
Very tiny update...

misc:  for softwarelist combined mode scanning a software list set is now strictly restricted to the assigned rompath. Should resolve all possible false-positive detection of unneeded stuff
fixed: falsely allow user to enter settings/scanner/rebuilder/merger when no profile is loaded
added: copy functions (not only move) to warnings window context menu

clrmame Discussion / Re: "clrmamepro has stopped working"
« on: 09 June 2020, 05:38 »
It's not corrupt, your rar software is too old. Use the latest winrar for example ;-)

But you can also use: https://mamedev.emulab.it/clrmamepro/binaries/cmpro20200608.7z

Pages: [1] 2 3 4 5 6 ... 139

Page created in 0.125 seconds with 22 queries.