[PD] Re: PD-list digest, Vol 1 #1017 - 14 msgs [OT]

Trevor Agus pd at earcatching.com
Mon Mar 8 17:23:22 CET 2004

Yes, I've had problems with aliasing too, and would be grateful for any
ways to get around it.

Just to check my understanding of it: If I try to synthesize a 66150Hz
sine wave at 44100Hz sampling-rate (after doodline on a bit of paper)
the samples end up looking like a 22050Hz sine wave.

As Matt points out, the obvious way to get around this is not to try and
create such high frequencies.

But unfortunately, square-waves and saw-tooth waves (for example) have
ridiculously high harmonics, whether you want them or not. When you
represent them at a certain bit-rate, all the harmonics above half the
sampling rate gets aliased somewhere where you don't want them.

So how does this link up with Matt's suggestion that aliasing doesn't
happen in the purely digital domain? Well I guess in a sense the square
and saw-tooth waves in my head/formulae are analogue (i.e. infinite
bandwidth.) and realising them in the digital domain involves quantising
and sampling from that. So it is certainly aliasing.

The only way I can think to get around it is to build all complex tones
from sine-waves, which is a little calculation intensive, and doesn't
solve the quantisation problem.


PS I tried to pose that as a question, but now suspect I've just joined
an argument... Rather than delete it, I've marked it 'off-topic' as an
acknowledgement of that. Please don't flame...

Message: 5
From: "matthew jones" <m.jones at signal.qinetiq.com>
To: "Larry Troxler" <lt at westnet.com>, "PD-List" <pd-list at iem.kug.ac.at>,
        "Johannes Taelman" <j0 at advalvas.be>
Subject: Re: [PD] band-limited square wave
Date: Mon, 8 Mar 2004 13:40:55 -0000

interesting arguments larry.
But you're definitely wrong....! ;)
how amusing.

> For the next experiment, imagine that you are sampling a non-filtered
> square wave through an ADC. In other words, there is no anti-aliasing
> filter in place. What do you expect the digitized samples to look like
> this case? Would they not be exactly the same as a square wave
> entirely in the digital domain?

well, this is where aliasing will occur.  aliasing MEANING more than one
analogue signal will give rise to the observed digital signal.  aliasing
MEANINGLESS if you're already in the digital domain.  it refers to going
from a high bandwidth to a lower bandwidth.

> The reconstruction filters in an DAC are there to remove all analogue
> frequency content above nyquist, without affecting the frequency
> below nyquist.
> So, yes it would ripple, but not in the right way.

no, this would be in the right way! the ripples are due to filtering out
above Nyquist as you say, which is what we want...!!!  that IS naturally

> A bandwith-limited square digital osc sould give the same output as
> ADC'ing a squarly analog square wave. So antialiasing filters are
?? what ?? sorry, don't get u

> And it's not the only way to get aliasing: nonlinearities
> all kinds of modulation (fm, am,...), and much more.
>Digital sine oscillators and digital filters are bandwith-limited by

> First, set your sampling rate to 44100Hz. Now take a digital sine
> oscillator, say [osc~] in PD and set its frequency to 30000Hz.
> What do you expect to hear from the DAC? A sine wave at 30000Hz, even
> though that frequency is higher than fs/2? No, you will in fact here
> an aliased sine at 14100Hz - do you agree. But wait, we constructed
> signal entirely  in the digital domain, and yet we have aliasing!

well, in DSP terminology, this isn't aliasing.  of course in the digital
domain you can't synthesise ANYTHING higher than nyquist, it's
if your own code runs functions that attempt to do that, but end up
something else (ie return numbers that represent tones that have the
reflected frequency as the equivalent aliased signals) then that
function is
not producing aliased outputs, but correctly generating frequencies that
lower than YOU intended.  again, aliasing only applies to going from
bandwidth to low bandwidth, so if you're sample rate hasn't changed,
not getting aliasing.
this is getting pedantic, I can see what you're getting at but at the
end of
the day:-

constructing a bunch of numbers in the digital domain cannot produce
'aliased' outputs because the bandwidth has not changed.  reconstruction
will 'perfectly' bandlimit the output (although perfect sinc functions
impossible) everytime.



More information about the Pd-list mailing list