Oversampling

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Oversampling

Stefan Westerfeld
   Hi!

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.

Comments are welcome.

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

_______________________________________________
beast mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/beast

bserectify.idl (1K) Download Attachment
bserectify.cc (10K) Download Attachment
testrect.bse (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Oversampling

Tim Janik
On Tue, 21 Feb 2006, Stefan Westerfeld wrote:

>   Hi!
>
> 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?

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

---
ciaoTJ
_______________________________________________
beast mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: Oversampling

Stefan Westerfeld
   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
[hidden email]
http://mail.gnome.org/mailman/listinfo/beast
Reply | Threaded
Open this post in threaded view
|

Re: Oversampling

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