[pd] 100000hz+

[padawan12]

On Fri, 27 Oct 2006 10:32:30 +0800
Chris McCormick <chris at mccormick.cx> wrote:

> On Fri, Oct 27, 2006 at 06:54:27AM +0100, padawan12 wrote:
> > 
> > This is as expected. What Chris says is no surprise. If you render the output
> > to a .wav file it is captured as a snapshot and the sample rate no longer 
> > has any effect (other than to change the overall playback rate). The problem
> > others were trying to explain is that the synthesis patch is not independent
> > of sample rate, so using the same Pd patch at different sample rates will
> > produce different results. If you're recording it the problem doesn't exist.
> 
> I am not sure if I understand this distinction correctly. If I use Pd at
> 44100Hz to generate a high frequency wave that aliases, and save it as
> a 44100Hz wave file, shouldn't that wave file be subjected to different
> aliasing if I play it back at say 22050Hz?

No. It will still be present in the recording at the same frequency relative
to everything else. The *whole* sound will shift down as you change the replay
sampling rate. As you say it's baked into the file now. If the alias component
was at 5000Hz when you recorded it at 44100Hz then shifting down the
sample rate will place it at 2500Hz, and of course everything else will also
be shifted down by a half.

> What about if I upsample it to 96kHz? Will the aliasing weirdness disappear
> if the tone I played was below 96kHz? Or is it somehow baked into the wav file.

Again, no. It will still be present. There is sometimes ambiguity in the usage
of the term "upsample". If you mean *change the sampling rate to 96000Hz* then the
recorded aliased signal will shift up in the ratio 96000/44100 (about 2).
It's the simple opposite of the previous operation, doubling instead of halving.
If it was at 5000Hz before it will be at about 10kHz after.

Sometimes "upsample" means to RE-sample the data at a higher sample rate,
which does nothing to improve the quality of the original recording, it's just 
to make the signal compatible with higher s/r DACs or another process running
at 96k further down the chain. Just imagine the stream of data at 44100
and then replace every occurence of a number by two numbers the same
and that's what's happening. It's not changing anything except doubling the
amount of data needed to represent the signal. This process (should) does not
affect the absolute or relative frequency components of the recording.

> I think I am out
> of my depth here.

No way Chris, this is 101 and I know you get it. It's sometimes
confusing because the words are overloaded to mean different things
at different stages. Take care over the terminology and remember that
there are really three universes in digital media. The first is the "compile"
time or pre universe where you prepare, write or capture your data/composition/
code. The second is the processing, the runtime computation. And the
third is the recording, getting final result - the actual media as a data
fixed in stone forever. Sampling theory applies at all points but
the effects are different. Only changes in parameters before recording can alter 
the relativity of components. After that point your alias has become part of the 
signal and is indistinguishable any another part of the mix.


The issue that Mathieu raises is that of portability prior to recording.
For example, if you were to give your Pd patch (which works nicely
for you playing back at 44000Hz) to someone who uses a 96k sound system
the whole thing will sound completely different. Let's say you had a component
at 30kHz. The bandwidth of the channel is 22000 so your component lies outside
the allowable range and will alias. You hear an alias at 14kHz (subtract the
difference from the top of the band).

Now you play that Pd file back on a 96kHz system, what happens? The bandwidth of the
channel is now 48kHz and the 30kHz component is no longer aliased, because it falls
inside the bandwidth.

That is very different from the earlier example of playing back a sound *file*
at a new rate.

These two are good intros,

http://www.indiana.edu/~emusic/etext/digital_audio/chapter5_nyquist.shtml

http://www.lavryengineering.com/documents/Sampling_Theory.pdf

There is a particularly poor Wiki entry that tries to look clever by
jumping straight into maths of complex functions of time - someone needs
to rewrite it so it makes sense to normal people.

http://en.wikipedia.org/wiki/Nyquist-Shannon_sampling_theorem

> 
> Chris.
> 
> -------------------
> chris at mccormick.cx
> http://mccormick.cx