The Audio Interchange File Format

Compared with other popular standards in use, Apple’s Audio Interchange File Format (AIFF) is ancient. The core functionality was stabilized over 30 years ago and has not changed since then. Given the pace of development in our industry that is a remarkable achievement.

AIFF files contain raw audio samples. This is optimum for production use. Most editing tools can open and save AIFF content after editing.

The embedded metadata describes the sample rates, track configuration and bit depths for the audio essence.

Despite its lack of complexity, AIFF is a versatile format and not likely to go out of use soon. Not least because of the massive legacy of archived recordings in this format.

Compressed Audio Storage With AIFF-C

The original classic AIFF files only contain uncompressed data. The AIFF-C specification was published as a replacement for version 1.3 of the original AIFF document and allows any kind of sound data to be carried. This has become the de-facto default format. When encountering what appears to be a classic AIFF file, it is likely to actually be an AIFF-C file.

Searching online for documentation only reveals a draft document, but additional supporting information can be found in these developer documents from Apple:

There are a few important differences between AIFF and AIFF-C files summarized here:

Multi-byte Data Formats

When AIFF was invented, CPU microprocessors had 8-bit architectures. They also ran at much slower clock speeds. With the enhancement of CPU chips to 16-bits, then 32-bits and 64-bits, the ordering of the bytes becomes important. The two principal CPU manufacturers (Motorola and Intel) chose opposing byte arrangements.

Since Apple based the original Macintosh design on Motorola 68000 and then PowerPC microprocessors, the AIFF data was organized with the highest ordered byte first. This is called Big-Endian.

Conversely, Intel arranged their data with the lowest ordered byte first. This is called Little-Endian. Since Windows PCs were based on the Intel architecture, this required some format conversion when moving content between the two platforms. The AIFF-C version switches to a Little-Endian arrangement eliminating this conversion.

Endianness In CPU Architectures

Early Apple Macintosh hardware was based on Big-Endian architectures, the move from PowerPC to Intel forced the OS to be rebuilt around the Little-Endian design. Windows had been running on Intel for some time; switching to Intel CPUs facilitated running Windows on Apple hardware or emulating it in a virtual machine.

When Apple moved to their own CPU design (Apple Silicon), retaining the Little-Endian architecture made sense because it avoids rebuilding the entire OS again, possibly introducing bugs into the bargain. This is the third (remarkably seamless) CPU architecture migration that Apple has undergone with the Macintosh operating system and the AIFF format has survived intact.

Note that the PowerPC and generic ARM CPUs can operate in both modes and are described as Bi-Endian.

Multiple Channel Support

AIFF can theoretically support an unlimited number of channels. The samples are interleaved together so that samples for a stereo pair (left and right channels) are stored adjacently. A group of samples stored like this across all the channels is called a Sample Frame.

Monaural sound, which we covered in the last section, is just a sequence of single samples so the sample framing is implied.

Multiple channels are mapped to numbers according to this grid (extracted from the specification). A sample frame spans all of the channels in use.

There are other alternative channel mapping arrangements to support more channels. The AIFF version 1.3 specification only describes 6 channel surround source mapping. This is sufficient for 5.1 surround but the source mapping is undefined beyond that. The accepted convention is to use the ITU-R BS.2159 standard. You may encounter systems that map the surround channels differently.

Sample Sizes

AIFF supports sample sizes from 1 to 32-bits.

Interestingly, music can be produced with a simple square wave by adjusting the on and off duty cycle in the time domain. So, specifying 1-bit audio is not such a crazy idea after all.

Realistically you would probably need at least 5-bits for low-quality speech coding. Sampling music at 8-bits delivers poor quality and 16-bits is considered a minimum for most applications. Larger sample sizes are useful in studio and production environments.

If the sample size does not fully occupy the bytes in the storage arrangement, it is left justified and right padded with zero bits. This example shows how a 12-bit sample is placed into a 16-bit word.

Mathematically (in a Boolean sense), the padding would have been more helpful had it been placed at the most significant end of the data word. That would have avoided bit-shifting the values.

There is a clever concept involved here. Placing the padding at the least significant end doesn’t improve the resolution or reduce the quantization. The innovation is that it does have (nearly) the same dynamic range (loudness) as the 16-bit data quality. This is elegant simplicity at work again because 16-bit and 12-bit samples can be mixed with no audible change to the loudness.

Sample Rates

The AIFF specification does not mandate any particular sample rates. The sample frames are delivered at a rate determined by an IEEE 64-bit double-precision floating-point value in the COMM chunk. The range of possible values supported by this floating point value far exceeds any sample rates we might ever encounter.

Chunk Format Details

AIFF files are organized into chunks of data. Each chunk has a header and a payload body.

A chunk header starts with a 32-bit long word containing a FourCC chunk type value. This determines how the application software should interpret the payload. The size of the payload is another 32-bit value. This size value does not include the 8 bytes of header data.

The chunk type ID is composed of four printable ASCII compatible characters packaged into a 32-bit long-word. The space character and other punctuation symbols are permitted.

Refer to Chapter 4-2 for a description of how FourCC codes work.

File Format Details

After that, the chunks can be presented in any order. The second and subsequent chunks are described as Local data. The maximum file size is 4GB. This is the only constraint on the number of channels or the run-time of the sampled sound data. These chunk types are important and must be present when mandated by the specification. Note that there are different constraints for classic AIFF files and the later AIFF-C files.

Here is an illustration showing a simple AIFF-C file with four chunks. The brackets indicate the example value stored in each property. The shaded boxes represent the individual bytes:

• 1 box = 8-bit byte.
• 2 boxes = 16-bit word.
• 4 boxes = 32-bit long-word.
• 8 boxes = 64 bit double-precision value.
• 16 boxes = Illustrates a container for a text string.

Here is an example of the 16 box framing:

FORM – File Format Descriptor Chunk

FVER – Format Version Chunk

COMM – Common Data Chunk

The Common chunk describes fundamental parameters for the sampled data. This chunk must be present. Without it, the player cannot unpack and stream the sample frames.

The basic format for classic AIFF files carries an 18-byte payload with the following properties:

The Extended Common chunk in the AIFF-C files has two additional parameters that increase size of the payload. Most AIFF files use this format now:

• A 32-bit FourCC compression type that describes the audio codec being used.
• A human readable name for the compression type.

Note that the compression type value is case sensitive with similar upper and lower-case variants. Consult the specifications for each one to ascertain whether they are otherwise identical.

The compression type registry is managed by Apple. Send them details of any compression types you define. The address described in Appendix B of the standard should reach the correct department but it is quite old.

The compression types registry does not appear to be publicly available so it must be synthesized by assembling the information from whatever sources are available.

If the same type is used for multiple different compression algorithms it creates a namespace-collision. The problem escalates if the content is propagated and the media is distributed with a compromised type value.

These are the compression type values to avoid if you are creating your own. There may be other types not documented here that we have not yet found.

Many earlier codecs that were used with AIFF-C are now obsolete and have been superseded by MPEG and other standards. That doesn’t necessarily mean you can use the newer codecs inside an AIFF-C file. It may be technically possible but your files would be proprietary and use a potentially unregistered FourCC code for the compression type. That would render them unreadable to most other applications. Simply registering the FourCC code will not automatically enable other apps to read your files.

This is an unofficial list of the codec types aggregated from a variety of sources.

SSND – Sampled Sound Data Chunk

• Size of the sound data chunk (not including the header data).
• Offset to the first sample frame at the start of the playable sound. This could adjust the in-point for playback. It is normally set to zero to play sample frames from the beginning.
• Size of alignment blocks. This indicates the size in bytes of the blocks that the audio data is packaged into. It is used in conjunction with the offset value. Most applications do not use this and it is usually set to zero. Block alignment speeds up disk access for real-time recording applications.

The sampled sound data immediately follows the block-size value in the header.

The sound data must contain an even number of bytes. A padding zero-byte might be added to the end to ensure the samples finish on a word boundary. Additional zero-byte padding may be necessary if alignment blocks are used.

Other Optional AIFF Chunk Types

These chunk types are optional and may not be present in an AIFF file. This is compiled from a variety of sources and includes some non-standard items. It may help when disassembling AIFF files. Some chunk types may only be supported by specific implementations.

Tagging & Metadata

Searching online for information about metadata storage in AIFF files is challenging. Some commentators state that AIFF files cannot carry metadata. Others tell us that ID3 is incompatible with AIFF containers. Neither of these assertions is true.

AIFF is flexible and extensible and carries data chunks other than audio samples. This is self-evident with the use of AIFF in iTunes where artist, track information and cover-artwork will survive when moving AIFF files from one library to another.

Any arbitrary metadata can be stored in the text chunks within an AIFF file. Since that data does not affect the sound playback, it could be ID3 structured tag data.

There are three embedded metadata/tagging approaches suitable for AIFF files. Externally maintained metadata is always a possibility too:

• AIFF standardized Native chunks – the AIFF specification describes Name, Author, Comment, Annotation, and Copyright text chunks. These are well supported by applications running on macOS. The specification is completely open and available for other platform developers to implement.
• ID3 tags – These are widely supported by many tools. Some tools are free and others have commercial fee-based licenses. All platforms are supported to some extent. You must use ID3v2 structured tag data in AIFF files.
• XMP – The Adobe Extensible Metadata Platform (XMP) was devised for use in JPEG images but can also be used with AIFF files. Even though XMP has been standardized as ISO 16684-1:2012, the tools to support it are predominantly provided as proprietary solutions by Adobe.

File Name Extensions

Media Type Identifiers

Applying AIFF

Although AIFF is an old format, it is still a good solution for storing uncompressed audio, especially for long-term archiving purposes.

Whilst this is an ancient and no longer actively developed format, files of this type will be widely used in libraries and archives. It has been sufficiently popular that media libraries will very likely continue to hold AIFF and AIFF-C files for hundreds of years into the future.

These Appendix articles contain additional information you may find useful: