Subject: [linux-audio-dev] The future of libsndfile
From: Erik de Castro Lopo (erikd_AT_zip.com.au)
Date: to elo 19 1999 - 08:19:39 EDT
Hi all,
I've been a little overwhelmed with the recent discussion about what
features people would like. Rather than trying to answer each email
separately I will try to respond to all the issues in one go. If
I have missed anything please point it out.
Maurizio Umberto Puxeddu had the following suggestion:
> > > 2) Some applications (see Csound) may need to update the file header
> > > each time you perform a write operation (so that B can read while A is
> > > writing).
<snip>
> Csound can rewrite continuously
> the header while writing a sound file (-R switch), so that you can use
> an audioplayer to move through the file while during the synthesis. (You
> probably sets the file length to the maximum value before the close
> operation, but this is a bit dangerous.)
Yes I think this is a good idea. I have been thinking about cleaning up
the
header writing code and when I do this I will add an interface something
like sf_update_header () which will rewrite the header with the number
of
samples written at the time it is called.
Another of Maurizio's suggestions was:
> I was not (not only) asking Erik to insert one or two features. I meant:
> you have the code for doing this operation while reading/writing a file
> but an application may have to do the same with audio data resident in
> memory. Why
> don't include in your API functions like
>
> swap_word_endianess(word_t *, size_t);
>
> convert_double_to_ulaw8(double *, size_t, byte_t *);
These functions in libsndfile are slightly different but I will expose
whatever may be useful. The exposed functions will all be named sf_* ().
In order to minimise the size of the libsndfile headers, I will use two
header files sndfile.h which will be similar to the current one and
sndfileex.h which contains the extra utility functions and includes
the first header.
Maurizio was rather busy and also brought up the issue of a possible
inconsistency between the behaviour of sf_read_XXX / sf_write_XXXX
and the behaviour of sf_seek.
I (Erik de Castro Lopo) wrote :
> > I did have my reasons for this but maybe you have found something that
> > needs correcting. The reason I use items for sf_read_XXX and
> > sf_write_XXX is so that there is no chance of over-running the end of
> > array pointer to by the pointer that has been passed into the library.
to which Bruce (est_AT_hyperreal.org) replied :
> Hmm..you still have that risk if the user is confused about the sample
> format. I'll throw in a strong vote for frame counts in read and
> write.
Maurizio asked for an explanation of my comment. Here it is :
Typically, someone using my library would have allocated a buffer to
read the samples into after opening the file ie:
int items, readcount ;
double array [BUFFER_LEN] ;
sndfile = sf_open_read ("/path/to/file.wav", &sfinfo) ;
items = BUFFER_LEN - (BUFFER_LEN % sfinfo.channels) ;
while (readcount = sf_read_double (sndfile, array, items, 0))
{
/* Process the samples */
}
With the read function operating in items, the worst that can happen
is that items will not be an integer multiple of channels and an
error condition will be gernerated.
If on the other hand the sf_read_XXXX functions worked on sample
frames the naive user may have done this :
int samples, readcount ;
double array [BUFFER_LEN] ;
sndfile = sf_open_read ("/path/to/file.wav", &sfinfo) ;
while (readcount = sf_read_double (sndfile, array, samples, 0))
{
/* Process the samples */
}
which would be fine for mono, would have over-run the end of the buffer
with a multichannel file. Having done silly things like myself, I
know that these kinds of errors can be particularly hard to find in some
instances.
Anyway, now I have explained it I am less convinced than I was. With a
little encouragement I'll probably make a decision to change the read
and write operations from items to frames. From a coding point of
view its a trivial change but I'm going to try and come up with a
way of making the change without breaking any existing apps.
Finally, there was much discussion about more dynamic operations on
files
than simple reads or writes. One of the first things I'll be
implementing
in this area is the ability to open a file in read/write mode. This is
not too difficult and was mainly left out originally to simplify the
implementation when I was still working out a spec for the library. As
Maurizio pointed out, there is an advantage to having separate read
and write file pointers.
I have also been having some thoughts along the lines of non-destructive
editing with edit lists etc. My conclucion was that none of the formats
libsndfile currently supports is all that well suited to this problem.
My idea was to make a new (or yet another) file format which would
specifically be designed to be cross platform and allow non-destructive
editing. It would also be possible to write a rendering routine which
takes a file in this new format as input and mixes/renders it into one
of the standard playback formats like WAV or AIFF. The only questions is
whether this should be part of the library or a separte application.
So, it looks like I've got lots of things to do. I had planned to get a
new version out in the next couple of weeks contained PAF and SVX/IFF
file support and reading/writing pipes. Once that is out I'll start
picking of these suggestions one by one.
Cheers and thanks,
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo erikd_AT_zip.com.au
+-------------------------------------------------+
The National Multiple Sclerosis Society of America recently started an
advertising campaign with the slogan "MS: It's not a software company".
Seasoned IT professionals will have no trouble telling the two MS's
apart.
One is a debilitating and surprisingly widespread affliction that
renders
the sufferer barely able to perform the simplest task. The other is a
disease.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST