Forums

Filters - Maximizing Quality (Structures and Scaling)

Started by davidross January 18, 2006
Dear List,

I was wondering if anyone could offer some advice on what i can do to
maximize the quality of my filters. I have developed a Parametric
Equalizer with 10 bands (for audio). I would like the EQ to sound as good
as possible.

I am currently implementing the structure as a second order Direct Form.
Would it be worthwhile converting this structure over to a lattice ladder
structure - I have read here that the lattice ladder structure gives the
least quantization noise error. Would I notice an improvement?

I also have considered scaling my input signal to reduce the chance of
overflow error or roundoff error within the filter structure. But I'm not
sure what to choose as suitable scale factor? If I scale to much i may
throw away precious audio data, is this right? So how do we choose a
suitable scale factor? Just for fun I chosed an arbitrary scale factor of
50 i.e.  x = input / 50; and for the output y = output * 50; . But there
must be a way in which scale factors are chosen?

Thanks once again for any help.

Cheers,
David
not that it's your fault or your newsserver's or news client's fault, but
for some reason the ASCII LF characters "
" weren't getting properly
translated for me to read in my client program (OE).

in article IPmdncNyZ8dHr1PeRVn-vA@giganews.com, davidross at
david_ross@hotmail.co.uk wrote on 01/18/2006 07:21:

> I was wondering if anyone could offer some advice on what i can do to
maximize
> the quality of my filters. I have developed a Parametric
Equalizer with 10
> bands (for audio). I would like the EQ to sound as good
as possible. well, that's commendable. some of us don't like our EQs do sould as good as possible. we sorta like it if it sounds like dog excrement. :-)
> I am currently implementing the structure as a second order Direct Form.
there is more than one kind of Direct Form. also are your second order section in parallel or in cascade (series)?
>
Would
> it be worthwhile converting this structure over to a lattice ladder
structure
> - I have read here that the lattice ladder structure gives the
least
> quantization noise error. Would I notice an improvement? > > I also have considered scaling my input signal to reduce the chance > of
overflow error or roundoff error within the filter structure. But I'm
> not
sure what to choose as suitable scale factor? If I scale to much i
> may
throw away precious audio data, is this right? So how do we choose
> a
suitable scale factor? just, to confirm, is the processing done for your EQ being done in fixed-point arithmetic? it sounds like it but you never mention it. nowadays, i, for the most part, assume they're doing it in floating point until i read differently.
> Just for fun I chosed an arbitrary scale factor of
50
> i.e. x = input / 50; and for the output y = output * 50; . But there
must be
> a way in which scale factors are chosen?
it depends on the architecture. assuming fixed-point, given a filter architecture, you try to compute the gain vs. frequency for each node w.r.t. the input. then try to scaling the input so that the maximum gain at any frequency is unity. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
> >not that it's your fault or your newsserver's or news client's fault,
but
>for some reason the ASCII LF characters " >" weren't getting properly >translated for me to read in my client program (OE). >
mmh, thats strange, not sure why that happened?? Sorry!
>in article IPmdncNyZ8dHr1PeRVn-vA@giganews.com, davidross at >david_ross@hotmail.co.uk wrote on 01/18/2006 07:21: > >> I was wondering if anyone could offer some advice on what i can do to >maximize >> the quality of my filters. I have developed a Parametric >Equalizer with 10 >> bands (for audio). I would like the EQ to sound as good >as possible. > >well, that's commendable. some of us don't like our EQs do sould as good
as
>possible. we sorta like it if it sounds like dog excrement. :-) >
haha! Those filters must smell bad too then!
>> I am currently implementing the structure as a second order Direct
Form.
> >there is more than one kind of Direct Form. also are your second order >section in parallel or in cascade (series)? >
Two sections cascaded, Direct Form I
>just, to confirm, is the processing done for your EQ being done in >fixed-point arithmetic? it sounds like it but you never mention it. >nowadays, i, for the most part, assume they're doing it in floating
point
>until i read differently.
good old-fashioned floating point.
>> Just for fun I chosed an arbitrary scale factor of >50 >> i.e. x = input / 50; and for the output y = output * 50; . But there >must be >> a way in which scale factors are chosen? > >it depends on the architecture. assuming fixed-point, given a filter >architecture, you try to compute the gain vs. frequency for each node
w.r.t.
>the input. then try to scaling the input so that the maximum gain at
any
>frequency is unity.
cool, i liked that answer :-) Actually, I just found an article on music-dsp.org which has an article by some guy called rbg or something. It has some nice lattice-ladder structures in there. You kept that one quiet guvnor! Soo, what do you think about my idea, go for the lattice? Or do you think its overkill? Best, David
in article iKSdnZf4u7DOMVLenZ2dnUVZ_tidnZ2d@giganews.com, davidross at
david_ross@hotmail.co.uk wrote on 01/19/2006 10:12:

>> >> not that it's your fault or your newsserver's or news client's fault,
but
>> for some reason the ASCII LF characters " >> " weren't getting properly >> translated for me to read in my client program (OE). >> > > mmh, thats strange, not sure why that happened?? Sorry! >
the funny thing is that the LF i put in quotes above became a real LF (note the line breaks between quotes) and below your quoting of my text has inserted more of these "little rectangles" are are ASCII LF (0x0A). and the strangest thing is that, as far as i know, when the messages are out there in the USENET ether, the line breaks are *supposed* to be LF and then our client programs are supposed to fix it (convert to CR, 0x0D, for Mac and to CR/LF, 0x0D0A, for the PC). so i do not understand this at all. is it possible that you're spitting out something other than 0x0A for line breaks and then somehow they fail to break the lines and then get converted to 0x0A to display?
>> in article IPmdncNyZ8dHr1PeRVn-vA@giganews.com, davidross at >> david_ross@hotmail.co.uk wrote on 01/18/2006 07:21: >> >>> I was wondering if anyone could offer some advice on what i can do to >> maximize >>> the quality of my filters. I have developed a Parametric >> Equalizer with 10 >>> bands (for audio). I would like the EQ to sound as good >> as possible. >> >> well, that's commendable. some of us don't like our EQs do sould as good
as
>> possible. we sorta like it if it sounds like dog excrement. :-) >> > > haha! Those filters must smell bad too then! > >>> I am currently implementing the structure as a second order Direct
Form.
>> >> there is more than one kind of Direct Form. also are your second order >> section in parallel or in cascade (series)? >> > > Two sections cascaded, Direct Form I
not bad.
>> just, to confirm, is the processing done for your EQ being done in >> fixed-point arithmetic? it sounds like it but you never mention it. >> nowadays, i, for the most part, assume they're doing it in floating
point
>> until i read differently. > > good old-fashioned floating point.
then there simply is no scaling issue. it's not that there is any internal saturation. one might argue that if your internal states are single-precision floats, your quality might suffer noticeably in comparison to having double-precision internal states.
> >>> Just for fun I chosed an arbitrary scale factor of >> 50 >>> i.e. x = input / 50; and for the output y = output * 50; . But there >> must be >>> a way in which scale factors are chosen? >> >> it depends on the architecture. assuming fixed-point, given a filter >> architecture, you try to compute the gain vs. frequency for each node
w.r.t.
>> the input. then try to scaling the input so that the maximum gain at
any
>> frequency is unity. > > cool, i liked that answer :-)
yeah, but it's not an issue for you since you're good old-fashioned floating point.
> Actually, I just found an article on music-dsp.org which has an article > by
some guy called rbg or something. It has some nice
> lattice-ladder
structures in there. You kept that one quiet guvnor! if i thought it was "sequitur", i'd a brought it up. are you talking about the "equivalence" paper? it's more than a decade old.
> Soo, what do you think about my idea, go for the lattice? Or do you think
its
> overkill?
i think it's not necessary for the purpose of controlling the magnitude of internal states. if double precision is not used for the internal states, one thing that some people do is dithering and noise shaping at the point of quantization, but it's sorta hard and unnatural to do that for floating point because the magnitude of quantization error varies unpredictably. pretty hard to dither that. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
>in article iKSdnZf4u7DOMVLenZ2dnUVZ_tidnZ2d@giganews.com, davidross at >david_ross@hotmail.co.uk wrote on 01/19/2006 10:12: > >>> >>> not that it's your fault or your newsserver's or news client's fault, >but >>> for some reason the ASCII LF characters " >>> " weren't getting properly >>> translated for me to read in my client program (OE). >>> >> >> mmh, thats strange, not sure why that happened?? Sorry! >> > >the funny thing is that the LF i put in quotes above became a real LF
(note
>the line breaks between quotes) and below your quoting of my text has >inserted more of these "little rectangles" are are ASCII LF (0x0A). and
the
>strangest thing is that, as far as i know, when the messages are out
there
>in the USENET ether, the line breaks are *supposed* to be LF and then
our
>client programs are supposed to fix it (convert to CR, 0x0D, for Mac and
to
>CR/LF, 0x0D0A, for the PC). so i do not understand this at all. is it >possible that you're spitting out something other than 0x0A for line
breaks
>and then somehow they fail to break the lines and then get converted to
0x0A
>to display? >
rbj - to be honest, i'm not sure why this happens. I post from either my computer at work or from home. I use Internet Explorer on both machines. I dont know in any way why little squares would be displayed. Judging b what you say it seems that this behaviour is rare, so I'm not sure why i seem to generate it? I just want to post like everyone else.
>>> in article IPmdncNyZ8dHr1PeRVn-vA@giganews.com, davidross at >>> david_ross@hotmail.co.uk wrote on 01/18/2006 07:21: >>> >>>> I was wondering if anyone could offer some advice on what i can do
to
>>> maximize >>>> the quality of my filters. I have developed a Parametric >>> Equalizer with 10 >>>> bands (for audio). I would like the EQ to sound as good >>> as possible. >>> >>> well, that's commendable. some of us don't like our EQs do sould as
good
>as >>> possible. we sorta like it if it sounds like dog excrement. :-) >>> >> >> haha! Those filters must smell bad too then! >> >>>> I am currently implementing the structure as a second order Direct >Form. >>> >>> there is more than one kind of Direct Form. also are your second
order
>>> section in parallel or in cascade (series)? >>> >> >> Two sections cascaded, Direct Form I > >not bad.
ta. If you know of anything better, i.e. less internal buffers, then feel free to suggest. Of course i'll find all this out in due course, but if you want to hasten my passage then feel free...
>>> just, to confirm, is the processing done for your EQ being done in >>> fixed-point arithmetic? it sounds like it but you never mention it. >>> nowadays, i, for the most part, assume they're doing it in floating >point >>> until i read differently. >> >> good old-fashioned floating point. > >then there simply is no scaling issue. it's not that there is any
internal
>saturation. one might argue that if your internal states are >single-precision floats, your quality might suffer noticeably in
comparison
>to having double-precision internal states.
cool, so i dont really need to scale. One less thing to think about...
>> >>>> Just for fun I chosed an arbitrary scale factor of >>> 50 >>>> i.e. x = input / 50; and for the output y = output * 50; . But
there
>>> must be >>>> a way in which scale factors are chosen? >>> >>> it depends on the architecture. assuming fixed-point, given a filter >>> architecture, you try to compute the gain vs. frequency for each node >w.r.t. >>> the input. then try to scaling the input so that the maximum gain at >any >>> frequency is unity. >> >> cool, i liked that answer :-) > >yeah, but it's not an issue for you since you're good old-fashioned
floating
>point. >
cool
>> Actually, I just found an article on music-dsp.org which has an
article
>> by >some guy called rbg or something. It has some nice >> lattice-ladder >structures in there. You kept that one quiet guvnor! > >if i thought it was "sequitur", i'd a brought it up. are you talking
about
>the "equivalence" paper? it's more than a decade old. > >> Soo, what do you think about my idea, go for the lattice? Or do you
think
>its >> overkill? > >i think it's not necessary for the purpose of controlling the magnitude
of
>internal states. > >if double precision is not used for the internal states, one thing that
some
>people do is dithering and noise shaping at the point of quantization,
but
>it's sorta hard and unnatural to do that for floating point because the >magnitude of quantization error varies unpredictably. pretty hard to
dither
>that. >
well, i'll probably just leave as is for the time being. its sounding ok and theres lots of pretty girls out there to soak up my attention at the minute.. Best Regards, David E Ross
davidross wrote:
> rbj wrote:
>>> Two sections cascaded, Direct Form I >> >>not bad. > > ta. If you know of anything better, i.e. less internal buffers, > then feel free to suggest.
DF2 transposed halves the number of states. Martin -- I am an Indian and looked upon by the whites as a foolish man; but it must be because I follow the advice of the white man. --Shunka Witko
>davidross wrote: >> rbj wrote: > >>>> Two sections cascaded, Direct Form I >>> >>>not bad. >> >> ta. If you know of anything better, i.e. less internal buffers, >> then feel free to suggest. > >DF2 transposed halves the number of states. > > >Martin
Thanks Martin, I'll look into that. Hey, your from the VST Developers list. Do you make plugins? Cheers, David PS EQ18 is now finished for the time being. I have to leave it to the side for the minute although I would of really liked a 'reset' button in there I couldnt get it work, should be simple'ish though which is strange. Your in the credits doco for providing some testing, and RBJ is in there too for helping with my post here. You can check out EQ18 here, I would still like to do more with it such as make the gui a bit more professional and add a reset button, but theres only so much time you can spare for the old hobbies... http://www.davideross.net/EQ18.htm
davidross wrote:

> Hey, your from the VST Developers list. Do you make plugins?
Yes, but none are public so far. Some are custom for a friend's use, in other cases I'm just too perfectionist for my own good.
> Your in the credits doco for providing some testing, and RBJ is > in there too for helping with my post here.
Ooh, how glamorous! ;) Martin -- Quidquid latine scriptum sit, altum viditur.
we'll see how long it takes Google to post this.  last time i used
Google to post, IT TOOK TWO DAYS to get out there.  (totally
inexcusable).  just for everyone's info, it's midnight EST (GMT-5hours)
Sunday night/Monday morn.

Martin Eisenberg wrote:
> davidross wrote: > > rbj wrote: > > >>> Two sections cascaded, Direct Form I > >> > >>not bad. > > > > ta. If you know of anything better, i.e. less internal buffers, > > then feel free to suggest. > > DF2 transposed halves the number of states.
not for multiple cascaded biquad sections. the two output states of "section n-1" are the same as the input states of "section n". so, for cascaded biquad DF1, the number of states are 2N+2 and for DF2, it's 2N (if "N" is the number of biquad sections). although the DF2 won't suffer saturation if floating point is used, i have noted a numerical problem for DF2 if single precision is used (having to do with loss of precision when scaled states are subtracted). we've discussed this before on comp,dsp you might unwrap this URL and read about it: http://groups.google.com/group/comp.dsp/browse_thread/thread/39672b521039867c/72b222fd8b2bad41?hl=en#72b222fd8b2bad41 DF1 with a double-wide accumulator (so there is precisely one quantization operation per biquad, DF2 has two quantization points in each biquad unless your states are double precision), is still the best way to go for either fixed or floating point, unless there are other strange requirements (like decoupling the filter frequency from Q in the filter coefficients). r b-j
robert bristow-johnson wrote:
> Martin Eisenberg wrote:
>> DF2 transposed halves the number of states. > > not for multiple cascaded biquad sections. the two output > states of "section n-1" are the same as the input states of > "section n".
OK -- numerical properties aside you presume one way of constructing programs there, and so did I when I catered to David's immediate question but no more. Fusing the states of adjacent DF1 sections is of course easy if you write the thing from scratch every time. If you just want to chain modules from a library and still do it, either you end up connecting filter objects to state buffers explicitly which sort of defies the premise; or you abstract the fusing into another library entity which is unconventional enough to add a fair bit of complexity however its code actually looks, and also possibly incurs runtime overhead.
> although the DF2 won't suffer saturation if floating point is > used, i have noted a numerical problem for DF2 if single > precision is used (having to do with loss of precision when > scaled states are subtracted). we've discussed this before on > comp,dsp you might unwrap this URL and read about it:
Are you referring to DF2 or DF2-transposed here? You didn't respond to Nigel's pointing out in that thread that the latter is more benign (even though it has three summing nodes, alas). Also, when the code mostly keeps states in the extended-precision registers of the x86 (David's target, as I learned on music-dsp) the difference between DF1 and DF2-t might be inconsequential after all, what do you say? Martin -- There are two kinds of people -- those who do the work and those who take the credit. Try to be in the first group; there is less competition there. --Indira Gandhi