Re: [linux-audio-dev] protux, stereo and interleaving

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] protux, stereo and interleaving
From: Richard Dobson (rwd_AT_cableinet.co.uk)
Date: Sat Feb 10 2001 - 13:40:01 EET


[ttrying to reply to all the posts on this thread!]

I very substantially agree with all this, given that the atomic unit, so
to speak, is the mono track. I also, in particular, take the point about
the limits to file size. My one concern is that, for some of the
applications I have in mind, some of the audio data is not really atomic
at this level. Specifically, B-Format encoded data exists in a minimum
of three tightly phase and amplitude related signals, and for higher and
periphonic orders this can expand to nine signals and beyond. As far as
I understand, there are virtually no safe operations that can be applied
to one signal, without destroying the encoding relationship.
Nevertheless, there are plenty of interesting, safe, and musically
useful operations that can be applied to the overall 'track'.

Now these multi-channel encoded tracks may already be quite large, and
splitting them into separate mono files, even where this is hidden from
the user, will take up even more disk space (presuming non-destructuive
editing). This is rather different from the situation in which most, or
all, the sources are mono, and only the result is stereo, or
multi-channel. Taking the example of the Samplitude locked-stereo mode,
I rather like this (!), as it serves to prevent even accidental
operations that would destroy the integrity of the oveall signal. One
could still offer an 'unlocked' mode for hackers, which would split
everything and anything up, with a suitable warning to the user.

So, could the mono-file paradigm extend comfortably enough, where such
multi-channel encoded sources are involved? Or could a mixed model,
supporting both mono files and interleaved files, be practicable?

Paul Davis wrote:
>
> >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 did wonder.

> 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.
>

I haven't read all the arguments about this. I assume one requirement is
for project transfer using read-write removeable media (external SCSI
disk, even a Jaz drive). I never thought ISO9660 could be used that way.
Is that possible?

Richard Dobson

-- 
Test your DAW with my Soundcard Attrition Page!
http://www.bath.ac.uk/~masrwd (LU: 3rd July 2000)
CDP: http://www.bath.ac.uk/~masjpf/CDP/CDP.htm (LU: 23rd February 2000)


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Sat Feb 10 2001 - 13:51:34 EET