[Speex-dev] Preprocessor denoise. Does it work?

[Andy Ross]

Jean-Marc Valin wrote:
> Andy Ross wrote:
> > Uh, production applications almost always require squelch, no?
>
> Some do, some don't. In general, distinguishing between a keyboard
> and a speech transient is next to impossible based only on a few ms
> of speech.

That is true for distinguishing it by waveform, but not by amplitude.
As I mentioned, these transients are objectively tiny.  I guess I'd be
curious as to which voice codec applications require no squelch (other
than trivial examples like push-to-talk interfaces).  Especially in
the presence of the AGC feature, it seems pretty much required to me.
(I'll try the svn code, though.  It may be that a better AGC would
eliminate the need for squelch.)

I'm not saying a general squelch algorithm would be a easy task, just
that it's (1) important to real world applications (IMHO rather more
important than spectrum-based denoise or AGC) and (2) not all *that*
difficult, as evidenced by my really brief experiment.  Again: my tiny
chat application is perceptibly better sounding than the bare speex
preprocessor in the presence of anything but total silence in the
environment.

> I wouldn't be surprised if you algo either 1) adds delay or 2) cuts
> onsets

The latter, if anything.  There is no state or buffering; it's just a
short-circuit to the preprocess call.  But I will say that, given
minimal testing, the output quality doesn't seem to suffer at all.
And the lack of the very loud keyboard pops and squeals is a real
improvement.

I guess I don't understand your resistance to squelch, it's a very
well-tested idiom.  Sure, there are sexier algorithms out there, but
there's still room for squelch in a modern application.

Andy