ADF Format

[bippym]

As most of you have read Feltzkrone has started a better renaming util.. anyway I think it'd be a better idea to hold game/adf info in an ID tag at the end of the adf.

Read this (THe posts by me!!)

Look in here (http://eab.abime.net/showthread.php?s=&threadid=7013)

Tell me what you think, Pros, Cons, I'll try and answer it all..

And don't say NO just because it means changing a few things here and there!!

I will need backing from you guys, the more there are supporting, the easier it'll be :)

[Paul]

It sounds a good idea, but what about if you want to put the adf back onto a floppy to use on the real Amiga via 720k MS-DOS floppy. Will it still work?:confused

[Guede]

This is a good idea I reckon, as the current system is IMO quite cumbersome when it comes to renaming disk images. Some of the filenames produced are simply rediculous in terms of their length.

A header/footer ID tag, would be a much easier and more compact way to rename and identify different dumps. This would also allow more flexibility when it comes to images that difer only due to hi-score tables, save games etc. At the moment I can only think of positives and can find no negative aspects to a system such as this.

[Toni Wilen]

Bad: probably breaks most ADF-utilities, does not work with non 901120 byte images. Example image's ID tag contents are not flexible enough. (there must be way to add extra tags)

Good: idea :)

ADF is only a direct dump from AmigaDOS formatted floppy, nothing more. I think it is much better to design new and flexible structured format (for example using IFF-style chunks)

[bippym]

Originally posted by Toni Wilen
Bad: probably breaks most ADF-utilities, does not work with non 901120 byte images. Example image's ID tag contents are not flexible enough. (there must be way to add extra tags)

Good: idea :)



Okay it doesn't matter what size the adf is, it does matter what size the TAG is.

If the TAG is an agreed size, say 1-2Kb (1024 - 2048 bytes) and that amount is always tagged onto the end of the adf then all you have to do is check 1024/2048 bytes from the end for the word TAG, if it exists it has a tag, get info. If it doesn't then read as a normal ADF!

Basically what we need to do is sit down with all those involved, (Tosec/ WinUAE/ Punters) and come up with all the info that will be needed in the TAG. We then decide how big the tag should be (Taking into account some HUGE filenames and Company names) and once that is done a decision can be made on the size of the TAG 2k should be enuff if not, 3k!

Once done, we get to work convincing authors of ADF utils that it'd be a good idea for them to add TAGS to their programs. Imagine ADF-Opus batch converting and TAGGING ADF's automatically!

UAE/FELLOW can be upgraded to display info on the disks inserted on its floppy menu by using info from TAGS, no tags found then it simply says NO TAGS or similar.



Remember MP3's have had TAGS for a long time and they are not constricted to a certain size.


It sounds a good idea, but what about if you want to put the adf back onto a floppy to use on the real Amiga via 720k MS-DOS floppy. Will it still work?

It'd still work, it'd be easy to write a program to write the image back to floppy and ignore the tag.

And even if the TAG was written it won't make much difference to the disk, as it'd never be accessed, and would be sat in an "unused" part of the floppy! :)

ADF is only a direct dump from AmigaDOS formatted floppy, nothing more. I think it is much better to design new and flexible structured format (for example using IFF-style chunks)

This is a bad idea, as it will BREAK the format and you wont be able to write the ADF back to floppy, this would UPSET alot of ppl!:(


PS.. WHO VOTED NO and WHY?

[bippym]

Who voted NO

Can we at least be constructive and say why you voted no, it wont take long, and this idea is to try and get rid of the headaches TOSEC currently have :(

Rememeber this can be adjusted to fit ANYTHING, ROMS, C64 tapes/dats etc..

[AmiGer]

I vote: YES

[Akira]

I didn't vote yet but i'll vote no.
because: I don't give a shit about all these ROM shite :D

[Fissuras]

OOOOOPS, Akira has said the forbidden word!!!!!

[Akira]

NO
As I told Bippy on IRC, if you don't want anybody to say NO, why the heck do you post a poll? :P

NO!! :D

DO NOT mess wif me files and me ADF programs. Don't be lazy and create a DECENT directory structure instead of putting shitty long names on a zip file. That's what I say
NO
:D

[Djay]

mmm... i'm not sure i need to have a proper look...... but so far i say no... tosec is good enough... as long as the software works when transfered back to a Real Amiga....

i will investigate

[§ane]

A standard ADF is NOT a file format, it is strictly a container for disk data.

Toni suggests a new file format, one that would retain greater detail about a disk's layout, structure and so forth - respective relevant information!

What you are proposing is just wrong! This information best belongs in a database, not in the file name, especially not tacked to the end of the image in question!

You're fretting over long file names? Pah! I can just imagine what troubles this hybrid ADF format will insight.

Note: The above is constructive criticism.

[Djay]

yeah... an ADF is a raw read of YOUR original Amiga software!!!

[fiath]

Originally posted by Toni Wilen
I think it is much better to design new and flexible structured format (for example using IFF-style chunks)

Interesting you should say that Toni ;)

[fiath]

A very interesting idea!

I totally agree - there is too much information that is associated with a game than can be possibly be held in a file name. Not that I don't love what TOSEC is doing - it is just that we need to store a hell of a lot more information than we would want to put in a filename (see below).

However, I voted no... But I have a pretty good reason and a possible alternative. Please do not make the flames too hot. ;)

As you may or may not know, C.A.P.S. is developing a disk file format (IPF) which is *absolutely necessary* to store the copy protected information on a disk. We have no choice - we need a new file format because we need to store not just the data, but also the disk structure, density, etc. too.

As far as I can see it, the file format proposed here (it is a file format if you start adding non-standard stuff to it) is going to be created just to store textual information about each disk? Is that right? That basically means that there will soon be 2 new Amiga disk file formats. ADF-ID (?) and IPF.

Apart from not really liking the idea of that (confusion is bad, m'kay?) I will ignore that for the moment as IMHO there is a better way anyway.

The problem of how we are going to tackle this problem of storing information about each game concerns us as well... We have the same problem as you guys after all, so I am very interested in this tread.

So anyway, to give you a different perspective I will tell you how we intend to do it. You have your disk image (IPF in our case - guesses on what this stands for will be met with praise and admiration - but no prizes - especially as I probably say tell if you are right just yet ;)), i.e. the DATA. Then you will also have the seperate descriptor file - the META-DATA.

We believe that they are different things and should be kept seperate if possible. This is *expecially* true because the information may found to be wrong (for example, the copyright year needs to be changed) and so you would need to change the image and hence the CRC! On the other hand, images will very rarely (if ever) "wrong" - and if they are, it is a bad dump and needs to be completely replaced.

We are working on this META-DATA descriptor file right now. It will be in XML which has major advantages, not least of which like being extendable, if you forgot something in the initial draft, you can just add it without worrying about applications that use it breaking (at least - if they are written properly). No going and specifying 2/3Kb space and hope you don't run out later...

So in your game ZIP you might have:
- gameinfo.xml
- OutRun.ipf (for example)
- (manuals, box art, etc.)

Attached is a *very* peliminary example of what I mean. This is a work in progress. We are also working on the XMLSchema (what makes a valid descriptor file basically) but that it is not nearly ready yet.

We intend for front-end developers to use this descriptor file so they can present a game in the best possible way (for example, 3D rotatable box art, game information, manual available for reading, launch the game, etc.) Something we do not have time for ourselves - but we can generate most of this information from contributor supplied information - so we can make the descriptors almost for free.

If you decided to adopt this approach, you would not need to have a new file format (with all the problems that would entail - like getting people to use it for one) you could still use ADF. I personally think it would be a bad idea to create a new file format just for the hell of it - when it is not really strickly needed (hence why I voted no).

Also, as we are still in the process of defining this descriptor - any collaboration would be cool - as our problems are the same. We could even work ogether if you decided you wanted to do something along the same lines.

That way, front end developers can treat CAPS releases like any other Amiga game that comes with the necessary "industry standard" descriptor.

If you don't like this approach - no problem, but if you do - then let us know - I am sure resolution of the same problem working together would save us both a lot of bother - let alone being a united front.

Please see attached example (peliminary) descriptor for OutRun. The only thing C.A.P.S. specific in this example is the release number and the reference to the schema (which is not actually there yet).

Another idea would be to get HOL team in with this - since they have collected a lot of this information already.

[Interceptor]

i think it would be a good idea to build LZ compression into the file structure.

[Akira]

fiath, you rock. When we talked about this with Bippy on IRC, I told him "but there is CAPS and that is all I need", not knowing exactly teh way you were going to tackle this problem.

This is exactly the same thing I suggested.. adding a ".nfo" type of thing inside the zip.

However the problem remains if you want to download something. How to know what's inside before downloading? With original images is not much of a problem though, no zillions of crack versions to worry about.

A nice directory structure to go along CAPS would be nice anyway :)

[fiath]

I rock? I don't do anything apart from telling people what other people are doing! :)

About bippy on IRC - Oh yeah? And what was his response? ;)

Seriously though - I think the mail above gives pretty good reason why not to put this info in the disk image itself - well that is my opinion anyway - I don't mean to dictate what you guys are doing - it is just my (our) opinion on these things, and the best way to do it without causing confusion to an already convoluted mass of game images.

As far as knowing what is in the ZIP before downloading, we plan to have all info files on the website - probably integrated into the database we are currently building. So you can just have look.

Another way of getting this info would be to get something like Download Mage and just download the info file from within the ZIP (that program rocks btw).

However, all this is rather academic I think since if you have a format like "ADF-ID" (or whatever) then wouldn't you have to download the ZIP to get the info anyway? Or do you mean looking at the extra files? (box art, etc)

Lastly, I am not sure what you mean about "a nice directory structure". Please explain!

[Akira]

Have you seen the High Voltage SID Collection? (http://hvsc.c64.org).

Look at that directory structure. Now imagine if all that info would appear in the SID's filenamse.. like this:

Hubbard_Rob_-_Commando(1985)(Elite)[6581][PAL].sid

This sucks :D. However they organized it all in a nice directory structure and everything can be found at a glance!

However some of the info lies inside the SID file though. But I dont want that, I am just showing up the kind of tidy directory structure I would like.

[fiath]

I see...

In that case, I don't see any reason why anyone couldn't write up a quick tool to rearrange your collection into directories based on the XML file... You could choose the ordering and "execute".

However, this may not be quite as effective for C.A.P.S. releases simply because most will larger than 10Mb. Or even more.

Dragon's Breath is currently 35Mb and that is without the disk images - I have not got round to scanning the Spell Book yet!

[bippym]

Okay chaps,

Remarks taken on board and I'll not go adding tags to my ADF's (for the time being ;) )

Anyway Fiath if you wanna discuss these ideas further then hop onto irc, and private chat me (I'm on most days!)

I am very interested in making everyones life easier (esp. my own!)

. Also how do you view these XML files?

[CodyJarrett]

Viewing XML:
Use a text editor or something like XMLSpy...

[fiath]

Sure, sounds good. I will try to get on tomorow.

XML - no special application needed! Just load them into IE 4+ and it should give it to you nicely colour coded. XML files should in fact be associated with IE on a windows machine anyway...

[Overdoc]

Me too thinks changing the ADF file is niot a good idea.
I am not a big fan of renaming diskimages, anyway, because unlike in roms there are lots of games that save highscores or maybe savegames and so there will be tons of different images of one and the same crack of a game :( And on systems where more than 1 game can be on a disk ( like e.g. C64 ) there will be unlimited number of different crc for the same game -> totally useless for these systems.

But ofcourse CAPS idea of getting this problem done for the Amiga is excellent !!
And on a FTP site or CD you can always create a nice directory structure like Akira suggested and put all different versions of one and the same game in one directory :)

[LaundroMat]

What about some sort of adfdb.com? A front-end scans your ADF directories, compares the ADF's with those stored in an online database, and "meta-names" them (ie without changing the actual filename, but listing them as what they are, nicely presented in columns as "Name", "Cracker", etc etc).

Submitting to the adfdb.com would ofcourse be impossible save for trusted Amiga guardians (otherwise the database'd be full of dupes, just as cddb.com).

A bit of an over-the-top idea, I know :)

[CPC464]

I personally think ADF's should stay as they are :)

[rlake]

I vote no for tagging extra information onto an ADF. I'm fully supportive of the XML idea and until there are official CAPS releases metadata could be gathered into XML files with the same name as the TOSEC ADF.

Plus, XML + Perl... scope for very powerful tools.

[Feltzkrone]

Facts:
- if my tool becomes ready within next few weeks it won't be necessary to put those MP3-alike tags at the end of ADF files, instead add a record to a database for a yet unrecognized ADF and it will be recognized by my tool after it, so the ADF will be identified (regardless of highscores, savegames etc, my renamer will recognize it even if such things are changed)
- those tags are not in competition with my tool, instead, both can be combined: my tool can recognize ADFs, so it could write specific info at the end of an ADF file
- vice versa is impossible, my database needs more info than just a TAG, a person who makes database records needs to select those files of an ADF which are really used by the game / program AND can edit each file's info (in database) so that specific errors on one file can be described as "levelfile error", "code error", "graphics error", "graphics suspicious" etc.

Ideas:
Ssuch a tag doesn't have to be of a fixed size. Let's say we put a magic number MN (dword) at the end of a TAG and before that magic number a length integer L (dword). MN at (@filesize-4) would indicate we've got a TAG, and L (@filesize-8) would indicate where to start reading the TAG. That way the TAG size remains dynamic and can be held still at the end of file

My opinion:
If my tool gets ready the next few weeks this is simply useless. Instead of editing a ADF tag you could make a database record for that ADF and fill in even more info so that alternate versions of that ADF can be recognized, too. I even could extend the tool to act as a frontend or something similar. And simple listing will be possible, too.

End statement:
I vote for NO. I won't be confused by these TAGs but others could be. What the hell do we need MP3 tags for? Everybody has his own way of filling in these fields and it does mean chaos, at least if we have no naming convention and every stupid user can change these TAGs.

And... okay, you one ADF of a 1-disk game is tagged, you get an alternate version of it and what now? You must tag it too, where my tool would probably recognize it and offers the user to view what's different from the "known" version (any Checksum errors, which files are affected etc.)

In the end I don't see the sense, except one thing: If highscores are altered or savegames made, the TAG will be intact and still indicate which disk this one is. But my tool will do the same, too. And what if somebody has fun of smashing disk images and deleting some files in workbench in WinUAE? The disk still claims to be correct (as the TAG says) but it won't work anymore. My tool would detect it (missing files, errors etc.), but TAGs and TAG readers can't.

Conclusion: For me it's totally unimportant if ADFs will be tagged or not, as I don't use a real machine, so I won't transfer anything from PC to Amiga. I voted for NO, as I won't use those TAGs and don't want to see ADFs with file sizes like 883KB (THIS is only a matter of taste, no argues against it, I just wouldn't like it :D).

But as long as those TAGs would be placed at the end of ADF files (i.e. the first 880KB are exactly what they were ment to be!) it won't make me angry and it won't affect usability in my renaming tool (which will work with 880KB files and less only).

So do what you can't stop, but it will take time until ClrMame or some other renamer will be capable of handling those TAGs. For a short period of time we'd definetly have some sort of chaos if everybody would start to TAG those images (and isn't able to see that block 755 has a checksum error which affects level 12 of a certain game). TAGs would assure images to are correct, but in many cases they won't be correct. Anyway, for me it doesn't matter.

[Syko]

don't know about the programming, but the name size is a problem. Adding a TAG of some kind solves all the problems, and causes very few.

Don't like TAG - ignore... Like TAG - make use. Get confused with all the naming variations? Only use one! TOSEC's may not be the best possible, but it's widlly used...

Having TAG's allows extra non-essential info to be included.

So unless you wrote some util that gets broken by TAG's, what's the problem?

[AmiGer]

Looking at the poll, there are 15 against 13 people. I think it would be worth to give it a try (both XML and Tag solution), maybe for a small amount of adfs in the first step !? We can stop the project every time if there're no advantages...

[pcGTW_Webmaster]

I had this idea a long time ago... I created a TAG with a size of 22528 Bytes, so you would get an ADF with a size of 923648 Bytes. That corresponds to an ADF with 82 tracks and the file would remain compatible. I never finished it, maybe i should continue ?

@Feltzkrone:
And what if somebody has fun of smashing disk images and deleting some files in workbench in WinUAE? The disk still claims to be correct (as the TAG says) but it won't work anymore.
That can always happen, no matter if you use a TAG or not. Maybe your tool can detect deleted files, but only if the file is analyzed again after the files were deleted. When using a TAG, all you have to do is to store the CRC in the TAG and you can always check, if the file was modified. ;)

[Feltzkrone]

@WK: That's right, at least CRC32 over the whole thing will let us know if the disk is in its original state. But what if there's a game on it which modifies the disk by itself (either by writing savegames to it or modifying the highscore table). Legend of Kyrandia even tries to write (and if the disk is write protected the game won't run!) something to disk before the game starts (perhaps this is the reason for that many alternative versions of the first disk!).

In the end you will always have the problem to decide whether to check the actual CRC32 against the stored one or to do nothing. IMHO both ways aren't accurate enough.

Apart from that ADFLib won't support 82 Track ADFs as it always tries to read the rootblock at the middle sector (number of all sectors / 2) as this is the way it can be always done for both ADFs and HDFs. For example ADFOpus won't work anymore (perhaps the only application which uses ADFLib?)

Anyway - if you form a TAG standard then I'll support it in ADFRen (my alternative ADF renaming project) and tagged images will get a "[tag]" in the name or something else.

[fiath]

Oh yeuck. I thought we weren't going to convolute the ADF format with all that tag crap ;).

??

On this topic, I have basically finished the XML Schema for the C.A.P.S. releases, if you wanted to use it, feel free. The only think C.A.P.S. centric is the <release> tag at the beginning.

Attached is both Schema and in the next post is an updated Out Run example that can be fully verified against the schema. It looks a bit crap in IE for some reason, but a text editor shows it nicely...

If you want the verifying features you need a XML editor with said capabilities. XML Spy is apparently good. I personally use my Java IDE (IntelliJ IDEA - www.intellij.com).

IF NOTHING ELSE:

Why use tags anyway when you now have HOL? Seems a bit of a waste of effort to me...

Anyway, all this is just IMHO of course...

[fiath]

..

[pcGTW_Webmaster]

Originally posted by Feltzkrone
In the end you will always have the problem to decide whether to check the actual CRC32 against the stored one or to do nothing. IMHO both ways aren't accurate enough.
That's true, the CRC of the whole file isn't accurate enough... But I have another idea now. :) The TAG will contain the CRC16 of all 1760 blocks. Then it is possible to check exactly what was changed. The TAG can also hold information about where the highscore is stored...

Originally posted by Feltzkrone
Apart from that ADFLib won't support 82 Track ADFs as it always tries to read the rootblock at the middle sector (number of all sectors / 2) as this is the way it can be always done for both ADFs and HDFs. For example ADFOpus won't work anymore (perhaps the only application which uses ADFLib?)
ADFOpus is crap. ;) ADFView (uses ADFLib, too) has no problems with 82-track ADFs.

@fiath:
Why use tags anyway when you now have HOL? Seems a bit of a waste of effort to me...
Can't see the connection... :cheese

[fiath]

With HOL you can get search for the game name and you get all the info you need. No need for stuffing redundant info into a file that is meant to be pure ADOS data...

Just because it "can be done", even if it is fun to do, does not necessarily mean that it "should be done".

;)

[andreas]

Agree too. :D

Moreover, quirky Amiga site webmasters could just misuse such tags for "eternizing" themselves like 'ADF ripped by Th3 H4ck3r' and other silly stuff :cheese

[pcGTW_Webmaster]

Originally posted by fiath
With HOL you can get search for the game name and you get all the info you need.
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...

[oldpx]

Hol is not actually about a specific disk image or a release (in terms of piracy) a game. It's all about unique games. I did not know there were ~4000 amiga games until the opening of hol. The ADFs on my HD were far more than that!!!

[Feltzkrone]

Originally posted by WindowsKiller
But I have another idea now. :) The TAG will contain the CRC16 of all 1760 blocks. Then it is possible to check exactly what was changed. The TAG can also hold information about where the highscore is stored...

Hehe, so we could attach a disk database record (compatible to my tool) to the ADF. Note that such a record covers normal ADOS files aswell as defined pure ranges (for NDOS disks). Should be no problem to write a utility to check the stored data against the actual data of the disk image.

Anyway I'm against that TAG, but if we decide to use it I'll support it in my renamer.

[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.

?

[pcGTW_Webmaster]

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: :great

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. :D

[pcGTW_Webmaster]

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... :D

[Feltzkrone]

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

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!