Charles Z Henry czhenry at gmail.com
Mon Jun 3 15:49:50 CEST 2019

```On Mon, Jun 3, 2019 at 5:14 AM cyrille henry <ch at chnry.net> wrote:
>
> Hello,
>
> - When reading a file at slower speed, tabread4~ create audible artefact. tabred4c~ use the same algorithm but with small difference in the interpolation coefficient (tabread4c~ use very classic coefficient for audio interpolation. Miller use a coefficient set that minimize artefact from a mathematical pov. But put them in very audible place).
> So, when using tabread4 object to read an audio file t low speed, replacing it with tabread4c~ is an easy solution to improve audio quality.
>
> - When you want to speed up a file playback, aliasing appear. Some algorithm solve this problem is a good way but I'm not aware of any pd implementation yet.

Any interpolator function i(t) can be applied as an anti-aliasing
interpolator g(t).  With playback speed a > 1,
g(t)=(1/a) * i(t/a)

You just have to make it longer and flatter.  It's surprisingly simple
and works--accomplishes filtering and interpolation in one step. The
number of operations scales with playback speed, a, but you only apply
the filtering at each sample it's needed.

There is probably no way to reduce the problem O(a) to something nice
like O(log(a) ), but I still wonder.  Without reducing the order of
operations or bounding the speed, there are potentially bad cases that
would hang the audio.

I had an implementation tabread4a~ and tested it on a 256-point table.
I used the interpolation function i(t) from tabread4~ in order to have
it be exactly the same output and cpu cost at a<=1.
Worked just great (though I left unfinished some goals there).  You
could play the table on a sweep from 1x up to 128x speed and the
partials just move right up to the Nyquist frequency and trail off.

The point of having tabread4~ is to have a cheap polynomial
interpolator with no tables, but it just costs more in this situation.
Should be changed to a table of interpolation function values if you
want to apply the g(t) formula.

> Since the interpolated value depend of the playback speed, I don't think it should be implemented in a tabread object but in a tabosc~ object (or a "multispeed_play" file)
> I made a tabosci~ (i for interpolated) that allow to oversample/filter the interpolation algorithm. I agree that this is the worst solution to remove aliasing, but I did never had time to implement a better algorithm.
> So, for now, you can use tabosci~ when you want to play a file at faster rate with reduced aliasing.
>
> And I +1 with you for asking a correct Whittaker–Shannon interpolation object.
>
> cheers
> Cyrille
>
> Le 02/06/2019 à 16:58, Peter P. a écrit :
> > Hi list,
> >
> > having asked my students to compose pieces in Pd using audio data in
> > tables and reading them via tabread4~ my ears are still slightly
> > bleeding from the interpolation artefacts audible in almost every second
> > composition. Surely, everyone likes to slow down playback and I think it
> > should be possible without too many audible artifacts in Pd.
> >
> > There is this legendary discussion on this list
> > https://lists.puredata.info/pipermail/pd-list/2008-06/062864.html
> > after Cyrille kindly posted about his tabread4c~ external. He also
> > pointed out more elaborate interpolation schemes such as in
> > https://lists.puredata.info/pipermail/pd-list/2008-06/063221.html
> > At that time a lot of list members agreed that it might be great to
> > switch interpolation algorithms in tabread4~ with an argument or
> > message to the object. As far as I can tell no additional interpolation
> > got implemented until today. Am I correct here?
> >
> > The issue got briefly revisited two years later in 2010
> > https://lists.puredata.info/pipermail/pd-list/2010-03/077232.html
> > and raised by me again in 2015
> > https://lists.puredata.info/pipermail/pd-list/2015-05/110312.html
> > https://lists.puredata.info/pipermail/pd-list/2015-06/110751.html
> > after which I switched to supercollider for the specific project I was
> > working on at that time as it performed better at slow playback.
> >
> > What could be a possible way to get slow playback from tables with less
> > artifacts? (I am tempted to add "in 2019") ;)
> >
> > Thank you for all ideas and comments!
> > P
> >
> >
> >
> > _______________________________________________
> > Pd-list at lists.iem.at mailing list
> > UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
> >
>
>
>
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

```