Analyzing bat recordings - overview

 
 
 

The recordings made by CBDISK are quite large (about 200 megabytes for 5 minutes) and often contain thousands of calls.  To minimize the time required to actually analyze those sounds (and to minimize the amount of direct input required) I have used a variety of software programs to automatically extract and analyze the calls recorded using CBDISK.  I have also written programs to convert the inaudible sounds produced by the bats into a form that humans can hear (similar to the technique used by many bat detectors).

The extraction process takes several steps, summarized in this flowchart:

 
  1. The original sound file is produced by CBDISK

  2. The sound is converted to an audible WAV file. Any comments made during the recording are transcribed.

  3. Various comments about the recording are stored directly in the CBDISK sound file header (including any comments from step 2).

  4. The modified and original sound files and the WAV file are stored on DVD's for long-term storage.

  5. Specialized software is used to extract individual echolocation calls from the sound file (see the section on call extraction for more information)

  6. The individual calls are analyzed to measure variables that describe them (see the page on call analysis for more information on how this works).

For each of these steps, I have provided further information on how it works below...

 
 
 

Initial recording

 
 
 
Bat sonar sounds are generally outside the range of human hearing, so the process of recording them is a little more complicated than with other sounds.  The basic technique is pretty similar to the methods you would use to record the sounds of any animal...

  1. The bat makes sounds that are picked up by a microphone
  2. The microphone is connected to a computer that converts the sounds into a digital format for recording
  3. The recordings are analyzed using various programs that are able to extract information from those calls


The recording programs save the files as continuous sequences, often several minutes in length.  In the image shown above shows 11 calls (they show up as the lighter curved lines at various spots on the screen).  In a full recording, it is not difficult to get a single file that contains thousands of calls in it.  There are often far too many to manually go in and find them all, so we need an automated method to allow us to get access to the individual calls.  What does an individual call look like if we zoom in on just one of them?

 
 
 

Extracting calls

 
 
 

Once we get the sound onto the computer, the programs can make pictures of those sounds called "sonograms".  This sonogram shows a typical E. fuscus sonar call recorded in the laboratory.  The color of the figure tells you how loud the sound was at a given time and frequency.  Dark red is very loud, while blue and green are very soft.

There are a number of characteristics to note about this call:

  1. It is very short - this example is about 1.5 milliseconds long.
  2. The call has very high frequencies.  Human hearing goes up to about 20 kiloHertz, while this call reaches up to almost 150 kHz!
  3. The call contains four harmonics, shown by the four separate orange-red bands

Unfortunately, this call looks very different from the entire sequence shown above, and so the goal is to figure out a way to get a continuous recording containing multiple calls and break it into chunks corresponding to individual calls.

Once you record a sequence of calls from a bat, you now have to do something with those calls.  The problem with real-time recording systems is that they produce files that are quite large, so you need to break the files down into smaller pieces so that they can be analyzed more easily. 

Below  is a two-second sequence of calls recorded from a big brown bat (E. fuscus).   


The calls are clearly visible on the screen, but the time to manually select and save each of these calls would be prohibitive.  I use computer programs that detect the increases in amplitude (visible in the top part of the graph) to determine where a call has been recorded.  It then takes that segment of the file, copies all the information until the sound level drops back below the ambient level, and saves that information to a new file.  That information will correspond to an individual call.  Here's an illustration showing where the software would separate the calls:


You can see that 10 different calls will be extracted from this segment.  Below is an illustration of call #2:

Each of these calls is saved into its own file with a unique name, along with the time that the call occurred relative to the beginning of the entire recording.  After extraction, I can have the computer analyze the calls and save those data.  What sorts of analyses are carried out on these calls?.

 
 
 

Measuring call variables

 
 
 

Displaying the call is helpful, but the analysis programs do a lot more than just showing pictures of the sounds. A number of variables are measured by examining various aspects of the calls. There are a number of problems that we encounter when trying to analyze bat sounds.  The first is the simple fact that we can't hear them, so we're stuck with having to use the computer.  The second (and more important) is that it is very easy to get thousands of calls in just a few minutes of recording, which means you have a major analysis problem to deal with.  To get around this, I'm using a system to analyze calls that the OSU batlab developed while I was there.  This system automatically analyzes extracted bat recordings so that we can gather information on thousands of calls in a very short time.  The third and final problem has to do with the presence of other sounds in the environment.  As you can see in the image below, this extracted call is not a bat call (it's probably wind noise).


This was extracted because the extraction routine only looks at the amplitude of the signal, without paying attention to whether or not it's a bat call.  We wrote a number of routines to eliminate those calls and keep them from being analyzed by mistake.

Sometimes problems crop up even when the sound actually came from a bat.  In the figure below, you can see two overlapping bat echolocation calls.


In this case, we also wrote the analysis routines to ignore these calls, because the measurements would be incorrect, since it would be measuring multiple calls as a single one.  This isn't something we had to do - as long as the calls don't overlap, it is possible to analyze them separately, so I'm hoping to get that working some time soon so that I don't have to throw out as many calls as I currently do.

When a call is judged acceptable by the program (and there are other reasons they can be excluded as well as the two reasons listed above) the program measures a number of time, frequency, and amplitude variables describing the call.  It also fits a curve to the call shape to describe the shape of the call mathematically.  The image below shows some of the measurements.


Once you have these measurements, there are a number of analyses you can conduct on the data.  The advantage of getting thousands of calls in one night of recording is that I don't have a shortage of calls, but it also means I am sometimes drowning in a sea of data.  Research on these data typically depends on statistical analyses to determine what the results mean and what we can learn from them.  Past research has shown that we can use the call variables to tell one bat from another, to tell males from females, and to differentiate between species. Further studies examining playback of calls have shown that the bats are able to tell individuals and males from females just by the sound of calls as well.  We're a long way from understanding HOW the bats do this, but it's pretty amazing that we've even been able to figure that much out.

 
 
 
 
 
 
 
 
 
 
This website requires Internet Explorer 8 and higher.
Please update to the newest version.