Subject: Re: [linux-audio-dev] protux, stereo and interleaving
From: Paul Davis (pbd_AT_Op.Net)
Date: Sat Feb 10 2001 - 00:59:28 EET
>> the files are 1 per-channel, just like protools and samplitude.
>
>
>yes, a lot of programs do this (even CEP); is this out of choice, or
>because of the assumption that WAVE/AIFF can't support multi-channel
>data?
No, its for two completely unrelated reasons. First, the same general
reason for using a non-interleaved format - ease of independent
per-track editing and more notably, recording. Its just
programmatically very complex to do all this stuff with multiple
channels in the same file. Secondly, you would end up with files that
are too big for non-64-bit filesystems. As it stands, we can
comfortably fit a very, very long recording with arbitrary numbers of
channels onto a disk, since each file can be up to 2^32-1 bytes long
(up to about 6 hours of 32 bit data (float or int) at 48kHz). Try that
with 24+ channels in the same file.
>So it is impossible to play the composite result outside the
>application. This is what interests me - while I can readily appreciate
>the 'editorial' advantages of separate mono files, to be able to render
>the final piece independently of the application, a 'standard'
>interleaved format also needs to be supported, for both reading and
>writing.
Ardour exports to any format supported by Erik de Castro Lopo's
libsndfile. At this time, I restrict that to mono or stereo output
files, since I assume that the goal is to be able to play the
composite result with software that doesn't understand multichannel,
EDL based audio.
>Maybe the forthcoming AES 31 standard for portable audio file exchange
>(in which EDLs figure prominently) will be useful as a baseline; they
>are inclining towards Broadcast WAVE at the moment;
Digidesign claims that the decision has already been made!
>I don't know yet how
>they are approaching multi-channel.
Well, I trust that they won't attempt to force a single-file
arrangement. If they do, they'll upset Digidesign and several others,
I suspect.
The result of all this
>committee-work will be a file format enabling complete transfer of audio
>projects (EDLs included, and including a spec for the disk format,
>probably FAT32)
Yes, I've complained to some of the powers that be about this. Its
outrageous that they should be specifying the file system for
this. Absolutely outrageous. If they have to specify something, it
should be ISO9660. The TASCAM-derived format has the same problem.
>Journals per year. Even if you end up with a Linux/Ardour-only file
>format and structure, supporting AES-31 in the fullness of time might be
>a good stategic move. And I can expand my multi-channel toolkit to help
>glue all those mono files together again!
Its definitely my goal to support AES31 at some point. Its not a high
priority right now, partly because there is so much else to do on
Ardour, and partly because I don't know of a single other application
that can import AES31, making it a fairly pointless exercise at this
time.
--p
This archive was generated by hypermail 2b28 : Sat Feb 10 2001 - 01:18:39 EET