Files of this type and auxiliary type contain sampled sounds in Apple Computer's Audio Interchange File Format (Audio IFF).
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 "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:
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.
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:
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.
__________________________ | FORM AIFF Chunk | | chkID = 'FORM' | | formType = 'AIFF' | | __________________ | | | Common Chunk | | | | ckID = 'COMM' | | | |__________________| | | __________________ | | | Sound Data Chunk | | | | ckID = 'SSND' | | | |__________________| | |__________________________| 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.
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 describes fundamental parameters of the sampled sound.
One, and only one, Common Chunk is required in every FORM AIFF.
A large part of interpreting Audio IFF files revolves around the two concepts of sample points and sample frames.
A sample point is a 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.
___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ | | | | | | | | | | | | | | | | | | 1 0 1 0 0 0 0 1 | 0 1 1 1 0 0 0 0 | |___|___|___|___|___|___|___|___|___|___|___|___|___|___|___|___| <---------------------------------------------> <-------------> 12 bit sample point is left justified rightmost 4 bits are zero padded Figure 2 - A 12-Bit Sample Point
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.
sample sample sample frame 0 frame 1 frame N _____ _____ _____ _____ _____ _____ | ch1 | ch2 | ch1 | ch2 | . . . | ch1 | ch2 | |_____|_____|_____|_____| |_____|_____| _____ | | = one sample point |_____| 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.
channel 1 2 3 4 5 6 __________ __________ __________ __________ __________ __________ | left | right | | | | | stereo | | | | | | | |__________|__________|__________|__________|__________|__________| | left | right | center | | | | 3 channel | | | | | | | |__________|__________|__________|__________|__________|__________| | front | front | rear | rear | | | quad | left | right | left | right | | | |__________|__________|__________|__________|__________|__________| | left | center | right | surround | | | 4 channel | | | | | | | |__________|__________|__________|__________|__________|__________| | left | left | center | right | right | surround | 6 channel | | center | | | center | | |__________|__________|__________|__________|__________|__________| 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 contains the actual sample frames.
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.
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.
____________ __________________________________ ____________ |\\ unused \\| sample frames |\\ unused \\| |____________|__________________________________|____________| <-- offset --><- numSampleFrames sample frames -> | blockSize | | | | |<- bytes ->| | | | |_______________|_______________|_______________|_______________| block N-1 block N block N+1 block N+2 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 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.
A marker has the following format:
Sample Frames ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ | | | | | | | | | | | | | |___|___|___|___|___|___|___|___|___|___|___|___| ^ ^ ^ position 0 position 5 position 12 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 defines basic parameters that an instrument, such as a sample, could use to play the sound data.
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.
___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ ___ sample frames | | | |<--- loop segment ---->| | | | |___|___|___|___|___|___|___|___|___|___|___|___| ^ ^ begin position end position 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.
The following structure describes a loop:
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 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.
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 contains information pertinent to audio recording devices.
The Audio Recording Chunk is optional. No more than one Audio Recording Chunk may appear in a FORM AIFF.
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.
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 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.
The format of a comment is described below:
Note: The routine to convert timeStamp into a standard GS/OS date, as described in the Audio IFF 1.3 specification, is not available at this time.
The Comments Chunk is optional. No more than one Comments Chunk may appear in a single FORM AIFF.
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.
This chunk names the sampled sound.
No more than one Name Chunk may exist within a FORM AIFF.
This chunk can be used to identify the creator of a sampled sound.
No more than one Author Chunk may exist within a FORM AIFF.
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."
No more than one Copyright Chunk may exist within a FORM AIFF.
Use of this comment is discouraged within FORM AIFF. The more powerful Comments Chunk should be used instead.
Many Annotation Chunks may exist within a FORM AIFF.
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.
Common Chunk Highest Precedence | Sound Data Chunk | Marker Chunk | Instrument Chunk | Comment Chunk | Name Chunk | Author Chunk | Copyright Chunk | Annotation Chunk | Audio Recording Chunk | MIDI Data Chunk | Application Specific Chunk Lowest Precedence 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 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.
_____________________________________________________________________ | FORM AIFF | | _____________ | | ckID |_ 'FORM' ____| | | ckSize |_ 176516 ____| | | _____________ formType |_ 'AIFF' ____| __________________________ | | | Common ckID |_ 'COMM' ____| | | | | Chunk ckSize |_ 18 ________| | | | | numChannels |_ 2 ___|_____ | | | | numSampleFrames |_ 88200 _____| | | | | sampleSize |_ 16 __|_______________________________ | | | |___________ sampleRate |_ 44100.00 ____________________________| | | | | Marker ckID |_ 'MARK' _____| | | | | Chunk ckSize |_ 34 _________| | | | | numMarkers |_ 2 ___| | | | | id |_ 1 ___|_______ | | | | position |_ 44100 ___ ___|___ ___ ___ ___ ___ ___ | | | | markerName | 8 |'b'|'e'|'g'|' '|'l'|'o'|'o'|'p'| 0 | | | | | id |_ 2 ___|_______ | | | | position |_ 88200 _______|___ ___ ___ ___ ___ ___ | | | |___________ markerName | 8 |'e'|'n'|'d'|' '|'l'|'o'|'o'|'p'| 0 | | | | | Instrument ckID |_ 'INST' ______| | | | | Chunk ckSize |_ 20 __________| | | | | baseNote | 60| | | | | detune | -3| | | | | lowNote | 57| | | | | highNote | 63| | | | | lowVelocity | 1 | | | | | highVelocity |127|__ | | | | gain |_ 6 __| | | | | sustainLoop.playMode |_ 1 __| | | | | sustainLoop.beginLoop |_ 1 __| | | | | sustainLoop.endLoop |_ 2 __| | | | | releaseLoop.playMode |_ 0 __| | | | | releaseLoop.beginLoop |_ - __| | | | |__ releaseLoop.endLoop |_ - __|__________________________________| | | | Sound ckID |_ 'SSND' ______| | | | | Data ckSize |_ 176408 ______| | | | | Chunk offset |_ 0 ___________| | | | | blockSize |_ 0 ___________| _______ _______ | | | | soundData |_ch 1 _|_ch 2 _| . . . |_ch 1 _|_ch 2 _| | | | | first sample frame 88200th sample frame | | | |_________________________________________________________________| | |_____________________________________________________________________| Figure 9 - Sample FORM AIFF
This and all of the other Apple II Technical Notes have been converted to HTML by Aaron Heiss as a public service to the Apple II community, with permission by Apple Computer, Inc. Any and all trademarks, registered and otherwise, are properties of their owners.