Interchange File Format (IFF)

The Interchange File Format (IFF) was created by Electronic Arts in 1985 to help introduce some standards to the multitude of custom file formats that were in use at the time. As it was developed on the Amiga and related platforms, all the length fields are stored in big-endian format, so in 1991 Microsoft introduced the Resource Interchange File Format (RIFF) which is largely based on this standard, except that it uses little-endian numbers better suited to the Intel platforms used by Microsoft software.

Structure

The file format is arranged as a series of chunks. Certain chunks can be nested inside other chunks, and beyond the initial "root" level object, the nesting is entirely user-defined depending on the file format.

FOURCC

The FOURCC data type is used to identify each chunk type. It must conform to the following rules:

• Each character must be in the ASCII range 32 to 126 inclusive. This includes alphanumeric characters and punctuation, but excludes control characters and extended (8-bit) ASCII. Trailing spaces are allowed, but embedded spaces are not.
• FORM, CAT and PROP type IDs may be used as filename extensions, so lowercase letters and punctuation are forbidden. Only uppercase letters and numeric digits may be used for these, and trailing spaces are permitted if the length is less than four characters.

Chunk

A chunk is defined as follows:

Type	Name	Description
FOURCC	chunkID	Chunk name
UINT32BE	lenChunk	Length of chunk data, in bytes. Does not include the pad byte.
BYTE[lenChunk]	content	Actual data of the chunk
BYTE	pad	Optional padding byte, only present if lenChunk is not a multiple of 2.

Standard chunks

Most of the chunk types and their content are specific to the data being stored, however there are three chunks that are well-defined for all IFF files. These standard chunks follow the same structure as above, however the content for each chunk is defined as follows:

Type	Name	Description
FOURCC	formatID	Code specifying layout of child chunks
CHUNK[]	chunk	One or more additional chunks

If a chunkID is FORM and the formatID is BLAH then it is written below as FORM:BLAH. These are the standard chunkIDs:

FORM

This is a self-contained data section. The FORM chunk could be copied out and stored in an object by itself, and that file would be a valid object. Composite objects can be made up of multiple FORM chunks, such as an animation which stores each frame in a FORM chunk, and when one of these chunks is saved into a separate file it becomes a valid image file with that single frame/picture in it.

CAT  (note the trailing space on this code)

This chunk is a simple untyped list of objects. The spec hints that all the objects in a CAT chunk could be concatenated without corrupting the data, and suggests that because of this, nested chunks within a CAT do not really make sense and would be better off being merged into one chunk rather than nested. If the CAT chunk's contents should not be merged, then a LIST chunk should be used instead.

LIST

Similar to a CAT, this chunk holds a list of objects. Unlike CAT, the objects are structured and the LIST can contain PROP chunks which apply properties to all objects within the LIST. The spec says that unlike CAT chunks, the contents of LIST chunks should not be merged without understanding their contents. The LIST chunk should contain one or more FORM chunks, preceded by zero or more PROP chunks, with each PROP holding common chunks that apply to the FORM ones. This way duplicate chunks are removed from each FORM and are instead listed once in the PROP.

PROP

This chunk can only appear inside a LIST chunk, and contains chunks that should apply to all other chunks within the same parent LIST. The chunk type matches the FORM type, so all the chunks inside PROP:ILBM should apply to all sibling FORM:ILBM chunks.

____ (four spaces)

These "filler" chunks contain no meaningful data and should be ignored, and can be omitted/deleted if the file is being rewritten.

FORM types

This is a list of all known FORM format IDs.

FORM FOURCC	File format
FORM FOR1 to FOR9 LIST LIS1 to LIS9 CAT CAT1 to CAT9	Reserved and not permitted as FORM types
8SVX	8-bit sampled sound voice
ANBM	animated bitmap
FNTR	raster font
FNTV	vector font
FTXT	formatted text
GSCR	general-use musical score
ILBM	interleaved raster bitmap image, see LBM Format
PDEF	Deluxe Print page definition
PICS	Macintosh picture
PLBM	(obsolete)
USCR	Uhuru Sound Software musical score
UVOX	Uhuru Sound Software Macintosh voice
SMUS	simple musical score
VDEO	Deluxe Video Construction Set video
XDIR XMID	eXtended MIDI music, see XMI Format

Examples

In this example structure:

• FORM:DEMO
  • LIST:XMPL
    • PROP:ONE 
      • INF1
    • PROP:TWO 
      • INF2
    • FORM:ONE 
      • DATA
    • FORM:ONE 
      • DATB
    • FORM:TWO 
      • DATC

There are three data files combined into the one file. Some common data chunks have been removed (INF1 and INF2) from their respective FORM files, as they were the same for each file and only needed to be listed once in the combined file. The PROP chunks indicate this shared-use with their types matching the FORM types, so the chunks within PROP:ONE  should be used with FORM:ONE  to create a valid file that could be saved separately:

• FORM:ONE 
  • INF1
  • DATA

External links

• The original IFF specification: Jerry Morrison, Electronic Arts, "EA IFF 85" Standard for Interchange Format Files, January 1985