cannam@125: cannam@125: cannam@125: cannam@125: cannam@125: cannam@125: libsndfile : Frequently Asked Questions. cannam@125: cannam@125: cannam@125: cannam@125: cannam@125: cannam@125: cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

libsndfile : Frequently Asked Questions.

cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q1 : Do you plan to support XYZ codec in libsndfile?

cannam@125:

cannam@125: If source code for XYZ codec is available under a suitable license (LGPL, BSD, cannam@125: MIT etc) then yes, I'd like to add it. cannam@125:

cannam@125:

cannam@125: If suitable documentation is available on how to decode and encode the format cannam@125: then maybe, depending on how much work is involved. cannam@125:

cannam@125:

cannam@125: If XYZ is some proprietary codec where no source code or documentation is cannam@125: available then no. cannam@125:

cannam@125:

cannam@125: So if you want support for XYZ codec, first find existing source code or cannam@125: documentation. cannam@125: If you can't find either then the answer is no. cannam@125:

cannam@125: cannam@125: cannam@125:

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

cannam@125:

cannam@125: This was dropped for a number of reasons: cannam@125:

cannam@125:

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

cannam@125:

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

cannam@125: cannam@125: cannam@125: cannam@125:

Q3 : Compiling is really slow on MacOS X. Why?

cannam@125:

cannam@125: When you configure and compile libsndfile, it uses the /bin/sh shell for a number cannam@125: of tasks (ie configure script and libtool). cannam@125: Older versions of OS X (10.2?) shipped a really crappy Bourne shell as /bin/sh cannam@125: which resulted in really slow compiles. cannam@125: Newer version of OS X ship GNU Bash as /bin/sh and this answer doesn't apply in that cannam@125: case. cannam@125:

cannam@125:

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

cannam@125:

cannam@125: When I did this on my iBook running MacOS X, compile times dropped from 13 minutes cannam@125: to 3 minutes. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

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

cannam@125:

cannam@125: It seems that the Solaris Bourne shell disagrees with GNU libtool. cannam@125:

cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

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

cannam@125:

cannam@125: This problem is bigger than it may seem at first. cannam@125:

cannam@125:

cannam@125: For a stereo file, it is a pretty safe bet that a simple interleaving/de-interleaving cannam@125: could satisfy most users. cannam@125: However, for files with more than 2 channels this is unlikely to be the case. cannam@125: If the user has a 4 channel file and want to play that file on a stereo output cannam@125: sound card they either want the first 2 channels or they want some mixed combination cannam@125: of the 4 channels. cannam@125:

cannam@125:

cannam@125: When you add more channels, the combinations grow exponentially and it becomes cannam@125: increasingly difficult to cover even a sensible subset of the possible combinations. cannam@125: On top of that, coding any one style of interleaver/de-interleaver is trivial, while cannam@125: coding one that can cover all combinations is far from trivial. cannam@125: This means that this feature will not be added any time soon. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

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

cannam@125: cannam@125:

cannam@125: When you want to store temporary data there are a number of requirements; cannam@125:

cannam@125:

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

cannam@125:

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

cannam@125:

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

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

Q7 : On Linux/Unix/MaxOS X, what's the best way of detecting the presence cannam@125: of libsndfile using autoconf?

cannam@125: cannam@125:

cannam@125: libsndfile uses the pkg-config (man pkg-config) method of registering itself with the cannam@125: host system. cannam@125: The best way of detecting its presence is using something like this in configure.ac cannam@125: (or configure.in): cannam@125:

cannam@125:

cannam@125:         PKG_CHECK_MODULES(SNDFILE, sndfile >= 1.0.2, ac_cv_sndfile=1, ac_cv_sndfile=0)
cannam@125: 
cannam@125:         AC_DEFINE_UNQUOTED([HAVE_SNDFILE],${ac_cv_sndfile},
cannam@125: 			[Set to 1 if you have libsndfile.])
cannam@125: 
cannam@125:         AC_SUBST(SNDFILE_CFLAGS)
cannam@125:         AC_SUBST(SNDFILE_LIBS)
cannam@125:

cannam@125:

cannam@125: This will automatically set the SNDFILE_CFLAGS and SNDFILE_LIBS cannam@125: variables which can be used in Makefile.am like this: cannam@125:

cannam@125:

cannam@125:         SNDFILE_CFLAGS = @SNDFILE_CFLAGS@
cannam@125:         SNDFILE_LIBS = @SNDFILE_LIBS@
cannam@125:

cannam@125:

cannam@125: If you install libsndfile from source, you will probably need to set the cannam@125: PKG_CONFIG_PATH environment variable as suggested at the end of the cannam@125: libsndfile configure process. For instance on my system I get this: cannam@125:

cannam@125:

cannam@125:         -=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=-
cannam@125: 
cannam@125:           Configuration summary :
cannam@125: 
cannam@125:             Version : ..................... 1.0.5
cannam@125:             Experimental code : ........... no
cannam@125: 
cannam@125:           Tools :
cannam@125: 
cannam@125:             Compiler is GCC : ............. yes
cannam@125:             GCC major version : ........... 3
cannam@125: 
cannam@125:           Installation directories :
cannam@125: 
cannam@125:             Library directory : ........... /usr/local/lib
cannam@125:             Program directory : ........... /usr/local/bin
cannam@125:             Pkgconfig directory : ......... /usr/local/lib/pkgconfig
cannam@125: 
cannam@125:         Compiling some other packages against libsndfile may require
cannam@125:         the addition of "/usr/local/lib/pkgconfig" to the
cannam@125:         PKG_CONFIG_PATH environment variable.
cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

Q8 : I have libsndfile installed and now I want to use it. I just want cannam@125: a simple Makefile! What do I do?

cannam@125: cannam@125:

cannam@125: The pkg-config program makes finding the correct compiler flag values and cannam@125: library location far easier. cannam@125: During the installation of libsndfile, a file named sndfile.pc is installed cannam@125: in the directory ${libdir}/pkgconfig (ie if libsndfile is installed in cannam@125: /usr/local/lib, sndfile.pc will be installed in cannam@125: /usr/local/lib/pkgconfig/). cannam@125:

cannam@125:

cannam@125: In order for pkg-config to find sndfile.pc it may be necessary to point the cannam@125: environment variable PKG_CONFIG_PATH in the right direction. cannam@125:

cannam@125:

cannam@125:         export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
cannam@125:

cannam@125: cannam@125:

cannam@125: Then, to compile a C file into an object file, the command would be: cannam@125:

cannam@125:

cannam@125:         gcc `pkg-config --cflags sndfile` -c somefile.c
cannam@125:

cannam@125:

cannam@125: and to link a number of objects into an executable that links against libsndfile, cannam@125: the command would be: cannam@125:

cannam@125:

cannam@125:         gcc `pkg-config --libs sndfile` obj1.o obj2.o -o program
cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

Q9 : How about adding the ability to write/read sound files to/from cannam@125: memory buffers?

cannam@125: cannam@125:

cannam@125: This has been added for version 1.0.13. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

Q10 : Reading a 16 bit PCM file as normalised floats and then cannam@125: writing them back changes some sample values. Why?

cannam@125: cannam@125:

cannam@125: This is caused by the fact that the conversion from 16 bit short to float is cannam@125: done by dividing by 32768 (0x8000 in hexadecimal) while the conversion from cannam@125: float to 16 bit short is done by multiplying by 32767 (0x7FFF in hex). cannam@125: So for instance, a value in a 16 bit PCM file of 20000 gets read as a floating cannam@125: point number of 0.6103515625 (20000.0 / 0x8000). cannam@125: Converting that back to a 16 bit short results in a value of 19999.3896484375 cannam@125: (0.6103515625 * 0x7FFF) which then gets rounded down to 19999. cannam@125:

cannam@125:

cannam@125: You will notice that for this particular case, the error is 1 in 20000 or cannam@125: 0.005%. cannam@125: Interestingly, for values of less than 16369, dividing by 0x8000 followed cannam@125: by multiplying by 0x7FFF and then rounding the result, gives back the cannam@125: original value. cannam@125: It turns out that as long as the host operating system supplies the 1999 ISO cannam@125: C Standard functions lrintf and lrint (or a replacement has cannam@125: been supplied) then the maximum possible error is 1 in 16369 or about 0.006%. cannam@125:

cannam@125:

cannam@125: Regardless of the size of the error, the reason why this is done is rather cannam@125: subtle. cannam@125:

cannam@125:

cannam@125: In a file containing 16 bit PCM samples, the values are restricted to the range cannam@125: [-32768, 32767] while we want floating point values in the range [-1.0, 1.0]. cannam@125: The only way to do this conversion is to do a floating point division by a value cannam@125: of 0x8000. cannam@125: Converting the other way, the only way to ensure that floating point values in cannam@125: the range [-1.0, 1.0] are within the valid range allowed by a 16 bit short is cannam@125: to multiply by 0x7FFF. cannam@125:

cannam@125:

cannam@125: Some people would say that this is a severe short-coming of libsndfile. cannam@125: I would counter that anybody who is constantly converting back and forth cannam@125: between 16 bit shorts and normalised floats is going to suffer other losses cannam@125: in audio quality that they should also be concerned about. cannam@125:

cannam@125:

cannam@125: Since this problem only occurs when converting between integer data on disk and cannam@125: normalized floats in the application, it can be avoided by using something cannam@125: other than normalized floats in the application. cannam@125: Alternatives to normalized floats are the short and int data cannam@125: types (ie using sf_read_short or sf_read_int) or using un-normalized floats cannam@125: (see cannam@125: cannam@125: SFC_SET_NORM_FLOAT). cannam@125:

cannam@125:

cannam@125: Another way to deal with this problem is to consider 16 bit short data as a cannam@125: final destination format only, not as an intermediate storage format. cannam@125: All intermediate data (ie which is going to be processed further) should be cannam@125: stored in floating point format which is supported by all of the most common cannam@125: file formats. cannam@125: If floating point files are considered too large (2 times the size of a 16 bit cannam@125: PCM file), it would also be possible to use 24 bit PCM as an intermediate cannam@125: storage format (and which is also supported by most common file types). cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

Q11 : I'm having problems with u-law encoded WAV files generated by cannam@125: libsndfile in Winamp. Why? cannam@125:

cannam@125: cannam@125:

cannam@125: This is actually a Winamp problem. cannam@125: The official Microsoft spec suggests that the 'fmt ' chunk should be 18 bytes. cannam@125: Unfortunately at least one of Microsoft's own applications (Sound Recorder on cannam@125: Win98 I believe) did not accept 18 bytes 'fmt ' chunks. cannam@125:

cannam@125:

cannam@125: Michael Lee did some experimenting and found that: cannam@125:

cannam@125:

cannam@125:     I have checked that Windows Media Player 9, QuickTime Player 6.4,
cannam@125:     RealOne Player 2.0 and GoldWave 5.06 can all play u-law files with
cannam@125:     16-byte or 18-byte 'fmt ' chunk. Only Winamp (2.91) and foobar2000
cannam@125:     are unable to play u-law files with 16-byte 'fmt ' chunk.
cannam@125:

cannam@125: cannam@125:

cannam@125: Even this is a very small sampling of all the players out there. cannam@125: For that reason it is probably not a good idea to change this now because there cannam@125: is the risk of breaking something that currently works. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

**Q12 : I'm looking at sf_read*. What are items? What are frames? cannam@125:**

cannam@125: cannam@125:

cannam@125: An item is a single sample of the data type you are reading; ie a cannam@125: single short value for sf_read_short or a single float cannam@125: for sf_read_float. cannam@125:

cannam@125: cannam@125:

cannam@125: For a sound file with only one channel, a frame is the same as a item (ie a cannam@125: single sample) while for multi channel sound files, a single frame contains a cannam@125: single item for each channel. cannam@125:

cannam@125: cannam@125:

cannam@125: Here are two simple, correct examples, both of which are assumed to be working cannam@125: on a stereo file, first using items: cannam@125:

cannam@125: cannam@125:

cannam@125:         #define CHANNELS 2
cannam@125:         short data [CHANNELS * 100] ;
cannam@125:         sf_count items_read = sf_read_short (file, data, 200) ;
cannam@125:         assert (items_read == 200) ;
cannam@125:

cannam@125: cannam@125:

cannam@125: and now reading the exact same amount of data using frames: cannam@125:

cannam@125: cannam@125:

cannam@125:         #define CHANNELS 2
cannam@125:         short data [CHANNELS * 100] ;
cannam@125:         sf_count frames_read = sf_readf_short (file, data, 100) ;
cannam@125:         assert (frames_read == 100) ;
cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

Q13 : Why can't libsndfile open this Sound Designer II (SD2) file? cannam@125:

cannam@125: cannam@125:

cannam@125: This is somewhat complicated. cannam@125: First some background. cannam@125:

cannam@125: cannam@125:

cannam@125: SD2 files are native to the Apple Macintosh platform and use features of cannam@125: the Mac filesystem (file resource forks) to store the file's sample rate, cannam@125: number of channels, sample width and more. cannam@125: When you look at a file and its resource fork on Mac OS X it looks like cannam@125: this: cannam@125:

cannam@125: cannam@125:

cannam@125:         -rw-r--r--  1 erikd erikd   46512 Oct 18 22:57 file.sd2
cannam@125:         -rw-r--r--  1 erikd erikd     538 Oct 18 22:57 file.sd2/rsrc
cannam@125:

cannam@125: cannam@125:

cannam@125: Notice how the file itself looks like a directory containing a single file cannam@125: named rsrc. cannam@125: When libsndfile is compiled for MacOS X, it should open (for write and read) cannam@125: SD2 file with resource forks like this without any problems. cannam@125: It will also handle files with the resource fork in a separate file as cannam@125: described below. cannam@125:

cannam@125: cannam@125:

cannam@125: When SD2 files are moved to other platforms, the resource fork of the file cannam@125: can sometimes be dropped altogether. cannam@125: All that remains is the raw audio data and no information about the number cannam@125: of channels, sample rate or bit width which makes it a little difficult for cannam@125: libsndfile to open the file. cannam@125:

cannam@125: cannam@125:

cannam@125: However, it is possible to safely move an SD2 file to a Linux or Windows cannam@125: machine. cannam@125: For instance, when an SD2 file is copied from inside MacOS X to a windows cannam@125: shared directory or a Samba share (ie Linux), MacOS X is clever enough to cannam@125: store the resource fork of the file in a separate hidden file in the cannam@125: same directory like this: cannam@125:

cannam@125:

cannam@125:         -rw-r--r--  1 erikd erikd     538 Oct 18 22:57 ._file.sd2
cannam@125:         -rw-r--r--  1 erikd erikd   46512 Oct 18 22:57 file.sd2
cannam@125:

cannam@125: cannam@125:

cannam@125: Regardless of what platform it is running on, when libsndfile is asked to cannam@125: open a file named "foo" and it can't recognize the file type from cannam@125: the data in the file, it will attempt to open the resource fork and if cannam@125: that fails, it then tries to open a file named "._foo" to see if cannam@125: the file has a valid resource fork. cannam@125: This is the same regardless of whether the file is being opened for read cannam@125: or write. cannam@125:

cannam@125: cannam@125:

cannam@125: In short, libsndfile should open SD2 files with a valid resource fork on cannam@125: all of the platforms that libsndfile supports. cannam@125: If a file has lost its resource fork, the only option is the open the file cannam@125: using the SF_FORMAT_RAW option and guessing its sample rate, channel count cannam@125: and bit width. cannam@125:

cannam@125: cannam@125:

cannam@125: Occasionally, when SD2 files are moved to other systems, the file is cannam@125: BinHexed cannam@125: which wraps the resource fork and the data fork together. cannam@125: For these files, it would be possible to write a BinHex parser but cannam@125: there is not a lot to gain considering how rare these BinHexed SD2 cannam@125: files are. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q14 : I'd like to statically link libsndfile to my closed source cannam@125: application. Can I buy a license so that this is possible? cannam@125:

cannam@125: cannam@125:

cannam@125: Unfortunately no. cannam@125: libsndfile contains code written by other people who have agreed that their cannam@125: code be used under the GNU LGPL but no more. cannam@125: Even if they were to agree, there would be significant difficulties in cannam@125: dividing up the payments fairly. cannam@125:

cannam@125: cannam@125:

cannam@125: The only way you can legally use libsndfile as a statically linked cannam@125: library is if your application is released under the GNU GPL or LGPL. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q15 : My program is crashing during a call to a function in libsndfile. cannam@125: Is this a bug in libsndfile? cannam@125:

cannam@125: cannam@125:

cannam@125: libsndfile is being used by large numbers of people all over the world cannam@125: without any problems like this. That means that it is much more likely cannam@125: that your code has a bug than libsndfile. However, it is still possible cannam@125: that there is a bug in libsndfile. cannam@125:

cannam@125:

cannam@125: To figure out whether it is your code or libsndfile you should do the cannam@125: following: cannam@125:

cannam@125:

Make sure you are compiling your code with warnings switched on and cannam@125: that you fix as many warnings as possible. cannam@125: With the GNU compiler (gcc) I would recommend at least cannam@125: -W -Wall -Werror which will force you to fix all warnings cannam@125: before you can run the code. cannam@125:
Try using a memory debugger. cannam@125: Valgrind on x86 Linux is excellent. cannam@125: Purify also cannam@125: has a good reputation. cannam@125:
If the code is clean after the above two steps and you still get cannam@125: a crash in libsndfile, then send me a small snippet of code (no cannam@125: more than 30-40 lines) which includes the call to sf_open() and cannam@125: also shows how all variables passed to/returned from sf_open() cannam@125: are defined. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q16 : Will you accept a fix for compiling libsndfile with compiler X? cannam@125:

cannam@125: cannam@125:

cannam@125: If compiler X is a C++ compiler then no. cannam@125: C and C++ are different enough to make writing code that compiles as valid C cannam@125: and valid C++ too difficult. cannam@125: I would rather spend my time fixing bugs and adding features. cannam@125:

cannam@125: cannam@125:

cannam@125: If compiler X is a C compiler then I will do what I can as long as that does cannam@125: not hamper the correctness, portability and maintainability of the existing cannam@125: code. cannam@125: It should be noted however that libsndfile uses features specified by the 1999 cannam@125: ISO C Standard. cannam@125: This can make compiling libsndfile with some older compilers difficult. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q17 : Can libsndfile read/write files from/to UNIX pipes? cannam@125:

cannam@125: cannam@125:

cannam@125: Yes, libsndfile can read files from pipes. cannam@125: Unfortunately, the write case is much more complicated. cannam@125:

cannam@125: cannam@125:

cannam@125: File formats like AIFF and WAV have information at the start of the file (the cannam@125: file header) which states the length of the file, the number of sample frames cannam@125: etc. cannam@125: This information must be filled in correctly when the file header is written, cannam@125: but this information is not reliably known until the file is closed. cannam@125: This means that libsndfile cannot write AIFF, WAV and many other file types cannam@125: to a pipe. cannam@125:

cannam@125: cannam@125:

cannam@125: However, there is at least one file format (AU) which is specifically designed cannam@125: to be written to a pipe. cannam@125: Like AIFF and WAV, AU has a header with a sample frames field, but it is cannam@125: specifically allowable to set that frames field to 0x7FFFFFFF if the file cannam@125: length is not known when the header is written. cannam@125: The AU file format can also hold data in many of the standard formats (ie cannam@125: SF_FORMAT_PCM_16, SF_FORMAT_PCM_24, SF_FORMAT_FLOAT etc) as well as allowing cannam@125: data in both big and little endian format. cannam@125:

cannam@125: cannam@125:

cannam@125: See also FAQ Q6. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q18 : Is it possible to build a Universal Binary on Mac OS X? cannam@125:

cannam@125: cannam@125:

cannam@125: Yes, but you must do two separate configure/build/test runs; one on PowerPC cannam@125: and one on Intel. cannam@125: It is then possible to merge the binaries into a single universal binary using cannam@125: one of the programs in the Apple tool chain. cannam@125:

cannam@125: cannam@125:

cannam@125: It is not possible to build a working universal binary via a single cannam@125: compile/build run on a single CPU. cannam@125:

cannam@125: cannam@125:

cannam@125: The problem is that the libsndfile build process detects features of the CPU its cannam@125: being built for during the configure process and when building a universal binary, cannam@125: configure is only run once and that data is then used for both CPUs. cannam@125: That configure data will be wrong for one of those CPUs. cannam@125: You will still be able to compile libsndfile, and the test suite will pass on cannam@125: the machine you compiled it on. cannam@125: However, if you take the universal binary test suite programs compiled on one cannam@125: CPU and run them on the other, the test suite will fail. cannam@125:

cannam@125: cannam@125:

cannam@125: Part of the problem is that the CPU endian-ness is detected at configure time. cannam@125: Yes, I know the Apple compiler defines one of the macros __LITTLE_ENDIAN__ cannam@125: and __BIG_ENDIAN__, but those macros are not part of the 1999 ISO C Standard cannam@125: and they are not portable. cannam@125:

cannam@125: cannam@125:

cannam@125: Endian issues are not the only reason why the cross compiled binary will fail. cannam@125: The configure script also detects other CPU specific idiosyncrasies to provide cannam@125: more optimized code. cannam@125:

cannam@125: cannam@125:

cannam@125: Finally, the real show stopper problem with universal binaries is the problem cannam@125: with the test suite. cannam@125: libsndfile contains a huge, comprehensive test suite. cannam@125: When you compile a universal binary and run the test suite, you only test the cannam@125: native compile. cannam@125: The cross compiled binary (the one with the much higher chance of having cannam@125: problems) cannot be tested. cannam@125:

cannam@125: cannam@125:

cannam@125: Now, if you have read this far you're probably thinking there must be a way cannam@125: to fix this and there probably is. cannam@125: The problem is that its a hell of a lot of work and would require significant cannam@125: changes to the configure process, the internal code and the test suite. cannam@125: In addition, these changes must not break compilation on any of the platforms cannam@125: libsndfile is currently working on. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

Q19 : I have project files for Visual Studio / XCode / Whatever. Why cannam@125: don't you distribute them with libsndfile? cannam@125:

cannam@125: cannam@125:

cannam@125: There's a very good reason for this. cannam@125: I will only distribute things that I actually have an ability to test and cannam@125: maintain. cannam@125: Project files for a bunch of different compilers and Integrated Development cannam@125: Environments are simply too difficult to maintain. cannam@125:

cannam@125: cannam@125:

cannam@125: The problem is that every time I add a new file to libsndfile or rename an cannam@125: existing file I would have to modify all the project files and then test that cannam@125: libsndfile still built with all the different compilers. cannam@125:

cannam@125: cannam@125:

cannam@125: Maintaining these project files is also rather difficult if I don't have access cannam@125: to the required compiler/IDE. cannam@125: If I just edit the project files without testing them I will almost certainly cannam@125: get it wrong. cannam@125: If I release a version of libsndfile with broken project files, I'll get a bunch cannam@125: of emails from people complaining about it not building and have no way of cannam@125: fixing or even testing it. cannam@125:

cannam@125: cannam@125:

cannam@125: I currently release sources that I personally test on Win32, Linux and cannam@125: MacOS X (PowerPC) using the compiler I trust (GNU GCC). cannam@125: Supporting one compiler on three (actually much more because GCC is available cannam@125: almost everywhere) platforms is doable without too much pain. cannam@125: I also release binaries for Win32 with instructions on how to use those cannam@125: binaries with Visual Studio. cannam@125: As a guy who is mainly interested in Linux, I'm not to keen to jump through cannam@125: a bunch of hoops to support compilers and operating systems I don't use. cannam@125:

cannam@125: cannam@125:

cannam@125: So, I hear you want to volunteer to maintain the project files for Some Crappy cannam@125: Compiler 2007? cannam@125: Well sorry, that won't work either. cannam@125: I have had numerous people over the years offer to maintaining the project cannam@125: files for Microsoft's Visual Studio. cannam@125: Every single time that happened, they maintained it for a release or two and cannam@125: then disappeared off the face of the earth. cannam@125: Hence, I'm not willing to enter into an arrangement like that again. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q20 : Why doesn't libsndfile support MP3? Lots of other Open Source cannam@125: projects support it! cannam@125:

cannam@125: cannam@125:

cannam@125: MP3 is not supported for one very good reason; doing so requires the payment cannam@125: of licensing fees. cannam@125: As can be seen from cannam@125: cannam@125: mp3licensing.com cannam@125: the required royalty payments are not cheap. cannam@125:

cannam@125: cannam@125:

cannam@125: Yes, I know other libraries ignore the licensing requirements, but their legal cannam@125: status is extremely dubious. cannam@125: At any time, the body selling the licenses could go after the authors of those cannam@125: libraries. cannam@125: Some of those authors may be students and hence wouldn't be worth pursuing. cannam@125:

cannam@125: cannam@125:

cannam@125: However, libsndfile is released under the name of a company, Mega Nerd Pty Ltd; cannam@125: a company which has income from from libsamplerate licensing, libsndfile based cannam@125: consulting income and other unrelated consulting income. cannam@125: Adding MP3 support to libsndfile could place that income under legal threat. cannam@125:

cannam@125: cannam@125:

cannam@125: Fortunately, Ogg Vorbis exists as an alternative to MP3. cannam@125: Support for Ogg Vorbis was added to libsndfile (mostly due to the efforts of cannam@125: John ffitch of the Csound project) in version 1.0.18. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125: cannam@125:

Q21 : How do I use libsndfile in a closed source or commercial program cannam@125: and comply with the license? cannam@125:

cannam@125: cannam@125:

cannam@125: Here is a checklist of things you need to do to make sure your use of libsndfile cannam@125: in a closed source or commercial project complies with the license libsndfile is cannam@125: released under, the GNU Lesser General Public License (LGPL): cannam@125:

cannam@125: cannam@125:

Make sure you are linking to libsndfile as a shared library (Linux and Unix cannam@125: systems), Dynamic Link Library (Microsoft Windows) or dynlib (Mac OS X). cannam@125: If you are using some other operating system that doesn't allow dynamically cannam@125: linked libraries, you will not be able to use libsndfile unless you release cannam@125: the source code to your program. cannam@125:
In the licensing documentation for your program, add a statement that your cannam@125: software depends on libsndfile and that libsndfile is released under the GNU cannam@125: Lesser General Public License, either cannam@125: version 2.1 cannam@125: or optionally cannam@125: version 3. cannam@125:
Include the text for both versions of the license, possibly as separate cannam@125: files named libsndfile_lgpl_v2_1.txt and libsndfile_lgpl_v3.txt. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q22 : What versions of Windows does libsndfile work on? cannam@125:

cannam@125: cannam@125:

cannam@125: Currently the precompiled windows binaries are thoroughly tested on Windows XP. cannam@125: As such, they should also work on Win2k and Windows Vista. cannam@125: They may also work on earlier versions of Windows. cannam@125:

cannam@125: cannam@125:

cannam@125: Since version 0.1.18 I have also been releasing precompiled binaries for Win64, cannam@125: the 64 bit version of Windows. cannam@125: These binaries have received much less testing than the 32 bit versions, but cannam@125: should work as expected. cannam@125: I'd be very interested in receiving feedback on these binaries. cannam@125:

cannam@125: cannam@125: cannam@125: cannam@125:

Q23 : I'm cross compiling libsndfile for another platform. How can I cannam@125: run the test suite? cannam@125:

cannam@125: cannam@125:

cannam@125:

cannam@125: cannam@125:

cannam@125: Since version 1.0.21 the top level Makefile has an extra make target, cannam@125: 'test-tarball'. cannam@125: Building this target creates a tarball called called: cannam@125:

cannam@125: cannam@125: cannam@125: libsndfile-testsuite-${host_triplet}-${version}.tar.gz cannam@125: cannam@125: cannam@125:

cannam@125: in the top level directory. cannam@125: This tarball can then be copied to the target platform. cannam@125: Once untarred and test script test_wrapper.sh can be run from cannam@125: the top level of the extracted tarball. cannam@125:

cannam@125: cannam@125: cannam@125:

cannam@125:

cannam@125: The libsndfile home page is here : cannam@125: cannam@125: http://www.mega-nerd.com/libsndfile/. cannam@125:
cannam@125: Version : 1.0.27 cannam@125:

cannam@125: cannam@125: cannam@125: