Author: Erik de Castro Lopo (erikd AT zip DOT com DOT au)
Description: The libsndfile FAQ.
Keywords: WAV AIFF AU libsndfile sound audio dsp Linux

# libsndfile : Frequently Asked Questsions.

Q1 : On Linux, sf_open returns weird info about files. Why?
Q2 : In version 0 the SF_INFO struct had a pcmbitwidth field but version 1 does not. Why?
Q3 : Compiling is really slow on MacOSX. Why?
Q4 : When trying to compile libsndfile on Solaris I get a "bad substitution" error during linking. What can I do to fix this?
Q5 : Why doesn't libsndfile do interleaving/de-interleaving?
Q6 : What's the best format for storing temporary files?

##
Q1 : On Linux, sf_open returns weird info about files. Why?

This simple call to sf_open :

            file = sf_open (filename, SFM_READ, &sfinfo) ;

            printf ("srate    : %d\n", sfinfo.samplerate) ;
            printf ("frames   : %d\n", sfinfo.frames) ;
            printf ("channels : %d\n", sfinfo.channels) ;
            printf ("format   : %d\n", sfinfo.format) ;
            printf ("sections : %d\n", sfinfo.sections);
            printf ("seekable : %d\n", sfinfo.seekable) ;

returns this weird info:

            srate     : 0
            frames    : 1445760
            channels  : 44100
            format    : 2
            sections  : 65538
            seekable  : 1

## Answer

This is only a problem on Linux and other 32 bit OSes (possibly 32 bit Solaris) which require special compiler command line options to allow access to files greater than 2 Gig in size. These instructions should show you a way around this problem.

##
Q2 : In version 0 the SF_INFO struct had a pcmbitwidth field but version 1 does not. Why?

This was dropped for a number of reasons:

- pcmbitwidth makes little sense on compressed or floating point formats
- with the new API you really don't need to know it

As documented here there is now a well defined behaviour which ensures that no matter what the bit width of the source file, the scaling always does something sensible. This makes it safe to read 8, 16, 24 and 32 bit PCM files using sf_read_short() and always have the optimal behaviour.

##
Q3 : Compiling is really slow on MacOSX. Why?

When you configure and compile libsndfile, it uses the Bourne shell for a number of tasks (ie configure script and libtool). However, Apple has decided to ship their system with a really crappy Bourne shell.

To fix this I suggest that you install the GNU Bash shell, rename /bin/sh to /bin/sh.old and make a softlink from /bin/sh to the bash shell. Bash is designed to behave as a Bourne shell when is is called as /bin/sh.

When I did this on my iBook running MacOSX, compile times dropped from 13 mintes to 3 minutes.

##
Q4 : When trying to compile libsndfile on Solaris I get a "bad substitution" error on linking. Why?

It seems that the Solaris Bourne shell disagrees with GNU libtool.

To fix this I suggest that you install the GNU Bash shell, rename /bin/sh to /bin/sh.old and make a softlink from /bin/sh to the bash shell. Bash is designed to behave as a Bourne shell when is is called as /bin/sh.

##
Q5 : Why doesn't libsndfile do interleaving/de-interleaving?

This problem is bigger then it may seem at first. For a stereo file, it might be desirable to read out either the left or the right channel or supply two spearate mono channels and write it to a stereo file. This particular problem is trival and can easily be done in the application program.

With files of more than 2 channels the picture is much more complex. For instance, you may wish to read channels 1 and 2 of a 4 channel file as an interleaved pair (or as two separate mono channels). The possiblities are endless.

Any interleaver/de-interleaver which gets added to libsndfile but be able to handle the simple cases as well as more complex cases. This means that this feature will not be added any time soon.

##
Q6 : What's the best format for storing temporary files?

When you want to store temporary data there are a number of requirements;

- A simple, easy to parse header.
- The format must provide the fastest possible read and write rates (ie avoid conversions and encoding/decoding).
- The file format must be reasonably common and playable by most players.
- Able to store data in either endian-ness.

The format which best means these requirements is AU, which allows data to be stored in any one of short, int, float and double (among others).

For instance, if an application uses float data internally, it temporary files should use a format of (SF_ENDIAN_CPU | SF_FORMAT_AU | SF_FORMAT_FLOAT) which will store big endian float data in big endian CPUs and little float endian data on little endian CPUs. Reading and writing this format will not require any conversions or byte swapping regardless of the host CPU.

The libsndfile home page is here : http://www.zip.com.au/~erikd/libsndfile/.
Version : 1.0.3