Dear list,
this has been discussed already, but I would need a best-practice advice. I am trying to play back a 44.1kHz sound file with tabread4~ at very slow speed. I do get interpolation noise in the higher audible range of course. Now I tried to resamples the sound file to 96kHz, place it in an oversampled sub-patch and applied the 15kHz anti-alias filter from the J07.oversampling.pd example before its outlet~.
I am aware that interpolation noise and aliasing are different things, but I was under the impression that a higher samplerate would help tabread4~ to do better interpolation?
I also had a look at tabread4c~ from the nusmuk externals, but it produced very similar artifacts.
Is there any way how to reduce the interpolation noise? Could I use a low-pass filter whose cutoff frequency I could adapt wrt. playback speed?
Thank you for all ideas, this is really appreciated! P
Theoretically you should use a brickwall lowpass at one half the playback sample rate. So practically a multipole lowpass at a lower frequency than that.
Martin
On Sat, May 30, 2015 at 1:37 PM, Peter P. peterparker@fastmail.com wrote:
Dear list,
this has been discussed already, but I would need a best-practice advice. I am trying to play back a 44.1kHz sound file with tabread4~ at very slow speed. I do get interpolation noise in the higher audible range of course. Now I tried to resamples the sound file to 96kHz, place it in an oversampled sub-patch and applied the 15kHz anti-alias filter from the J07.oversampling.pd example before its outlet~.
I am aware that interpolation noise and aliasing are different things, but I was under the impression that a higher samplerate would help tabread4~ to do better interpolation?
I also had a look at tabread4c~ from the nusmuk externals, but it produced very similar artifacts.
Is there any way how to reduce the interpolation noise? Could I use a low-pass filter whose cutoff frequency I could adapt wrt. playback speed?
Thank you for all ideas, this is really appreciated! P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think the playback patch should be at whatever rate the dac is running at, and in this case filtering won't fix teh problem.
Most likely the upsampling from 44k1 to 96k wan't done perfectly. I use Julius Smith's "resample" program which I think is quite trustworthy.
cheers Miller
On Sat, May 30, 2015 at 01:51:58PM -0400, Martin Peach wrote:
Theoretically you should use a brickwall lowpass at one half the playback sample rate. So practically a multipole lowpass at a lower frequency than that.
Martin
On Sat, May 30, 2015 at 1:37 PM, Peter P. peterparker@fastmail.com wrote:
Dear list,
this has been discussed already, but I would need a best-practice advice. I am trying to play back a 44.1kHz sound file with tabread4~ at very slow speed. I do get interpolation noise in the higher audible range of course. Now I tried to resamples the sound file to 96kHz, place it in an oversampled sub-patch and applied the 15kHz anti-alias filter from the J07.oversampling.pd example before its outlet~.
I am aware that interpolation noise and aliasing are different things, but I was under the impression that a higher samplerate would help tabread4~ to do better interpolation?
I also had a look at tabread4c~ from the nusmuk externals, but it produced very similar artifacts.
Is there any way how to reduce the interpolation noise? Could I use a low-pass filter whose cutoff frequency I could adapt wrt. playback speed?
Thank you for all ideas, this is really appreciated! P
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
I think the playback patch should be at whatever rate the dac is running at, and in this case filtering won't fix teh problem.
The patch itself runs at dac speed, in it there is a oversampling subpatch. Do you suggest that this is oversampling not necessary?
Most likely the upsampling from 44k1 to 96k wan't done perfectly. I use Julius Smith's "resample" program which I think is quite trustworthy.
I did it with sox, and it should be fine as well.
Will check other parts of my patch for problems.
Thanks Miller and Martin, P
Hi Claude, list,
On 30/05/15 18:37, Peter P. wrote:
I am aware that interpolation noise and aliasing are different things,
How long is your table?
Could it be quantization of the index causing the issue?
Thank you for your suggestions. I only have gotten into that issue today again, so please excuse me for the late reply. Recap: I am hearing some pitched noise when playing back audio data from tables using [tabread4~] in a very slow way.
I have a table with 819474 samples in it, and am using a [line~] to play back from sample 222300 to 222400 in 400 milliseconds. I am getting a silent but too audible (-60dBFSR) pitched noise that at a sampling rate of 48k has partials at 750Hz, 1500Hz, 2250Hz, 3000Hz and so on further up, always adding 750Hz. When I upsample the soundfile that is loaded into the table to 96kHz and run Pd and the audio interface at 96kHz these noise components are at 1500Hz, 4500Hz, 6000Hz and so on respectively. What is strange is that I feel this noise is less apparent at earlier positions of the table, for example when I ramp from sample 5400 to 5500 in 400ms (regardless of the audio data volume, I am testing with a constant sine wave).
So I came across B15.tabread4~-onset.pd from the manual, which tells me of lower resolution in larger tables indexed by a 32bit audio signal. In that case I wonder what the best implementation of a changing onset message would be. Since it's a message, not an audio signal in itself I would have to make sure there are no incontinuities in the index audio signal when I am changing the onset message. Has anyone already addressed this in a reliable way so that the onset message can be derived from the index signal, and is sent to tabread4~ at precisely the correct point in time? Is there a specific reason that the onset is a message, not a signal by the way? All this sounds surprisingly complicated for a very common task, that is reading audio data in normal quality from tables larger than 32k. Perhaps there is an abstraction around that does exactly what I am looking for already? I went through the mailing list archive and looked at [tabread4c] already.
Thanks for any pointers, Peter
On 06/29/2015 06:22 AM, Peter P. wrote:
All this sounds surprisingly complicated for a very common task, that is reading audio data in normal quality from tables larger than 32k.
reading audio data in "normal" quality from tables larger than 32k is indeed a common task. however, upsampling a signal by a factor of 192 (you are trying to play back 100 samples in 400ms, right?) without any artefacts is not. you will need a high-order sinc interpolation to get that amount of upsampling correct - which would eat enough CPU cycles and needs enough surrounding points to make it unfit for a simple general-purpose interpolator as used by [tabread4].
hdsr IOhannes
On 06/29/2015 06:22 AM, Peter P. wrote:
All this sounds surprisingly complicated for a very common task, that is reading audio data in normal quality from tables larger than 32k.
reading audio data in "normal" quality from tables larger than 32k is indeed a common task. however, upsampling a signal by a factor of 192 (you are trying to play back 100 samples in 400ms, right?) without any artefacts is not. you will need a high-order sinc interpolation to get that amount of upsampling correct - which would eat enough CPU cycles and needs enough surrounding points to make it unfit for a simple general-purpose interpolator as used by [tabread4].
Good morning, and thanks for the general advice, which is really appreciated. I acknowledge the extreme degree of upsampling I am asking for, but would such a high-order sinc interpolation exist at all in Pd? Would that cure any indexing problems due to 32bit audio signals as well?
Have a most lovely day!
P