Beautiful, Tim! This helps a lot. All the Best, Eric
________________________________ From: Tim Krein <[email protected]> To: [email protected] 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 > > > > > > > > ________________________________ From: Chris Tessaglia-Hymes <[email protected]> >To: [email protected] >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 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 >[email protected] >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/[email protected]/maillist.html >-- > > -- NFC-L List Info: http://www.NortheastBirding.com/NFC_WELCOME http://www.NortheastBirding.com/NFC_RULES http://www.mail-archive.com/[email protected]/maillist.html --
