Re: Oversampling

[Stefan Westerfeld <stefan space twc de>]

   Hi!

On Tue, May 02, 2006 at 12:11:02AM +0200, Tim Janik wrote:
> On Tue, 21 Feb 2006, Stefan Westerfeld wrote:
> >I've implmeneted some code for per-module oversampling. It is based on
> >FIR filters which are designed from a windowed sinc function.
> >Oversampling ratios from 2 to 16 are supported.
> >
> >To test it, I've implemented Bse::Rectify, a plugin which should -
> >without oversampling - generate extreme aliasing.
> >
> >I am attaching the code here, and an example .bse file. When running the
> >bse file, use a fft scope to monitor the rectify output, while playing
> >with the oversample ratio setting.
> 
> hm, thinking about the general test casing you developed here,
> could you turn this into an audio unit test based on bsefeature
> extract/compare?

I don't exactly know what you mean by that. If you mean that bsefextract
bsefcompare should somehow take the role of a human being looking at the
spectrum and saying "well, that looks like it doesn't have aliasing", I
don't think thats feasible. That relies too much on listening and
experience to be automated.

But of course what could be done is to oversample a plugin properly (say
16 times), and generate a average spectrum from that. After you listened
to it and convinced yourself it sounds "right", you could then compare
it to the average spectrum of a non-oversampled run automatically, and
see how this differs.

Hoever, this method may still fail, because the non-oversampled version
may not produce output in "inaudible" frequencies (>18kHz), or less
output in high frequencies in general, so they may still differ.

So I think in the end, when it comes to aliasing you always have to
check manually in some way or other.

Of your bsefextract/compare can be used to detect regressions after you
once have validated that some version is correct.

   Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan