Speex dev - Oct 2005 - audio preprocess questions

Jean Marc,

I have been fiddling around with preprocess to try to get it sounding
less metallic/underwater- so based on some things said recently,
I have been first fiddling with mean_post and mean_prior to try to
get them to do change the update rate, so that update_noise gets
called at the right times.

Haven't made it too deep into the code, but I have a few
questions in speex_preprocess:

Is there a particular reason for choosing .1 as the gamma
coefficient (for the posteriori SNR)?  It seems like you started
to use a predictor and then hard coded it...  probably this is
in some paper but I can't find it so far.

Are the following best engineering judgement or statistically based:
if (mean_prior<0.23f && mean_post<0.5f)
I seem to have altered mean_prior and mean_post such that
these don't work anymore so I was wondering how you went
about choosing these.

Same question on st->gain having 2.0f as an arbitrary limit?  Seems
to work but just wondering about why it works to cap it there.

same question on:
st->echo_noise[i] = (0.3f*st->echo_noise[i] + echo[i]);
Seems to work well in the original code, trying to figure
out why it is what it is.

So far it seems like denoising is working well, but now I can no longer
properly handle the echo signal.  arg,

Thanks for all of your help so far!

Tom


______________________________________________

Tom Harper
Lead Software Engineer
SightSpeed - <http://www.sightspeed.com/>http://www.sightspeed.com/

918 Parker St, Suite A14
Berkeley, CA 94710

Email: tharper@sightspeed.com
Phone: 510-665-2920
Fax: 510-649-9569
My SightSpeed Video Link: http://tom.sightspeed.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20051025/94d8e131/attachment.html

> I have been fiddling around with preprocess to try to get it sounding 
> less metallic/underwater- so based on some things said recently,
> I have been first fiddling with mean_post and mean_prior to try to 
> get them to do change the update rate, so that update_noise gets 
> called at the right times.
Those aren't very important anymore (since I added the MCRA noise
estimation).
> Is there a particular reason for choosing .1 as the gamma
> coefficient (for the posteriori SNR)?  It seems like you started
> to use a predictor and then hard coded it...  probably this is
> in some paper but I can't find it so far.
.1 seemed to work fine and having an adaptive one hasn't helped much so
far.
> Are the following best engineering judgement or statistically based:
> if (mean_prior<0.23f && mean_post<0.5f)
> I seem to have altered mean_prior and mean_post such that 
> these don't work anymore so I was wondering how you went
> about choosing these.
Black magic. Not very relevant anymore.
> Same question on st->gain having 2.0f as an arbitrary limit?  Seems
> to work but just wondering about why it works to cap it there.
Intuition. Just preventing things from going really wrong. I have yet to
see a case where this has a real effect.
> same question on:
> st->echo_noise[i] = (0.3f*st->echo_noise[i] + echo[i]);
> Seems to work well in the original code, trying to figure
> out why it is what it is.
Just smoothing out the echo spectrum over time. Very ad hoc, needs to be
improved one day.

	Jean-Marc