[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