Subject: Re: [linux-audio-dev] Re: Nicola Bernardini's sound file library comments
From: Erik de Castro Lopo (erikd_AT_zip.com.au)
Date: ke elo 18 1999 - 08:52:56 EDT
Maurizio Umberto Puxeddu wrote:
>
> Hello Erik and Nicola. Hello all.
>
> I think my messange has been partially misunderstood (due to my poor
> english! :).
I maintain that your english is very much better than my Italian. You
have nothing to apologise for.
> 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 *);
I will consider it if other people think it is a good idea. At the moment
I cannot see why anybody would want to do either endian swapping or ulaw
encoding/decoding in any place other than reading from or writing to a
file. Under what circumstances would you want to perform either of these
two operations resident in memory?
> word_t *resample(word_t *, size_t, double, double);
I am almost certain I will add a buffer to buffer resample function
as it is both difficult and generally useful.
> so that an application needn't to link two libraries for doing the same
> operation in different contexts? Depending on your implementation this
> may require little or no modifications.
>
> I donwloaded last version of libsndfile.
I hope that was version 0.0.15 or 0.0.16. Version 0.0.15 had a very minor
MacOS bug that was fixed in 0.0.16. On Linux they are identical.
> Is the documentation of your API up to date?
I just checked and it does seem to be.
> If yes I'd like to point some things that, as far as I understand, are
> important:
>
> 1) There is no format-independent way to know the file length (/duration
> in seconds) other than waiting for EOF.
Opening a file works like this :
SNDFILE *sndfile ;
SF_INFO sfinfo ;
sndfile = sf_open_read ("/path/to/file.wav", &sfinfo) ;
On successful file open the sndfile pointer will be a non-NULL
pointer and the value of sfinfo.samples will tell your how many
samples are in the file. A sample in this case is what I think
you are calling a sample frame (one value per sample for mono,
two values for stereo etc).
> 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).
At the moment libsndfile only works with regular files. That is, it does
not work with pipes. When a file is opened for write and is closed using
sf_close, the library fseeks() to the start of the file and fills in the
header information correctly.
One of the things I have on my TODO list is to make libsndfile work
so it can read and write pipes. Unfortunately, once one has started
writing a large amount of data to a pipe it is not possible to fseek ()
back to the beginning of the file and correct the header like one can
with regular files. I see no way around this problem.
> 3) Some functions in audio editors are easy to implement in "direct
> mode" if the file is accessible in read/write mode.
> 3bis) It is possible to append data to a file with your API?
Neither of these two things are currently possible. I have just had a
look at SGI's libaudiofile documentation and it has similar restrictions.
That does not mean it will never be possible with libsndfile, just that
I did not think it was important yet. Give me a real example where these
operations are really necessary and I'll look into it.
I should mention that I had originally thought that operation on
pipes was not necessary. I then received email from the LAME
(http://www.sulaco.org/mp3/) mpeg 3 encoder project. They were
using libsndfile when encoding files from disk and different code
when reading a pipe. It turns out LAME can accept data piped out
of a CD ripper. Working with pipes is now high on my list of
priorities. When I get that working the LAME people will probably
drop their own header parsing code.
> 4) Why don't you make the I/O operations frame-based instead of
> requiring that
> "items" to be an integer times the channels number? (you did it for seek
> but not for read and write)
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.
At the time of writing the early versions of libsndfile it seemed
sensible that sf_seek () move by number of multichannel samples
but I can see now that there is an inconsistency.
> I think you should decide about 4) now that libsndfile is still no so
> popular... :)
What do other people think? Is this inconsistency a problem? The
documentation does spell it out fully and correctly. To a certain
extent I took my lead from the interface of the fread/fwrite/fseek
functions which work in a similar way.
> This is just one of the two way I'd like to help libsndfile. The other
> will be WRITING THE C++ API. Not now, because I have to finish some
> other stuff but I'll first start discussing details with Erik.
Good, I look forward to it.
> About channel mixing/splitting:
I'm not really sure that something like this belongs in a library
for reading and writing sound files. Being able to split a multichannel
file and read samples from one channel at a time might be useful,
but at the moment it is not high on my list of priorities. Being
able to mix a number of channels down to mono or a stereo pair
was not something I even envisioned. I think it would be difficult
to make it general enough for even a large majority of the cases where
mixing is done.
Maybe your C++ wrapper (which may be named something like
libAbstractAudio) could have a broader interface than the C library
it wraps. Your library could use libsndfile for for file I/O but
provide many features that libsndfile does not. This would not be
inconsistent with the differences in the ways that C and C++ coders
work. Latter, if features which are available in the C++ version of
the library are attractive to users of the C library, code could
(with a little work) migrate from the C++ wrapper to the C library,
lightening the code size of the C++ wrapper.
> I could adapt and send some code from Abstract Audio.
> It works this way: the library stores a mixer pointer, defined as a NxM
> matrix where N is the virtual channel number and M is the real channel
> number.
>
> mixer[i][j] is the contribute from the source channel j to the virtual
> channel i
>
> vchannel[i] = mixer[i][j] * rchannel[j] (using Einstein notation)
>
> During a read or write operation the library calls the mixing routine if
> the channel numbers don't match. If at open time the application don't
> indicate a mixer (that is, the mixer pointer in the handle structure is
> NULL), the library creates a default mixer that mixes channels in equal
> parts.
> I should have code for mixing and for default mixer generation. The
> mixing routine has code to handle efficiently common cases like 2x1 or
> 1x2 mixers and general code for the remaining cases.
> Of course, I'd add a general mix_buffer() call too.
I'd prefer not to rush into this. I am by nature a rather conservative
coder and I think there are a number of issues in libsndfile that need
to be resolved before features like you have proposed. As I have
suggested, this does not mean that you cannot work your ideas into
a library that wraps libsndfile. Your work can bypass completely the
complexities of file header parsing and other file I/O issues while
providing feedback and ideas for the development of libsndfile.
Cheers,
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo erikd_AT_zip.com.au
+-------------------------------------------------+
Windows 95/98 - 32 bit extensions and a graphical shell for a 16 bit
patch to an 8 bit operating system originally coded for a 4 bit
microprocessor, written by a 2 bit company that can't stand 1 bit
of competition.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:25:52 EST