Re: Oversampling

[Tim Janik <timj gtk org>]

On Tue, 2 May 2006, Stefan Westerfeld wrote:

>   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.

i was really thinking of something simpler:

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

yeah, that's what i was thinking of. i.e. a simple test that figures:
a) the signal is really resampled, i.e. != the original
b) the resampled signal matches the features extracted by a previous run.

so we'd figure if some change breaks the resampling logic in principle
(e.g. the move to SSE or similar).

>   Cu... Stefan

---
ciaoTJ