File Type: $D8 (216)

Auxiliary Type: $0000

Full Name: Audio Interchange File Format File

Short Name: Audio IFF File

Revised by: Matt Deatherage March 1991

Written by: Matt Deatherage March 1989

Files of this type and auxiliary type contain sampled sounds in Apple Computer's Audio Interchange File Format (Audio IFF).

Changes since March 1989: Corrected the description of the sample format and added a warning about interchange format testing. Added a reference to ConvSeconds for time utilities.

The Audio Interchange File Format (Audio IFF) provides a standard for storing sampled sounds. The format is quite flexible, allowing the storage of monaural or multichannel sampled sounds at a variety of sample rates and sample widths.

This Note describes version 1.3 (January 4, 1989) of the Audio Interchange File Format. This Note describes Audio IFF as it pertains to Apple II developers. For a copy of the original Audio IFF specification, you may order "Audio Interchange File Format v. 1.3" from APDA.

Audio IFF conforms to the "EA IFF 85" Standard for Interchange Format Files developed by Electronic Arts.

Audio IFF is primarily an interchange format, although application designers should find it flexible enough to use as a data storage format as well. If an application does choose to use a different storage format, it should be able to convert to and from the format defined in this document. This ability to convert will facilitate the sharing of sound data between applications.

Audio IFF is the result of several meetings held with music developers over a period of ten months during 1987 and 1988. Apple Computer greatly appreciates the comments and cooperation provided by all developers who helped define this standard.

Another "EA IFF 85" sound storage format is "8SVX" IFF 8-bit Sampled Voice, by Electronic Arts. "8SVX," which handles eight-bit monaural samples, is intended mainly for storing sound for playback on personal computers. Audio IFF is intended for use with a larger variety of computers, sampled sound instruments, sound software applications, and high fidelity recording devices.

The official name for this standard is Audio Interchange File Format. If an application program needs to present the name of this format to a user, such as in a "Save As..." dialog box, the name can be abbreviated to Audio IFF. Although the Apple IIGS Sampled Instrument format is often abbreviated as "ASIF," referring to Audio IFF files by a four-letter abbreviation (i.e., "AIFF") in user-level documentation or program-generated messages should be avoided.

The Chunk Concept

The "EA IFF 85" Standard for Interchange Format Files defines an overall structure for storing data in files. Audio IFF conforms to the "EA IFF 85" standard. This Note describes those portions of "EA IFF 85" that are germane to Audio IFF. For a more complete discussion of "EA IFF 85," please refer to "EA IFF 85" Standard for Interchange Format Files.

Audio IFF, like all IFF-style storage formats, is a series of discrete pieces, or "chunks." Each chunk has an eight-byte "header," which is as follows:

ckID 4 Bytes The ID for this chunk. These four bytes must be ASCII characters in the range $20-$7F. Spaces may not precede printing characters, although trailing spaces are allowed. Characters outside the range $20-$7F are forbidden. A program can determine how to interpret the chunk data by examining ckID.

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID. You may think of this value as the offset to the end of the chunk. Note that this is a Reverse Long; the bytes are stored high byte first.

ckData Chunk The data, specific to each individual chunk. There are exactly ckSize bytes of data here. If the length of the chunk is odd, a pad byte of $00 must be added at the end. The pad byte is not included in ckSize.

Since Audio IFF is primarily an interchange format, it will come as no surprise to find that all constants, such as each chunk's ckSize field, are stored in reverse format (the bytes of multiple-byte values are stored with the high-order bytes first). This is true for all constants, which are marked in their individual descriptions by the Reverse notation.

Note: All numeric values in this Note are signed unless otherwise noted. This is different from the normal File Type Note convention.

An Audio IFF file is a collection of a number of different types of chunks. There is a Common Chunk which contains important parameters describing the sampled sound, such as its length and sample rate. There is a Sound Data Chunk which contains the actual audio samples. There are several other optional chunks which define markers, list instrument parameters, store application-specific information, etc. All of these chunks are described in detail in this Note.

File Structure

The chunks in an Audio IFF file are grouped together in a container chunk. "EA IFF 85" Standard for Interchange Format Files defines a number of container chunks, but the one used by Audio IFF is called a FORM. A FORM has the following format:

ckID 4 Bytes The ID for this chunk. These four bytes must be "FORM."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID. You may think of this value as the offset to the end of the chunk. Note that this is a Reverse Long; the bytes are stored high byte first. Also note that the data portion of the chunk is broken into two parts, formType and chunks.

formType 4 Bytes Describes what's in the FORM chunk. For Audio IFF files, formType is always "AIFF." This indicates that the chunks within the FORM pertain to sampled sound. A FORM chunk of formType AIFF is called a FORM AIFF.

chunks Bytes The chunks contained within the FORM. These chunks are called local chunks. A FORM AIFF along with its local chunks make up an Audio IFF file.

Figure 1 is a pictorial representation of a simple Audio IFF file. It consists of a single FORM AIFF which contains two local chunks, a Common Chunk, and a Sound Data Chunk.



Figure 1-Simple Audio IFF File

There are no restrictions on the ordering of local chunks within a FORM AIFF.

The FORM AIFF is stored in a file with file type $D8 and auxiliary type $0000. Versions 1.2 and earlier of the Audio IFF standard used file type $CB and auxiliary type $0000. This is incorrect; the assignment listed in this Note is the correct assignment. Applications which use Audio IFF files with the older assignment should not perform adversely, since no one should be creating files of any kind with the older assignment. However, we strongly urge developers to update their applications as soon as possible to only create Audio IFF files with file type $D8 and auxiliary type $0000.

Audio IFF files may be identified in other file systems as well. On a Macintosh under MFS or HFS, the FORM AIFF is stored in the data fork of a file with file type "AIFF." This is the same as the formType of the FORM AIFF.

Note: Applications should not store any data in the resource fork of an Audio IFF file, since this information may not be preserved by all applications or in translation to foreign file systems. Applications can use the Application Specific Chunk, described later in this Note, to store extra information specific to their application.

In file systems that use file extensions, such as MS-DOS or UNIX, it is recommended that Audio IFF file names have the extension ".AIF."

A more detailed visual example of an Audio IFF file may be found later in this Note. Please refer to it as often as necessary while reading the remainder of this Note.

Local Chunk Types

The formats of the different local chunk types found within a FORM AIFF are described in the following sections, as are their ckIDs.

There are two types of chunks: required and optional. The Common Chunk is required. The Sound Data chunk is required if the sampled sound has a length greater than zero. All other chunks are optional. All applications that use FORM AIFF must be able to read the required chunks and can choose to selectively ignore the optional chunks. A program that copies a FORM AIFF should copy all the chunks in the FORM AIFF, even those it chooses not to interpret the optional chunks.

To ensure that this standard remains usable by all developers across machine families, only Apple Computer, Inc. should define new chunk types for FORM AIFF. If you have suggestions for new chunk types, Apple is happy to listen. Please send all comments to the address listed in "About File Type Notes" to the attention of Audio IFF Suggestions.

The Common Chunk

The Common Chunk describes fundamental parameters of the sampled sound.

ckID 4 Bytes The ID for this chunk. These four bytes must be "COMM."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID. For the Common Chunk, this is always 18.

numChannels Rev. Word The number of audio channels for the sound. A value of 1 means monophonic sound, 2 means stereo, 4 means four-channel sound, and so on. Any number of audio channels may be represented. The actual sounds samples are stored in the Sound Data Chunk.

numSampleFrames Rev. Unsigned Long The number of sample frames in the Sound Data Chunk. Sample frames are described below. Note that numSampleFrames is the number of sample frames, not the number of bytes nor the number of sample points (also described below) in the Sound Data Chunk. The total number of sample points in the file is numSampleFrames multiplied by numChannels.

sampleSize Rev. Word The number of bits in each sample point. This can be any number from 1 to 32.

sampleRate Rev. Extended The sample Rate at which the sound is to be played back, in sample frames per second.

One, and only one, Common Chunk is required in every FORM AIFF.

Sample Points and Sample Frames

A large part of interpreting Audio IFF files revolves around the two concepts of sample points and sample frames.

A sample point is a linear, two's-complement value representing a sample of a sound at a given point in time. A sample point may be from 1 to 32 bits wide, as determined by sampleSize in the Common Chunk. Sample points are stored in an integral number of contiguous bytes. One- to eight-bit wide sample points are stored in one byte, 9- to 16-bit wide sample points are stored in two bytes, 17- to 24-bit wide sample points are stored in three bytes, and 25- to 32-bit wide sample points are stored in four bytes (most significant byte first). When the width of a sample point is not a multiple of eight bits, the sample point data is left justified, with the remaining bits zeroed. An example case is illustrated in Figure 2. A 12-bit sample point, binary 101000010111, is stored left justified in two bytes. The remaining bits are set to zero.



Figure 2-A 12-Bit Sample Point

Warning: Previous versions of this Note omitted the important phrase "two's-complement" in the preceding description of a sample point. This means that sound files created using only this Note (and not also the Audio IFF Specification version 1.3) are incompatible with Audio IFF applications created from the specification. However, any simple amount of testing with Audio IFF files available from a variety of Macintosh programs would instantly make this obvious to an Audio IFF programmer.

We cannot emphasize enough the importance of cross-platform testing with Audio IFF or any interchange file format. It's not enough to create the files; you have to make sure your application can read the files created by other applications and vice-versa. An interchange format that doesn't interchange correctly is somewhat less than useful.

Sample frames are sets of sample points which are interleaved for multichannel sound. Single sample points from each channel are interleaved such that each sample frame is a sample point from the same moment in time for each channel available. This is illustrated in Figure 3 for the stereo (two channel) case.



Figure 3-Sample Frames for Multichannel Sound

For monophonic sound, a sample frame is a single sample point. For multichannel sounds, you should follow the conventions in Figure 4.



Figure 4-Sample Frame Conventions for Multichannel Sound

Note: Portions of Figure 4 do not follow the Apple IIGS standard of right on even channels and left on odd channels. The portions that do follow this convention usually use channel two for right instead of channel zero as most Apple IIGS standards. Be prepared to interpret data accordingly.

Sample frames are stored contiguously in order of increasing time. The sample points within a sample frame are packed together; there are no unused bytes between them. Likewise, the sample frames are packed together with no pad bytes.

The Sound Data Chunk

The Sound Data Chunk contains the actual sample frames.

ckID 4 Bytes The ID for this chunk. These four bytes must be "SSND."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID.

offset Rev. Unsigned Long Determines where the first sample frame in the soundData starts, in bytes. Most applications will not use offset and should set it zero. Use for a non-zero offset is explained below.

blockSize Rev. Unsigned Long Used in conjunction with offset for block-aligning sound data. It contains the size in bytes of the blocks to which soundData is aligned. As with offset, most applications will not use blockSize and should set it to zero. More information on blockSize is given below.

soundData Bytes Contains the actual sample frames that make up the sound. The number of sample frames in the soundData is determined by the numSampleFrames parameter in the Common Chunk.

The Sound Data Chunk is required unless the numSampleFrames field in the Common Chunk is zero. A maximum of one Sound Data Chunk may appear in a FORM AIFF.

Block-Aligning Sound Data

There may be some applications that, to ensure real time recording and playback of audio, wish to align sampled sound data with fixed-size blocks. This alignment can be accomplished with the offset and blockSize parameters of the Sound Data Chunk, as shown in Figure 5.



Figure 5-Block-Aligned Sound Data

In Figure 5, the first sample frame starts at the beginning of block N. This is accomplished by skipping the first offset bytes of the soundData. Note too, that the soundData bytes can extend beyond valid sample frames, allowing the soundData bytes to end on a block boundary as well.

The blockSize specifies the size in bytes of the block to which you would align the sound data. A blockSize of zero indicates that the sound data does not need to be block-aligned. Applications that don't care about block alignment should set the blockSize and offset to zero when creating Audio IFF files. Applications that write block-aligned sound data should set blockSize to the appropriate block size. Applications that modify an existing Audio IFF file should try to preserve alignment of the sound data, although this is not required. If an application does not preserve alignment, it should set the blockSize and offset to zero. If an application needs to realign sound data to a different sized block, it should update blockSize and offset accordingly.

The Marker Chunk

The Marker Chunk contains markers that point to positions in the sound data. Markers can be used for whatever purposes an application desires. The Instrument Chunk, defined later in this Note, uses markers to mark loop beginning and end points.

ckID 4 Bytes The ID for this chunk. These four bytes must be "MARK."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID.

numMarkers Rev. Unsigned Word The number of markers (defined below) in the Marker Chunk. If non-zero, this is followed by the markers themselves. Because all fields in a marker are an even number of bytes, the length of any marker will always be even. Thus, markers are packed together with no unused bytes between them, although the markers themselves need not be ordered in any particular manner.

Marker Markers Defined below.

A marker has the following format:

MarkerID Rev. Word The ID for this marker. This is a number that uniquely identifies the marker within a FORM AIFF. The number can be any positive, non-zero integer, as long as no other marker within the same FORM AIFF has the same ID.

position Rev. Unsigned Long Determines the marker's position in the sound data. Markers conceptually fall between two sample frames. A marker that falls before the first sample frame in the sound data is at position zero, while a marker that falls between the first and second sample frame in the sound data is at position one. Units for position are sample frames, not bytes nor sample points.

markerName String Pascal-type string containing the name of the mark.



Figure 6-Sample Frame Marker Positions

Note: Some "EA IFF 85" files store strings as C-style strings (null terminated). Audio IFF uses Pascal-style (length byte) strings because they are easier to skip over when scanning a file or a chunk.

The Marker Chunk is optional. No more than one Marker Chunk can appear in a FORM AIFF.

The Instrument Chunk

The Instrument Chunk defines basic parameters that an instrument, such as a sample, could use to play the sound data.

ckID 4 Bytes The ID for this chunk. These four bytes must be "INST."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID. For the Instrument Chunk, this field is always 20.

baseNote Byte The note at which the instrument plays the sound data without pitch modification. Units are MIDI (Musical Instrument Digital Interface) note numbers, and are in the range 0 through 127. Middle C is 60.

detune Byte Determines how much the instrument should alter the pitch of the sound when it is played . Units are cents (1/100 of a semitone), and range from -50 to +50. Negative numbers mean that the pitch of the sound should be lowered, while positive numbers mean that it should be raised.

lowNote Byte Suggested lowest note on a keyboard for playback of the sound data. The sound data should be played if the instrument is requested to play a note between the lowNote and highNote, inclusive. The base note does not have to be within this range. Units for lowNote and highNote are MIDI note values.

highNote Byte Suggested highest note on a keyboard for playback of the sound data. See the description of lowNote above.

lowVelocity Byte The low end of the suggested range of velocities for playback of the sound data. The sound data should be played if the note-on velocity is between lowVelocity and highVelocity, inclusive. Units are MIDI velocity values, 1 (lowest velocity) through 127 (highest velocity).

highVelocity Byte The high end of the suggested range of velocities for playback of the sound data. See the description of lowVelocity above.

gain Rev. Word The amount by which to change the gain of the sound when it is played. Units are decibels. For example, 0 dB means no change, 6 dB means double the value of each sample point, while -6 dB means halve the value of each sample point.

sustainLoop Loop A loop that is to be played when an instrument is sustaining a sound. The format of loops is described below.

releaseLoop Loop A loop that is to be played when an instrument is in the release phase of playing back a sound. The release phase usually occurs after a key on an instrument is released. The format of loops is described below.

Loops

Sound data can be looped, allowing a portion of the sound to be repeated to lengthen the sound. A loop is marked with two points, a begin position and an end position. There are two ways to play a loop, forward looping and forward/backward looping. In the case of forward looping, playback begins at the beginning of the sound, continues past the begin position and continues to the end position, at which point playback starts again at the begin position. The segment between the begin and end positions, called the loop segment, is played repeatedly until interrupted by a user action, such as the release of a key on a sampling instrument.



Figure 7-Sample Frame Looping

With forward/backward looping, the loop segment is first played from the begin position to the end position, and then played backwards from the end position to the begin position. This flip-flop pattern is repeated over and over again until interrupted.

To end a loop, finish the current loop section and don't repeat it any more. This usually means playing to the end position, but it can mean playing back to the beginning position if in the backwards half of a forward/backward loop.

The following structure describes a loop:

playMode Rev. Word The type of looping to be performed.

0 = no looping

1 = Forward looping

2 = Forward/Backward looping

If 0 is specified, the loop points are ignored during playback.

beginLoop Rev. Word A Marker ID of the marker to the begin position.

endLoop Rev. Word A Marker ID of the marker to the end position. The begin position must be less than the end position. If this is not the case, the loop segment has zero or negative length and no looping occurs.

The Instrument Chunk is optional. No more than one Instrument Chunk can appear in a FORM AIFF.

ASIF Note: The Apple IIGS Sampled Instrument Format also defines a chunk with ID of "INST," which is not the same as the Audio IFF Instrument Chunk. A good way to tell the two chunks apart in generic IFF-style readers is by the ckSize fields. The Audio IFF Instrument Chunk's ckSize field is always 20, whereas the Apple IIGS Sampled Instrument Format Instrument Chunk's ckSize field, for structural reasons, can never be 20.

The MIDI Data Chunk

The MIDI Data Chunk can be used to store MIDI data. Please refer to Musical Instrument Digital Interface Specification 1.0, available from the International MIDI Association, for more details on MIDI.

The primary purpose of this chunk is to store MIDI System Exclusive messages, although other types of MIDI data can be stored in the block as well. As more instruments come to market, they will likely have parameters that have not been included in the Audio IFF specification. The MIDI System Exclusive messages for these instruments may contain many parameters that are not included in the Instrument Chunk. For example, a new sampling instrument may have more than the two loops defined in the Instrument Chunk. These loops will likely be represented in the MIDI System Exclusive message for the new machine. This MIDI System Exclusive message can be stored in the MIDI Data Chunk.

ckID 4 Bytes The ID for this chunk. These four bytes must be "MIDI."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID.

MIDIdata Unsigned Bytes A stream of MIDI Data.

The MIDI Data Chunk is optional. Any number of MIDI Data Chunks may exist in a FORM AIFF. If MIDI System Exclusive messages for several instruments are to be stored in a FORM AIFF, it is better to use one MIDI Data Chunk per instrument than one big MIDI Data Chunk for all of the instruments.

The Audio Recording Chunk

The Audio Recording Chunk contains information pertinent to audio recording devices.

ckID 4 Bytes The ID for this chunk. These four bytes must be "AESD."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID. For the Audio Recording Chunk, this value is always 24.

AESChannelStatusData 24 Bytes These 24 bytes are specified in the AES Recommended Practice for Digital Audio Engineering--Serial Transmission Format for Linearly Represented Digital Audio Data, section 7.1, Channel Status Data. This document describes a format for real-time digital transmission of digital audio between audio devices. This information is duplicated in the Audio Recording Chunk for convenience. Bits 2, 3, and 4 of byte zero are of general interest as they describe recording emphasis.

The Audio Recording Chunk is optional. No more than one Audio Recording Chunk may appear in a FORM AIFF.

The Application Specific Chunk

The Application Specific Chunk can be used for any purposes whatsoever by developers and application authors. For example, an application that edits sounds might want to use this chunk to store editor state parameters such as magnification levels, last cursor position, etc.

ckID 4 Bytes The ID for this chunk. These four bytes must be "APPL."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID. For the Audio Recording Chunk, this value is always 24.

OSType 4 Bytes Identifies a particular application. For Apple II applications, these four bytes should always be `pdos' ($70 $64 $6F $73). In this case, the beginning of the data area is defined to be a Pascal string containing the name of the application. For Macintosh applications, this is simply the four-character signature as registered with Developer Technical Support.

AppSignature String Pascal string identifying the application.

data Bytes Data specific to the application.

Note: AppSignature does not exist unless OSType is "pdos." In all other cases, the data area starts immediately following the OSType field.

The Application Specific Chunk is optional. Any number of Application Specific Chunks may exist in a single FORM AIFF.

The Comments Chunk

The Comments Chunk is used to store comments in the FORM AIFF. "EA IFF 85" has an Annotation Chunk (used in ASIF) that can be used for comments, but the Comments Chunk has two features not found in the "EA IFF 85" chunk. They are a time-stamp for the comment and a link to a marker.

ckID 4 Bytes The ID for this chunk. These four bytes must be "COMT."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID.

numComments Rev. Unsigned Word The number of comments in the Comments Chunk. This is followed by the comments themselves. Comments are always an even number of bytes in length, so there is no padding between comments in the Comments Chunk.

Comment Comment The comments. There are numComments of them.

The format of a comment is described below:

timeStamp Rev. Unsigned Long Indicates when the comment was created. Units are the number of seconds since 12:00 a.m. (midnight), January 1, 1904. This is the standard Macintosh time format. Macintosh routines to manipulate this time stamp may be found in Inside Macintosh, Volume II.

Note: Apple IIGS System Software 5.0.3 and later contains a Miscellaneous Tools routine, ConvSeconds, which can convert times in the format of timeStamp into standard ProDOS, GS/OS or HyperCard IIGS dates.

marker Rev. Word A Marker ID. If this comment is linked to a marker (to store a long description of a marker as a comment, for example), this is the ID of that marker. Otherwise marker is zero, indicating there is no such link.

count Rev. Word Count of the number of characters in the following text. By using a word instead of a byte, much larger comments may be created.

text Bytes The comment itself. If the text is an odd number of bytes in length, it must be padded with a zero byte to ensure that it is an even number of bytes in length. If the pad byte is present, it is not included in count.

The Comments Chunk is optional. No more than one Comments Chunk may appear in a single FORM AIFF.

The Text Chunks

These four chunks are included in the definition of every "EA IFF 85" file. All are text chunks; their data portion consists solely of text. Each of these chunks is optional.

The Name Chunk

This chunk names the sampled sound.

ckID 4 Bytes The ID for this chunk. These four bytes must be "NAME."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID.

Name Bytes ASCII characters ($20-$7F) representing the name. There should be ckSize characters.

No more than one Name Chunk may exist within a FORM AIFF.

The Author Chunk

This chunk can be used to identify the creator of a sampled sound.

ckID 4 Bytes The ID for this chunk. These four bytes must be "AUTH."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID.

author Bytes ASCII characters ($20-$7F) representing the name of the author of the sampled sound. There should be ckSize characters.

No more than one Author Chunk may exist within a FORM AIFF.

The Copyright Chunk

The Copyright Chunk contains a copyright notice for the sound. The copyright contains a date followed by the copyright owner. The chunk ID "(c) " serves as the copyright character ((c)). For example, a Copyright Chunk containing the text "1989 Apple Computer, Inc." means "(c) 1989 Apple Computer, Inc."

ckID 4 Bytes The ID for this chunk. These four bytes must be "(c) ".

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID. You may think of this value as the offset to the end of the chunk.

notice Bytes ASCII characters ($20-$7F) representing a copyright notice for the voice or collection of voices. There should be ckSize characters.

No more than one Copyright Chunk may exist within a FORM AIFF.

The Annotation Chunk

Use of this comment is discouraged within FORM AIFF. The more powerful Comments Chunk should be used instead.

ckID 4 Bytes The ID for this chunk. These four bytes must be "ANNO."

ckSize Rev. Long The length of this chunk, excluding ckSize and cdID. You may think of this value as the offset to the end of the chunk. Note that this is a Reverse Long; the bytes are stored high byte first.

author Bytes ASCII characters ($20-$7F) representing the name of the author of the voices or collection of voices. There should be ckSize characters.

Many Annotation Chunks may exist within a FORM AIFF.

Chunk Precedence

Several of the local chunks for FORM AIFF may contain duplicate information. For example, the Instrument Chunk defines loop points and MIDI System Exclusive data in the MIDI Data Chunk may also define loop points. What happens if these loop points are different? How is an application supposed to loop the sound? Such conflicts are resolved by defining a precedence for chunks. This precedence is illustrated in Figure 8.



Figure 8-Chunk Precedence

The Common Chunk has the highest precedence, while the Application Specific Chunk has the lowest. Information in the Common Chunk always takes precedence over conflicting information in any other chunk. The Application Specific Chunk always loses in conflicts with other chunks. By looking at the chunk hierarchy, for example, one sees that the loop points in the Instrument Chunk take precedence over conflicting loop points found in the MIDI Data Chunk.

It is the responsibility of applications that write data into the lower precedence chunks to make sure that the higher precedence chunks are updated accordingly.

Figure 9 (on the following page) illustrates an example of a FORM AIFF. An Audio IFF file is simple a file containing a single FORM AIFF. The FORM AIFF is stored in the data fork of file systems that can handle resource forks.

Further Reference

* Apple Numerics Manual, Second Edition

* File Type Note File Type $D8, Auxiliary Type $0002, Apple IIGS Sampled Instrument Format

* Audio Interchange File Format v1.3 (APDA)

* AES Recommended Practice for Digital Audio Engineering--Serial Transmission Format for Linearly Represented Digital Audio Data, Audio Engineering Society, 60 East 42nd Street, New York, NY 10165

* MIDI: Musical Instrument Digital Interface, Specification 1.0, the International MIDI Association.

* "EA IFF 85" Standard for Interchange Format Files (Electronic Arts)

* "8SVX" IFF 8-bit Sampled Voice (Electronic Arts)



Figure 9-Sample FORM AIFF