ADF Format

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

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

[derSammler]

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]

..

[derSammler]

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

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

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

[derSammler]

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

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.