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