Subject: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
From: Erik de Castro Lopo (erikd_AT_zip.com.au)
Date: su elo 15 1999 - 17:54:22 EDT
Nicola Bernardini wrote:
<snip>
> 2) among all the difficult things we should do (like convincing hardware
> manufacturers that, like open source, open hardware *is* better),
> there's a fairly easy one we should try: converge on 'the' sound
> library for linux, retrofit all applications with it, and maintain
> it as a separate entity so that all application may enjoy free upgrades
> as we upgrade the library. Among the many excellent ones I've seen
> around, currently I feel that Bill Schottstaedt's is the one we should
> go with for several reasons: a) it's simple (or at least it *looks*
> simple, which is even better); b) it's documented; c) it covers pretty
> much basic 'pro' features already (unlimited file length, buffering,
> audio hardware independent handling, etc.). The library is lacking
> a proper Makefile and autoconf features, so again, if Bill agrees
> or does'nt want to do it himself I can offer my help to build these
> files and also a cvs repository for it (at the end of august).
I will first off state that I am the author an audio file reading/writing
library which competes with Bill Schottstaedt's sndlib. Have a look at
http://www.zip.com.au/~erikd/libsndfile/
Like sndlib, libsndfile already has points a, b and c above covered. For
libsndfile documentation have a look at
http://www.zip.com.au/~erikd/libsndfile/api.html
In my personal opinion I think sndlib has some weaknesses in comparision
to my own library that can be enumerated as follows :
1) sndlib looks as if it hasn't been worked on for a number of years
while libsndfile is still under active development
2) sndlib needs to have automake/autoconf support added while libsndfile
already has it
3) libsndfile has more comprehensive error reporting
4) libsndfile has thorough regression tests (distributed with the library)
of nearly all library functionality
Some of the features that make libsndfile attractive are :
1) An interface is designed to limit name space pollution. All libsndfile
functions are named sf_* and all constants are named SF_*
2) The ability to read the audio data as shorts, ints and doubles. For
instance, once a file has been opened the data may be read using any
combination of sf_read_short (), sf_read_int () or sf_read_double
depending on what the user wishes to do with the data. At the moment
there are some small inconsistencies with scaling of audio data (ie
reading a 24-bit WAV file using sf_read_short()) but these will be fixed
in the very near future.
As I stated above libsndfile is currently under development. Some of the
things I am working on at the moment are :
1) improved (and configuable) control of scaling on read/write
2) ability to read from / write to a pipe
3) sample rate convert on read (ie open a file, see that it is not the
desired sample rate, call something like sf_set_samplerate (), then
read data at the correct sample rate using the normal read functions.
4) support for Ensoniq PARIS (digital audio workstation) 16 and 24 bit
file formats and Amiga 8SVX and 16SV file formats.
5) support for IMA ADPCM encoded AIFF files
This "currently under development" status I think is the libsndfile's
greatest strength. libsndfile was started in December last year and
in my opinion has progressed at an amazing pace. Up until now, nobody
else has contibuted code (other than small bug fixes) but I am more
than willing for this to happen.
Cheers,
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo erikd_AT_zip.com.au
+-------------------------------------------------+
"I think there is a world market for maybe five computers."
-- Thomas Watson, Chairman of IBM, 1943
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST