ADF Format

[fiath]

Originally posted by WindowsKiller
Still can't see the connection... The TAG would contain information about the image as well, not only game information. HOL can't tell you who cracked a game, if it has a trainer, if the image is damaged or not, etc...

Okay, *some* of the information is about the actual image, but by your screenshot it looks like a very small amount of information. You were initially intending to put a box scan + game info in there too were you not?

IMO This small amount of info is better left tagged in the filename as per TOSEC naming (verified/generated by Feltzkrone's renamer).

Other than that, it is a hacky hacky solution to a simple problem. I really don't see why you want it just because similar info is kept by MP3's... Besides, as I have said before, MP3's have its tags stored in a formal, well defined chunck. Not "tacked on the end".

What you are proposing is basically making a DATAFILE into a FILE FORMAT with no way to know if it is *really* one or the other.

If you *really* wanted to do it though, the only way I can see it not convoluting the ADF concept is if you changed the file extension, i.e. ATF (Amiga Tagged File) or something. This would mean that all ADF's with tags will be known as exactly what they are.

But if you are going to do that, why not just make a new "chunky" style format as Toni suggested? You could have three main chunks, 1) header, 2) ADF data part, 3) tag info.

?

[derSammler]

Originally posted by fiath
You were initially intending to put a box scan + game info in there too were you not?

No. As I already said, I had this idea months ago. The screenshot shows a very early version of the tag reader. Not much work was done at this point...

My aim is to store EVERYTHING about the image and the game in the tag. This also includes config information for WinUAE and a lot of other information that you cannot put in the filename.

Originally posted by fiath
Besides, as I have said before, MP3's have its tags stored in a formal, well defined chunck. Not "tacked on the end".

Ever saw ID3v1 ?

Originally posted by fiath
But if you are going to do that, why not just make a new "chunky" style format as Toni suggested? You could have three main chunks, 1) header, 2) ADF data part, 3) tag info.

I can't see why ? The tag does not break the compatibility. A new format however would break the compatibility with all current emulators.

[Konrad]

I voted no. I just like the idea of the caps team keeping all necessary files and information in a zip archive.

[fiath]

Originally posted by WindowsKiller
No. As I already said, I had this idea months ago. The screenshot shows a very early version of the tag reader. Not much work was done at this point...

My aim is to store EVERYTHING about the image and the game in the tag. This also includes config information for WinUAE and a lot of other information that you cannot put in the filename.

So my argument still stands. Leave the game information to HOL and stick only image specific information on the TOSEC filename.

Ever saw ID3v1 ?

It doesn't matter if ID3v1 is stuck on the end, the point is that MP3 IS A FILE FORMAT and ADF IS A DATAFILE.

For MP3, as long as you say "ID3 info is stuck on the end of the file" it is okay, because FILE FORMATS are defined, DATA FILES are not - they are just data.

But putting non disk data on the end of the datafile you are effectivily changing ADF into a file format (because it is not just ADOS track data anymore). So if you are going to do it, you should make sure that people know that it is NOT an ADF - so use a different file extension. It would still be compatible with ADF, but then people know it has tag info straight away.

I can't see why ? The tag does not break the compatibility. A new format however would break the compatibility with all current emulators.

Very true. That is exactly why I don't really see the point.

I am not trying to bar your way, I just think it is a bad idea to mess with the ADF files themselves.

You would get *exactly* the same functionality by creating a datafile and putting all the information about each disk image in it key'ed by it's CRC, then make the TAG viewer file use this datafile.

This means you don't need to mess with the images!

The *only* thing I can this about this which is slightly negative is that you need to have the latest version of the datafile. However, writing code to do an auto-update from the net is not exactly hard...

This is why we decided to distribute each "TAG info file" with each disk image... No needs for updates when new games released.

[Feltzkrone]

@fiath:

You described the whole problem very well. But IF someone decides to put TAGs to ADFs it won't be a big problem to write a "remove-all-TAGs-from-all-ADFs" util.

[derSammler]

Originally posted by fiath
So my argument still stands. Leave the game information to HOL and stick only image specific information on the TOSEC filename.

But why ? There's enough space in the tag to store the game information, so why should I leave it out ? Maybe people don't want to go online everytime they need information about a game...

Originally posted by fiath
You would get *exactly* the same functionality by creating a datafile and putting all the information about each disk image in it key'ed by it's CRC, then make the TAG viewer file use this datafile.

This has two disadvantages: The CRC can change if you save the highscore. Then you can no longer identify the image by its CRC. With a tag attached to the end, you don't have this problem.

Another thing is, that you always need the complete database... Just imagine how big a database with information about e.g. 5000 games is ? 5 MB, 10 MB or even more ? With a tag, you only download the information that belongs to the image.

But it's ok if you don't like the tag. I don't force anyone to use it...

[Feltzkrone]

This is a fight, isn't it...

In my opinion the BEST way is to provide an extra file with different extension. If there's game_a_disk_1.adf why not make a game_a_disk_1.xml or game_a_disk_1.adt file?

This file should hold all information, and should be able to hold game information aswell so that a manager util can be used to list and browse all disks which somebody has got and filter them with certain criteria.

At least this is some kind of compromise:
- ADF is not affected itself
- ADT is connected to ADF by its root filename

And possible, too:
- ADT can contain information so that one can check out if this ADT really belongs to the ADF

[BippyM]

the XML or whatever could hold the CRC or whatever for the adf, then if it gets lost when a anager reads it it notes this and says!