[gst-devel] gst-bad equalizer element

[Benjamin Otte]

FWIW, I lack the mathematical knowledge about this, too. I tried to rad up
on it before coding, but it wasn't that easy.
The element works pretty much like the XMMS equalizer and there's a
sourceforge project at http://equ.sourceforge.net where I took the ideas
from. The relevant paper for all the math-interested people is at
http://www.harmony-central.com/Computer/Programming/apr2-d.pdf
(I hope that is noted in the sources somewhere, if it's not, please add
it.)

The big change I did was making the number of bands configurable since
it can be eating a lot of CPU if you use too many of them or you run on a
not-so-powerful machine.

On Mon, 2007-02-12 at 09:39 +0100, Stefan Kost wrote:
> This does not look like its doing a db
> (http://en.wikipedia.org/wiki/Decibel) mapping. If '0' is no action
> (factor 1.0) is a:
> * value of 1 then meaning factor+1=2 aka double volume (+3db) and
> * value of -1 then meaning a fifth of the volume (somewhere around -7db)
> Thats what I assume, but maybe company can clarify. If its like this
> it should be changed. The range is a bit too small imho. E.g. the EQ
> in winamp it goes from -12db to 12 db (in media player it goes from
> -14 to +14 whatever). I'd say -12 to +6 sounds good.
>
The difference between Winamp's and my equalizer is that if you crank up
one of the sliders, you'll get distortions while in my Winamp (2.8x) you
have to crank up quite a few sliders to get that effect.
But then, I have no clue anymore if that scale is really in dB - if it's
not, all your calculations are moot anyway. Look at the source I guess.

On Mon, 12 Feb 2007, James "Doc" Livingston wrote:
> One important questions, is whether the values should be in dB or a
> simple factor. Most applications would display a logarithmic scale, but
> the 'volume' element uses a factor, and it might be good to be
> consistent.
>
Well, for a start, the effects are quite different, as in the equalizer
case a 0 means "no change" while in the volume case it means "silence".
And unless there's an interface that policies how these elements should
behave, I'd argue against policing how properties should be exported.
You'll end up writing code that requests the "equalizer" element anyway.
Properties have always been used to export the features of the element in
the form the element preferred. That's why filesrc's location doesn't take
a URI even though gnomevfssrc's location does.

Final question: Did anyone solve the problem on how to set the values for
the different bands? using a pointer GParam that is supposed to take an
n-channel float array? That was such a bad property design that I decided
to skip it. Right now I'd probably invent a GstParamSpecArray for that
case, because parameters suck so much.


Cheers,
Benjamin