Chris@0: Q1 : Do you plan to support XYZ codec in libsndfile?
Chris@0: Q2 : In version 0 the SF_INFO struct had a pcmbitwidth field
Chris@0: but version 1 does not. Why?
Chris@0: Q3 : Compiling is really slow on MacOS X. Why?
Chris@0: Q4 : When trying to compile libsndfile on Solaris I get a "bad
Chris@0: substitution" error during linking. What can I do to fix this?
Chris@0: Q5 : Why doesn't libsndfile do interleaving/de-interleaving?
Chris@0: Q6 : What's the best format for storing temporary files?
Chris@0: Q7 : On Linux/Unix/MacOS X, what's the best way of detecting the
Chris@0: presence of libsndfile?
Chris@0: Q8 : But I just want a simple Makefile! What do I do?
Chris@0: Q9 : How about adding the ability to write/read sound files to/from
Chris@0: memory buffers?
Chris@0: Q10 : Reading a 16 bit PCM file as normalised floats and then
Chris@0: writing them back changes some sample values. Why?
Chris@0: Q11 : I'm having problems with u-law encoded WAV files generated by
Chris@0: libsndfile in Winamp. Why?
Chris@0: Q12 : I'm looking at sf_read*. What are items? What are frames?
Chris@0: Q13 : Why can't libsndfile open this Sound Designer II (SD2)
Chris@0: file?
Chris@0: Q14 : I'd like to statically link libsndfile to my closed source
Chris@0: application. Can I buy a license so that this is possible?
Chris@0: Q15 : My program is crashing during a call to a function in libsndfile.
Chris@0: Is this a bug in libsndfile?
Chris@0: Q16 : Will you accept a fix for compiling libsndfile with compiler X?
Chris@0:
Chris@0: Q17 : Can libsndfile read/write files from/to UNIX pipes?
Chris@0:
Chris@0: Q18 : Is it possible to build a Universal Binary on Mac OS X?
Chris@0:
Chris@0: Q19 : I have project files for Visual Studio / XCode / Whatever. Why
Chris@0: don't you distribute them with libsndfile?
Chris@0:
Chris@0: Q20 : Why doesn't libsndfile support MP3? Lots of other Open Source
Chris@0: projects support it!
Chris@0:
Chris@0: Q21 : How do I use libsndfile in a closed source or commercial program
Chris@0: and comply with the license?
Chris@0:
Chris@0: Q22 : What versions of windows does libsndfile work on?
Chris@0:
Chris@0: Q23 : I'm cross compiling libsndfile for another platform. How can I
Chris@0: run the test suite?
Chris@0:
Chris@0:
Chris@0: If source code for XYZ codec is available under a suitable license (LGPL, BSD, Chris@0: MIT etc) then yes, I'd like to add it. Chris@0:
Chris@0:Chris@0: If suitable documentation is available on how to decode and encode the format Chris@0: then maybe, depending on how much work is involved. Chris@0:
Chris@0:Chris@0: If XYZ is some proprietary codec where no source code or documentation is Chris@0: available then no. Chris@0:
Chris@0:Chris@0: So if you want support for XYZ codec, first find existing source code or Chris@0: documentation. Chris@0: If you can't find either then the answer is no. Chris@0:
Chris@0: Chris@0: Chris@0:Chris@0: This was dropped for a number of reasons: Chris@0:
Chris@0:Chris@0: As documented Chris@0: here Chris@0: there is now a well defined behaviour which ensures that no matter what the Chris@0: bit width of the source file, the scaling always does something sensible. Chris@0: This makes it safe to read 8, 16, 24 and 32 bit PCM files using sf_read_short() Chris@0: and always have the optimal behaviour. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: When you configure and compile libsndfile, it uses the /bin/sh shell for a number Chris@0: of tasks (ie configure script and libtool). Chris@0: Older versions of OS X (10.2?) shipped a really crappy Bourne shell as /bin/sh Chris@0: which resulted in really slow compiles. Chris@0: Newer version of OS X ship GNU Bash as /bin/sh and this answer doesn't apply in that Chris@0: case. Chris@0:
Chris@0:Chris@0: To fix this I suggest that you install the GNU Bash shell, rename /bin/sh to Chris@0: /bin/sh.old and make a symlink from /bin/sh to the bash shell. Chris@0: Bash is designed to behave as a Bourne shell when is is called as /bin/sh. Chris@0:
Chris@0:Chris@0: When I did this on my iBook running MacOS X, compile times dropped from 13 minutes Chris@0: to 3 minutes. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: It seems that the Solaris Bourne shell disagrees with GNU libtool. Chris@0:
Chris@0:Chris@0: To fix this I suggest that you install the GNU Bash shell, rename /bin/sh to Chris@0: /bin/sh.old and make a symlink from /bin/sh to the bash shell. Chris@0: Bash is designed to behave as a Bourne shell when is is called as /bin/sh. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: This problem is bigger than it may seem at first. Chris@0:
Chris@0:Chris@0: For a stereo file, it is a pretty safe bet that a simple interleaving/de-interleaving Chris@0: could satisfy most users. Chris@0: However, for files with more than 2 channels this is unlikely to be the case. Chris@0: If the user has a 4 channel file and want to play that file on a stereo output Chris@0: sound card they either want the first 2 channels or they want some mixed combination Chris@0: of the 4 channels. Chris@0:
Chris@0:Chris@0: When you add more channels, the combinations grow exponentially and it becomes Chris@0: increasingly difficult to cover even a sensible subset of the possible combinations. Chris@0: On top of that, coding any one style of interleaver/de-interleaver is trivial, while Chris@0: coding one that can cover all combinations is far from trivial. Chris@0: This means that this feature will not be added any time soon. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: When you want to store temporary data there are a number of requirements; Chris@0:
Chris@0:Chris@0: The format which best meets these requirements is AU, which allows data to be Chris@0: stored in any one of short, int, float and double (among others) formats. Chris@0:
Chris@0:Chris@0: For instance, if an application uses float data internally, its temporary files Chris@0: should use a format of (SF_ENDIAN_CPU | SF_FORMAT_AU | SF_FORMAT_FLOAT) which Chris@0: will store big endian float data in big endian CPUs and little endian float data Chris@0: on little endian CPUs. Chris@0: Reading and writing this format will not require any conversions or byte swapping Chris@0: regardless of the host CPU. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: libsndfile uses the pkg-config (man pkg-config) method of registering itself with the Chris@0: host system. Chris@0: The best way of detecting its presence is using something like this in configure.ac Chris@0: (or configure.in): Chris@0:
Chris@0:
Chris@0: PKG_CHECK_MODULES(SNDFILE, sndfile >= 1.0.2, ac_cv_sndfile=1, ac_cv_sndfile=0)
Chris@0:
Chris@0: AC_DEFINE_UNQUOTED([HAVE_SNDFILE],${ac_cv_sndfile},
Chris@0: [Set to 1 if you have libsndfile.])
Chris@0:
Chris@0: AC_SUBST(SNDFILE_CFLAGS)
Chris@0: AC_SUBST(SNDFILE_LIBS)
Chris@0:
Chris@0: Chris@0: This will automatically set the SNDFILE_CFLAGS and SNDFILE_LIBS Chris@0: variables which can be used in Makefile.am like this: Chris@0:
Chris@0:Chris@0: SNDFILE_CFLAGS = @SNDFILE_CFLAGS@ Chris@0: SNDFILE_LIBS = @SNDFILE_LIBS@ Chris@0:Chris@0:
Chris@0: If you install libsndfile from source, you will probably need to set the Chris@0: PKG_CONFIG_PATH environment variable as suggested at the end of the Chris@0: libsndfile configure process. For instance on my system I get this: Chris@0:
Chris@0:Chris@0: -=-=-=-=-=-=-=-=-=-= Configuration Complete =-=-=-=-=-=-=-=-=-=- Chris@0: Chris@0: Configuration summary : Chris@0: Chris@0: Version : ..................... 1.0.5 Chris@0: Experimental code : ........... no Chris@0: Chris@0: Tools : Chris@0: Chris@0: Compiler is GCC : ............. yes Chris@0: GCC major version : ........... 3 Chris@0: Chris@0: Installation directories : Chris@0: Chris@0: Library directory : ........... /usr/local/lib Chris@0: Program directory : ........... /usr/local/bin Chris@0: Pkgconfig directory : ......... /usr/local/lib/pkgconfig Chris@0: Chris@0: Compiling some other packages against libsndfile may require Chris@0: the addition of "/usr/local/lib/pkgconfig" to the Chris@0: PKG_CONFIG_PATH environment variable. Chris@0:Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:
Chris@0: The pkg-config program makes finding the correct compiler flag values and Chris@0: library location far easier. Chris@0: During the installation of libsndfile, a file named sndfile.pc is installed Chris@0: in the directory ${libdir}/pkgconfig (ie if libsndfile is installed in Chris@0: /usr/local/lib, sndfile.pc will be installed in Chris@0: /usr/local/lib/pkgconfig/). Chris@0:
Chris@0:Chris@0: In order for pkg-config to find sndfile.pc it may be necessary to point the Chris@0: environment variable PKG_CONFIG_PATH in the right direction. Chris@0:
Chris@0:Chris@0: export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig Chris@0:Chris@0: Chris@0:
Chris@0: Then, to compile a C file into an object file, the command would be: Chris@0:
Chris@0:Chris@0: gcc `pkg-config --cflags sndfile` -c somefile.c Chris@0:Chris@0:
Chris@0: and to link a number of objects into an executable that links against libsndfile, Chris@0: the command would be: Chris@0:
Chris@0:Chris@0: gcc `pkg-config --libs sndfile` obj1.o obj2.o -o program Chris@0:Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:
Chris@0: This has been added for version 1.0.13. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: This is caused by the fact that the conversion from 16 bit short to float is Chris@0: done by dividing by 32768 (0x8000 in hexadecimal) while the conversion from Chris@0: float to 16 bit short is done by multiplying by 32767 (0x7FFF in hex). Chris@0: So for instance, a value in a 16 bit PCM file of 20000 gets read as a floating Chris@0: point number of 0.6103515625 (20000.0 / 0x8000). Chris@0: Converting that back to a 16 bit short results in a value of 19999.3896484375 Chris@0: (0.6103515625 * 0x7FFF) which then gets rounded down to 19999. Chris@0:
Chris@0:Chris@0: You will notice that for this particular case, the error is 1 in 20000 or Chris@0: 0.005%. Chris@0: Interestingly, for values of less than 16369, dividing by 0x8000 followed Chris@0: by multiplying by 0x7FFF and then rounding the result, gives back the Chris@0: original value. Chris@0: It turns out that as long as the host operating system supplies the 1999 ISO Chris@0: C Standard functions lrintf and lrint (or a replacement has Chris@0: been supplied) then the maximum possible error is 1 in 16369 or about 0.006%. Chris@0:
Chris@0:Chris@0: Regardless of the size of the error, the reason why this is done is rather Chris@0: subtle. Chris@0:
Chris@0:Chris@0: In a file containing 16 bit PCM samples, the values are restricted to the range Chris@0: [-32768, 32767] while we want floating point values in the range [-1.0, 1.0]. Chris@0: The only way to do this conversion is to do a floating point division by a value Chris@0: of 0x8000. Chris@0: Converting the other way, the only way to ensure that floating point values in Chris@0: the range [-1.0, 1.0] are within the valid range allowed by a 16 bit short is Chris@0: to multiply by 0x7FFF. Chris@0:
Chris@0:Chris@0: Some people would say that this is a severe short-coming of libsndfile. Chris@0: I would counter that anybody who is constantly converting back and forth Chris@0: between 16 bit shorts and normalised floats is going to suffer other losses Chris@0: in audio quality that they should also be concerned about. Chris@0:
Chris@0:Chris@0: Since this problem only occurs when converting between integer data on disk and Chris@0: normalized floats in the application, it can be avoided by using something Chris@0: other than normalized floats in the application. Chris@0: Alternatives to normalized floats are the short and int data Chris@0: types (ie using sf_read_short or sf_read_int) or using un-normalized floats Chris@0: (see Chris@0: Chris@0: SFC_SET_NORM_FLOAT). Chris@0:
Chris@0:Chris@0: Another way to deal with this problem is to consider 16 bit short data as a Chris@0: final destination format only, not as an intermediate storage format. Chris@0: All intermediate data (ie which is going to be processed further) should be Chris@0: stored in floating point format which is supported by all of the most common Chris@0: file formats. Chris@0: If floating point files are considered too large (2 times the size of a 16 bit Chris@0: PCM file), it would also be possible to use 24 bit PCM as an intermediate Chris@0: storage format (and which is also supported by most common file types). Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: This is actually a Winamp problem. Chris@0: The official Microsoft spec suggests that the 'fmt ' chunk should be 18 bytes. Chris@0: Unfortunately at least one of Microsoft's own applications (Sound Recorder on Chris@0: Win98 I believe) did not accept 18 bytes 'fmt ' chunks. Chris@0:
Chris@0:Chris@0: Michael Lee did some experimenting and found that: Chris@0:
Chris@0:Chris@0: I have checked that Windows Media Player 9, QuickTime Player 6.4, Chris@0: RealOne Player 2.0 and GoldWave 5.06 can all play u-law files with Chris@0: 16-byte or 18-byte 'fmt ' chunk. Only Winamp (2.91) and foobar2000 Chris@0: are unable to play u-law files with 16-byte 'fmt ' chunk. Chris@0:Chris@0: Chris@0:
Chris@0: Even this is a very small sampling of all the players out there. Chris@0: For that reason it is probably not a good idea to change this now because there Chris@0: is the risk of breaking something that currently works. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: An itemtt> is a single sample of the data type you are reading; ie a Chris@0: single short value for sf_read_short or a single float Chris@0: for sf_read_float. Chris@0:
Chris@0: Chris@0: For a sound file with only one channel, a frame is the same as a item (ie a Chris@0: single sample) while for multi channel sound files, a single frame contains a Chris@0: single item for each channel. Chris@0: Chris@0: Chris@0:Chris@0: Here are two simple, correct examples, both of which are assumed to be working Chris@0: on a stereo file, first using items: Chris@0:
Chris@0: Chris@0:Chris@0: #define CHANNELS 2 Chris@0: short data [CHANNELS * 100] ; Chris@0: sf_count items_read = sf_read_short (file, data, 200) ; Chris@0: assert (items_read == 200) ; Chris@0:Chris@0: Chris@0:
Chris@0: and now readng the exact same amount of data using frames: Chris@0:
Chris@0: Chris@0:Chris@0: #define CHANNELS 2 Chris@0: short data [CHANNELS * 100] ; Chris@0: sf_count frames_read = sf_readf_short (file, data, 100) ; Chris@0: assert (frames_read == 100) ; Chris@0:Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:
Chris@0: This is somewhat complicated. Chris@0: First some background. Chris@0:
Chris@0: Chris@0:Chris@0: SD2 files are native to the Apple Macintosh platform and use features of Chris@0: the Mac filesystem (file resource forks) to store the file's sample rate, Chris@0: number of channels, sample width and more. Chris@0: When you look at a file and its resource fork on Mac OS X it looks like Chris@0: this: Chris@0:
Chris@0: Chris@0:Chris@0: -rw-r--r-- 1 erikd erikd 46512 Oct 18 22:57 file.sd2 Chris@0: -rw-r--r-- 1 erikd erikd 538 Oct 18 22:57 file.sd2/rsrc Chris@0:Chris@0: Chris@0:
Chris@0: Notice how the file itself looks like a directory containing a single file Chris@0: named rsrc. Chris@0: When libsndfile is compiled for MacOS X, it should open (for write and read) Chris@0: SD2 file with resource forks like this without any problems. Chris@0: It will also handle files with the resource fork in a separate file as Chris@0: described below. Chris@0:
Chris@0: Chris@0:Chris@0: When SD2 files are moved to other platforms, the resource fork of the file Chris@0: can sometimes be dropped altogether. Chris@0: All that remains is the raw audio data and no information about the number Chris@0: of channels, sample rate or bit width which makes it a little difficult for Chris@0: libsndfile to open the file. Chris@0:
Chris@0: Chris@0:Chris@0: However, it is possible to safely move an SD2 file to a Linux or Windows Chris@0: machine. Chris@0: For instance, when an SD2 file is copied from inside MacOS X to a windows Chris@0: shared directory or a Samba share (ie Linux), MacOS X is clever enough to Chris@0: store the resource fork of the file in a separate hidden file in the Chris@0: same directory like this: Chris@0:
Chris@0:Chris@0: -rw-r--r-- 1 erikd erikd 538 Oct 18 22:57 ._file.sd2 Chris@0: -rw-r--r-- 1 erikd erikd 46512 Oct 18 22:57 file.sd2 Chris@0:Chris@0: Chris@0:
Chris@0: Regardless of what platform it is running on, when libsndfile is asked to Chris@0: open a file named "foo" and it can't recognize the file type from Chris@0: the data in the file, it will attempt to open the resource fork and if Chris@0: that fails, it then tries to open a file named "._foo" to see if Chris@0: the file has a valid resource fork. Chris@0: This is the same regardless of whether the file is being opened for read Chris@0: or write. Chris@0:
Chris@0: Chris@0:Chris@0: In short, libsndfile should open SD2 files with a valid resource fork on Chris@0: all of the platforms that libsndfile supports. Chris@0: If a file has lost its resource fork, the only option is the open the file Chris@0: using the SF_FORMAT_RAW option and guessing its sample rate, channel count Chris@0: and bit width. Chris@0:
Chris@0: Chris@0:Chris@0: Occasionally, when SD2 files are moved to other systems, the file is Chris@0: BinHexed Chris@0: which wraps the resource fork and the data fork together. Chris@0: For these files, it would be possible to write a BinHex parser but Chris@0: there is not a lot to gain considering how rare these BinHexed SD2 Chris@0: files are. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: Unfortunately no. Chris@0: libsndfile contains code written by other people who have agreed that their Chris@0: code be used under the GNU LGPL but no more. Chris@0: Even if they were to agree, there would be significant difficulties in Chris@0: dividing up the payments fairly. Chris@0:
Chris@0: Chris@0:Chris@0: The only way you can legally use libsndfile as a statically linked Chris@0: library is if your application is released under the GNU GPL or LGPL. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: libsndfile is being used by large numbers of people all over the world Chris@0: without any problems like this. That means that it is much more likely Chris@0: that your code has a bug than libsndfile. However, it is still possible Chris@0: that there is a bug in libsndfile. Chris@0:
Chris@0:Chris@0: To figure out whether it is your code or libsndfile you should do the Chris@0: following: Chris@0:
Chris@0:Chris@0: If compiler X is a C++ compiler then no. Chris@0: C and C++ are different enough to make writing code that compiles as valid C Chris@0: and valid C++ too difficult. Chris@0: I would rather spend my time fixing bugs and adding features. Chris@0:
Chris@0: Chris@0:Chris@0: If compiler X is a C compiler then I will do what I can as long as that does Chris@0: not hamper the correctness, portability and maintainability of the existing Chris@0: code. Chris@0: It should be noted however that libsndfile uses features specified by the 1999 Chris@0: ISO C Standard. Chris@0: This can make compiling libsndfile with some older compilers difficult. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: Yes, libsndfile can read files from pipes. Chris@0: Unfortunately, the write case is much more complicated. Chris@0:
Chris@0: Chris@0:Chris@0: File formats like AIFF and WAV have information at the start of the file (the Chris@0: file header) which states the length of the file, the number of sample frames Chris@0: etc. Chris@0: This information must be filled in correctly when the file header is written, Chris@0: but this information is not reliably known until the file is closed. Chris@0: This means that libsndfile cannot write AIFF, WAV and many other file types Chris@0: to a pipe. Chris@0:
Chris@0: Chris@0:Chris@0: However, there is at least one file format (AU) which is specifically designed Chris@0: to be written to a pipe. Chris@0: Like AIFF and WAV, AU has a header with a sample frames field, but it is Chris@0: specifically allowable to set that frames field to 0x7FFFFFFF if the file Chris@0: length is not known when the header is written. Chris@0: The AU file format can also hold data in many of the standard formats (ie Chris@0: SF_FORMAT_PCM_16, SF_FORMAT_PCM_24, SF_FORMAT_FLOAT etc) as well as allowing Chris@0: data in both big and little endian format. Chris@0:
Chris@0: Chris@0:Chris@0: See also FAQ Q6. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: Yes, but you must do two separate configure/build/test runs; one on PowerPC Chris@0: and one on Intel. Chris@0: It is then possible to merge the binaries into a single universal binary using Chris@0: one of the programs in the Apple tool chain. Chris@0:
Chris@0: Chris@0:Chris@0: It is not possible to build a working universal binary via a single Chris@0: compile/build run on a single CPU. Chris@0:
Chris@0: Chris@0:Chris@0: The problem is that the libsndfile build process detects features of the CPU its Chris@0: being built for during the configure process and when building a universal binary, Chris@0: configure is only run once and that data is then used for both CPUs. Chris@0: That configure data will be wrong for one of those CPUs. Chris@0: You will still be able to compile libsndfile, and the test suite will pass on Chris@0: the machine you compiled it on. Chris@0: However, if you take the universal binary test suite programs compiled on one Chris@0: CPU and run them on the other, the test suite will fail. Chris@0:
Chris@0: Chris@0:Chris@0: Part of the problem is the the CPU endian-ness is detected at configure time. Chris@0: Yes, I know the Apple compiler defines one of the macros __LITTLE_ENDIAN__ Chris@0: and __BIG_ENDIAN__, but those macros are not part of the 1999 ISO C Standard Chris@0: and they are not portable. Chris@0:
Chris@0: Chris@0:Chris@0: Endian issues are not the only reason why the cross compiled binary will fail. Chris@0: The configure script also detects other CPU specific idiosyncrasies to provide Chris@0: more optimized code. Chris@0:
Chris@0: Chris@0:Chris@0: Finally, the real show stopper problem with universal binaries is the problem Chris@0: with the test suite. Chris@0: libsndfile contains a huge, comprehensive test suite. Chris@0: When you compile a universal binary and run the test suite, you only test the Chris@0: native compile. Chris@0: The cross compiled binary (the one with the much higher chance of having Chris@0: problems) cannot be tested. Chris@0:
Chris@0: Chris@0:Chris@0: Now, if you have read this far you're probably thinking there must be a way Chris@0: to fix this and there probably is. Chris@0: The problem is that its a hell of a lot of work and would require significant Chris@0: changes to the configure process, the internal code and the test suite. Chris@0: In addition, these changes must not break compilation on any of the platforms Chris@0: libsndfile is currently working on. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: There's a very good reason for this. Chris@0: I will only distribute things that I actually have an ability to test and Chris@0: maintain. Chris@0: Project files for a bunch of different compilers and Integrated Development Chris@0: Environments are simply too difficult to maintain. Chris@0:
Chris@0: Chris@0:Chris@0: The problem is that every time I add a new file to libsndfile or rename an Chris@0: existing file I would have to modify all the project files and then test that Chris@0: libsndfile still built with all the different compilers. Chris@0:
Chris@0: Chris@0:Chris@0: Maintaining these project files is also rather difficult if I don't have access Chris@0: to the required compiler/IDE. Chris@0: If I just edit the project files without testing them I will almost certainly Chris@0: get it wrong. Chris@0: If I release a version of libsndfile with broken project files, I'll get a bunch Chris@0: of emails from people complaining about it not building and have no way of Chris@0: fixing or even testing it. Chris@0:
Chris@0: Chris@0:Chris@0: I currently release sources that I personally test on Win32, Linux and Chris@0: MacOS X (PowerPC) using the compiler I trust (GNU GCC). Chris@0: Supporting one compiler on three (actually much more because GCC is available Chris@0: almost everywhere) platforms is doable without too much pain. Chris@0: I also release binaries for Win32 with instructions on how to use those Chris@0: binaries with Visual Studio. Chris@0: As a guy who is mainly interested in Linux, I'm not to keen to jump through Chris@0: a bunch of hoops to support compilers and operating systems I don't use. Chris@0:
Chris@0: Chris@0:Chris@0: So, I hear you want to volunteer to maintain the project files for Some Crappy Chris@0: Compiler 2007? Chris@0: Well sorry, that won't work either. Chris@0: I have had numerous people over the years offer to maintaining the project Chris@0: files for Microsoft's Visual Studio. Chris@0: Every single time that happened, they maintained it for a release or two and Chris@0: then disappeared off the face of the earth. Chris@0: Hence, I'm not willing to enter into an arrangement like that again. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: MP3 is not supported for one very good reason; doing so requires the payment Chris@0: of licensing fees. Chris@0: As can be seen from Chris@0: Chris@0: mp3licensing.com Chris@0: the required royalty payments are not cheap. Chris@0:
Chris@0: Chris@0:Chris@0: Yes, I know other libraries ignore the licensing requirements, but their legal Chris@0: status is extremely dubious. Chris@0: At any time, the body selling the licenses could go after the authors of those Chris@0: libraries. Chris@0: Some of those authors may be students and hence wouldn't be worth pursuing. Chris@0:
Chris@0: Chris@0:Chris@0: However, libsndfile is released under the name of a company, Mega Nerd Pty Ltd; Chris@0: a company which has income from from libsamplerate licensing, libsndfile based Chris@0: consulting income and other unrelated consulting income. Chris@0: Adding MP3 support to libsndfile could place that income would be under legal Chris@0: threat. Chris@0:
Chris@0: Chris@0:Chris@0: Fortunately, Ogg Vorbis exists as an alternative to MP3. Chris@0: Support for Ogg Vorbis was added to libsndfile (mostly due to the efforts of Chris@0: John ffitch of the Csound project) in version 1.0.18. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0: Chris@0:Chris@0: Here is a checklist of things you need to do to make sure your use of libsndfile Chris@0: in a closed source or commercial project complies with the license libsndfile is Chris@0: released under, the GNU Lesser General Public License (LGPL): Chris@0:
Chris@0: Chris@0:Chris@0: Currently the precompiled windows binaries are thoroughly tested on Windows XP. Chris@0: As such, they should also work on Win2k and Windows Vista. Chris@0: They may also work on earlier versions of Windows. Chris@0:
Chris@0: Chris@0:Chris@0: Since version 0.1.18 I have also been releasing precompiled binaries for Win64, Chris@0: the 64 bit version of Windows. Chris@0: These binaries have received much less testing than the 32 bit versions, but Chris@0: should work as expected. Chris@0: I'd be very interested in receiving feedback on these binaries. Chris@0:
Chris@0: Chris@0: Chris@0: Chris@0:Chris@0:
Chris@0: Chris@0:Chris@0: Since version 1.0.21 the top level Makefile has an extra make target, Chris@0: 'test-tarball'. Chris@0: Building this target creates a tarball called called: Chris@0:
Chris@0: Chris@0:Chris@0: in the top level directory. Chris@0: This tarball can then be copied to the target platform. Chris@0: Once untarred and test script test_wrapper.sh can be run from Chris@0: the top level of the extracted tarball. Chris@0:
Chris@0: Chris@0: Chris@0:
Chris@0: The libsndfile home page is here :
Chris@0:
Chris@0: http://www.mega-nerd.com/libsndfile/.
Chris@0:
Chris@0: Version : 1.0.25
Chris@0: