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
- PROP:ONE
- LIST:XMPL
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