Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
From: Jörn Nettingsmeier (nettings_AT_folkwang.uni-essen.de)
Date: pe loka 08 1999 - 10:51:19 EDT
hello,
i hope you'll forgive me joining this thread as a non-programmer...
i have some thoughts about multitrack files that may be useful but
need verification.
some suggestions may be utterly stupid, and i'd appreciate
corrections from people who really know about this !
one file, many tracks interleaved:
+ easy streaming
+ easier to organize and backup than multiple files
+ probably easier to implement (my guess)
- changing track offsets means rewriting the entire file
(these are useful for me to give a sloppy hihat-track a little
more "edge" or relaxing eager bass players :). the adat has
this built in.)
- moving around parts is complicated
one file per track:
+ easy offsetting, just add zeros at the beginning
+ easy to move parts around
+ tracks can be spread over different disks, thus speeding up disk
i/o.
- tracks will be read at differrent speeds depending on disk
geometry and other fs related things, so i'd expect this needs
larger buffers than interleaved files, thus greater latency.
(does that make sense ?)
it seems that the first way is more elegant to read from/write to in
real time, while the latter is nicer for editing purposes.
waiting for enlightenment,
jörn
Paul Barton-Davis wrote:
>
> >> OK, so to my disappointment, Michael Pruett's libaudiofile, just like
> >> its SGI counterpart, doesn't support multi-track files. Does anyone
> >> have any advice on file formats that support non-interleaved,
> >> multi-track sound ?
> >
> >Non-interleaved? Why not just use multiple conventional files (mono or
> >stereo) which get read or written in parallel?
>
> Looks like this will have to be the way for now. But this sucks from
> the application/user point of view. I want my recording session
> bundled up in a single file, not 2 or 3 or 17 files.
>
> >But why wouldn non-interleaved be better performance? Wouldn't you have
> >to bounce around the disk more?
>
> well, now that i think about it, what with fs prefetching and all,
> yes, you might be right for the read case. but for writing, it means
> all kinds of lseek() calls if we just want to overwrite a single track
> so that we can write single samples.
>
> however, because the mixer doesn't do this (rewrite a single track),
> its cheap enough for now. to be honest even if it did, it would be
> reading the file in as a series of chunks, then do pointer skips
> rather than lseeks() to reset the data for a given track, and then a
> final write(2) of a chunk. its only in the case of wanting to
> overwrite a track without reading the file first that the interleaving
> will cost, right ?
-- Jörn Nettingsmeier Kurfürstenstr. 49 45138 Essen, Germany
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST