Subject: RE: [linux-audio-dev] gain curves, interpolation, etc.
From: MOULET Xavier FTRD/DMR/ISS (xavier.moulet_AT_rd.francetelecom.fr)
Date: Wed Nov 29 2000 - 11:13:08 EET
this is really 1-order interpolation, and summing it up is NOT cool.
Besides, do you recompute and store differencial on every sample ? Thus you
will have NO gain.
I think that what you need is a way of representing a control signal (so, a
signal) with a few parameters. For example for manipulating it, or storing
it.
So, I would say that you must use a lower sampling frequency for example.
then you cut yur signal in slices and approximate each slice with a polynom.
('cause it is fast to reconstruct). Then you try to lower the stored
information by setting the order of the polynom to a certain value. And you
store each polynom definitions.
So you store : the constant value, and the first derivative over a segment
for liner interpolation. You can then store second order derivative for a
second order interpolation, a third order for ... etc. etc.
But you need to be exact (for the values, and any N-th order other
derivatives ..) on the splitting points. So you store f(t) and f'(t). Else,
you will accumulate errors and you can just feed a white noise in you app,
it would be simpler.
In fact to define your polynom, what do you need ? for a 1-order
interpolation, a linear singnal, you need 2 points : the values of the
signal on the borders.
For second approximation, you need the curbs (parabols, y=ax^2+bx+c) to
connect smoothly, so you need the first derivative evaluation on the
borders.
For the third order, you need it to be supersmooth and that the second order
derivatives of segments are equals .. and so on.
Er, the polynoms don't have to be the same order from one slice to another,
and the points don't have to be evenly spaced. We can be smarter than that,
given enough processing time (ON CREATING THE SIGNAL ONLY !! replaying is
the same time): if we have a signal that is zero for a long time, then
rapidly grows to 1 at the end, we may have two slices : one big slice
interpolated with a constant zero, then a two-order polynom fopr thge rapid
ramping at the end.(adaptative interpolation. wow. sounds too cool.)
BUT we are doing math on signals that we assume have certain properties. And
for example , a too much variable signal is not to be interpolated this way.
(think a smooth signal+noise ...) So we need that those signals are smooth
enough (in fact, we assume that they are continuous (no hops), and that
their N-th order derivatives are continuous, too). So we may need to filter
them down if we are trying to reconstruct an existing signal.
If you consider to EDIT the envelopes by hand, you really are _defining_ a
few points. So you can EDIT the polynoms (each) by hand. (hopefully NOT by
entering the coefficients ..). Consider that a third order interpolation is
named a spline in 2-D and are sufficiently accurate for the fact that I
haven't seen any drawing program tht goes beyond them.
or maybe I didn't understand the question ... anyway, thank you for reading
that far.
xavier
> -----Message d'origine-----
> De : Roger Larsson [mailto:roger.larsson_AT_norran.net]
> Envoyé : mercredi 29 novembre 2000 00:42
> À : Paul Barton-Davis; linux-audio-dev_AT_ginette.musique.umontreal.ca
> Objet : Re: [linux-audio-dev] gain curves, interpolation, etc.
>
>
> Reread your mail after sending response...
>
> On Tuesday 28 November 2000 23:34, Paul Barton-Davis wrote:
> > i'm looking for ideas on efficient ways of representing a gain curve
> > so that it can be applied to audio data and modified.
> >
> > originally, i thought i could use a break-point style structure, but
> > i'm not convinced this makes a lot of sense or is even
> computationally
> > feasible.
> >
> > basically, i want to attach the gain curve object to a data
> structure
> > that represents a contiguous section of audio data, and apply the
> > curve to the data as it is is read (i.e. multiply them). extreme
> > efficiency is called for here. interpolating each and every frame's
> > gain value will not work.
>
> OK, now I got it - the other axis, of cause...
> Precompute the derivate for each section (sample step).
> G = Gprev + derivate[section]
> Y = G * X
>
> >
> > another approach i considered was to store the actual gain values
> > one-or-one in a data buffer parallel to the one that holds the audio
> > data. but this doubles the data storage requirements for
> any sections
> > of audio with non-unity gain, and my sense that this is too great a
> > burden to pay.
> >
> > any ideas ?
>
> /RogerL
>
> --
> --
> Home page:
> http://www.norran.net/nra02596/
>
This archive was generated by hypermail 2b28 : Wed Nov 29 2000 - 12:03:31 EET