ADF Format
 

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

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

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

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.

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)

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'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! :)

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?

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

I vote: YES

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

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

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

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

No! I am opposed to defacing ADF (Amiga Disk File) images.
 

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.

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

Interesting you should say that Toni ;)

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.

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

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

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!

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.

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!