Subject: Re: [linux-audio-dev] Alsa Recording Software Programming HOWTO
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: Sun Jun 25 2000 - 02:14:18 EEST
Deep from the heart of ardour-ville ....
>>>15. Don't overwrite
>>>
>>>Each new recording should go to a new file. For sure, recordist
>doesn't
>>>want the recorder overwrite files without asking.
>>
>>
>>This is simply not true. If I am overdubbing, then there are
>>situations where I definitely want to use the original file. One
>>example would be the case of recording 35 minutes of
>>pre-MIDI-sequenced material as a backing track. If I decide to alter
>>the sequence, and re-record it, I don't want another 280MB of data
>>written instead of re-using the original allocation.
>
>But maybe it is true. This is a key issue that highlights the
>superiority of hd recording over tape. The random access nature of the
>hd has resulted in the development of two tools that are simply
>unthinkable in the tape realm, and are so powerful that I sincerely
>recommend forgetting everything you ever learned about tape. The tools
>are virtual tracks and playlists (known also by their more official name
>Edit Decision Lists, or EDL's. The AES is currently working to
>standardize EDL's so that projects can be transferred from one
>proprietary daw to another as easily as a role of tape can be taken from
>one machine to another.)
"virtual tracks" strike me as slightly misleading.
if you write data to blocks of data without regard to which "virtual
track" is in use (but obviously keeping track of which blocks you
use), then its a reasonable term, but it doesn't really describe
anything over and above what "EDL" implies.
a track, from an operational point of view, seems to be "a place to
put recorded material". talking about "virtual tracks" is very odd in
this context. it seems to me to make more sense to use the terminology
adopted by Mackie for their HDR system, and refer to "takes" when
specifically referring to the idea of switching to an entirely new,
semantically contiguous "place to put recorded material". when dealing
with the possibilities of EDL's, such as jumping from material
recorded on one track to material recorded on another, and back again,
the term "virtual tracks" doesn't seem to help much.
>With hdr there is no need for direct correlation between
>physical tracks and the files that they are recorded to, it is a virtual
again, i find this all rather confusing terminology. a recording
system typically has "tracks" and "channels". the "channels" are
physical, the tracks are, in an HDR system, somewhat of an conceptual
simplification because of EDL's. defining what emerges from a given
channel when monitoring (or producing a master (say, stereo, or 5.1,
or whatever), is the process of setting up the EDL.
>one. A system that is only capable of accessing 24 simultaneous tracks
>can simply ignore existing files and create a new one, so there is no
>need to record over an existing file.
that depends on your disk space.
>If the desire to allow over-writes is based on disk space, and not on
>disk performance, then I think that you are being penny wise and pound
>foolish. As disk capacity is now on the order of 10 GB, a 280 MB file
>takes up less than 3% of the total disk space and is not worth thinking
>about during a recording session.
this is nonsense. if i'm doing a 24 channel 32 bit session, and i'm
working on a 20 minute piece, after not very long into the process,
i've got 24 * 215MB of data sitting around. Thats 5GB. If I'm working
with someone who needs to frequently re-record entire tracks, it won't
take me very long to completely fill a 10GB disk. Every time we made a
decision to re-record, we would have been aware of the possibilities:
* use a new take, and thus leave the old one around
* overwrite a previous take, thus destroying it
Your suggesting that you never overwrite denies us the chance to take
that second option, and so after we've been up till 4am, with 16 mikes
on a drum kit plus 6 stereo sound modules running from a sequencer, we
suddenly find we're out of disk space and have to figure out what to
clean up. Which is precisely when the "Delete" option is worst chosen:
tired, irritable and wanting to get things finished. If possible (and
its not always possible) I think it better to allow a recording
engineer and/or artist(s) to use their judgement in a constructive way
to prevent this kind of scenario.
>leisure. More importantly, any application that allows recorded
>material to be written over is not Non Destructive.
And any application that prevents overwriting is inefficient and
restrictive.
> A file that can be
>rewritten deliberately can also be rewritten accidentally. The
Any file that can be deleted "at the end of a recording session or at
your leisure" can also be deleted "at the wrong time".
>combination of virtual tracks and edl's has resulted in the creation of
>two classes of audio applications, destructive and non destructive.
I don't agree. "Non-destructive" was a term used to describe editing
with EDL's. I have never seen it applied to the overall operation of a
program with respect to overwriting when tracking, even if many
programs force that the "no-overwrite" requirement upon you.
>Destructive applications, such as wave editors, actually change the
>audio in a file.
"wave editors" are not, as a class, destructive. some of them are,
some of them are not. snd, for example, is completely non-destructive,
but its definitely not a DAW.
>the risk of accidents. Live recordings can't be repeated, and you never
>know which take will turn out to be the best.
but you certainly know when they turn out wrong. "Oops, I left the
BigBottom (TM) on for that entire take, and its sounds awful. I want
to re-record it. Oh, damn, the program requires me to delete it first."
you can view the extra step in either way:
* require deletion if the user really wants it to go away
* require confirmation if the user really wants to record over it
i'd suggest that its also possible that a user may wish to set things
up so the default is to record over it. i don't like telling users "we
don't think you really want to do that, so you can't". i *do* like
asking them "are you really sure you know what you're doing?".
>of a file; file>delete. Even punch-ins are obsolete. I abandoned tape
To be more precise: you mean the act of writing data directly "over
the top" of existing data.
In general, I agree with you.
>in 1996 and have been doing hdr with cd-r archiving ever since. I am
>currently designing a new recording/editing/mixing application and my
>first decision was to make it non destructive.
Why view the world in such binary terms ? I wasn't suggesting for a
moment that EDL-based non-destructive editing was a bad idea. But I've
got lots of friends who complain about (and read more than a few
magazine articles that also complain about) having to constantly be
watching disk space and constantly cleaning up after a
"non-destructive" recorder has been running for a while.
I am currently *finishing* a new recording/editing/mixing application,
and my first decision was to get it to work efficiently enough that it
could replace 3 8 channel tape machines, and then some (i.e. 24
channels of 32 bit audio at at least 48kHz). Very few (perhaps none)
existing s/w DAW's seem capable of doing this reliably (partly because
of the OS's on which they run).
Having succeeded in doing that, and partially integrated it with the
best Linux sound editor there is (snd), I now need to use snd's EDL
system to enhance the extent to which ardour is "non-destructive". All
editing is 100% non-destructive already, but recording (particularly
in "tracking" situations), which I view as a different task entirely
from editing, has the option of being destructive or not, as the user
sees fit.
>>Well, its a judgement call. I would say that most people used to
>>working with tape systems would say that it should be the other way
>>around.
>
>People working with tape would definitely say that it should be the
>other way around, but tape has a fixed number of simultaneous tracks and
>does not offer random access or playlists. Toto, we're not in Kansas
>any more, and you can't go back to Kansas once you've been to OZ.
Sure, but that doesn't mean that none of the ways of doing things in
Kansas are useful or relevant in the land of OZ, either.
--p
This archive was generated by hypermail 2b28 : Sun Jun 25 2000 - 02:41:46 EEST