Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Evan Balster]

I'm working on a game application that routinely runs around 60-80 of these
pitch shifters in a real-time callback on consumer hardware.  Performance
is fine.

To clarify, the state of the resampler is:

   - Four stored samples for continuity between runs
   - The fractional offset from the last sample of the last input chunk
   - Resampling rate settings

The resampling procedure and state management work as follows

   1. Ascertain the required quantity of input (through simulation, in my
   case)
   2. Allocate* an input buffer of this length, plus four.
   3. Copy stored samples to the beginning of the input buffer.
   4. Render source audio into the remaining samples of the input buffer
   5. Resample from the working buffer into the output buffer (with rate
   interpolation)
   6. Copy the final samples of the input buffer to storage for the next
   run.

Note that this scheme is meant for rendering to an output of fixed sampling
rate from an on-demand input.  If both the input and output are streaming
data, I would use a variable delay line rather than a rate-based resampler
-- which sounds like what you're talking about.

* Allocations come from a stack-buffer which is a staple of my audio
processing framework; all allocations from this buffer occur in constant
time and are relinquished when processing is complete.

Tying back into the central topic of the thread, the state management
really isn't too bad.  The only complicated bit is -- as always -- the
lock-free settings propagation, and that's easily solved with standard data
structures.

– Evan Balster
creator of imitone 

On Mon, Feb 22, 2016 at 8:52 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

>
>
>  Original Message 
> Subject: Re: [music-dsp] Tip for an audio resampler library doing cubic
> interpolation
> From: "Evan Balster" 
> Date: Mon, February 22, 2016 6:45 pm
> To: music-dsp@music.columbia.edu
> --
>
> >
> > Robert --
> >
> > Look again; no circular buffer is used.
>
> that might explain why i couldn't see any code that would indicate such.
>
> > The sampling buffer consists of
> > the last four samples from the previous buffer, followed by the input
> > chunk. The "length" value indicates the length of the input chunk.
>
>
>
> so you're copying those four samples from the end of the previous chunk to
> the beginning of the current chunk?  and you're doing this every chunk time?
>
> well, then i dunno how i would use it for a real-time pitch shifter or a
> real-time asynchronous sample-rate-converter or something where i am
> striding though the sample record, for a sustained period where the stride
> is not equal to 1 sample (output) per sample (input).  usually what you
> have is a circular buffer and a mean delay of around half the length of the
> circular buffer and then *some* operation to deal with if your output
> pointer (or read pointer, which has both integer and fractional components)
> gets too close to the either edge of the buffer (or too close to the input
> or write pointer).
>
> there are two ways i have dealt with this.  one has a better *average*
> execution time and the other a better *worst case* execution time.  the
> former, when the write pointer wraps around to the beginning of the buffer,
> i copy a segment of sufficient length from the beginning of the buffer and
> append it to the end.  then my read pointer can always be considered linear
> (it wraps, too, but i don't have to worry about it regarding 4+chunksize or
> more valid contiguous samples).  the latter, i just make my circular buffer
> with size equal to a power of two and mask the bits of the index (modulo
> 2^p) of the read pointer every time i use it.
>
>
>
> --
>
>
>
>
> r b-j  r...@audioimagination.com
>
>
>
>
> "Imagination is more important than knowledge."
>
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[robert bristow-johnson]

 Original Message 

Subject: Re: [music-dsp] Tip for an audio resampler library doing cubic 
interpolation

From: "Evan Balster" 

Date: Mon, February 22, 2016 6:45 pm

To: music-dsp@music.columbia.edu

--



>

> Robert --

>

> Look again; no circular buffer is used.
that might explain why i couldn't see any code that would indicate such.
> The sampling buffer consists of

> the last four samples from the previous buffer, followed by the input

> chunk. The "length" value indicates the length of the input chunk.
�
so you're copying those four samples from the end of the previous chunk to the 
beginning of the current chunk? �and you're doing this every chunk time?
well, then i dunno how i would use
it for a real-time pitch shifter or a real-time asynchronous 
sample-rate-converter or something where i am striding though the sample 
record, for a sustained period where the stride is not equal to 1 sample 
(output) per sample (input). �usually what you have is a circular buffer and a 
mean
delay of around half the length of the circular buffer and then *some* 
operation to deal with if your output pointer (or read pointer, which has both 
integer and fractional components) gets too close to the either edge of the 
buffer (or too close to the input or write pointer).
there are two
ways i have dealt with this. �one has a better *average* execution time and the 
other a better *worst case* execution time. �the former, when the write pointer 
wraps around to the beginning of the buffer, i copy a segment of sufficient 
length from the beginning of the buffer and append it
to the end. �then my read pointer can always be considered linear (it wraps, 
too, but i don't have to worry about it regarding 4+chunksize or more valid 
contiguous samples). �the latter, i just make my circular buffer with size 
equal to a power of two and mask the bits of the index (modulo
2^p) of the read pointer every time i use it.
�
--
�

r b-j � � � � � � � � �r...@audioimagination.com
�


"Imagination is more important than knowledge."


�
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Evan Balster]

Kjetil --

I suspect you'll have a very hard time finding a library with the functions
you need that doesn't include quite a lot else.  If you'd like to reference
a more comprehensive implementation (with anti-aliasing and rate
interpolation) I can provide my current code -- but it's part of a larger
framework which does a lot of things you wouldn't need.


Robert --

Look again; no circular buffer is used.  The sampling buffer consists of
the last four samples from the previous buffer, followed by the input
chunk.  The "length" value indicates the length of the input chunk.

This is an outdated version of my resampler and it has various minutiae
worthy of criticism -- with the most glaring being a lack of antialiasing.
I supplied it here because it gets the job done and my current
implementation relies on a rather large body of filter design code for
Chebychev-II antialiasing.

– Evan Balster
creator of imitone 

On Mon, Feb 22, 2016 at 5:36 PM, Ross Bencina 
wrote:

> On 23/02/2016 1:24 AM, Kjetil Matheussen wrote:
>
>> On Mon, Feb 22, 2016 at 2:59 PM, Ross Bencina
>> > wrote:
>>
>> Hi Kjetil,
>>
>> On 22/02/2016 11:52 PM, Kjetil Matheussen wrote:
>>
>> I wonder if anyone has a tip for a C or C++ of an implementation
>> of a
>> Cubic interpolating resampler. I'm not asking about the algorithm
>> itself, that is all covered (currently I'm using a Catmull-Rom
>> spline
>> algorithm, but that is not so important here). What I'm asking
>> about
>> is a framework for using the algorithm.
>>
>>
>> It's hard to suggest a framwork out of thin air. One thing: it
>> probably doesn't matter what kind of interpolation you use. The
>> interface is concerned with samples in, samples out, current
>> interpolation phase, conversion ratio. Here's a few questions that
>> come to mind:
>>
>>
>> Thanks Ross. I'm sorry I didn't provide more information. I did actually
>> answer all your questions,
>> through code, but I guess it was quite arrogant of me not to explain the
>> somewhat hairy interface.
>>
>
> Hi Kjetil,
>
> Thanks for the clarification. Sorry, I misunderstood your question. When
> you ask for "a framework for using the algorithm." I thought you meant the
> best way to structure the interface to the code. But it sounds like you
> have already decided on the interface.
>
> The interpolation is a function of the lookup phase and a few input
> samples. What else do you need to resolve?
>
> If I was going to implement that interface, I'd write some tests and the
> simplest possible implementation (probably, pulling single samples from the
> source as needed, maybe just using linear or 0-order interpolation to start
> with). Then I'd profile, refactor and optimize as needed.
>
> Ross.
>
> P.S. Using a C function pointer in C++ is not very flexible. You could
> either define an abstract interface for the source, or use std::function.
>
> P.P.S. How do you communicate the amount of source data needed? the
> callback has no "count" parameter.
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Ross Bencina]

On 23/02/2016 1:24 AM, Kjetil Matheussen wrote:

On Mon, Feb 22, 2016 at 2:59 PM, Ross Bencina
> wrote:

Hi Kjetil,

On 22/02/2016 11:52 PM, Kjetil Matheussen wrote:

I wonder if anyone has a tip for a C or C++ of an implementation
of a
Cubic interpolating resampler. I'm not asking about the algorithm
itself, that is all covered (currently I'm using a Catmull-Rom
spline
algorithm, but that is not so important here). What I'm asking about
is a framework for using the algorithm.


It's hard to suggest a framwork out of thin air. One thing: it
probably doesn't matter what kind of interpolation you use. The
interface is concerned with samples in, samples out, current
interpolation phase, conversion ratio. Here's a few questions that
come to mind:


Thanks Ross. I'm sorry I didn't provide more information. I did actually
answer all your questions,
through code, but I guess it was quite arrogant of me not to explain the
somewhat hairy interface.


Hi Kjetil,

Thanks for the clarification. Sorry, I misunderstood your question. When 
you ask for "a framework for using the algorithm." I thought you meant 
the best way to structure the interface to the code. But it sounds like 
you have already decided on the interface.


The interpolation is a function of the lookup phase and a few input 
samples. What else do you need to resolve?


If I was going to implement that interface, I'd write some tests and the 
simplest possible implementation (probably, pulling single samples from 
the source as needed, maybe just using linear or 0-order interpolation 
to start with). Then I'd profile, refactor and optimize as needed.


Ross.

P.S. Using a C function pointer in C++ is not very flexible. You could 
either define an abstract interface for the source, or use std::function.


P.P.S. How do you communicate the amount of source data needed? the 
callback has no "count" parameter.

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Kjetil Matheussen]

On Mon, Feb 22, 2016 at 8:40 PM, robert bristow-johnson <
r...@audioimagination.com> wrote:

> >
> > Pulling in a library for just this seems like massive overkill. The
> > venerable pink elephant paper
> >  describes
> > several cubic resampling algorithms (I prefer four-point hermite)
>
> i think, for the present purposes (with uniform sampling), that the
> Catmull-Rom spline is the same as hermite.
>
> That's right. My Catmull-Rom spline implementation is exactly the same
as the four-point hermite implementation in that paper.

if Kjetil wants better quality than hermite interpolation and has a few K
> word of memory for a lookup table of polyphase coefficients, i might
> recommend doing that.  it might need MATLAB (and the firpm() or firls()
> function) to generate the table of coefficients.  but the pink elephant
> paper (or Duane's and my paper) shows sorta how the polynomial
> interpolation compares to straight polyphase (if i recall correctly, gee, i
> better check that, it's been 20 years).
>
>
>
Sound quality is not the issue. My code is sounding good, but it's buggy,
and
I rather want to use tested and optimized code instead of writing my own.
I don't want to spend time implementing these things if there is already
something available. Resampling is so very very common, that there really
should be something well written and well tested available, one should
think.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Kjetil Matheussen]

On Mon, Feb 22, 2016 at 7:02 PM, Evan Balster  wrote:

> Hey, Kjetil --
>
> Pulling in a library for just this seems like massive overkill.  The
> venerable pink elephant paper
>  describes
> several cubic resampling algorithms (I prefer four-point hermite)
>

That's what I'm using already. (and I also know about that paper, the
OPTIMAL 4x
algorithm is also in my code as an option)



> and it's fairly straightforward to implement the necessary state
> management.
>
>
Hmm, I disagree. It's the state management I rather not want to do it
myself,
although I have to implement it myself if there really isn't anything
usable available.

Mind that I have already a working implementation for this, but I don't
trust
the code I have already written. Especially when it comes to extreme ratios,
things are getting complicated. I would think that there are some
enterprise-like code, such as JUCE, that have already implement this
but I haven't found anything.




> Attached is the source file for an older implementation of my rate-change
> class.  (It's a version without anti-aliasing as that adds a number of
> dependencies.)  It's ~200 lines of C++ and while it won't compile without
> various modifications it should be relatively straightforward as reference
> code or a basis for your own adaptation.
>
>
This code doesn't look better than what I already have.

Here's the type of code quality I'm looking for:

Linear interpolation + lowpass filter:
https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_basics/sources/juce_ResamplingAudioSource.cpp

Lagrange interpolator:
https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_basics/effects/juce_LagrangeInterpolator.cpp

Actually, the lagrange JUCE code above shouldn't be so much work converting
into a general resampler library using 4-point hermite instead of lagrange.
This seems to be the best alternative so far.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[robert bristow-johnson]

 Original Message 

Subject: Re: [music-dsp] Tip for an audio resampler library doing cubic 
interpolation

From: "Evan Balster" 

Date: Mon, February 22, 2016 1:02 pm

To: k.s.matheus...@notam02.no

music-dsp@music.columbia.edu

--



> Hey, Kjetil --

>

> Pulling in a library for just this seems like massive overkill. The

> venerable pink elephant paper

>  describes

> several cubic resampling algorithms (I prefer four-point hermite)
i think, for the present purposes (with uniform sampling), that the Catmull-Rom 
spline is the same as hermite.
�
> and it's�fairly straightforward to implement the necessary state management.

>

> Attached is the source file for an older implementation of my rate-change

> class. (It's a version without anti-aliasing as that adds a number of

> dependencies.) It's ~200 lines of C++ and while it won't compile without

> various modifications it should be relatively straightforward as reference

> code or a basis for your own adaptation.
so Evan, i couldn't resist browsing the code and this appears to be the kernel 
of it:
�

float c1, c2, c3;
rate = a.rate;
off = offset;
Sint32 *in = sub.start(i), *out = chunk.start(i), *end = 
chunk.end(i);

while (out < end)
{
//4-point, 3rd order hermite resampling
off += rate;
steps = off; off -= steps;
in += steps;

c1 = .5f*(in[2]-in[0]);
c2 = in[0] - 2.5f*in[1] + 2.0f*in[2] - 
.5f*in[3];
c3 = .5f*(in[3]-in[0]) + 1.5f*(in[1]-in[2]);
*out = in[1] + ((c3*off+c2)*off+c1)*off;

++out;
}


somewhere it needs to be made explicity that "steps" is an integer and "off" is 
floating-point. �and that when you say "steps=off" that you are always rounding 
down so that "off-=steps" always results in a float that is between 0.0 and 
0.999
.
the coefficients looks quite familiar to me. �my concern is that of wrap-around 
the circular buffer. �what if "in" points to one of the last 3 samples in your 
circular buffer? �are you extending past the end (by copying the first 3 
samples at the beginning and
appending to the end)? �it just ain't apparent here that circular wrapping is 
dealt with and i couldn't see it in the other part of the code.
if�Kjetil wants better quality than hermite interpolation and has a few K word 
of memory for a lookup table of polyphase coefficients, i might
recommend doing that. �it might need MATLAB (and the firpm() or firls() 
function) to generate the table of coefficients. �but the pink elephant paper 
(or Duane's and my paper) shows sorta how the polynomial interpolation compares 
to straight polyphase (if i recall correctly, gee, i better
check that, it's been 20 years).

--
�


r b-j � � � � � � � � �r...@audioimagination.com
�


"Imagination is more important than knowledge."


�
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Time-domain noisiness estimator

[STEFFAN DIEDRICHSEN]

> Am 22.02.2016 um 17:01 schrieb Dario Sanfilippo :
> 
> I'll try studying autocorrelation more and see if I can implement a new 
> algorithm or combine it to the one I already have. 

Dario, 

you need to be careful with polyphonic material plus noise. The autocorrelation 
will have much lower peaks  for polyphonic signals and maybe a large one 
representing a common bass note for the (major) chord, so you need a large 
window to make room for the bass peak. 

> 
> ZCR alone doesn't seem to work unless for specific contexts. Would you agree 
> on that? For example, a 10kHz sine and a 2kHz bandwidth noise centred at 10k 
> both result in pretty much the same ZCR average (100ms window). 
> 

Actually, guitar tuners do wrk well with ZCR, but to discriminate between noise 
and periodic signals, it’s too easy to trigger a false positive, as your 
thought experiment already shoed. 

Steffan ___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Evan Balster]

Hey, Kjetil --

Pulling in a library for just this seems like massive overkill.  The
venerable pink elephant paper
 describes
several cubic resampling algorithms (I prefer four-point hermite) and it's
fairly straightforward to implement the necessary state management.

Attached is the source file for an older implementation of my rate-change
class.  (It's a version without anti-aliasing as that adds a number of
dependencies.)  It's ~200 lines of C++ and while it won't compile without
various modifications it should be relatively straightforward as reference
code or a basis for your own adaptation.

– Evan Balster
creator of imitone 

On Mon, Feb 22, 2016 at 11:08 AM, Kjetil Matheussen <
k.s.matheus...@gmail.com> wrote:

>
>
> On Mon, Feb 22, 2016 at 5:38 PM, Kjetil Matheussen <
> k.s.matheus...@gmail.com> wrote:
>
>>
>> Thank you, but I found something else.
>>
>> It seems like JUCE actually have a resampling class that seems to do the
>> right thing:
>>
>> https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_basics/sources/juce_ResamplingAudioSource.cpp
>>
>>
> No, this seems to be just linear interpolation with a lowpass filter.
>
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
#include 
#include 

//#include "../effects.h"


namespace plaid
{
	//HEADER
	
	struct Pitch_Node {float rate; Uint32 alg;};
	/*
		Pitch:  Allows volume/pitch modulation and pausing of a stream.

		Frequency modulation can be constant, based on another

		WARNING:  Pitch takes in audio from the source stream at an altered
			rate; thus, performance issues will arise from the use of very
			high Pitches as large amounts of data are consumed, and certain
			streams such as Microphones will be unable to keep up with demand.
	*/
	class Pitch : public AudioEffect
	{
	public:
		//Interpolation styles
		enum RESAMPLER
			{
			NONE=0, //Bottom-of-the-barrel
			LINEAR=1, //Low-quality linear
			HERMITE=2, HERMITE_43=2, //4-point 3rd order hermite.
			//Coming: sinc interpolation
			};

	public:
		//Bind to signal
		Pitch(Signal source, float rate=1.0f, Uint32 alg=HERMITE);
		virtual ~Pitch();

		//Choose the resampling algorithm.  Default is HERMITE.
		void resampling(Uint32 alg);

		//Set and interpolate to the given pitch.  "Note" is in semitones.
		void rate(float factor)   {settings.rate = std::max(factor,.0f);}
		void note(float note) {settings.rate = Semitones(note);}

		//Query current pitch
		float rate()  {return settings.rate;}
		float note()  {return Semitones(settings.rate);}

	protected:
		virtual void pull(AudioChunk ,
			const Pitch_Node , const Pitch_Node );
		virtual Pitch_Node interpolate(
			const Pitch_Node , const Pitch_Node , float mid);

		virtual void effectTick(Uint64) {}

	private:
		float offset;
		std::vector mem;
	};
}


using namespace plaid;


static Pitch_Node makeNode(float rate, Uint32 alg)
{
	Pitch_Node node = {rate, alg};
	return node;
}


Pitch::Pitch(Signal source, float rate, Uint32 alg) :
	AudioEffect(source, makeNode(rate, alg))
{
	offset = 0.0f;
	for (int i = 4*source.format().channels; i--;) mem.push_back(0);
}
Pitch::~Pitch()
{
}

void Pitch::resampling(Uint32 alg)
{
	settings.alg = alg;
}


void Pitch::pull(AudioChunk , const Pitch_Node , const Pitch_Node )
{
	Uint32 length = chunk.length(), chan = source.format().channels;

	/*{
		static float sanity = 0.0f;
		if (a.rate != sanity)
			std::cout << "TIME BREAK " << sanity << " -> " << a.rate << std::endl;
		sanity = b.rate;
	}*/

	//Compute rate and offset
	float rate = a.rate, inc = std::pow(b.rate/a.rate, 1.0f/float(length));
	float off = offset;

	//"simulate" the render to figure out how many samples are needed.
	Uint32 count = 0, steps;
	if (inc == 1.0f)
	{
		for (Uint32 i = length; i--;)
		{
			off += rate;
			steps = off; off -= steps;
			count += steps;
		}
	}
	else
	{
		for (Uint32 i = length; i--;)
		{
			off += rate; rate *= inc;
			steps = off; off -= steps;
			count += steps;
		}
	}

	//Allocate temp buffer from scratch pool; account for failure
	AudioChunk sub(chunk, (4 + count), source.format());
	if (!sub.ok()) {chunk.silence(); return;}

	//Pull source audio into temp buffer
	{
		//Copy from memory to beginning of buffer
		Sint32 *forward[PG_MAX_CHANNELS];
		for (Uint32 i=0; i

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Ethan Fenn]

I'm not sure exactly what your requirements are (e.g. does it need to be a
cubic resampler?). But I've used the resampler that is part of the speex
library in the past and it did a fine job. It uses the table-based windowed
sinc approach. I believe it's a BSD-style license, and it's well-separated
from the rest of the library, so you should be able to use it in any kind
of project.

-Ethan



On Mon, Feb 22, 2016 at 12:08 PM, Kjetil Matheussen <
k.s.matheus...@gmail.com> wrote:

>
>
> On Mon, Feb 22, 2016 at 5:38 PM, Kjetil Matheussen <
> k.s.matheus...@gmail.com> wrote:
>
>>
>> Thank you, but I found something else.
>>
>> It seems like JUCE actually have a resampling class that seems to do the
>> right thing:
>>
>> https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_basics/sources/juce_ResamplingAudioSource.cpp
>>
>>
> No, this seems to be just linear interpolation with a lowpass filter.
>
>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Kjetil Matheussen]

Thank you, but I found something else.

It seems like JUCE actually have a resampling class that seems to do the
right thing:
https://github.com/julianstorer/JUCE/blob/master/modules/juce_audio_basics/sources/juce_ResamplingAudioSource.cpp

I don't know what type of resampler this is, but it should be simple to
reimplement
the ResamplingAudioSource::applyFilter method, if necessary.

I guess it's not very good netiquette to answer your own questions, but this
is a problem I've had for 4 years (i.e. a messy and buggy cubic resampler),
and I've
looked around many times to see if I could find something better.
For some reason, it clears the mind just asking someone for help, and
suddenly you solve the problem yourself...

Hopefully someone else finds this thread useful.




On Mon, Feb 22, 2016 at 4:13 PM, Tito Latini  wrote:

> SoX Resampler Library (https://sourceforge.net/projects/soxr) also
> provides a
> quick cubic interpolation with a header (soxr-lsr.h) compatible with
> libsamplerate.
>
> (audacity uses soxr)
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Time-domain noisiness estimator

[Dario Sanfilippo]

Thanks, Corey, Steffan and Risto.

I'll try studying autocorrelation more and see if I can implement a new
algorithm or combine it to the one I already have.

ZCR alone doesn't seem to work unless for specific contexts. Would you
agree on that? For example, a 10kHz sine and a 2kHz bandwidth noise centred
at 10k both result in pretty much the same ZCR average (100ms window).

But the differentiator on the ZCR seems to give an index which roughly
behaves the way you would intuitively expect, at least for some common
situations like analysing the sounds in a room through a microphone.

Best,
Dario


On 22 February 2016 at 14:38, Risto Holopainen  wrote:

>
>
>
> On February 22, 2016 at 12:13:39 pm +01:00, Corey K 
> wrote:
>
> I don't have any links on the use of autocorrelation in this context, and
> I don't even know if it would work. My basic thought, however, was that the
> autocorrelation of white noise should be zero at all time lags other than
> 0. Pitched signals, on the other hand, should have peaks at multiples of
> the pitch period. So the idea would be to see if your autocorrelation has
> many prominent peaks (e.g., is a pitched sound), or is flat and small
> (e.g., a noisy sound).
>
> Best,
> Corey
>
> Autocorrelation seems promising, but it might have problems with brown or
> pink noise where the shortest lags have a decaying acf.
>
> Another time domain approach would be to look at the peaks of the
> waveform; irregularly spaced peaks should indicate a more noisy sound.
>
> Permutation entropy also looks interesting, and according to its
> inventors, it performs better than zcr for detecting noise (or "complexity"
> as they say in their paper).
>
> http://www.math.uni-bremen.de/zetem/DFG-Schwerpunkt/preprints/orig/bandt_pompe_permutation.pdf
>
> Risto
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Tito Latini]

SoX Resampler Library (https://sourceforge.net/projects/soxr) also provides a
quick cubic interpolation with a header (soxr-lsr.h) compatible with 
libsamplerate.

(audacity uses soxr)
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] (no subject)

[Tejas Doshi]

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Tip for an audio resampler library doing cubic interpolation

[Kjetil Matheussen]

On Mon, Feb 22, 2016 at 3:24 PM, Kjetil Matheussen  wrote:

> * Interleaved/non-interleaved input? output? always interpolate all
>> channels?
>>
>>
> Interleaved, always interpolate all channels.
>
>
That was wrong. It's always just one channel. No interleaving is necessary.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Time-domain noisiness estimator

[Risto Holopainen]

On February 22, 2016 at 12:13:39 pm +01:00, Corey K  wrote:

> I don't have any links on the use of autocorrelation in this context, and I 
> don't even know if it would work. My basic thought, however, was that the 
> autocorrelation of white noise should be zero at all time lags other than 0. 
> Pitched signals, on the other hand, should have peaks at multiples of the 
> pitch period. So the idea would be to see if your autocorrelation has many 
> prominent peaks (e.g., is a pitched sound), or is flat and small (e.g., a 
> noisy sound).
> 
> Best,
> Corey
> Autocorrelation seems promising, but it might have problems with brown or 
> pink noise where the shortest lags have a decaying acf.

Another time domain approach would be to look at the peaks of the waveform; 
irregularly spaced peaks should indicate a more noisy sound.

Permutation entropy also looks interesting, and according to its inventors, it 
performs better than zcr for detecting noise (or "complexity" as they say in 
their paper).


Risto


___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

[music-dsp] Tip for an audio resampler library doing cubic interpolation

[Kjetil Matheussen]

Hi all,

I wonder if anyone has a tip for a C or C++ of an implementation of a Cubic
interpolating resampler.
I'm not asking about the algorithm itself, that is all covered (currently
I'm using a Catmull-Rom spline algorithm,
but that is not so important here). What I'm asking about is a framework
for using the algorithm.

To be more specific, what I need is something that I can use to implement
the following abstract class:

typedef long (*src_callback_t) (void *cb_data, float **data) ; // 'data' is
a pointer to a pointer of interleaved multi channel data

struct Resampler{
  virtual ~Resampler(){}
  virtual void init(src_callback_t callback, int num_channels, void
*callback_arg, void *other_init_args) = 0;
  virtual int read(double ratio, int num_frames, float *out) = 0; // 'out'
is interleaved multi channel data
  virtual void reset() = 0;
};


I already did an implementation of this 4 years ago, but the code is a
mess, which also misbehaves if
the samplerate ratio is too extreme. And I don't really trust the code for
non-extreme ratios either.
(Here's the horrible code:
https://github.com/kmatheussen/radium/blob/master/audio/Resampler.cpp )

I don't think it's a good idea to try to fix the code. It's probably better
just to write it again, or better,
find some existing code, or library, which has already been optimized and
debugged.

I've looked around a bit, but haven't really found anything. My code is GPL.
Any help is appreciated.
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Time-domain noisiness estimator

[STEFFAN DIEDRICHSEN]

These properties are true, if you have only noise or only signal. In case of a 
mixture, also the described properties mix and this “torpedoes” that approach. 
So, an FFT with a subsequent processing like floor estimation (connect a line 
thru all floors between peaks) and peak estimation (connect a line thru all 
peaks) and some math processing of the results of the estimations might give 
you more robust numbers on noisiness of a signal. 

Steffan 


> On 22.02.2016|KW8, at 00:47, Ethan Duni  wrote:
> 
> The underlying idea is that "signal" and "noise" can be distinguished in the 
> sense that signals have some compact structure underlying them. But that 
> structure may only be apparent in one domain or another. Noise, however, 
> doesn't have such a structure, so no matter what (fixed) transform you throw 
> at it, it still looks more-or-less uniform and featureless. 
> 

___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Time-domain noisiness estimator

[Corey K]

I don't have any links on the use of autocorrelation in this context, and I
don't even know if it would work. My basic thought, however, was that the
autocorrelation of white noise should be zero at all time lags other than
0. Pitched signals, on the other hand, should have peaks at multiples of
the pitch period. So the idea would be to see if your autocorrelation has
many prominent peaks (e.g., is a pitched sound), or is flat and small
(e.g., a noisy sound).

Best,
Corey


On Mon, Feb 22, 2016 at 12:01 AM, Dario Sanfilippo <
sanfilippo.da...@gmail.com> wrote:

> Hello.
>
> Corey: I'm honestly not so familiar with auto-correlation; I'm aware that
> it is implemented for pitch-detection but I didn't know about those other
> features; would you have a reference or link to a document I could check
> out?
>
> Evan: I get your point; in my case I was following more of a low-level and
> context-independent approach, namely that of trying to distinguish between
> periodic and non-periodic signals; indeed that's why I thought that varying
> ZCR could have worked out.
>
> James: do you mean that frequency modulated sounds and bell sounds are
> perceived as noisy although they have a non-varying ZCR? A noisy signal
> with a DC-offset would also make the algorithm faulty.
>
> Would you say that the most reliable estimation if that of the FFT-based
> flatness?
>
> Best,
> Dario
>
> On 21 February 2016 at 21:03, James McCartney  wrote:
>
>>
>> wouldn't using varying ZCR be defeated by frequency modulated or bell
>> tones?
>> One could also craft a very noisy signal with a perfectly periodic ZCR.
>> James McCartney
>>
>>
>> On Feb 19, 2016, at 04:49, Dario Sanfilippo 
>> wrote:
>>
>> Hello everybody.
>>
>> Following on a discussion about cheap/time-domain spectral centroid
>> estimators, I thought it could have been interesting to also discuss
>> time-domain noisiness estimators.
>>
>> I think that a common approach is the FFT-based spectral flatness
>> algorithm. In the time-domain, zero-crossing rate is another common
>> approach, although it seems to only work for specific cases like voiced Vs.
>> unvoiced sounds, or percussive Vs. non-percussive. A very high frequency
>> sinewave would also have a high ZCR, although it is not noisy.
>>
>> I tried implementing a rudimentary noisiness estimator based on the idea
>> that a noisy signal is characterised by a varying ZCR, rather than a high
>> ZCR. What I did was to use a differentiator on successive averaging windows
>> of ZCR, and then I averaged the absolute value of differentiator's output
>> to obtain an index.
>>
>> The algorithm seems to work fine for most cases, although some particular
>> frequencies of a sinusoidal input result in unexpected indexes. I guess
>> that a problem here is to find a good compromise in the averaging windows
>> of the ZCR. I am using 10-msec windows which seemed to work OK. I was also
>> thinking that I could make the averaging window time-variant, piloting it
>> based on a centroid estimation in order to optimes it according to the
>> spectral content of the signal.
>>
>> Does any of the above make sense for you? Are you aware of other
>> algorithms using a similar technique?
>>
>> If you're familiar with the Pure Data audio environment, you can have a
>> look at the patch here:
>> https://dl.dropboxusercontent.com/u/43961783/noisiness.jpg
>>
>> Thanks,
>> Dario
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
> https://lists.columbia.edu/mailman/listinfo/music-dsp
>
___
dupswapdrop: music-dsp mailing list
music-dsp@music.columbia.edu
https://lists.columbia.edu/mailman/listinfo/music-dsp

Re: [music-dsp] Time-domain noisiness estimator

[Dario Sanfilippo]

Thank you so much for the explanation, Ethan.

Best,
Dario

On 21 February 2016 at 23:47, Ethan Duni  wrote:

> Not a purely time-domain approach, but you can consider comparing sparsity
> in the time and Fourier domains. The idea is that periodic/tonal type
> signals may be non-sparse in the time domain, but look sparse in the
> frequency domain (because all of the energy is on/around harmonics).
> Similarly, transient signals are quite sparse in the time domain, but quite
> non-sparse in the frequency domain. Noisy signals, in comparison, aren't
> sparse in either domain. So if you detect sparsity in at least one domain,
> you mark that as signal. If you don't find a sparse structure in either
> domain, you classify as noise. You can imagine expanding this to a larger
> set of test transforms, working in the LPC residual domain, etc.
>
> The underlying idea is that "signal" and "noise" can be distinguished in
> the sense that signals have some compact structure underlying them. But
> that structure may only be apparent in one domain or another. Noise,
> however, doesn't have such a structure, so no matter what (fixed) transform
> you throw at it, it still looks more-or-less uniform and featureless.
>
> E
>
> On Sun, Feb 21, 2016 at 3:01 PM, Dario Sanfilippo <
> sanfilippo.da...@gmail.com> wrote:
>
>> Hello.
>>
>> Corey: I'm honestly not so familiar with auto-correlation; I'm aware that
>> it is implemented for pitch-detection but I didn't know about those other
>> features; would you have a reference or link to a document I could check
>> out?
>>
>> Evan: I get your point; in my case I was following more of a low-level
>> and context-independent approach, namely that of trying to distinguish
>> between periodic and non-periodic signals; indeed that's why I thought that
>> varying ZCR could have worked out.
>>
>> James: do you mean that frequency modulated sounds and bell sounds are
>> perceived as noisy although they have a non-varying ZCR? A noisy signal
>> with a DC-offset would also make the algorithm faulty.
>>
>> Would you say that the most reliable estimation if that of the FFT-based
>> flatness?
>>
>> Best,
>> Dario
>>
>> On 21 February 2016 at 21:03, James McCartney  wrote:
>>
>>>
>>> wouldn't using varying ZCR be defeated by frequency modulated or bell
>>> tones?
>>> One could also craft a very noisy signal with a perfectly periodic ZCR.
>>> James McCartney
>>>
>>>
>>> On Feb 19, 2016, at 04:49, Dario Sanfilippo 
>>> wrote:
>>>
>>> Hello everybody.
>>>
>>> Following on a discussion about cheap/time-domain spectral centroid
>>> estimators, I thought it could have been interesting to also discuss
>>> time-domain noisiness estimators.
>>>
>>> I think that a common approach is the FFT-based spectral flatness
>>> algorithm. In the time-domain, zero-crossing rate is another common
>>> approach, although it seems to only work for specific cases like voiced Vs.
>>> unvoiced sounds, or percussive Vs. non-percussive. A very high frequency
>>> sinewave would also have a high ZCR, although it is not noisy.
>>>
>>> I tried implementing a rudimentary noisiness estimator based on the idea
>>> that a noisy signal is characterised by a varying ZCR, rather than a high
>>> ZCR. What I did was to use a differentiator on successive averaging windows
>>> of ZCR, and then I averaged the absolute value of differentiator's output
>>> to obtain an index.
>>>
>>> The algorithm seems to work fine for most cases, although some
>>> particular frequencies of a sinusoidal input result in unexpected indexes.
>>> I guess that a problem here is to find a good compromise in the averaging
>>> windows of the ZCR. I am using 10-msec windows which seemed to work OK. I
>>> was also thinking that I could make the averaging window time-variant,
>>> piloting it based on a centroid estimation in order to optimes it according
>>> to the spectral content of the signal.
>>>
>>> Does any of the above make sense for you? Are you aware of other
>>> algorithms using a similar technique?
>>>
>>> If you're familiar with the Pure Data audio environment, you can have a
>>> look at the patch here:
>>> https://dl.dropboxusercontent.com/u/43961783/noisiness.jpg
>>>
>>> Thanks,
>>> Dario
>>>
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>>
>>>
>>> ___
>>> dupswapdrop: music-dsp mailing list
>>> music-dsp@music.columbia.edu
>>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>>
>>
>>
>> ___
>> dupswapdrop: music-dsp mailing list
>> music-dsp@music.columbia.edu
>> https://lists.columbia.edu/mailman/listinfo/music-dsp
>>
>
>
> ___
> dupswapdrop: music-dsp mailing list
> music-dsp@music.columbia.edu
>