AIFF/AIF格式解析

最新推荐文章于 2022-10-26 20:33:09 发布

b547510

最新推荐文章于 2022-10-26 20:33:09 发布

阅读量3.6k

点赞数

分类专栏：格式解析文章标签：流媒体格式解析 AIFF格式解析 AIF格式解析 demux

格式解析专栏收录该内容

6 篇文章 0 订阅

订阅专栏

Audio Interchange FileFormat: "AIFF"

A Standard for Sampled Sound Files

Version 1.3

Apple Computer, Inc.

______________________________________________________________________________

Modification History

Version 1.1 January 21, 1988 Originalversion.

Version 1.2 June 17, 1988 Corrected typographical error in illustration on page4.

Version 1.3 January 4, 1989 AppleII modifications. Changed Apple II file

type from0xCB to 0xD8 on page 4. Defined

convention forusing applicationSignaturefield

inApplication Specific Chunkfor Apple II on

page 15.

______________________________________________________________________________

The Audio Interchange File Format (AudioIFF) provides a standard for storing sampled sounds.

The format is quite flexible, allowing forthe storage of monaural or multichannel sampled sounds

at a variety of sample rates and samplewidths.

Audio IFF conforms to the "EA IFF85" Standard for Interchange FormatFilesdeveloped by

Electronic Arts.

Audio IFF is primarily an interchangeformat, although applicationdesigners should find it

flexible enough to use as a data storageformat as well. If an application does choose to use a

different storage format, it should be ableto convert to and from the format defined in this

document. This will facilitate the sharingof sound data between applications.

Audio IFF is the result of several meetingsheld with music developers over a period of ten

months in 1987-88. Apple Computer greatlyappreciates the comments and cooperation provided

by all developers who helped define thisstandard.

Another "EA IFF 85" sound storageformat is"8SVX" IFF 8-bit Sampled Voice, by Electronic

Arts. "8SVX", which handles 8-bitmonaural samples, is intended mainly for storing sound for

playback on personal computers. Audio IFFis intended for use with a larger variety of

computers, sampled sound instruments, soundsoftware applications, and high fidelity recording

devices.

Data types

AC-like language will be used to describe data structures in this document. Thedata types used are listed below:

char: 8bits, signed. A char can contain more than just ASCII characters. It

can contain any number from -128 to 127 (inclusive).

unsigned char: 8 bits, unsigned. Contains any number from zero to 255(inclusive).

short: 16bits, signed. Contains any number from-32,768 to 32,767 (inclusive).

unsigned short: 16 bits, unsigned. Contains any number from zero to 65,535(inclusive).

long: 32bits, signed. Contains any number from -2,147,483,648 to

2,147,483,647(inclusive).

unsigned long: 32 bits, unsigned. Contains any number from zero to4,294,967,295

(inclusive).

extended: 80bit IEEE Standard 754 floating point number (Standard Apple

Numeric Environment [SANE] data type Extended).

pstring: Pascal-stylestring, a one byte count followed by text bytes. The total

number of bytes in this data type should be even. A pad byte can be

added at the end of the text to accomplish this. This pad byte isnot

reflected in the count.

ID: 32bits, the concatenation of four printable ASCII character in the range '

' (SP, 0x20) through '~' (0x7E). Spaces (0x20) cannot precedeprinting

characters; trailing spaces are allowed. Control characters areforbidden.

OSType: 32bits. A concatenation of four characters, as defined in Inside

Macintosh, vol II.

Constants

Decimalvalues are referred to as a string of digits, for example 123, 0, 100 are alldecimal

numbers.Hexadecimal values are preceded by a 0x - e.g. 0x0A12, 0x1, 0x64.

DataOrganization

Alldata is stored in Motorola 68000 format. Data is organized as follows:

Referring to Audio IFF

The official name for this standard isAudio Interchange File Format.If an application program

needs to present the name of this format toa user, such as in a "Save as…" dialog box, the name

can be abbreviated to Audio IFF.

File Structure

The "EA IFF 85" Standard for Interchange Format Filesdefinesan overall structure for storing

data in files. Audio IFF conforms to the"EA IFF 85" standard. This document will describe

those portions of "EA IFF 85"that are germane to Audio IFF. For a more complete discussion of

"EA IFF 85", please refer to thedocument "EA IFF 85" Standard for Interchange Format Files.

An "EA IFF 85" file is made up ofa number of chunksof data. Chunks are the building blocks

of "EA IFF 85" files. A chunkconsists of some header information followed by data:

Achunk can be represented using our C-like language in the following manner:

typedef struct {

ID ckID; /* chunk ID */

long ckSize; /* chunk Size */

char ckData[]; /* data */

} Chunk;

ckID describes the format of the dataportion a chunk. A program candetermine how to

interpret the chunk data by examining ckID.

ckSize is the size of the data portion of the chunk, in bytes. It does notinclude the 8 bytes used

by ckIDand ckSize.

ckData contains the data stored in thechunk. The format of this data is determined by ckID. If

the data is an odd number of bytes inlength, a zero pad byte must be added at the end. The pad

byte is not included in ckSize.

Note that an array with no sizespecification (e.g. char ckData[];)indicates a variable-sized

array in our C-like language. This differsfrom standard C.

An Audio IFF file is a collection of anumber of different types of chunks. There is a Common

Chunk which contains important parameters describing the sampled sound, suchas it's length

and sample rate. There is a Sound Data Chunkthatcontains the actual audio samples. There are

several other optional chunks that definemarkers, list instrument parameters, store applicationspecific information,etc. All of these chunks are described in detail in later sections of this document.

The chunks in a Audio IFF file are groupedtogether in a container chunk. "EA IFF 85" defines a

number of container chunks, but the oneused by Audio IFF is called a FORM. A FORM has the

following format:

typedef struct {

ID ckID;

long ckSize;

ID formType;

char chunks [];

} Chunk;

ckID is always 'FORM'. This indicates that this is a FORM chunk.

ckSize contains the size of data portion of the 'FORM' chunk. Note thatthe data portion has been

broken into two parts, formTypeandchunks[].

formType describes what's in the 'FORM' chunk. For Audio IFF files,formTypeis always 'AIFF'.

This indicates that the chunks within theFORM pertain to sampled sound. A FORM chunk of

formType'AIFF' is called a FORM AIFF.

Chunks are the chunks contained within the FORM. These chunks are calledlocal chunks. A

FORM AIFF along with its local chunks makeup an Audio IFF file.

Here is an example of a simple Audio IFFfile. It consists of a file containing single FORM AIFF

which contains two local chunks, a CommonChunk and a Sound Data Chunk.

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

On an Apple II, the FORM AIFF is stored ina ProDOS file. The file type is 0xD8 and the aux

type is 0x0000. AIFF versions 1.2 andearlier used file type 0xCB, which is incorrect. Please see

the Apple II File Type Note for file type0xD8 and aux type 0x0000 for strategies on dealing with

this inconsistency.

On a Macintosh, the FORM AIFF is stored inthe data fork of an Audio IFF file. The Macintosh

file type of an Audio IFF file is 'AIFF'.This is the same as the formTypeof the FORM AIFF.

Macintosh or Apple II applications shouldnot store any information in Audio IFF file's resource

fork, as this information may not bepreserved by all applications. Applications can use the

Application Specific Chunk, defined laterin this document, to store extra information specific to

their application.

On an operating system that uses fileextensions, such as MS-DOS or UNIX, it is recommended

that Audio IFF file names have a ".AIF"extension.

A more detailed example of an Audio IFFfile can be found in Appendix A. Please refer to this

example as often as necessary while readingthe remainder of this document.

Local Chunk Types

The formats of the different local chunktypes found within a FORM AIFF are described in the

following sections. The ckIDs for eachchunk are also defined.

There are two types of chunks, those thatare required and those that are optional. The Common

Chunk is required. The Sound Data chunk isrequired if the sampled sound has greater than zero

length. All other chunks are optional. Allapplications that use FORM AIFF must be able to read

the required chunks, and can choose toselectively ignore the optional chunks. A program that

copies a FORM AIFF should copy all of thechunks in the FORM AIFF.

To insure that this standard remains usableby all developers, only Apple Computer, Inc. should

define new chunk types for FORM AIFF. Ifyou have suggestions for new chunk types, Apple is

happy to listen! Please refer to Appendix Bfor instructions on how to send comments to Apple.

Common Chunk

TheCommon Chunk describes fundamental parameters of the sampled sound.

#define CommonID 'COMM' /* ckID for CommonChunk */

typedef struct {

ID ckID;

long ckSize;

short numChannels;

unsigned long numSampleFrames;

short sampleSize;

extended sampleRate;

} CommonChunk;

ckID is always 'COMM'. ckSizeisthe size of the data portion of the chunk, in bytes. It does not

include the 8 bytes used by ckIDandckSize. For the Common Chunk, ckSizeisalways 18.

numChannelscontains the number of audio channels for the sound. A value of 1 means

monophonic sound, 2 means stereo, and 4means four channel sound, etc. Any number of audio

channels may be represented.

The actual sound samples are stored inanother chunk, the Sound Data Chunk, which will be

described shortly. For multichannel sounds, single sample pointsfrom each channel are

interleaved. A set of interleaved samplepoints is called a sample frame. This isillustrated below

for the stereo case.

For monophonic sound, a sample frame is asingle sample point.

For multichannel sounds, the followingconventions should be observed:

numSampleFrames contains the number of sample frames in the Sound Data Chunk. Note that

numSampleFrames is the number of sampleframes, not the number of bytes nor the number of

sample points in the Sound Data Chunk.Thetotal number of sample points in the file is

numSampleFrames times numChannels.

sampleSize is the number of bits in each sample point. It can be any numberfrom 1 to 32. The

format of a sample point will be describedin the next section, the Sound Data Chunk.

sampleRate is the sample rate at which the sound is to be played back, insample framesper

second.

One and only one Common Chunk is requiredin every FORM AIFF.

Sound Data Chunk

TheSound Data Chunk contains the actual sample frames.

#define SoundDataID 'SSND' /* ckID forSound Data Chunk */

typedef struct {

ID ckID;

long ckSize;

unsigned long offset;

unsigned long blockSize;

unsigned char soundData[];

} SoundDataChunk;

ckID is always 'SSND'. ckSizeisthe size of the data portion of the chunk, in bytes. It does not

include the 8 bytes used by ckIDand ckSize.

offsetdetermines where the first sample frame in the soundDatastarts. offsetis in bytes. Most

applications won't use offsetand should setit to zero. Use for a non-zero offsetis explained in the

Block-Aligning Sound Datasection below.

blockSize is used in conjunction with offset for block-aligning sound data.It contains the size in

bytes of the blocks that sound data isaligned to. As with offset, most applications won't use

blockSize and should set it to zero. More information on blockSize is in the Block-Aligning Sound

Datasection below.

soundData contains the sample frames that make up the sound. The number ofsample frames in

the soundDatais determined by thenumSampleFramesparameter in the Common Chunk.

SamplePoints

Each sample point in a sample frame is alinear, 2's complement value. The sample points are

from 1 to 32 bits wide, as determined bythe sampleSizeparameter in the Common Chunk.

Sample points are stored in an integralnumber of contiguous bytes. One to 8 bit wide sample

points are stored in one byte, 9 to 16 bitwide sample points are stored in two bytes, 17 to 24 bit

wide sample points are stored in 3 bytes,and 25 to 32 bit wide samples are stored in 4 bytes.

When the width of a sample point is lessthan a multiple of 8 bits, the sample point data is left

justified, with the remaining bits zeroed.An example case is illustrated below. A 12 bit sample

point, binary 101000010111, is stored leftjustified in two bytes. The remaining bits are set to

zero.

Sample Frames

Sample frames are stored contiguously inorder of increasing time. The sample points within a

sample frame are packed together, there areno unused bytes between them. Likewise, the sample

frames are packed together with no padbytes.

Block-Aligning Sound Data

There may be some applications that, toinsure real time recording and playback of audio, wish to

align sampled sound data with fixed-sizeblocks. This can be accomplished with the offsetand

blockSize parameters, as shown below.

In the above figure, the first sample framestarts at the beginning of block N. This is

accomplished by skipping the firstoffsetbytes of the soundData. Note too that the soundData

array can extend beyond valid sampleframes, allowing the soundData array to end on a block

boundary.

blockSizespecifies the size in bytes of the block that is tobe aligned to. A blockSizeof zero

indicates that the sound data does not needto be block-aligned. Applications that don't care about

block alignment should set blockSizeandoffsetto zero when writing Audio IFF files.

Applications that write block-aligned sounddata should set blockSizeto the appropriate block

size. Applications that modify an existingAudio IFF file should try to preserve alignment of the

sound data, although this is not required.If an application doesn't preserve alignment, it should

set blockSize andoffset to zero. If anapplication needs to realign sound data to a different sized

block, it should update blockSize andoffsetaccordingly.

The Sound Data Chunk is required unless thenumSampleFramesfield in the Common Chunkis

zero. A maximum of one Sound Data Chunk canappear in a FORM AIFF.

Marker Chunk

TheMarker Chunk contains markers that point to positions in the sound data.Markers can be used for whatever purposes an application desires. TheInstrument Chunk, defined later in this document, uses markers to mark loopbeginning and end points, for example.

Markers

Amarker has the following format.

typedef short MarkerId;

typedef struct {

MarkerId id;

unsigned long position;

pstring markerName;

} Marker;

id is a number that uniquely identifies the marker within a FORM AIFF.The id can be any

positive non-zero integer, as long as noother marker within the same FORM AIFF has the same

id.

The marker's position in the sound data isdetermined by position. Markers conceptually fall

between two sample frames. A marker thatfalls before the first sample frame in the sound data is

at position zero, while a marker that fallsbetween the first and second sample frame in the sound

data is at position 1. Note that the unitsfor position are sample frames, not bytes nor sample

points.

markerNameis a Pascal-style text string containing the name of the mark.

Note: Some "EA IFF 85" filesstore strings as C-strings (text bytes followed by a null terminating

character) instead of Pascal-style strings.Audio IFF uses pstringsbecause they are more

efficiently skipped over when scanningthrough chunks. Using pstrings, a program can skip

over a string by adding the string count tothe address of the first character. C strings require that

each character in the string be examinedfor the null terminator.

Marker Chunk Format

Theformat for the data within a Marker Chunk is shown below.

#define MarkerID 'MARK' /* ckID for MarkerChunk */

typedef struct {

ID ckID;

long ckSize;

unsigned short numMarkers;

Marker Markers[];

} MarkerChunk;

ckID is always 'MARK'. ckSizeisthe size of the data portion of the chunk, in bytes. It does not

include the 8 bytes used by ckIDand ckSize.

numMarkers is the number of markers in the Marker Chunk.

numMarkers, if non-zero, it is followed by the markers themselves. Because allfields in a

marker are an even number of bytes inlength, the length of any marker will always be even.

Thus, markers are packed together with nounused bytes between them. The markers need not be

ordered in any particular manner.

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

Instrument Chunk

TheInstrument Chunk defines basic parameters that an instrument, such as asampler, could use to play back the sound data.

Looping

Sounddata can be looped, allowing a portion of the sound to be repeated in order tolengthen the sound. The structure below describes a loop:

typedef struct {

short playMode;

MarkerId beginLoop;

MarkerId endLoop;

} Loop;

A loop is marked with two points, a beginposition and an end position. There are two ways to

play a loop, forward looping andforward/backward looping. In the case of forward looping,

playback begins at the beginning of thesound, continues past the begin position and continues to

the end position, at which point playbackrestarts again at the begin position. The segment

between the begin and end positions, calledthe loop segment, is played over and over again, until

interrupted by something, such as therelease of a key on a sampling instrument, for example.

Withforward/backward looping, the loop segment is first played from the beginposition to the end position, and then played backwardsfrom the end positionback to the begin position. This flip-flop pattern is repeated over and overagain until interrupted.

playModespecifieswhich type of looping is to be performed.

#define NoLooping 0

#define ForwardLooping 1

#define ForwardBackwardLooping 2

If NoLoopingis specified, then the looppoints are ignored during playback.

beginLoop is a the marker id that marks the begin position of the loopsegment.

endLoop marks the end position of a loop. The begin position must be lessthan the end position.

If this is not the case, then the loopsegment has zero or negative length and no looping takes

place.

Instrument Chunk Format

Theformat of the data within an Instrument Chunk is described below.

#define InstrumentID 'INST' /* ckID forInstrument Chunk */

typedef struct {

ID ckID;

long ckSize;

char baseNote;

char detune;

char lowNote;

char highNote;

char lowVelocity;

char highVelocity;

short gain;

Loop sustainLoop;

Loop releaseLoop;

} InstrumentChunk;

ckID is always 'INST'. ckSizeisthe size of the data portion of the chunk, in bytes. For the

Instrument Chunk, ckSizeis always 20.

baseNote is the note at which the instrument plays back the sound datawithout pitch

modification. Units are MIDI (MIDI is an acronym for Musical Instrument DigitalInterface)

note numbers, and are in the range 0through 127. Middle C is 60.

detune determines how much the instrument should alter the pitch of thesound when it is played

back. Units are in cents(1/100 of asemitone) and range from -50 to +50. Negative numbers

mean that the pitch of the sound should belowered, while positive numbers mean that it should be

raised.

lowNote and highNote specify the suggested range on a keyboard for playbackof the sound data.

The sound data should be played if theinstrument is requested to play a note between the low and

high notes, inclusive. The base note doesnot have to be within this range. Units for lowNote

and highNote are MIDInote values.

lowVelocity and highVelocity specify the suggested range of velocities forplayback of the sound

data. The sound data should be played ifthe note-on velocity is is between low and high velocity,

inclusive. Units are MIDIvelocity values, 1 (lowest velocity) through 127 (highest velocity).

gain is the amount by which to change the gain of the sound when it isplayed. 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 eachsample point.

sustainLoop specifies a loop that is tobe played when an instrument is sustaining a sound.

releaseLoop specifies a loop that is to be played when an instrument is in therelease phase of

playing back a sound. The release phaseusually occurs after a key on an instrument is released.

The Instrument Chunk is optional. No morethan one Instrument Chunk can appear in a FORM

AIFF.

MIDIData Chunk

TheMIDI Data Chunk can be used to store MIDI data (please refer to MusicalInstrument Digital Interface Specification 1.0, available from theInternational MIDI Association, for more details on MIDI).

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

#define MIDIDataID 'MIDI'/* ckID for MIDI Data Chunk */

typedef struct {

ID ckID;

long ckSize;

unsigned char MIDIdata[];

} MIDIDataChunk;

ckID is always ' MIDI'. ckSizeis the size of the data portion of thechunk, in bytes. It does not

include the 8 bytes used by ckIDand ckSize.

MIDIData contains a stream of MIDI data.

The MIDI Data Chunk is optional. Any numberof MIDI Data Chunks may exist in a FORM

AIFF. If MIDI System Exclusive messages forseveral instruments are to be stored in a FORM

AIFF, it is better to use one MIDI DataChunk per instrument than one big MIDI Data Chunk for

all of the instruments.

Audio Recording Chunk

TheAudio Recording Chunk contains information pertinent to audio recordingdevices.

#define AudioRecordingID 'AESD' /* ckID forAudio Recording */

/* Chunk. */

typedef struct {

ID ckID;

long ckSize;

unsigned char AESChannelStatusData[24];

} AudioRecordingChunk;

ckID is always 'AESD'. ckSizeisthe size of the data portion of the chunk, in bytes. For the

Audio Recording Chunk, ckSizeis always 24.

The 24 bytes of AESChannelStatusData arespecified in the AES Recommended Practice for

Digital Audio Engineering - SerialTransmission Format for Linearly Represented Digital Audio

Data, section 7.1, Channel Status Data.That document describes a format for real-time digital

transmission of digital audio between audiodevices. This information is duplicated in the Audio

Recording Chunk for convenience. Of generalinterest would be bits 2, 3, and 4 of byte 0, which

describe recording emphasis.

The Audio Recording Chunk is optional. Nomore than one Audio Recording Chunk may appear

in a FORM AIFF.

Application Specific Chunk

TheApplication Specific Chunk can be used for any purposes whatsoever bymanufacturers of applications. For example, an application that edits soundsmight want to use this chunk to store editor state parameters such asmagnification levels, last cursor position, and the like.

#define ApplicationSpecificID 'APPL' /*ckID for Application */

/* Specific Chunk. */

typedef struct {

ID ckID;

long ckSize;

OSType applicationSignature;

char data[];

} ApplicationSpecificChunk;

ckID is always 'APPL'. ckSizeisthe size of the data portion of the chunk, in bytes. It does not

include the 8 bytes used by ckIDand ckSize.

applicationSignature identifies a particular application. For Macintosh applications,this will be

the application's four character signature.For Apple II applications, applicationSignatureshould

always be 'pdos', or the hexadecimal bytes0x70646F73. If applicationSignatureis 'pdos', the

beginning of the dataarea is defined to bea Pascal-style string (a length byte followed by ASCII

string bytes) containing the name of theapplication. This is necessary because Apple II

applications do not have a four-bytesignature as do Macintosh applications.

data is the data specific to the application.

The Application Specific Chunk is optional.Any number of Application Specific Chunks may

exist in a single FORM AIFF.

Comments Chunk

TheComments Chunk is used to store comments in the FORM AIFF. "EA IFF85" has an

AnnotationChunkthat can be used for comments, but the Comments Chunk has two features notfound in the "EA IFF 85" chunk. They are: 1) a timestamp for thecomment; and 2) a link to a marker.

Comment

A comment consists of a time stamp, markerid, and a text count followed by text.

typedef struct {

unsigned long timeStamp;

MarkerID marker;

unsigned short count;

char text;

} Comment;

timestamp indicates when the comment was created. Units are the number ofseconds since

January 1, 1904. (This time convention isthe one used by the Macintosh. For procedures that

manipulate the time stamp, see TheOperating System Utilities chapter in Inside Macintosh, vol II

). For a routine that will convert this toan Apple II GS/OS format time, please see Apple II File

Type Note for filetype 0xD8, aux type0x0000.

A comment can be linked to a marker. Thisallows applications to store long descriptions of

markers as a comment. If the comment isreferring to a marker, then marker is the ID of that

marker. Otherwise, markeris zero,indicating that this comment is not linked to a marker.

count is the length of the text that makes up the comment. This is a 16bit quantity, allowing

much longer comments than would beavailable with a pstring.

text contains the comment itself. This text must be padded with a byteat the end to insure that it

is an even number of bytes in length. Thispad byte, if present, is not included in count.

Comments Chunk Format

#define CommentID 'COMT' /* ckID forComments Chunk. */

typedef struct {

ID ckID;

long ckSize;

unsigned short numComments;

Comment comments[];

} CommentsChunk;

ckID is always ' COMT'. ckSizeisthe size of the data portion of the chunk, in bytes. It does not

include the 8 bytes used by ckIDand ckSize.

numComments contains the number of comments in the Comments Chunk. This isfollowed by

the comments themselves. Comments arealways an even number of bytes in length, so there is

no padding between comments in the CommentsChunk.

The Comments Chunk is optional. No morethan one Comments Chunk may appear in a single

FORM AIFF.

Text Chunks - Name, Author, Copyright, Annotation

Thesefour 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 thesechunks is optional.

#define NameID 'NAME' /* ckID for NameChunk. */

#define AuthorID 'AUTH' /* ckID for AuthorChunk. */

#define CopyrightID '(c) ' /* ckID forCopyright Chunk. */

#define AnnotationID 'ANNO' /* ckID forAnnotation Chunk. */

typedef struct {

ID ckID;

long ckSize;

char text[];

} TextChunk;

ckID is either ' NAME', ' AUTH', '(c) ', or ' ANNO', depending onwhether the chunk as a Name

Chunk, Author Chunk, Copyright Chunk, orAnnotation Chunk, respectively. For the Copyright

Chunk, the 'c' is lowercase and there is aspace (0x20) after the close parenthesis.

ckSize is the size of the data portion of the chunk, in this case thetext.

text contains pure ASCII characters. It is not a pstringnor a C string.The number of

characters in textis determined by ckSize. The contents oftextdepend on the chunk, as described

below:

NameChunk

text contains the name of the sampled sound. The Name Chunk is optional.No more than one

Name Chunk may exist within a FORM AIFF.

AuthorChunk

text contains one or more authornames. An author in this case is the creator of a sampled sound.

The Author Chunk is optional. No more thanone Author Chunk may exist within a FORM AIFF.

CopyrightChunk

The Copyright Chunk contains a copyrightnotice for the sound. textcontains adate followed by

Computer, Inc."

The Copyright Chunk is optional. No morethan one Copyright Chunk may exist within a FORM

AIFF.

AnnotationChunk

text contains a comment. Use ofthis chunk is discouraged within FORM AIFF. The more

powerful Comments Chunk should be usedinstead. The Annotation Chunk is optional. Many

Annotation Chunks may exist within a FORMAIFF.

Chunk Precedence

Several of the local chunks for FORM AIFFmay contain duplicate information. For example, the

Instrument Chunkdefines loop points and MIDI system exclusive data in the MIDI Data Chunk

may also define loop points. What happensif these loop points are different? How is an

application supposed to loop the sound?

Such conflicts are resolved by defining aprecedence for chunks:

The Common Chunkhas the highest precedence,while the Application Specific Chunkhas the

lowest. Information in the CommonChunkalways takes precedence over conflicting information

in any other chunk. The ApplicationSpecific Chunkalways loses in conflicts with other chunks.

By looking at the chunk hierarchy, forexample, one sees that the loop points in the Instrument

Chunk take precedence over conflicting looppoints found in the MIDI Data Chunk.

It is the responsibility of applicationsthat write data into the lower precedence chunks to make

sure that the higher precedence chunks areupdated accordingly.

Appendix A - An Example

Illustratedbelow is an example of a FORM AIFF. An Audio IFF file is simply a filecontaining a single FORM AIFF. On a Macintosh, the FORM AIFF is stored in thedata fork of a file and the file type is 'AIFF'.

Appendix B - Sending comments to Apple Computer, Inc.

Ifyou have suggestions for new chunks to be added to the Audio Interchange FileFormat, please describe the chunk in as much detail as possible, and give anexample of its use. Suggestions for new FORMs, ways to group FORM AIFF's into abank, and new local chunks are welcome. When sending in suggestions, be sure tomention that your comment refers to the Audio

InterchangeFile Format: "AIFF" document version 1.3.

Sendcomments to:

DeveloperTechnical Support

(AppleII or Macintosh)

AppleComputer, Inc.

20525 Mariani Avenue, MS: 51-T

Cupertino, CA 95014 USA

References

AESRecommended Practice for Digital Audio Engineering - Serial Transmission Formatfor

LinearlyRepresented Digital Audio Data,Audio Engineering Society, 60 East 42nd Street, New York, New York 10165

MIDI:Musical Instrument Digital Interface, Specification 1.0, the International MIDI

Association.