8
« on: 04 July 2020, 19:56 »
"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.
