Subject: Re: [linux-audio-dev] multi-track audio files - what format ?
From: David Slomin (dgslomin_AT_CS.Princeton.EDU)
Date: pe loka 08 1999 - 10:36:40 EDT
On Thu, 7 Oct 1999, Paul Barton-Davis wrote:
> 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.
On NeXTStep, there was this convention, the name of which I forget, that a
directory could be treated as a single file. You'd name the directory
with a file extension (ie: "multi-track-song1.mts") and each file in that
directory would be equivalent to a chunk in an IFF file. For the
application that needed the multiple chunks, you'd enter the directory and
access them like normal files, but for file management and distribution,
you'd move the directory around as a whole. I'd love to see that on
Linux, as it would solve this problem and many others very cleanly. The
only required code changes would be in file managers (kfm, gmc, etc).
> 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 ?
I'm a little confused. Actually a lot confused. Isn't the default and
most often used case to read and write all tracks at once? Besides, if
you want to rewrite a single track efficiently in an interleaved file,
just mmap the thing, and let paging remove all the cost (and complexity)
of lseeking.
Div.
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST