Subject: Re: [linux-audio-dev] peakfiles and EDL's
From: Robert Schrem (Robert.Schrem_AT_WiredMinds.de)
Date: Tue Feb 27 2001 - 09:37:00 EET
On Mon, 26 Feb 2001, you wrote:
> In message <01022618013502.07471_AT_pc-robert>you write:
> >On Mon, 26 Feb 2001, you wrote:
> >> >From: Robert Schrem <Robert.Schrem_AT_WiredMinds.de>
> >> >
> >> >I think the values in a peak file should correspond to the level
> >> >meters of a compact casette recorders display. It should correspond
> >>
> >> It is often the peaks we are interested in to see in the waveform.
> >
> >If you would take only one peak value for 2048 samples you won't
> >see much of a waveform anyway. Only singnals BELOW a frequency of
> >44100/2048 ~ 20 Hz would show a recongizable waveform. And this
>
> I'm not totally sure, but I *think* that this is completely wrong.
Well I'm pretty sure: if you take a sample each 2048 samples
of a sample stream that was recorded at 44,1 kHz you would have
a resulting sampling frequency for the peak data of about 20 Hz.
I think this is pretty right, isn't it?
Well the sampling theorem now states, that you can only
represent frequencies up the the half sampling frequency
without introducing heavy alising effects, that don't
correspond with the input singnal at all. So the maximum
bandwidth of singnals that you could record and display
with an sampling rate of 20 Hz whould be in the range
of 0 - 10 Hz (with 44100 Hz sampling frequency you get
a bandwidth of 0 - 22050 Hz, always up to the half sampling
frequency). To avoid aalising effects you would have to
limit the bandwidth of the input singnal prior downsampling
with an low-pass filter. At least this is how all sampling
coverters work. As far as I have seen implementations they
are usually implemented as filters.
Analog peak meters work just ike this:
Put the singnal througth a rectifier (commutator?)
and the apply a low pass filter on the result.
Mechanical peak meters use for the low pass filtering
the mass of the moved parts.
Yust another try to explain my opinion:
Here a singnal where the sampling rate is six times
the recorded input singnal. You can still see the waveform:
.. ..
. . . . .
.. .. ..
Here the sampling frequency is only the double of the
sampled singnal frequency, you already can't tell anymore
if it's a sin wave or a square wave:
.. . . . . .
. . . . . .
The waveform is hardly visible. Now think what will happen,
if the input frequency is only little bit higher (only a
fraction of a percent): You would see a very low frequency
sine wave that don't correnspond with the input singnal at
all. There you go with the alising effect.
...........
..... ...... ...... ......
........... ...........
This alising effect applies also for complex singnals, because you
could convert it ito the frequency domain, apply this resampling
for each frequency and introduce the alising effect for each sine
wave, and convert it back. Mathematically this would give the
exactly same result.
> The waveform that you see when you display the amplitudes stored in a
> PCM data stream representing complex sounds does not display any
> particular frequency - it displays volume (albeit not necessarily in
> keeping with our physiologic perception of it). You almost note this
> yourself, but don't take the next step.
If you take only min/max peak data, the peak data does not neccessarily
correspond with the 'loudness' of the input singnal. One single
sample, maybe a glitch, would trigger a whole block of 2048 samples
at maximum volume. Maybe you want this, maybe not.
And if you would view 30 minutes on a screen you would have to
resample the peak data again. In the end you might get only
min/max values that equal to the minimum and maximum range
of the sample data values. You probably woun't see any meaningfull
data at all.
I don't understand why you take min AND max peak data - for usual
audio singnals sampled without an DC offset they would be almost
the same (except for the sign), wouldn't they?
> Its only when you display the amplitudes of simple wave forms that you
> are seeing the frequency of the waveform. In a complex waveform, the
> PCM values don't represent the amplitude of a sound at any particular
> frequency in any way. Remember, PCM is in the time-domain, you can
> only see the frequencies by doing an FFT and displaying the results.
I think the question is how to downsample the wave data in a
way that the result is still able to tell something of the
high resulution. I think the well known methods of downsampling
would apply best for this process. If someone is interested
I could look up some references about algorithms for this.
I'm sure paul, you know all this - sorry if I'm writing
another boring email without much news - I just got soaked
into my 'explain' mode... :)
> >only if you would apply antialias filtering. If you use peak
> >files you care more about the big picture: If you whould like
> >to see 1 Minute of music at once. If your screen resolution
>
> At 1 pixel = 1 sample, a typical modern monitor can display only about
> 0.03 seconds worth of 48kHz audio.
>
> At the other end of the scale, you might be viewing 20 minutes of
> audio on the screen.
>
> So there is clearly no single peaks-per-sample figure that satisfies
> all levels of viewing by itself. But I believe that about 2048 is a
> reasonable value: below that number and its almost possible to display
> the raw sample data for 16 tracks by reading it as you go. Go way
> above it, and you simply have to compute the peak-of-peaks, so to speak.
I also think 2048 is resonable. And maybe whatever downsampling algorithm
you coose, you won't get representative peak data values anyway, because
each of those peak value would have to speak for 2048 wildly spread
data values. A hard job I think :)
At least after mixing two signals you would have to recalculate
the peak data for the time perion where the signals interfere if
you care about phasing effects of the signals against each other.
And I think you have to care about that. Otherwise the peak
data would just show a pretty wild guess... The peak meters
would be degraded to some falshing disco lights...
I don't have a clue how this could be avoided. I pretty sure
it's just impossible.
robby.
This archive was generated by hypermail 2b28 : Tue Feb 27 2001 - 11:00:57 EET