Re: [nfc-l] NFC Detectors and Equipment?

[Tim Krein]

Some comments below regarding use of Raven for review of 
detections/selections.  Also, to answer Chris T-H's question about the 
BirdCast transient detector and the energy detector in Raven, the 
detector in Raven is a port of the old BirdCast detector to Java.  They 
should function similarly if you use the same parameters.

- Tim


On 8/22/09 10:06 AM, e kent wrote:
> Erik Johnson wrote:  "What's also frustrating is that I get a TON of 
> trash clips - many more than birds clips."
>  
> To be clear, I'm a hobbyist with limited time, so I use detectors 
> *assuming* it will give acceptable results more quickly than 
> viewing/listening to sound files directly.
>  
> Unfortunately, as Mike Lanzone points out, Trash-versus-Bird is one 
> trade-off when using detectors.  However, this trade-off can be 
> mitigated by an efficient tool to sift through the trash.  For 
> the this discussion, I'll say the software detection process has two 
> major phases: the software detection itself, and then the human 
> classification phase (trash versus bird).
>  
> Not sure if others agree, but as others work to improve the detectors, 
> I think a quick win is an improved tool for the 2nd phase, 
> wheat-vs-chaff classification.  
>  
> For example, last night I ran a file through a Raven detector 
> graciously forwarded by Mike Powers.  Examining the results with 
> Glass-of-Fire, I labelled one sound out of 200+ detections as a bird 
> (same as when I used Tseep/Thrush against the file).   This was quick 
> and painless.
>  
> However, individual review of Raven detections revealed I 
> *incorrectly* labelled 7 bird calls as Noise in Glass-of-Fire.  This 
> is because Glass-of-Fire stretches spectrograms to a pre-defined size, 
> rendering the bird calls visually unrecognizable.  So, the detector 
> found birds, but the efficient classifier was inaccurate.
>  
> Manual review of each Raven detection was accurate, but highly 
> inefficient:  viewing hundreds of selections one-at-a-time is slow and 
> tedious.  The bounding boxes effectively hide short sounds.  Keeping 
> or deleting good/bad selections from the selection list is error prone.
TK> You can hide the bounding boxes in Raven using the Layout side 
panel.  When doing this, you can increase the opacity of the selection 
fill to be able to see the selections, thereby allowing you to see the 
entire selection without the bounds getting in the way.  You can also 
show the selection number using the View > Configure Selection Labels 
dialog.  This is what Anne K. has done effectively.  We've recently 
received requests to be able to advance through selections automatically 
without any keystrokes or button presses.  In Raven Pro 1.4 build 24 
(currently in test), we have such a feature.  You can advance through 
each selection with a delay time in between, and you can optionally play 
the selections as you advance through them.  Perhaps this is still not 
as efficient as MxN selections displayed in a grid, but it does save on 
RSI for those people who have to scan their selections.  Rather than 
deleting selections from a table, it might make sense to add a 
particular annotation to them (x, d for delete, b for bad), then sort by 
that annotation column, then move all of the matching annotations to a 
new table.  We'll open a new feature request for the clip viewer.
>  
> Glass-of-Fire is a great format: view page-fulls of spectograms, and 
> quickly classify them with key combos.  A great improvement would be 
> to present spectrograms without stretching.  To use Raven detections 
> with a Glass-of-Fire style viewer, it would be helpful to see more 
> sound around the Raven detection.  For example, in the case of a 
> longer bird call it successfully detected part of the call, without 
> selecting the whole sound.  In the case of a short call, it's 
> difficult to understand what you're looking at without seeing more 
> context around the sound.
TK> When you export clips from Raven (File > Save All Selections...), 
you can specify a pad size so that Raven saves extra time around the 
selection as part of the exported file.  This will not get you identical 
file sizes unless you first alter the size of the selections in Raven.  
You can also save the Raven table, then edit it in Excel so that all of 
the selection time widths are identical.
>  
> Regardless, I think increased efficiency during human 
> classification should allow current detectors to flag even more 
> sounds, catching more bird calls along with the trash.
>  
>  
> Thanks,
> Eric
>  
>  
>  
>  
>  
>
> 
> *From:* Chris Tessaglia-Hymes 
> *To:* nfc-l@cornell.edu
> *Sent:* Friday, August 21, 2009 2:09:37 PM
> *Subject:* [nfc-l] NFC Detectors and Equipment?
>
> Hi everyone,
>
> In the past, I have not used any detectors when going through my night 
> recordings at home (Etna, NY). I have collected my sound data from the 
> 

Re: [nfc-l] NFC Detectors and Equipment?

[Michael Lanzone]

Hi All,

Even though we use Raven and XBAT to analyze our recordings, we also still
use GlassOFire to sort the clips as is a quicker and more efficient than
sorting within Raven. You will find with any program using settings for
export you will have files of slightly different lengths as you usually
export the selection with a user selected buffer (or fixed in the case of
tseep), and since the detected part of the call (often detectors do not
detect the whole call, just a small piece), or even whole calls are
different lengths the sizes will all be different. It is possible to get
files of uniform length in Raven, but I do that by editing the selection
table.

Best,
Mike

Michael Lanzone
Biotechnology and Biomonitoring Lab Supervisor
Carnegie Museum of Natural History
Powdermill Avian Research Center
1847 Route 381
Rector, PA 15677
724.593.5521 Office
mlanz...@gmail.com


On Mon, Aug 24, 2009 at 9:27 AM, David Martin  wrote:

>  I agree with Eric that work flow is a major consideration, and GlassOFire
> is also a key tool for me.   I set it up so that I see 36 sonograms on the
> screen at a time (2400 x 1600 twps).   At these settings I can easily
> separate the obvious noise and the calls, and I can clear out the katydids
> and rain pretty fast. Some calls are clearly recognizable, but many are too
> indistinct to identify.   I use Raven to verify the id's.
>
> One problem is that the sound files produced by Tseep-x are not all the
> same length.  GlassOFire works well with the majority of images.  But, if
> the file is long, GlassOFire compresses the image to fit the frame size, and
> the calls are hard to recognize. If the call also is faint, it looks like a
> smudge in the sonogram.  If the file is short, GlassOFire stretches the
> image.  For me stretching has usually not been a problem.  There are
> occasional cases where the file is greatly stretched and it is obvious that
> it has no useful content.
>
> In my view, it would  help if detectors like Tseep-x and Thrush-x produced
> files of uniform length.  Then the image size in GlassOFire could be matched
> to the file length.
>
> I still have to work on using the detector in Raven.
>
> David Martin
>
>
>
> At 10:06 AM 8/22/2009, you wrote:
>
> Erik Johnson wrote:  "What's also frustrating is that I get a TON of trash
> clips - many more than birds clips."
>
> To be clear, I'm a hobbyist with limited time, so I use detectors
> *assuming* it will give acceptable results more quickly than
> viewing/listening to sound files directly.
>
> Unfortunately, as Mike Lanzone points out, Trash-versus-Bird is one
> trade-off when using detectors.  However, this trade-off can be mitigated by
> an efficient tool to sift through the trash.  For the this discussion, I'll
> say the software detection process has two major phases: the software
> detection itself, and then the human classification phase (trash versus
> bird).
>
> Not sure if others agree, but as others work to improve the detectors, I
> think a quick win is an improved tool for the 2nd phase, wheat-vs-chaff
> classification.
>
> For example, last night I ran a file through a Raven detector graciously
> forwarded by Mike Powers.  Examining the results with Glass-of-Fire, I
> labelled one sound out of 200+ detections as a bird (same as when I used
> Tseep/Thrush against the file).   This was quick and painless.
>
> However, individual review of Raven detections revealed I *incorrectly*
> labelled 7 bird calls as Noise in Glass-of-Fire.  This is because
> Glass-of-Fire stretches spectrograms to a pre-defined size, rendering the
> bird calls visually unrecognizable.  So, the detector found birds, but the
> efficient classifier was inaccurate.
>
> Manual review of each Raven detection was accurate, but highly
> inefficient:  viewing hundreds of selections one-at-a-time is slow and
> tedious.  The bounding boxes effectively hide short sounds.  Keeping or
> deleting good/bad selections from the selection list is error prone.
>
> Glass-of-Fire is a great format: view page-fulls of spectograms, and
> quickly classify them with key combos.  A great improvement would be to
> present spectrograms without stretching.  To use Raven detections with a
> Glass-of-Fire style viewer, it would be helpful to see more sound around the
> Raven detection.  For example, in the case of a longer bird call it
> successfully detected part of the call, without selecting the whole sound.
> In the case of a short call, it's difficult to understand what you're
> looking at without seeing more context around the sound.
>
> Regardless, I think increased efficiency during human classification should
> allow current detectors to flag even more sounds, catching more bird calls
> along with the trash.
>
>
> Thanks,
> Eric
>
>
>
>
>
>
>
> *From:* Chris Tessaglia-Hymes 
> *To:* nfc-l@cornell.edu
> *Sent:* Friday, August 21, 2009 2:09:37 PM
> *Subject:* [nfc-l] NFC Detectors and Equipment?
>
> Hi everyone,
>
> In the past, I have not used 

Re: [nfc-l] Engineers - chime in? Adaptive Noise Cancellation

[Michael Lanzone]

I will look to see if we do..

Sent from my iPhone

On Aug 24, 2009, at 9:54 AM, Thomas Fowler  wrote:

>
> Hi Everyone,
>
> I am an engineer chiming in.
>
> I have used this technique to clean up a signal.  Technically, it is  
> pretty simple to subtract out a "noise" signal.
> The hard part is getting a signal which is the exact "noise" you  
> want to subtract.  By exact I mean it has
> the equivalent gain, and timing and spectral content.  If it is in  
> the same frequency band as the target signal things
> get more difficult in a hurry.  Does anyone have multiple channel  
> recordings where the noise shows more prominently
> on one channel while the target bird shows better on another  
> channel?  I have Labview and can read *.wav files.  I would
> be willing to spend some time messing with this if someone can  
> provide a appropriate file.
>
> TomF
> retired Cornell Bioacoustics Engineer.
>
>
> At 01:00 AM 8/22/2009 -0400, you wrote:
>> Okay, last post for the night
>>
>> The more I read about this, the more and more it sounds really cool.
>>
>> So, you software and hardware engineer people out there - what do  
>> you think? Can it work to better clean up night flight call data  
>> collection? Heck, this could get you closer to that 90-95% positive  
>> detection figure we'd all like to see.
>>
>> http://plaza.ufl.edu/badavis/EEL6502_Project_1.html
>>
>> Sincerely,
>> Chris T-H
>>
>> Chris Tessaglia-Hymes wrote:
>>> I think the idea with adaptive noise cancellation is this:
>>>
>>> you have a dual microphone system. One channel is the primary  
>>> channel (collecting the target sounds). The second channel is the  
>>> "noise collection" channel. Through some mathematical algorithms,  
>>> you subtract the noise collected in the "noise" channel from the  
>>> primary channel (e.g., a different microphone aimed at collecting  
>>> the cricket sounds or the katydid sounds, perhaps using a slightly  
>>> lower gain setting, so as not to pick up distant flight calls  
>>> being collected in the primary channel). The resulting signal in  
>>> the primary channel should have reduced cricket and katydid  
>>> sounds. Well, that's the theory, I guess.
>>>
>>> Here's an older paper abstract from 1975. Current technology can  
>>> probably do this adaptive noise filtering in very real-time.
>>>
>>> http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1451965
>>>
>>> Sincerely,
>>> Chris T-H
>

--
NFC-L List Info:
http://www.NortheastBirding.com/NFC_WELCOME
http://www.NortheastBirding.com/NFC_RULES

http://www.mail-archive.com/nfc-l@cornell.edu/maillist.html
--

Re: [nfc-l] Engineers - chime in? Adaptive Noise Cancellation

[Thomas Fowler]

Hi Everyone,

I am an engineer chiming in.

I have used this technique to clean up a signal.  Technically, it is pretty 
simple to subtract out a "noise" signal.
The hard part is getting a signal which is the exact "noise" you want to 
subtract.  By exact I mean it has
the equivalent gain, and timing and spectral content.  If it is in the same 
frequency band as the target signal things
get more difficult in a hurry.  Does anyone have multiple channel 
recordings where the noise shows more prominently
on one channel while the target bird shows better on another channel?  I 
have Labview and can read *.wav files.  I would
be willing to spend some time messing with this if someone can provide a 
appropriate file.

TomF
retired Cornell Bioacoustics Engineer.


At 01:00 AM 8/22/2009 -0400, you wrote:
>Okay, last post for the night
>
>The more I read about this, the more and more it sounds really cool.
>
>So, you software and hardware engineer people out there - what do you 
>think? Can it work to better clean up night flight call data collection? 
>Heck, this could get you closer to that 90-95% positive detection figure 
>we'd all like to see.
>
>http://plaza.ufl.edu/badavis/EEL6502_Project_1.html
>
>Sincerely,
>Chris T-H
>
>Chris Tessaglia-Hymes wrote:
>>I think the idea with adaptive noise cancellation is this:
>>
>>you have a dual microphone system. One channel is the primary channel 
>>(collecting the target sounds). The second channel is the "noise 
>>collection" channel. Through some mathematical algorithms, you subtract 
>>the noise collected in the "noise" channel from the primary channel 
>>(e.g., a different microphone aimed at collecting the cricket sounds or 
>>the katydid sounds, perhaps using a slightly lower gain setting, so as 
>>not to pick up distant flight calls being collected in the primary 
>>channel). The resulting signal in the primary channel should have reduced 
>>cricket and katydid sounds. Well, that's the theory, I guess.
>>
>>Here's an older paper abstract from 1975. Current technology can probably 
>>do this adaptive noise filtering in very real-time.
>>
>>http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1451965
>>
>>Sincerely,
>>Chris T-H


--
NFC-L List Info:
http://www.NortheastBirding.com/NFC_WELCOME
http://www.NortheastBirding.com/NFC_RULES

http://www.mail-archive.com/nfc-l@cornell.edu/maillist.html
--

Re: [nfc-l] NFC Detectors and Equipment?

[David Martin]

I agree with Eric that work flow is a major consideration, and 
GlassOFire is also a key tool for me.   I set it up so that I see 36 
sonograms on the screen at a time (2400 x 1600 twps).   At these 
settings I can easily separate the obvious noise and the calls, and I 
can clear out the katydids and rain pretty fast. Some calls are 
clearly recognizable, but many are too indistinct to identify.   I 
use Raven to verify the id's.

One problem is that the sound files produced by Tseep-x are not all 
the same length.  GlassOFire works well with the majority of 
images.  But, if the file is long, GlassOFire compresses the image to 
fit the frame size, and the calls are hard to recognize. If the call 
also is faint, it looks like a smudge in the sonogram.  If the file 
is short, GlassOFire stretches the image.  For me stretching has 
usually not been a problem.  There are occasional cases where the 
file is greatly stretched and it is obvious that it has no useful content.

In my view, it would  help if detectors like Tseep-x and Thrush-x 
produced files of uniform length.  Then the image size in GlassOFire 
could be matched to the file length.

I still have to work on using the detector in Raven.

David Martin


At 10:06 AM 8/22/2009, you wrote:
>Erik Johnson wrote:  "What's also frustrating is that I get a TON of 
>trash clips - many more than birds clips."
>
>To be clear, I'm a hobbyist with limited time, so I use detectors 
>*assuming* it will give acceptable results more quickly than 
>viewing/listening to sound files directly.
>
>Unfortunately, as Mike Lanzone points out, Trash-versus-Bird is one 
>trade-off when using detectors.  However, this trade-off can be 
>mitigated by an efficient tool to sift through the trash.  For the 
>this discussion, I'll say the software detection process has two 
>major phases: the software detection itself, and then the human 
>classification phase (trash versus bird).
>
>Not sure if others agree, but as others work to improve the 
>detectors, I think a quick win is an improved tool for the 2nd 
>phase, wheat-vs-chaff classification.
>
>For example, last night I ran a file through a Raven detector 
>graciously forwarded by Mike Powers.  Examining the results with 
>Glass-of-Fire, I labelled one sound out of 200+ detections as a bird 
>(same as when I used Tseep/Thrush against the file).   This was 
>quick and painless.
>
>However, individual review of Raven detections revealed I 
>*incorrectly* labelled 7 bird calls as Noise in Glass-of-Fire.  This 
>is because Glass-of-Fire stretches spectrograms to a pre-defined 
>size, rendering the bird calls visually unrecognizable.  So, the 
>detector found birds, but the efficient classifier was inaccurate.
>
>Manual review of each Raven detection was accurate, but highly 
>inefficient:  viewing hundreds of selections one-at-a-time is slow 
>and tedious.  The bounding boxes effectively hide short 
>sounds.  Keeping or deleting good/bad selections from the selection 
>list is error prone.
>
>Glass-of-Fire is a great format: view page-fulls of spectograms, and 
>quickly classify them with key combos.  A great improvement would be 
>to present spectrograms without stretching.  To use Raven detections 
>with a Glass-of-Fire style viewer, it would be helpful to see more 
>sound around the Raven detection.  For example, in the case of a 
>longer bird call it successfully detected part of the call, without 
>selecting the whole sound.  In the case of a short call, it's 
>difficult to understand what you're looking at without seeing more 
>context around the sound.
>
>Regardless, I think increased efficiency during human classification 
>should allow current detectors to flag even more sounds, catching 
>more bird calls along with the trash.
>
>
>Thanks,
>Eric
>
>
>
>
>
>
>
>From: Chris Tessaglia-Hymes 
>To: nfc-l@cornell.edu
>Sent: Friday, August 21, 2009 2:09:37 PM
>Subject: [nfc-l] NFC Detectors and Equipment?
>
>Hi everyone,
>
>In the past, I have not used any detectors when going through my 
>night recordings at home (Etna, NY). I have collected my sound data 
>from the roof-top microphone (Evans-style, with a Knowles microphone 
>element) piped into my home computer running Raven Pro, recording a 
>continuous file sequence from start to finish with each file 
>duration equal to 1 minute. The following day, I would browse 
>through the sound file sequence by hand, again using Raven Pro, 
>looking for sounds of interest. Once a sound of interest was worth 
>saving, as an example of a good flight note for species x, or an 
>interesting unidentified species flight call, I would cut-and-paste 
>that sound file into a new window and save it with a time-stamped 
>label, uniquely pairing it to the file/time it was copied from.
>
>Now, this is all fine when you are a single person, operating your 
>own home station, only recording on those nights which appear to 
>have good night flights. But, when you begin operating to capture 
>every