Re: Jamin EQ Preecho, Linear Phase EQ considered harmful.

Gregory Maxwell <[email protected]>
Newsgroups gmane.comp.audio.jamin.devel
Message-ID <[email protected]>
On 12/27/05, Steve Harris <[email protected]> wrote:
> There will be some preecho, but from what I remember from when I measured
> it, it shouldnt't be audible. I could well be wrong though.

In my testing it would seem to be audible in corner cases, but perhaps
I'm not a typical listener.. I've sensitized myself to pre-echo
through years of work with transform codecs. :) I didn't do much
listening testing for it.. once I heard it I went straight to the
numeric tests. :)

> I would be possible to build that EQ out of IIR filters, but the phase
> shift would be large, so it would need some correction. Its debatable
> which is the lesser of the evils. Personally I dont find the pre-echo that
> objectionable.

I'm not sure that we would need to worry much about phase shift
there... it's a topic worthy of discussion:

My position is that in a mastering EQ phase shift is not a problem
because the signal will never be added back to a differently EQed copy
of itself so no risk of phase shift induced comb filtering, and the
ear is not really sensitive to fairly substantial phase shift. In any
case where a minimum phase  produces enough shift (due to its
steepness) to create an audible distortion, a linear phase version
would have pronounced and objectionable pre-echo.

> The IIR xover option is off by default because the behaviour is
> terrible compared to the FFT one, largly because I dont have enough
> experience in filter design.

I can take a look at the IIR xover, but really I think that in the
case of the crossover linear phase is correct: In the case where none
of the subbands are being amplified or attenuated the reconstruction
should be lossless (excluding rounding error and window induced
modulation which is hopefully limited by proper overlap)... and in the
case were there is a gain change, preecho should be well below the
threshold of noticeability because the filter should not be very steep
and thus should have a compact time-domain representation.

> If you want to try some DRC based code then thats great, but I dont have
> the time to do it myself.

If there would be interest in integrating such a solution should it
work well I can give it a crack...

My primary concern is that it would negatively impact the
interactivity of Jamin: every EQ change would require a somewhat
computationally expensive filter-filtering operation before the filter
could be activated. I usually use DRC on filters *much* longer than
would be used in Jamin, so perhaps it's not as expensive as I'm
suspecting.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.