[PD] big soundfiles [interpolation]

Roman Haefeli reduzent at gmail.com
Wed Nov 24 13:56:05 CET 2010


On Wed, 2010-11-24 at 11:28 +0100, Derek Holzer wrote:
> Hi Ronni,
> 
> like I said, it has to do with interpolation. I'm working on a chapter 
> for the Pd FLOSS Manual about soundfiles now, but here is the short 
> version... math gurus on the list please correct me if I am wrong since 
> this will likely end up in that chapter!
> 
> When you play back the samples in the array at the same rate that they 
> were recorded, then Pd doesn't have a lot of work to do since it just 
> reads back the values. However, when you play them back at a different 
> rate, for example by reading a 44.1K sample at 48K, then Pd often has to 
> interpolate (i.e. guess the "missing" values in between the samples) in 
> order to create the audio. That is what the "4" in [tabread4~] means: 4 
> point interpolation which uses the 4 nearest values to calculate any 
> value which might fall in between two samples.
> 
> Super-geek explanation by Miller here: 
> http://www-crca.ucsd.edu/~msp/techniques/v0.11/book-html/node31.html

> Here is the part where I know the answer but not the explanation, 
> however... but the larger the soundfile you load into an array, the 
> lower the quality of the interpolation. Can someone fill *me* in on this 
> so I can write intelligently about it in the FLOSS Manual?

I guess, you bring in two different problems here.

First problem:
You want to know the value of a signal at an exact point in time s(t),
but you only have values stored for the nearby samples s(n) and s(n+1).
Depending on the algorithm used, you can calculate a more or less
accurate value for s(t) by taking into account the nearby points and
assume a certain path for the curve going trough all points. This
problem applies also to small tables (not only big ones). If you're
playing a sample at the native rate of Pd, s(t) is always matching s(n)
and no interpolation error is introduced, as you already stated.

The second problem is:
You can't even express the exact point in time, when the t in s(t) is a
very huge number, because t is expressed as a 32-bit floating point
number. Please someone correct me, if wrong, but above a certain value
(2^24-1=16777215, I guess) you cannot even represent every integer with
the 32-bit floating point format used by Pd. So, even when playing a
sample with Pd's own samplerate, it only works nice up to a certain
table size. When you play samples 'behind' that magic number, every
second sample is played for the time of two samples. 
If you play a sample at a different speed than Pd's rate, the error
starts much earlier and increases over time. This is because the higher
the number is to index a certain sample, the less values between two
sub-sequent integers are available, so the difference between the value
you meant and the value that can be represented might increase.

Check also this thread:
http://lists.puredata.info/pipermail/pd-list/2007-09/053463.html

I hope, I didn't cause more confusion.

Roman




More information about the Pd-list mailing list