|
List Info
Thread: Oversampling
|
|
| Oversampling |

|
2006-02-21 00:05:41 |
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/~stef
an
/* BseNoise - BSE FM Operator -*-mode: c++;-*-
* Copyright (C) 2006 Stefan Westerfeld
*
* This library is free software; you can redistribute it
and/or
* modify it under the terms of the GNU Lesser General
Public
* License as published by the Free Software Foundation;
either
* version 2 of the License, or (at your option) any later
version.
*
* This library is distributed in the hope that it will be
useful,
* but WITHOUT ANY WARRANTY; without even the implied
warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See
the GNU
* Lesser General Public License for more details.
*
* You should have received a copy of the GNU Lesser General
* Public License along with this library; if not, write to
the
* Free Software Foundation, Inc., 59 Temple Place, Suite
330,
* Boston, MA 02111-1307, USA.
*/
#include <bse/bsecxxmodule.idl>
namespace Bse {
class Rectify : Effect {
Info authors = "Stefan Westerfeld";
Info license = _("GNU Lesser General Public
License");
Info category =
_("/Distortion/Rectify");
Info blurb = _("Outputs -1 for signals <
0 and +1 for signals > 0");
IStream audio_in = (_("Audio In"),
_("Audio Input"));
OStream audio_out = (_("Audio Out"),
_("Audio Output"));
group _("General") {
Int oversample = (_("Oversampling"),
_("The amount of internal oversampling. If BSE is
running with a rate of 48000 Hz, "
"an
oversampling of 2 means to perform internal computations
with 2*48000 Hz = 96000 Hz. "
"\n\n"
"Higher oversampling means better quality
(less aliasing), but also more CPU usage."),
1, 1, 16, 1, STANDARD) ;
Bool bypass = Bool (_("Bypass
Rectification"), _("Bypasses Rectification (but
still does oversampling"), FALSE, STANDARD);
};
};
};
; BseProject
(bse-version "0.6.6")
(container-child "BseWaveRepo::Wave-Repository"
(modification-time "2006-02-17 07:26:13")
(creation-time "2006-02-17 07:26:13"))
(container-child "BseCSynth::Unnamed"
(auto-activate #t)
(modification-time "2006-02-17 07:26:18")
(creation-time "2006-02-17 07:26:18")
(container-child
"BseStandardOsc::StandardOsc-1"
(pulse-mod-perc 0)
(pulse-width 50)
(fm-n-octaves 1)
(exponential-fm #f)
(fm-perc 0)
(base-freq 440)
(wave-form bse-standard-osc-saw-fall)
(pos-y 1)
(pos-x -3))
(container-child "BseAmplifier::Amplifier-1"
(master-volume 1)
(base-level 2.7000000000000011)
(ostrength 100)
(ctrl-exp #f)
(ctrl-mul #t)
(clevel2 100)
(clevel1 100)
(alevel2 100)
(alevel1 100)
(pos-y 1)
(pos-x 1)
(source-input "audio-in1" (link 1
"Rectify-1") "audio-out"))
(container-child "BseRectify::Rectify-1"
(oversample 1)
(pos-y 1)
(pos-x -1)
(source-input "audio-in" (link 1
"StandardOsc-1") "audio-out"))
(container-child "BsePcmOutput::PcmOutput-1"
(pos-y 1.03)
(pos-x 3.15)
(source-input "left-audio-in" (link 1
"Amplifier-1") "audio-out")
(source-input "right-audio-in" (link 1
"Amplifier-1") "audio-out")))
_______________________________________________
beast mailing list
beast gnome.org
http://m
ail.gnome.org/mailman/listinfo/beast
|
|
| Oversampling |

|
2006-05-01 22:11:02 |
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/~stef
an
>
---
ciaoTJ
_______________________________________________
beast mailing list
beast gnome.org
http://m
ail.gnome.org/mailman/listinfo/beast
|
|
| Oversampling |

|
2006-05-02 09:32:16 |
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/~stef
an
_______________________________________________
beast mailing list
beast gnome.org
http://m
ail.gnome.org/mailman/listinfo/beast
|
|
| Oversampling |

|
2006-05-02 09:22:51 |
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
beast gnome.org
http://m
ail.gnome.org/mailman/listinfo/beast
|
|
[1-4]
|
|