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

2016-02-21 Thread Ethan Duni 
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
https://lists.columbia.edu/mailman/listinfo/music-dsp

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

2016-02-21 Thread Dario Sanfilippo 
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

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

2016-02-21 Thread James McCartney 

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

Re: [music-dsp] Cheap spectral centroid recipe

2016-02-21 Thread Evan Balster 
In late 2013 (I think) I experimented with a preliminary implementation of
the brightness articulation in my pitch tracking software.  I normalized it
based on fundamental frequency, which at the time seemed like common sense
due to the mathematical elegance of a well-defined minimum.

Since then I've reconsidered that decision on the basis of formant
structure:  the spectral centroid in hertz corresponds more closely to
mouth and throat shape than to pitch, especially for tenor and bass
registers.  While certainly present, the correlation between spectral
centroid and pitch can be *very* loose for deep vocal sounds -- I wouldn't
be surprised if it was non-monotonic.

I think my brightness metric at the time used first-order filters, but I
have implemented pinking-related techniques since then and I can confirm
they work quite well.  (Well enough that I forgot about the biases induced
by first-order implementations, anyway.)

– Evan Balster
creator of imitone 

On Fri, Feb 19, 2016 at 7:30 PM, Douglas Repetto  wrote:

> Robert,
>
> On Fri, Feb 19, 2016 at 3:38 PM, robert bristow-johnson <
> r...@audioimagination.com> wrote:
>
>> geez, i wish i could cut and paste text without getting all of that HTML
>> crap in there.  i dunno how this is going through majordomo or whatever
>> Douglas has running the list.
>
>
>
> That's a function of your email client, not the list. The list just sends
> through whatever you send to it. Your mail looks fine to me, no HTML to be
> seen, nice formatting, etc. This is in Chrome/gmail. So if you're seeing
> markup then it's your client that's displaying it as code instead of
> rendering it.
>
> douglas
>
>
>
>
> ___
> 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

2016-02-21 Thread Evan Balster 
Noise is an elusive concept.  One way of thinking about it is that the real
signal can be decomposed into a sum of two theoretical signals, comprising
desirable and undesirable information.  What isn't signal is noise; and
what isn't noise is signal -- so our definitions or models for these must
be complementary.  This implies that isolating noise -- or what noise even
*is* in a given context -- depends on what kind of information we're trying
to extract from the raw signal.

While it's not uncommon for the undesirable information to exhibit a white
spectral envelope, this quality is highly situational and depends heavily
on the context.  I've been bitten in the past when designing algorithms
around a white noise model and then running my software on systems with
integrated noise cancellation.

– Evan Balster
creator of imitone 

On Sun, Feb 21, 2016 at 6:16 AM, Corey K  wrote:

> I haven't researched this at all, so take the following with a grain of
> salt. But, how about looking at different features of the auto-correlation
> (e.g., flatness, peakiness, ...)?
>
> On Fri, Feb 19, 2016 at 1:49 PM, Dario Sanfilippo <
> sanfilippo.da...@gmail.com> 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

Re: [music-dsp] MIDI Synth Design Advice Please

2016-02-21 Thread Ross Bencina 

On 2/02/2016 2:10 AM, Scott Gravenhorst wrote:

Advice regarding this endeavor would be appreciated


In case you haven't found it, you should research the disable_pvt config
file flag. It can reduce system jitter a little.


Hi again Scott,

The following Linux system jitter optimisation blog posts by Mark Price 
were referenced on the mechanical-sympathy mailing list today. They may 
be of interest to your project:


http://epickrram.blogspot.co.uk/2015/09/reducing-system-jitter.html
http://epickrram.blogspot.co.uk/2015/11/reducing-system-jitter-part-2.html

Ross.
___
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

2016-02-21 Thread Corey K 
I haven't researched this at all, so take the following with a grain of
salt. But, how about looking at different features of the auto-correlation
(e.g., flatness, peakiness, ...)?

On Fri, Feb 19, 2016 at 1:49 PM, Dario Sanfilippo <
sanfilippo.da...@gmail.com> 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