Subject: Re: [linux-audio-dev] peakfiles and EDL's
From: Juhana Sadeharju (kouhia_AT_nic.funet.fi)
Date: Sun Feb 25 2001 - 19:15:51 EET
>But wait: the peak values are precomputed, and may represent max/min
>values that are not in the sample data that now forms the audio data
I think the solution is as simple as rejecting the wrong minmax blocks,
and recomputing new blocks (two blocks in most cases) from the uncut
samples. For that we need a separate EDL for minmax files.
When drawing a pixel in display, I check the minmax values from the blocks
lying under the pixel. It doesn't matter how the blocks are aligned.
Yes, the waveform will change slightly if the wave is not moved by
multiple of pixel size. But that is not the problem of minmax files.
-*-
Here is some sketching:
In the original minmax file, the offset is 0. The last minmax value is
computed from 1 to 2048 samples depending on how 2048 divides the length
of audiowave.
When we have the complete audiowave in the editor, the EDL looks following:
wave:
file "original wave"
begin 0
end <length - 1>
minmax:
file "original minmax"
begin 0
end <length - 1>
After cut-off from the middle, the EDL looks following:
wave:
file "original wave"
begin 0
end 12345
file "original wave"
begin 54321
end <length - 1>
minmax:
file "original minmax"
begin 0
end <12345 - 58> // rejecting the wrong minmax value before the cut
file "new minmax"
begin 0
end <58 + 975 - 1>
file "original minmax"
begin <54321 + 975> // rejecting the wrong minmax value after the cut
end <length - 1>
The "new minmax" is computed from 58 samples before the cut and from
975 samples after the cut. I would use the sample units because they are
easier to handle.
How about that?
Juhana
This archive was generated by hypermail 2b28 : Sun Feb 25 2001 - 19:50:03 EET