[PD] big soundfiles [interpolation]

[Derek Holzer]

Yes, it was the second point that I couldn't articulate. Thanks!
D.

On 11/24/10 1:56 PM, Roman Haefeli wrote:
> 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
>
>

-- 
::: derek holzer ::: http://macumbista.net :::
---Oblique Strategy # 54:
"Do something sudden, destructive and unpredictable"