Re: [nfc-l] NFC Detectors and Equipment?
Beautiful, Tim! This helps a lot. All the Best, Eric From: Tim Krein To: nfc-l@cornell.edu Sent: Monday, August 24, 2009 11:10:59 PM Subject: Re: [nfc-l] NFC Detectors and Equipment? 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 > &
Re: [nfc-l] NFC Detectors and Equipment?
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, Au
Re: [nfc-l] NFC Detectors and Equipment?
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 >
Re: [nfc-l] NFC Detectors and Equipment?
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 >
Re: [nfc-l] NFC Detectors and Equipment?
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 night from multiple stations, or you want to really quantify most or all of the calls that night, the question of data storage and data processing becomes the big issues. How do some of you out there collect your sound data? What tools do you use for browsing sounds? Do you only use detectors? Here's a question for probably three people on this list: What is the difference between the current Raven Pro detector that Mike Powers provided settings for and the old BirdCast transient detector? Is there a difference? Getting back to an earlier posting from Tom Fowler (prior to the bloom in membership...140+ now!), what kind of equipment do you each use for recording or listening to your sounds? I mentioned that I use a variation on the Bill Evans-style flowerpot microphone. I know that Andrew Farnsworth and Mike Powers use a microphone, pre-amp, and housing designed by engineers at Bioacoustics at the Cornell Lab of Ornithology, storing their night sounds on flash memory inside a SoundCache for analysis later, but what do others use? What are your personal home recording setups like? What obstacles or limitations have you encountered with your equipment setups or recordings? I realize these are a lot of questions, but I wanted to pose thes
Re: [nfc-l] NFC Detectors and Equipment?
So, the question is: can the unwanted cricket and katydid sounds be removed from the audio channel at the time of sound acquisition, real-time, such that their acoustic signatures are minimized or eliminated altogether from the collected sound data prior to an automatic detector batch process? Sincerely, Chris T-H Michael Lanzone wrote: No software we have worked with gets near 100%. I have toyed around with templates that got 95% of the calls, and detectors can get ~90%, but more commonly get in the 60-80% range. In Louisiana with the insects it would be on the low end of this. Katydids and such are problematic for detectors... Best, Mike Sent from my iPhone On Aug 21, 2009, at 7:43 PM, Erik Johnson wrote: Hi All, I've been recording from my home in south Louisiana with set-ups like Chris and David over the last few years. I've been using the oldbird software (tseep, etc), but only get about 20% of the flight calls that I would otherwise detect by ear (and visually on spectrographs). Not only is the detection software missing many calls, it's also underestimating the richness that I could get. In one of my best fall nights I more than doubled the species richness by listening through the entire night compared to running it through the software. What's also frustrating is that I get a TON of trash clips - many more than birds clips. I've tried to filter out background noise (which is mostly insects and air conditioning units) before running the file through the auto-detect software, but it doesn't change the results much. I haven't toyed with the other programs that have been mentioned in this threat, but as I understand it, they also don't get near 100% - or am I wrong - it sounds like this technology improving quickly. This list serve is giving me new inspiration to hook up the mic this fall and to play around with more settings and programs. I'm eager to see the upcoming manuscript and to hear everyone's thoughts on this subject! Happy listening, Erik Johnson Lafayette, LA ejoh...@lsu.edu -- 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 -- -- 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 -- -- = Christopher T. Tessaglia-Hymes TARU Product Line Manager and Field Applications Engineer Bioacoustics Research Program, Cornell Lab of Ornithology 159 Sapsucker Woods Road, Ithaca, New York 14850 Voice: 607-254-2418, FAX: 607-254-2460 http://www.birds.cornell.edu/brp mailto:c...@cornell.edu = -- 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?
No software we have worked with gets near 100%. I have toyed around with templates that got 95% of the calls, and detectors can get ~90%, but more commonly get in the 60-80% range. In Louisiana with the insects it would be on the low end of this. Katydids and such are problematic for detectors... Best, Mike Sent from my iPhone On Aug 21, 2009, at 7:43 PM, Erik Johnson wrote: Hi All, I've been recording from my home in south Louisiana with set-ups like Chris and David over the last few years. I've been using the oldbird software (tseep, etc), but only get about 20% of the flight calls that I would otherwise detect by ear (and visually on spectrographs). Not only is the detection software missing many calls, it's also underestimating the richness that I could get. In one of my best fall nights I more than doubled the species richness by listening through the entire night compared to running it through the software. What's also frustrating is that I get a TON of trash clips - many more than birds clips. I've tried to filter out background noise (which is mostly insects and air conditioning units) before running the file through the auto-detect software, but it doesn't change the results much. I haven't toyed with the other programs that have been mentioned in this threat, but as I understand it, they also don't get near 100% - or am I wrong - it sounds like this technology improving quickly. This list serve is giving me new inspiration to hook up the mic this fall and to play around with more settings and programs. I'm eager to see the upcoming manuscript and to hear everyone's thoughts on this subject! Happy listening, Erik Johnson Lafayette, LA ejoh...@lsu.edu -- 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 -- -- 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?
Hi All, I've been recording from my home in south Louisiana with set-ups like Chris and David over the last few years. I've been using the oldbird software (tseep, etc), but only get about 20% of the flight calls that I would otherwise detect by ear (and visually on spectrographs). Not only is the detection software missing many calls, it's also underestimating the richness that I could get. In one of my best fall nights I more than doubled the species richness by listening through the entire night compared to running it through the software. What's also frustrating is that I get a TON of trash clips - many more than birds clips. I've tried to filter out background noise (which is mostly insects and air conditioning units) before running the file through the auto-detect software, but it doesn't change the results much. I haven't toyed with the other programs that have been mentioned in this threat, but as I understand it, they also don't get near 100% - or am I wrong - it sounds like this technology improving quickly. This list serve is giving me new inspiration to hook up the mic this fall and to play around with more settings and programs. I'm eager to see the upcoming manuscript and to hear everyone's thoughts on this subject! Happy listening, Erik Johnson Lafayette, LA ejoh...@lsu.edu -- 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?
Hi All, I will post some specifics when I am looking at the data, but we did run comparisons between XBAT, Raven, and Tseep. Breifly, first step was to benchmark Bill's software. Then we ran detectors in XBAT and Raven using 140 different setting to look at site based and detector based variables that impact accuracy and efficiency, and which parameters are most important, i.e., which variables (site, weather, insects, etc.) influenced the behavior of the detector settings (SNR, Occ, Sep, etc) the most. We now are prepareing a manuscript that describes in detail the results from this work. It is not totally straightforward as depending on your site and what your doing with the data, different detector settings may work better or worse for you. Generally accuracy and efficiency are inversly related to each other, so picking a setting that is midline may be best for most, but not all. In any case it was a ton of work that Emma, Lewis, Amy and I have been trying hard to get "out the door" as quickly as possible. More soon! Talk to you all soon, 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 Fri, Aug 21, 2009 at 5:51 PM, Andrew Farnsworth < andrew.farnswo...@gmail.com> wrote: > Hi all, > There is much fodder for discussion here, but I'll need to keep this > brief - if I can, I'll reply at length to all the additional questions > that Chris posed in a previous email in this vein, but it probably > won't be until later in the weekend. > > David, I am pleased to hear that you are using the SongMeter. Cornell > has been working with Ian to develop a next generation "SongMeter" > unit, called the SoundCache, which we are now using. It's a wonderful > device, and it has many useful features as you mentioned. If any of > you are using these, Mike, Anne, and I may be able to provide some > useful suggestions about how to program the units, battery life, > storage space, etc. I won't bore all of you with that now, but if > there is interest, we can provide info! > > Re:detectors - there is precious little information available on the > full range of behavior of the energy detectors available to us, but I > know for certain that Powdermill Avian Research Center (Mike, Emma, > Lewis, do you want to chime in here?) has worked recently on > evaluating Raven, XBAT, and Oldbird-style detectors. Cornell has done > some work on this as well. Some of these results have been presented > at professional societies and my hope is that there will be a > forthcoming manuscript or two on exactly this topic. There are > differences among these different detectors, though that's a more time > consuming email better saved for later. > > More on this thread later - no doubt others will chime in as well! > > Best, > Andrew > > On Fri, Aug 21, 2009 at 17:28, David Martin wrote: > > I'm going to be very interested in other's responses to Chris' questions. > > > > This is my third fall recording NFCs. For the last two I was doing it > at > > home, feeding the mic input to my home computer and recording with Easy > Hi-Q > > Recorder. > > > > This year I added a second mic at a nature center. There is no power at > > the site, and I needed standalone recorder. Rather than kludge something > > together I bought a SongMeter SM1-M (wildlifeacoustics.com). Kind of > > pricey, but every other approach I could think of added up to the same > cost > > or more. You can set the SongMeter to record on whatever schedule you > want. > > It saves the data to an SDHC card. It provides power to the mic. > > > > The mic is based on Bill Evan's flowerpot design using the Knowles > element, > > but I put it on a government surplus mast to get it above some of the > insect > > noise. > > > > I've been using Bill Evan's tools Tseep-x and Thrush-x along with > GlassOFire > > to sort the data. I've been working in an unsystematic way to > > estimate how well Tseep-x and Thrush-x work. It's obvious that they > miss a > > lot sounds, but by far most of them are too faint for me to be confident > of > > the identity of the caller, anyway. > > > > I just got Raven 1.3 and I'm thinking of running some comparisons with > > Bill's tools. Has anyone done that? > > > > My biggest problem at home is katydid calls. I can sort through them > pretty > > fast using Glassofire, but it is a pain. > > > > David Martin > > http://naturebits.org > > > > > > > > > > -- > > 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 > > -- > > > > -- > 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 > -- > -- NFC-L List Info: http://www.NortheastBirding.com/NFC_
Re: [nfc-l] NFC Detectors and Equipment?
Hi all, There is much fodder for discussion here, but I'll need to keep this brief - if I can, I'll reply at length to all the additional questions that Chris posed in a previous email in this vein, but it probably won't be until later in the weekend. David, I am pleased to hear that you are using the SongMeter. Cornell has been working with Ian to develop a next generation "SongMeter" unit, called the SoundCache, which we are now using. It's a wonderful device, and it has many useful features as you mentioned. If any of you are using these, Mike, Anne, and I may be able to provide some useful suggestions about how to program the units, battery life, storage space, etc. I won't bore all of you with that now, but if there is interest, we can provide info! Re:detectors - there is precious little information available on the full range of behavior of the energy detectors available to us, but I know for certain that Powdermill Avian Research Center (Mike, Emma, Lewis, do you want to chime in here?) has worked recently on evaluating Raven, XBAT, and Oldbird-style detectors. Cornell has done some work on this as well. Some of these results have been presented at professional societies and my hope is that there will be a forthcoming manuscript or two on exactly this topic. There are differences among these different detectors, though that's a more time consuming email better saved for later. More on this thread later - no doubt others will chime in as well! Best, Andrew On Fri, Aug 21, 2009 at 17:28, David Martin wrote: > I'm going to be very interested in other's responses to Chris' questions. > > This is my third fall recording NFCs. For the last two I was doing it at > home, feeding the mic input to my home computer and recording with Easy Hi-Q > Recorder. > > This year I added a second mic at a nature center. There is no power at > the site, and I needed standalone recorder. Rather than kludge something > together I bought a SongMeter SM1-M (wildlifeacoustics.com). Kind of > pricey, but every other approach I could think of added up to the same cost > or more. You can set the SongMeter to record on whatever schedule you want. > It saves the data to an SDHC card. It provides power to the mic. > > The mic is based on Bill Evan's flowerpot design using the Knowles element, > but I put it on a government surplus mast to get it above some of the insect > noise. > > I've been using Bill Evan's tools Tseep-x and Thrush-x along with GlassOFire > to sort the data. I've been working in an unsystematic way to > estimate how well Tseep-x and Thrush-x work. It's obvious that they miss a > lot sounds, but by far most of them are too faint for me to be confident of > the identity of the caller, anyway. > > I just got Raven 1.3 and I'm thinking of running some comparisons with > Bill's tools. Has anyone done that? > > My biggest problem at home is katydid calls. I can sort through them pretty > fast using Glassofire, but it is a pain. > > David Martin > http://naturebits.org > > > > > -- > 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 > -- > -- 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 --
[nfc-l] NFC Detectors and Equipment?
I'm going to be very interested in other's responses to Chris' questions. This is my third fall recording NFCs. For the last two I was doing it at home, feeding the mic input to my home computer and recording with Easy Hi-Q Recorder. This year I added a second mic at a nature center. There is no power at the site, and I needed standalone recorder. Rather than kludge something together I bought a SongMeter SM1-M (wildlifeacoustics.com). Kind of pricey, but every other approach I could think of added up to the same cost or more. You can set the SongMeter to record on whatever schedule you want. It saves the data to an SDHC card. It provides power to the mic. The mic is based on Bill Evan's flowerpot design using the Knowles element, but I put it on a government surplus mast to get it above some of the insect noise. I've been using Bill Evan's tools Tseep-x and Thrush-x along with GlassOFire to sort the data. I've been working in an unsystematic way to estimate how well Tseep-x and Thrush-x work. It's obvious that they miss a lot sounds, but by far most of them are too faint for me to be confident of the identity of the caller, anyway. I just got Raven 1.3 and I'm thinking of running some comparisons with Bill's tools. Has anyone done that? My biggest problem at home is katydid calls. I can sort through them pretty fast using Glassofire, but it is a pain. David Martin http://naturebits.org -- 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?
If you feel so inclined, please respond to the list as there's at least more than one of us with many of these same questions. Thanks again. Colby On Fri, Aug 21, 2009 at 11:09 AM, Chris Tessaglia-Hymes wrote: > 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 night from multiple > stations, or you want to really quantify most or all of the calls that > night, the question of data storage and data processing becomes the big > issues. > > How do some of you out there collect your sound data? > > What tools do you use for browsing sounds? > > Do you only use detectors? > > Here's a question for probably three people on this list: > > What is the difference between the current Raven Pro detector that Mike > Powers provided settings for and the old BirdCast transient detector? Is > there a difference? > > Getting back to an earlier posting from Tom Fowler (prior to the bloom in > membership...140+ now!), what kind of equipment do you each use for > recording or listening to your sounds? > > I mentioned that I use a variation on the Bill Evans-style flowerpot > microphone. I know that Andrew Farnsworth and Mike Powers use a microphone, > pre-amp, and housing designed by engineers at Bioacoustics at the Cornell > Lab of Ornithology, storing their night sounds on flash memory inside a > SoundCache for analysis later, but what do others use? > > What are your personal home recording setups like? > > What obstacles or limitations have you encountered with your equipment > setups or recordings? > > I realize these are a lot of questions, but I wanted to pose these to the > list in order to help initiate discussion along these lines. > > Information about Bill Evans's flowerpot design can be found here: > http://www.oldbird.org/ (click on Microphone Design in the left panel) > > Information about the Raven software can be found here: > http://www.birds.cornell.edu/brp/raven/RavenOverview.html > > Another sound analysis software tool, Syrinx, can be found here: > http://syrinxpc.com/ > > Thanks and good night listening! > > Sincerely, > Chris T-H > > -- > Chris Tessaglia-Hymes > Listowner, NFC-L > Ithaca, New York > c...@cornell.edu > http://www.NortheastBirding.com/NFC_WELCOME > http://www.NortheastBirding.com/NFC_RULES > > > -- > 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 > -- > -- 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 --
[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 night from multiple stations, or you want to really quantify most or all of the calls that night, the question of data storage and data processing becomes the big issues. How do some of you out there collect your sound data? What tools do you use for browsing sounds? Do you only use detectors? Here's a question for probably three people on this list: What is the difference between the current Raven Pro detector that Mike Powers provided settings for and the old BirdCast transient detector? Is there a difference? Getting back to an earlier posting from Tom Fowler (prior to the bloom in membership...140+ now!), what kind of equipment do you each use for recording or listening to your sounds? I mentioned that I use a variation on the Bill Evans-style flowerpot microphone. I know that Andrew Farnsworth and Mike Powers use a microphone, pre-amp, and housing designed by engineers at Bioacoustics at the Cornell Lab of Ornithology, storing their night sounds on flash memory inside a SoundCache for analysis later, but what do others use? What are your personal home recording setups like? What obstacles or limitations have you encountered with your equipment setups or recordings? I realize these are a lot of questions, but I wanted to pose these to the list in order to help initiate discussion along these lines. Information about Bill Evans's flowerpot design can be found here: http://www.oldbird.org/ (click on Microphone Design in the left panel) Information about the Raven software can be found here: http://www.birds.cornell.edu/brp/raven/RavenOverview.html Another sound analysis software tool, Syrinx, can be found here: http://syrinxpc.com/ Thanks and good night listening! Sincerely, Chris T-H -- Chris Tessaglia-Hymes Listowner, NFC-L Ithaca, New York c...@cornell.edu http://www.NortheastBirding.com/NFC_WELCOME http://www.NortheastBirding.com/NFC_RULES -- 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 --
