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 _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list