Audio File Format Specifications

File Description: IRCAM soundfile / bicsf (Berkeley/IRCAM/Carl Sound Format) file
File Extension: Commonly .sf
File Byte Order: Big-endian or little-endian

Prof. Peter Kabal, MMSP Lab, ECE, McGill University: Last update: 2017-01-20

IRCAM File Specifications

The IRCAM Soundfile format originated from the Institut de Recherche et Coordination Acoustique / Musique in Paris. This format has been subsequently used in a number of programs.

Header Structure

The header structure is simple but the codes used have not always been consistent. The header size is 1024 bytes. The first part is fixed, the last part can be used for comments and other information.

File Identifier

The identifier for VAX machines was 107364 or \144\243\001\0 in little-endian byte order. The second last byte was then appropriated to indicate the type of machine.

• \001 - VAX
• \002 - Sun
• \003 - MIPS (Digital DECstation and SGI)
• \004 - NeXT

Note that the two MIPS machines have different byte-orders.

The present situation is that 7 codes seem to be accepted. In the following table the identifier is given in the order in which it is stored in the file.

• The reasons for this bizarre situation are as follows. Originally the IRCAM software ran on a VAX (first row). When Sun computers came along, they used the same code, but byte reversed all data including the header (second row). After machine codes were introduced, the identifier was changed for Sun machines (third row).
• Recent programs will write files with either a VAX code (first row) if the machine is little-endian or a Sun code (third row) if the machine is big-endian.

Sampling Frequency

The float sampling frequency can be problematic. For VAX computers, the float format is different from the IEEE format used in modern machines. However, the case where a VAX machine code was used, but the file byte order is big-endian, the file was probably written on a Sun computer which does use IEEE floats. See the description of INRS-Telecom Speech Files for a table look-up approach for standard sampling frequencies (VAX floating point format) frequencies. Alternately, a web search will find routines for converting VAX float values to IEEE float values.

A reasonable strategy for modern files is to assume that floats are in IEEE float format.

Data Types

The sample format code is one of the following.

Note that the code has the data length in the least significant part. These codes are not consistently applied, for instance the MIT Media Lab Csound package defines SF_ULAW as 0x00001.

There is also an ambiguity as to the normalization that should be applied to float data. In some cases, full-scale data is normalized to a maximum absolute value of one. In other cases, the data is written with no normalization, and so will often have a maximum amplitude of 32768.

Additional Header Information

The additional header information is stored as chunks. There common types of information chunks in use are SF_COMMENT for comments, SF_MAXAMP for maximum amplitude information, and SF_END to mark the end of the informatinon chunks.

Comment chunk

Maximum Amplitude Chunk

The maximum amplitude chunk has a peak value and location for each channel. It also includes a time tag which indicates when this chunk was updated.

End Chunk

Symbols for other informational chunks (SF_PVDATA, SF_AUDIOENCOD and SF_CODMAX are defined in the source code for Sox (see SoX - Sound eXchange). These are not used, nor is there any indication of their purpose.

Sample Files

addf8-sun-be.sf (48 kB)

IRCAM file, Sun code, big-endian data, 8 kHz, 16-bit integer data

addf8-vax-be.sf (48 kB)

IRCAM file, VAX code, big-endian data, 8 kHz, 16-bit integer data

addf8-mips-be.sf (48 kB)

IRCAM file, MIPS code, big-endian data, 8 kHz, 16-bit integer data

manna-mips-le-f.sf (93 kB)

IRCAM file, MIPS code, little-endian data, 44.1 kHz, 32-bit float data (from the Audio File Library) - the data is normalized to a maximum value of 1.