# Au file format

Short description: Simple audio file format
Filename extension .au.snd audio/basic .snd Sun Microsystems audio file format, container format Audio, most often μ-law

The Au file format is a simple audio file format introduced by Sun Microsystems. The format was common on NeXT systems and on early Web pages. Originally it was headerless, being simply 8-bit μ-law-encoded data at an 8000 Hz sample rate. Hardware from other vendors often used sample rates as high as 8192 Hz, often integer multiples of video clock signal frequencies. Newer files have a header that consists of six unsigned 32-bit words, an optional information chunk which is always of non-zero size, and then the data (in big endian format).

Although the format now supports many audio encoding formats, it remains associated with the μ-law logarithmic encoding. This encoding was native to the SPARCstation 1 hardware, where SunOS exposed the encoding to application programs through the /dev/audio interface. This encoding and interface became a de facto standard for Unix sound.

## New format

All fields are stored in big-endian format, including the sample data.

32 bit word (unsigned) field Description
0 Magic number The value 0x2e736e64 (four ASCII characters ".snd")
1 Data offset The offset to the data in bytes. (In the older Sun version, this had to be a multiple of 8.) The minimum valid number is 28 (decimal), since this is the header length (six 32-bit words) plus a minimal annotation size (4 bytes, another 32-bit word).
2 data size Data size in bytes. If unknown, the value 0xffffffff should be used.
3 Encoding Data encoding format:
• 1 = 8-bit G.711 μ-law
• 2 = 8-bit linear PCM
• 3 = 16-bit linear PCM
• 4 = 24-bit linear PCM
• 5 = 32-bit linear PCM
• 6 = 32-bit IEEE floating point
• 7 = 64-bit IEEE floating point
• 8 = Fragmented sample data
• 9 = DSP program
• 10 = 8-bit fixed point
• 11 = 16-bit fixed point
• 12 = 24-bit fixed point
• 13 = 32-bit fixed point
• 18 = 16-bit linear with emphasis
• 19 = 16-bit linear compressed
• 20 = 16-bit linear with emphasis and compression
• 21 = Music kit DSP commands
• 23 = 4-bit compressed using the ITU-T G.721 ADPCM voice data encoding scheme
• 24 = ITU-T G.722 SB-ADPCM
• 25 = ITU-T G.723 3-bit ADPCM
• 26 = ITU-T G.723 5-bit ADPCM
• 27 = 8-bit G.711 A-law
4 Sample rate The number of samples/second, e.g., 8000
5 Channels The number of interleaved channels, e.g., 1 for mono, 2 for stereo; more channels possible, but may not be supported by all readers.
6 Optional annotation or description string, NULL-terminated. A minimum of 4 bytes must be stored even if unused. (In the older Sun version, its length had to be a non-zero multiple of 8 bytes.)

The type of encoding depends on the value of the "encoding" field (word 3 of the header). Formats 2 through 7 are uncompressed linear PCM, therefore technically lossless (although not necessarily free of quantization error, especially in 8-bit form). Formats 1 and 27 are μ-law and A-law, respectively, both companding logarithmic representations of PCM, and arguably lossy as they pack what would otherwise be almost 16 bits of dynamic range into 8 bits of encoded data, even though this is achieved by an altered dynamic response and no data is actually "thrown away". Formats 23 through 26 are ADPCM, which is an early form of lossy compression, usually but not always with 4 bits of encoded data per audio sample (for 4:1 efficiency with 16-bit input, or 2:1 with 8-bit; equivalent to e.g. encoding CD quality MP3 at a 352kbit rate using a low quality encoder). Several of the others are DSP commands or data, designed to be processed by the NeXT Music Kit software.

Note: PCM formats are encoded as signed data (as opposed to unsigned).

Following the header structure is a variable-length annotation field. The contents of this field are currently undefined, except that its length must be a minimum of 4, and it should be a NULL-terminated string. (In the older Sun version, its length had to be a non-zero multiple of 8 bytes.) The audio data segment begins immediately following the annotation field. Audio data is encoded in the format identified by the file header. The current implementation supports only a single audio data segment per file. The variable-length annotation field is currently ignored by most audio applications.