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"
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
