Stretching Time...

[Dan Higdon]

>  First I sample a sound (let's say the vocals..."time") at an octave higher
> through a pitch shifter, then I play it back an octave lower than the
> original sample. The result is a much slower "time" but the TONE (correct me
> if I'm wrong)  is the same as the original sample saying  "time".

It should be half the speed if you use a full octave.

> 10 11 00 (voltage wrt time) then you could stretch it to...
> 10 10 11 11 00 00  Is this what you mean? 

This is the basis of sample-rate conversion.  All you would do in this case is
drop the entire sound 1 octave and double the playback time.  Exactly what
you would expect from sampling at C3 and playing back at C2 (or whatever).

> Like musically changing the tempo.  What would happen if you sampled a jazz
> drummer where there's constant cymbals throughout the loop? You would have
> to use the "copy then paste per bit" method.

This will naturally work, but will be a LOT of work! :-)

> What would happen if I time stretched a sine wave? The o/p would be simply a
> lower frequency depending on the amount of time stretching desired (T=1/f).
> Time stretched?? I would have to say no because what happend to my original
> (here it is again) TONE? Mabey TONE=complex wavefrom analysis. Fill me in if
> anyone can help me understand this situation...
> BTW How do samplers playback over a range of keys? By changing the DAC's
> clock...Nah sounds to easy! 

I hope you were serious when you asked this.... :-)

Yes, it would stretch time AND lower the pitch.  This works on any digital audio data
the same way.  Samplers use this method often.  A sample is recorded at a particular
frequency and "root key" (probably no news here :-).  When the sampler wants
to play back the sound, it calculates the frequency difference between the root
key and the key to be played, and uses this delta as a scaling factor of sorts
on the initial sample rate.  The result of this is the sample rate at which the
sample would have to be played in order to "sound" the correct pitch, assuming
that the root key was correctly specified.  For example,
Sample 1 = 22050 @ A4 (440hz)
Key pressed = A5 (880hz)
rate (Sample 1) * freq(A5) / freq (A4) = 44100
So, in order to play Sample 1 at A5, it needs to be sample-rate converted.

Now, here's the fun part.  Samplers don't generally have a DAC for each note
of polyphony, they usually just have one for each audio out port.  Since you
can't just change the DAC rate (you might affect an already playing sound),
ALL samples must undergo a final rate conversion to the DAC rate.
Usually this is 44.1khz these days, but it can be anything.  So, the final
"algorithm" for playing a sample is:

Have a sample, complete with data, recorded rate, and root key
Player hits a key
Calculate the desired frequency of the note played
Calculate the "perfect" playback rate for the sample based on the key and root.
Convert the resultant sample to the DAC rate

Now, all of this rate conversion is pretty simple in theory.  The implementation
is almost identical to the algorithm used to draw straight lines on a computer
screen (brezenham's works nicely, for any of you graphics programmers out there).
So, you're not really converting the sample twice and duplicating data and such,
you just calculate some numbers and use it to "walk" the sample data.

In your doubling case above, you are using the simplest form of conversion.
Another option is to get the "extra" samples by interpolating between the two
"real" samples.  I have NO idea what "real" samplers use; I would guess that
such information is a jealously guarded secret, since it can affect the sound
of the instrument.  I also know that many (if not all) synth manufacturers do
all of these calculations in hardware or custom DSPs, since sample rate
conversion lends itself to DSP operations.

(NB: I probably got some of the math above wrong.  I don't write sample-rate
conversion software for a living; it was just an interest of mine back when I
naively thought I could write a decent modular synth in software.  I know
better now, and I'm building one in hardware!  That's why I'm on this list.)

Later,
Dan Higdon (hdan at charybdis.com)