Re[2]: [linux-audio-dev] peakfiles and EDL's

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

Subject: Re[2]: [linux-audio-dev] peakfiles and EDL's
From: Tom Pincince (stillone_AT_snowcrest.net)
Date: Tue Feb 27 2001 - 21:28:22 EET


> And important note to add is that depending on the peak file bin size,
> low frequencies you will see the magnitude go up and down (real low as
> you have calculated).
>
Good point. Since the purpose of peakfiles is to produce a graphic
display of the envelope of the signal, then the number of samples
represented by a single peakfile sample must be high enough to avoid
having the display reveal frequency information for low frequency
signals. In light of this I suggest raising the number of samples
represented from 2048 to at least 4096, or maybe higher, since 2048
corresponds to an audible frequency with 44.1 khz audio.

So if a single peakfile sample contains both the largest + peak and the
largest - peak for N audio samples, then each displayed peakfile sample
produces a vertical line segment crossing (or touching) the horizontal
line that represents a signal level of 0. This produces a display of
the full envelope of the signal, and I like this kind of display. I
have noticed that some programs display half envelopes, showing only the
+ half. This may be because their peakfiles use absolute value, and
therefore store only one value per peakfile sample, or it may be a
feature that allows more tracks to be displayed simultaneously by
reducing the vertical space per track by 50%. I find full envelopes
much more natural to look at.

Reconsidering my previous post:

> the first and/or last sample in
> the waveform display will be computed from a peakfile sample that is not
> actually included in the region being displayed. This error only occurs
> in the first and last pixel of the waveform display. All others will be
> correct.
>
If you display regions as blocks, then the first and last pixels will be
used to represent the outline of the box, and the first and last
peakfile samples will be obscured, eliminating this issue entirely. If
your sequences hide the fact that they are made up of regions and simply
display a continuous waveform, then the pixel that represents a junction
will often be in error.

> 2047). Pixel 3 displays peakfile 2 sample 1... Regarding "out of
> phase", the shift will result in a waveform that is positioned
> incorrectly by a maximum of one pixel to the left or right,
>
Actually the display can only be shifted to the right, and still by a
maximum of one pixel.

Both types of errors mentioned above become less likely to occur as one
zooms out from maximum peakfile zoom. The only way I can see to
eliminate these errors is to constantly be computing new peakfiles, and
I don't think that such an effort is well spent. Maybe you can
implement the easiest form of peakfiles to free up more time for
developing something like loop recording :-)

Tom


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

This archive was generated by hypermail 2b28 : Tue Feb 27 2001 - 21:52:27 EET