Jean-Marc Valin wrote:> The noise suppressor will only attempt to remove stationary noise, > such as thermal noise, fans, ... The AGC can indeed do strange > things in these cases, but it's been improved in svn (compared to > 1.2beta1).OK, then the problem is that I misunderstood the feature. I assumed that dynamic squelch was part of it, but it's really something more along the lines of active noise cancellation. That's fine, I'll work on improving my own squelch code.> Congratulations. If it works better on your data, then use it. It'll > just fail miserably in other conditions, but you may not care about > those.Uh, production applications almost always require squelch, no? This is no less true today than it was in the days of analog transmitters. Note that mobile phones don't transmit low-value transients, even if I'm typing right next to them. While it's certainly true that the fixed-threshold static peak implementation I banged out isn't going to work everywhere, some more elaborate variation would be really nice to have in speex.> Are you using a frame size in the 10-20 ms range?I'm using the frame size returned from SPEEX_GET_FRAME_SIZE. It's 640 frames under this implementation, or 20ms. Andy
> OK, then the problem is that I misunderstood the feature. I assumed > that dynamic squelch was part of it, but it's really something more > along the lines of active noise cancellation. That's fine, I'll work > on improving my own squelch code.No. Active noise cancellation is yet another thing, where you cancel the noise in the "acoustic world" by destructive interference. Most likely not what you want.> 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. I wouldn't be surprised if you algo either 1) adds delay or 2) cuts onsets. This> is no less true today than it was in the days of analog transmitters. > Note that mobile phones don't transmit low-value transients, even if > I'm typing right next to them. While it's certainly true that the > fixed-threshold static peak implementation I banged out isn't going to > work everywhere, some more elaborate variation would be really nice to > have in speex.If you come up with a general algorithm that works for all cases, I'll definitely consider it.>> Are you using a frame size in the 10-20 ms range? > > I'm using the frame size returned from SPEEX_GET_FRAME_SIZE. It's 640 > frames under this implementation, or 20ms.OK. Jean-Marc
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 > onsetsThe 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
Andy Ross wrote:> Jean-Marc Valin wrote: > >> The noise suppressor will only attempt to remove stationary noise, >> such as thermal noise, fans, ... The AGC can indeed do strange >> things in these cases, but it's been improved in svn (compared to >> 1.2beta1). >> > > OK, then the problem is that I misunderstood the feature. I assumed > that dynamic squelch was part of it, but it's really something more > along the lines of active noise cancellation. That's fine, I'll work > on improving my own squelch code. > > >> Congratulations. If it works better on your data, then use it. It'll >> just fail miserably in other conditions, but you may not care about >> those. >> > > Uh, production applications almost always require squelch, no? This > is no less true today than it was in the days of analog transmitters. > Note that mobile phones don't transmit low-value transients, even if > I'm typing right next to them. While it's certainly true that the > fixed-threshold static peak implementation I banged out isn't going to > work everywhere, some more elaborate variation would be really nice to > have in speex. >It is -- in this case, you would use the result of speex_preprocess() to signal to your application whether or not to replace the audio with comfort noise (or, zeros if you prefer). -SteveK -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/speex-dev/attachments/20070227/0554b8ef/attachment.html