<br><br><div class="gmail_quote">On Thu, Aug 20, 2009 at 11:06 AM, Steve Underwood <span dir="ltr"><<a href="mailto:steveu@coppice.org">steveu@coppice.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">On 08/20/2009 05:22 AM, Michael Collins wrote:<br>
><br>
> There is no noise on those 3 beeps. In fact, for something that's been<br>
> through ulaw/alaw compression those beeps are very clean. They are<br>
> quite<br>
> short, though.<br>
><br>
><br>
> Heck yeah they're short! Steve, in your experience is there a<br>
> practical way to detect a beep that short without chewing up system<br>
> resources or having lots of false positives?<br>
> -MC<br>
><br>
</div></div>The tone samples I just looked at are about 130ms long. The problem is<br>
the detector is trying to be a very open ended detector of anything<br>
narrowband enough to be a single tone, and of any duration beyond some<br>
small minimum. Its difficult to make such a thing voice immune unless<br>
you can also count on a very large signal to noise ratio. With a digital<br>
trunk you can probably rely on a large SNR, but what happens when people<br>
use analogue lines? There is a reason why DTMF detectors try hard to<br>
work down to about 10dB SNR. :-)<br>
<br>
Steve<br>
</blockquote><div><br>Thanks for the lesson uncle Steve! I'm guessing that the OP will need a new strategy. Possibly waiting for silence? Not sure what's the best way to go but I'm interested in hearing if someone has a solution.<br>
<br>-MC<br><br></div></div><br>