No, due to file updates being stopped, updating the accompanying meta data seemed pointless. I could regenerate it once more, however, so see if this solves your issues. Let me know if it's better.

Sorry to bump this very old topic, but...

Is the Datfile still automatically regenerated every Monday morning?
Current version is dated 2020-06-15.

And there are some differences between Datfile and TGOD files at Archive.org.
I.E.: 003526_magic_boy [1 x 3.5' DD (720kB), English] (1993)
CRC matches the available file, but SHA-1 doesn't.

Datfile SHA-1: 6bc92b8b2bad2232a1fa5f0f18b4f86773ff3ef9
Available file SHA-1: 5330133202b7ae1c30cd6902b6164cd37c7d7792

And also 5 five other games (1177 / 1180 / 1181 / 2434 / 3505) with same situation: match CRC / wrong SHA-1

Thanks!!

That's very great. Thanks a lot. I will use it - for sure!

Done. The file will now automatically be regenerated every Monday morning. Any changes made to the database in between will be reflected not "live", but through that regular update.

Yes, because the output file will be named "Name of the Game.7z.7z"

Does it hurt to keep it?

Last nit: you don't need the ".7z" extension on the names. Those are included automatically by DAT tools. BTW, looks good, thanks for your work on this

Regenerated with the changes. Can I add this to the cron table now?

A CRC is not a hash.

Battle Isle 2 has data issues (as noted in another thread). It will appear when everything's consistent in the database.

Yep, boiling it down, those are the 3 changes. I tend to want to explain why I feel things need to be changed and not just go "CHANGE THIS!". Sorry if you felt it went too overboard.

For the hashes, contrary to what you say, there is both CRC-32 and SHA-1 hashes in the DAT, but, as I had mentioned, the order doesn't matter in the least.

The only game I can find that doesn't include any rom entries is "Battle Isle 2 [1]", though I thought I saw more originally.

In plain English, please. This is getting way over my head. I haven't seen "the standard" which you talk about yet. I don't need to see or understand it. Just tell me what to change. What I gather is:

* Change "description" to "comment"
* Change "archive" to "name" attribute of "game"
* Change "name" attribute of "game" to "description"

Correct?


Talking about OCD, I can't help but pointing out that the "hashes" are in fact in increasing order of security as there is only one hash


Not sure what you mean. Example?

Thank you for linking me, I completely missed that. A couple of minor things that I want to note for DAT correctness:

- The "description" tag under each game generally is used to house the "full title" of the game. That is, when it's used in MAME, the game name is "1942a" and the description is "1942 (Alternate Set)" or whatever. In all other cases, the game name and description are identical. That being said, you can use the (mostly unused) tag of "comment" under each game to include things like the number and type of disks, etc.
- The "archive" type is actually for sets that include an archive of that name in them, but don't want the hash data to be required. I haven't actually seen a proper use case of this yet personally, but it's in the specification. If you wanted to include the original name of the archive, I'd suggest having THAT as the game name and what you currently have as the game name as the description instead. This would allow the sets to be properly scanned in something like ClrMamePro
- The most minor nit is that the hashes aren't in increasing order of security. This is by no means required and is enforced by nothing, but I have my OCD-like tendencies sometimes
- I noticed that some games don't include any of the actual disks in the listing, was this just because the database didn't include them at the time? This is more just me pondering things than anything.

Other than those minor nits, the DAT looks really good! It would be really awesome if this ends up having a formal release instead of just my weird personal ones

This one.

I apologize for not knowing where the same place is, can you link me to the DAT? I would like to take a look as well if at all possible.

I will test in the the next days and will report back. Thanks!

New file available in the same place. Is it now accepted by the tool?

Strictly speaking the size is NOT required, but it is highly recommended to include the size of the file as well due to, again, backwards compatibility and better security. This is also information you can pull if you're looking at the zipfile headers the first time, so it should not be an issue. The only time that I've seen the size not included is for <disk>, because it relies on an internal hash instead of the external one, so the size doesn't strictly matter.

When I checked it yesterday, it was working working without including the file size.

Grabbing the CRCs from the archives is indeed my plan.

Are you saying size is also "required"?

Understood about the conventions. I'm simply baffled why everybody, including the conversion tool's website, cites the DTD, but without ever reflecting the striking difference with practical implementation. It seems to be assumed "everybody" knows.

The DTD from Logiqx has been long stagnant, so it's no surprise to me that modern convention trumps the DTD for everything.

As for the terminology of ROMs, Machines, Games, Disks, etc, these all started in the emulation community and were just adapted along the way. Here's a decent breakdown of some of the terms used in DATting that might help:

- ROM : Any file that is not a CHD image, originally referred only to arcade ROMs
- Disk : Any file that is in the CHD format. Look it up in MAME documentation for more
- Game / Machine : Generic title for a "set", that is the parent folder of a group of roms and disks. Again, terminology stems from usage in emulation primarily with Machine being newer