On Wednesday 20 June 2007, Roger Dannenberg wrote: > I haven't made much progress toward a portable sound file system, but I > want to revisit this problem. I'm still using my own library in Nyquist > and Aura, but I would like to use something with a wider base of users > and developers. I can put some resources into this, and I'm curious > about other people's opinions on the state of the art and what if > anything should be done. > > Recently, a student and I re-examined libsndfile and libaudiofile, and I > was disappointed by both. Libsndfile uses a different scale factor on > input and output. This seems to stem from a view that audio data is > basically an analog approximation and a little distortion is OK. My view > is that the implementation should follow a precise specification and the > relationship between float and int samples should be fixed (e.g. ints > can be viewed as binary fractions, making the scale factor 2^N). > Libsndfile does not support Ogg Vorbis, mp3, or SDIF, although it does > support a lot of formats and at least one that would allow files longer > than 2^32 bytes. Libaudiofile reads data with a scale factor of 1/(2^N - > 1) which seems wrong, but I think this can be changed through the API. > Worse, it rounds floats toward zero rather than rounding to the nearest > value, introducing a nonlinearity on output. In spite of the features > and support, I think both libsndfile and libaudiofile have some > fundamental (although easily fixed) problems.
Hello Roger, I am using libsndfile and libaudiofile in different projects. I started with libaudiofile which soon I filt to be hardly maintained. Therefore I switched to libsndfile in the more recent prokects and I am rather happy with it. 2 of the points that you critize above are in fact no longer true! 1.) The most important point for me that I noted as well when I started using libsndfie were the different scaling factors on input and output. When I complained about that Erik argued that by means of this he could avoid to take into account the asymmetric clipping (bounds for negative and positive values are different) in the output module which would be more efficient. Still I could convince him that the possibility to read and write float samples from integer sound files without implicite scaling would be a very valuable feature. So this is possible since version 1.0.12 (at least) by means of setting the clipping mode (per sound file) using the sf_command with the SFC_SET_CLIPPING argument. 2.) ogg vorbis is supported now at least since version 1.0.17 (as well as caf, flac and bwav by the way !) There was some lobbying for mp3, but Erik refused to implement that due to the legal problems - which I cannot comment on because I myself don't understand this very well. There was not yet any lobbying for SDIF - which is certainly our fault - however, we have the open source SDIF and Easdif libraries (now on sourceforge as well by the way) which we use for SDIF data such that I do not miss this format too much in libsndfile! > My sense is that writing a new sound file library is a waste of effort > and would not serve many users. I could modify libsndfile, but Erik de > Castro Lopo (creator of libsndfile) would consider a fork of the project > to be "hostile". (Is that important? Audacity already keeps a private > copy of libsndfile, but probably more for source control than anything > else.) I could also work on libaudiofile, but adding a lot of new file > formats there seems like duplication of effort. There's also the > legality question for mp3 support -- I don't understand this, but it > seems to me that dynamically linking to Lame as does Audacity would be > relatively easy. Given that libsndfile now supports everything that I ever needed - besides mp3 - and given as well that Erik is quickly implementing new formats if they become important I would agree that any effort put into a new sound file io library is a waste of time. Cheers Axel > Meanwhile, the portmedia project is up at SourceForge. I'm slowly > getting things set up there. If anyone would like to > adapt/recreate/update the PortMusic web pages on SourceForge, let me know. -- Axel Roebel IRCAM Analysis/Synthesis Team Phone: ++33-1-4478 4845 | Fax: ++33-1-4478 1540 _______________________________________________ media_api mailing list [email protected] http://www.create.ucsb.edu/mailman/listinfo/media_api
