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 <asy...@gmail.com> 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 <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 >
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
