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