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 _______________________________________________ beast mailing list [email protected] http://mail.gnome.org/mailman/listinfo/beast
