File Description: IRCAM soundfile / bicsf (Berkeley/IRCAM/Carl Sound
File Extension: Commonly .sf
File Byte Order: Big-endian or little-endian
Prof. Peter Kabal, MMSP Lab, ECE, McGill University: Last update: 2011-01-03
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.
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.
|8||4||integer||Number of interleaved channels|
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.
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.
|Identifier||File Byte Order||Machine code|
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.
A reasonable strategy for modern files is to assume that floats are in IEEE float format.
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.
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.
|0||2||integer||Code, SF_COMMENT (2)|
|2||2||integer||Length of comment in bytes|
The maximum amplitude chunk has on peak value and location for each channel. It also includes a time tag which indicates when this chunk was updated.
|0||2||integer||Code, SF_MAXAMP (1)|
|2||2||integer||Length of information (12n)|
|4||4n||float||Peak amplitude, n values|
|4+4n||4n||integer||Location of peak amplitude sample|
|4+8n||4n||integer||Time tag (seconds since Jan. 1, 1970)|
|0||2||character||Code, SF_END (0)|
|2||2||integer||Chunk length. 0|
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.