Subject: Re: [linux-audio-dev] Alsa Recording Software Programming HOWTO
From: Tom Pincince (stillone_AT_snowcrest.net)
Date: Sun Jun 25 2000 - 01:09:34 EEST
Juhana,
Thanks, I found this quite helpful.
>>12. Recording level meter.
>>
>>The recording level meter is metering the recorded signal. The meter
>>should be on during the recording. The meter should have a 2-3 seconds
>>peak meter.
>
>
>The meter hold time should be configurable, not fixed. The meter being
>on or off should be configurable, and may follow "auto-input" schemes,
>whereby it shows playback levels during playback and record levels
>during recording, or nothing at all.
I find resettable infinite peak hold to be the most useful, preferably
represented numerically in db below fs, with the bar graph providing
only momentary peak hold. If there is no numeric representation of peak
info then I prefer that the bar graph provide the infinite hold.
>>14. Saving the recording levels
>>
>>The mixer settings should be monitored and changes kept in a list.
This
>>feature allows the recordist later to bring the signal levels of the
entire
>>recording to the same level. Use of this technique adds extra bits to
the
>>sample size which might be useful.
>>
>>This feature would have been useful when an audio engineer decreased
>>the recording volume while symphony orchestra played a composition
with
>>a slowly increasing volume.
>>
>>This can be extended for automatic gain control. While recordist can
>>take the advantages of the AGC, he is still able to remove the AGC
>>effects of the recording.
>
>
>This seems completely absurd to me. You don't mess with this stuff in
>a professional recorder *while* recording. If you want to normalize
>the data later to a given level, then snd or ecasound or mix or a
>number of other programs can help do this. AGC has only ever existed
>in the domain of cheap consumer recorders.
If you mean mixer automation for the monitoring of the recorded signal
then this is ok, since this would not affect the actual recorded
material. For the purpose of capturing the dynamics of the original
performance in the recording, the record level should be set at the
beginning and not changed during the recording unless the original level
was set so poorly that clipping becomes an issue. The jump from 16 bits
to 24 will all but eliminate this kind of mistake.
>>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.) With tape a 24 track setup has the capacity to
store exactly 24 tracks. Once these tracks are used up there is no
option for adding more tracks. Old tracks must be recorded over, and if
the contents of the old tracks are still important, they can only be
preserved by bouncing which does not allow the tracks to be separated
later. If the 24 tracks are comprised of multiple synchronized 8 track
machines, then a complex bouncing procedure can be used that does not
require writing over the original material and allows the individual
tracks to remain separate, but this is a real time procedure that is so
time consuming that it is not appropriate to use during a recording
session. With hdr there is no need for direct correlation between
physical tracks and the files that they are recorded to, it is a virtual
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.
Hdr must also be able to support playlists, which allows for synchronous
playback of files or regions of files regardless of their physical
location on the disk. This places a lot of demand on the hd, and might
tempt the programmer to increase perceived track count by carefully
managing the seek characteristics of the hd through clever patterns of
file allocation on the disk. This is deceptive, and such a system is
not truly random access and may not be compatible with mixing
applications that work exclusively with edl's, particularly if the user
is into composite tracking - a very popular technique. If the current
file system and disk allocation techniques are so real-time unfriendly
that they result in a perceived need to preserve original allocation
when overdubbing, and therefore burdening the recording engineer with
the decision to sacrifice existing material to preserve existing
allocation and maintain high track count or to record to a new file and
possibly reduce track count - all at a time when he should be thinking
about nothing but the sound, then it is time to reconsider the current
file system and disk allocation methods.
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. It can simply be deleted during
normal file management at the end of the recording session or at ones
leisure. More importantly, any application that allows recorded
material to be written over is not Non Destructive. A file that can be
rewritten deliberately can also be rewritten accidentally. The
combination of virtual tracks and edl's has resulted in the creation of
two classes of audio applications, destructive and non destructive.
Destructive applications, such as wave editors, actually change the
audio in a file. Non destructive applications access audio data from
existing files and write any changes to new files. The process of
assembling a composite track from multiple virtual tracks, processing
this composite track with plugins, and writing the result to a new file
accomplishes everything that a destructive application can do, without
the risk of accidents. Live recordings can't be repeated, and you never
know which take will turn out to be the best. An application that has
an unconditional policy of not modifying soundfiles is wonderful,
particularly if more than one person uses the same machine. True non
destructive applications have only one command that alters the contents
of a file; file>delete. Even punch-ins are obsolete. I abandoned tape
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.
> But there is no time
to
>>ask recordist whether to overwrite a file, and there is neither time
to ask
>>for a new filename. Unless recordist explicitly executes "delete" for
the
>>old file, the recorder should record to a new file with automatically
>>generated filename.
Correct.
>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.
Tom
This archive was generated by hypermail 2b28 : Sun Jun 25 2000 - 01:37:35 EEST