Gold Fish 1/GoldFishApril1994_CD2.img/d4xx/d463/ilbm/aboutiff

Text File | 1991-03-09 | 10KB | 224 lines

    Electronic Arts is a company that deserves credit for helping make life
easier for the Amiga programmer and end user. The company has promoted the
Amiga since the computer's introduction more so than CBM (although very few
organizations have promoted the Amiga less than its manufacturer). By esta-
blishing IFF standards on behalf of CBM and releasing source code for reading
and writing IFF files, Electronic Arts has helped make the Amiga the success
that it is in the video/graphics market. Unfortunately, the people who wrote
the documents describing the IFF file formats have an appalling lack of respect
for the English language. No effort was made to be concise and clear. Sentences
seem to have been constructed by heaving several, long phrases together, and
subsequently inserting a verb or two. Then, if the text didn't sound
"technical" or "serious" enough, adjectives were invented, and brazenly thrust
into any sentence of less than 40 words. This mish-mash of technical newspeak
is typical of computer programmers who never learned to write in any language
other than Pascal. In fact, if the trend toward inventing technical jargon
continues, we may see the day when technical literature will have the words
BEGIN and END surrounding each "standard written language module" (i.e.
paragraph).  Many misguided programmers (and others engaged in scientific
disciplines) are also taught that any use of the first person (i.e. I or we)
is too conversational, and therefore unprofessional. Apparently, the function
of technical literature is not to converse, but to bore. Because the original
IFF documents exhibit all of these flaws, I will attempt to paraphrase those
documents. I do not guarantee that I will have correctly ascertained the
intentions of the lifeform that wrote those documents, so you should consult
the original text.

  BEGIN
  IFF stands for "InterChange Format Files". This is some of that technical
jargon that I was alluding to earlier. Basically, an IFF file is a set of
data that is in a form that many, unrelated programs can read. An IFF file
should not have anything in it that was intended specifically for just one,
particular program. If a program must save some "personal" data in an IFF
file, it must be saved in a manner which allows another program to "skip
over" this data. There are several different types of IFF files. ILBM files
store picture data. SMUS files store musical scores. 8SVX store sampled
sounds. Each of these files must start with an ID which indicates that it is
indeed an IFF file, followed by an ID that indicates which type of file. So
what is an ID? An ID is four, printable ascii characters. If you use the CLI
Type command (opt h) to print out an IFF file to the CLI window, you will
notice that every so often you will see 4 letters in a row. These 4 letters
are an ID. Every IFF file must start with one of the following 3 IDs.

  'FORM'  'LIST'  'CAT '

 If the first 4 chars (bytes) in a file are not one of these, then it is not
an IFF file. These IDs are referred to as group IDs in EA literature.
    END

  After this group ID, there is a ULONG that indicates how many bytes are
in the entire file. This count does not include the 4 byte group ID, nor this
LONG. This LONG is useful if you wish to load the rest of the file into mem-
ory to examine it. After this LONG, there is an ID that indicates which type
of IFF file this is. As mentioned earlier, "ILBM", "SMUS", and "8SVX" are 3
types of IFF files. There are many more, and programmers are always inventing
new types for lack of better things to do. What you find after the type ID
depends on which type it is (i.e. From here on, an ILBM will be different
than an 8SVX). Here is the beginning of a typical ILBM file.

  'FORM'  <- OK. This really is an IFF file.
  13000     <- There are 13000 more bytes after this ULONG
  'ILBM'  <- It is an ILBM (picture) file

  One thing that all IFF files do have in common after the group ID, byte
count, and type ID, is that data is organized into chunks. OK, more jargon.
What's a chunk? A chunk consists of an ID, a ULONG that tells how many bytes
of data are in the chunk, and then all those data bytes. For example, here
is a CMAP chunk (which would be found in an ILBM file).

  'CMAP'          <- This is the 4 byte chunk ID
  6              <- This tells how many data bytes are in the chunk (chunkSize)
  0,0,0,1,1,4 <- Here are the 6 data bytes

  Notice that the chunk size doesn't include the 4 byte ID or the ULONG for
the chunk Size.
  So, all IFF files are made up of several chunks. There are a few other
details to note. A chunk cannot have an odd number of data bytes (such as 3).
If necessary, an extra zero byte must be written to make an even number of
data bytes. The chunk Size doesn't include this extra byte. So for example,
if you want to write 3 bytes in a CMAP chunk, it would look like this:

  'CMAP'
  3          <- Note that chunk Size is 3
  0,1,33,0 <- Note that there is an extra zero byte

  In the preceding example, the group ID was 'FORM'. There are other group
IDs as well. A 'CAT ' is a collection of many different FORMs all stuck
together consecutively in 1 IFF file. For example, if you had an animation
with 6 sound effects, you would want to save the animation frames in an ANIM
FORM, and you would want to save the sound effects in several 8SVX FORMs
(one per sound effect). Note: a better way to store sound samples would be
the SAMP format. See Fish Disc #203. You could save the animation and sound
in 7 separate files. The ANIM file would start this way:

  FORM
  120000  <- Whatever the size happens to be (this is expressed in 32 bits)
  ANIM

  Each 8SVX file would start this way:

  FORM
  8000 <- whatever size
  8SVX

  If the user wanted to copy the data to another disc, he would have to copy
7 files. On the other hand, you could save all the data in one CAT file.

  CAT
  4+120008+8008+2028+...  <- The total size of the ANIM and the 6 8SVX files
  '     '                 <- Type of CAT. 4 spaces for the type ID means "a grab bag"
                             of IFF FORMs are going to be inside of this CAT
  FORM
  120000
  ANIM
  ...all the chunks in the ANIM file placed here (note: ANIMs have imbedded
      ILBM FORMs)

  FORM
  8000
  8SVX
  ...all the chunks in the first sound effect here

  FORM
  2020
  8SVX
  ...all the chunks in the second sound effect here

  ...etc. for the other 4 sound effects

  To further complicate matters, there are LISTs. LISTs are a lot like CATs
except that there is an additional group ID associated with LISTs. That ID
is a PROP. LISTs can have imbedded PROPS just like an ILBM can have an im-
bedded CMAP chunk. A PROP header looks very much like a FORM header in that
you must follow it with a type ID. For example, here is an ILBM PROP with
a CMAP in it.

  PROP  <- Here's a PROP
  4+14  <- Here's how many bytes follow in the PROP
  ILBM  <- It's an ILBM PROP
  CMAP        <- Here's a CMAP chunk inside this ILBM PROP
  6            <- There are 6 bytes following in this CMAP chunk
  0,0,0,1,1,4

     LISTs are meant to encompass similiar FORMs (i.e. several 8SVX
files stuck together). Often, when you have similiar FORMs stuck together,
some of the chunks in the individual FORMs are the same. For example,
assume that we have 2 8SVX sound effects. 8SVX FORMs can have a NAME chunk
which contains the ascii string that is the name of the sound effect. Also
assume that both sounds are called "car crash". Wouldn't it be nice if we
didn't have to have the same NAME chunk in each 8SVX FORM like so:

  CAT                    <- We put the 2 files into 1 CAT
  4+1004+504
  8SVX                <- It's an CAT of several 8SVX FORMs

  FORM                <- here's the start of the first sound effect file
  1000
  8SVX

  ...some chunks

  NAME                <- here's the name chunk for the 1st sound effect
  9
  'car crash',0

  ...more chunks

  FORM                <- here's the start of the second sound effect file
  500
  8SVX

  ...some chunks

  NAME                <- here's the name chunk for the 2nd sound effect. Look
  9                        familiar?
  'car crash',0

  ...more chunks

  With a LIST, we can have PROPs. A PROP is group ID that allows us to place
chunks that pertain to all the FORMs in the LIST. So, we can rip out the
NAME chunks inside both 8SVX FORMs and replace it with one NAME chunk inside
of a PROP.

  LIST                <- Notice that we use a LIST instead of a CAT
  4+30+990+490+...
  8SVX

  PROP                <- Here's where we put chunks intended for ALL the
  22                        subsequent FORMS; inside a PROP.
  8SVX                <- type of PROP
  NAME                <- here's the name chunk inside of the PROP
  9
  'car crash',0


  FORM                <- here's the start of the first sound effect file
  982                    <- size is 18 bytes less because no NAME chunk here
  8SVX

  ...some chunks, but no NAME chunk

  FORM                <- here's the start of the second sound effect file
  482
  8SVX

  ...some chunks, but no NAME for this guy either

  Notice that the PROP group ID is followed by a type ID (in this case 8SVX).
This means that the PROP only affects any 8SVX FORMs. If you were to sneak
in an SMUS FORM at the end, the NAME chunk would not apply to it. Also, if
you included a NAME chunk in one of the 8SVX FORMs, it would override the
PROP. For example, assume that you have a LIST containing 10 8SVX FORMs. All
but 1 of them is named "CBM needs an advertising budget". You can store a
NAME chunk in a PROP 8SVX for "CBM needs an advertising budget". Then, in
the one 8SVX FORM whose name is not "CBM needs an advertising budget", you
can include a NAME chunk to override the PROP.
  It should be noted that you can take several LISTs and squash them toge-
ther inside of a CAT or another LIST.² Personally, I have never seen a data
file with this level of nesting, and doubt that it would be of much use. If
you need this level of complexity, forget IFF and make your own proprietary
data format, then give info to anyone who wants to access your data. No doubt,
somewhere, there is a moron devising a plot to inflict a CAT of LISTs upon an
unsuspecting public now that VirusX has defeated his more devious aspirations.