Bioacoustic Monitoring: Detecting Wildlife From Continuous Audio

A passive acoustic monitoring programme is usually planned around the ecology and then surprised by the data volume. The volume is calculable before a single recorder is deployed, and the calculation changes the study design, so it is worth doing first.

Bytes per day, from first principles

Everything follows from three numbers you choose: sample rate, bit depth and channel count. There is no compression in the base case and no per-file overhead worth modelling.

Assumptions (state yours; these are the ones used below):
  sample rate  48,000 Hz
  bit depth    16 bit  = 2 bytes
  channels     1 (mono)
  recording    continuous, 24 h

Bytes per second = 48,000 * 2 * 1              =     96,000 B/s
Bytes per day    = 96,000 * 86,400             = 8,294,400,000 B
                                               =       8.29 GB/day
Bytes per 90-day season = 8.29 * 90            =     746.5 GB

One recorder. One season. Uncompressed.

Two adjustments move that number a lot. Recording in stereo doubles it. Recording at 96 kHz — necessary for bats, and for many insects — doubles it again, so a stereo ultrasonic deployment is 33.2 GB/day and 2.99 TB per season per unit. Conversely, a survey targeting large mammals or anurans may be fine at 16 kHz, which is 2.76 GB/day.

The recorder’s own limits interact with these figures and are frequently what actually decides the schedule. Card capacity sets a hard visit interval: at 8.29 GB/day, a 256 GB card fills in 30.9 days continuous or 154 days at a 20% duty cycle, and a field site that can only be reached monthly therefore cannot record continuously at 48 kHz regardless of budget. Battery draw scales with recording time rather than storage, but not linearly, because the unit’s idle draw continues between windows — a schedule that halves recording time does not halve battery life. Work out which of card capacity, battery and visit interval binds first; optimising the other two is wasted.

Lossless compression is close to free and should be the default. FLAC on natural soundscape material typically lands somewhere in the 40–60% range of the original size depending on how much of the band is quiet; taking 55% as an explicit assumption, the continuous 90-day figure becomes 746.5 × 0.55 ≈ 410 GB. Lossy compression is a different matter and should be approached carefully: a codec tuned for speech or music discards exactly the low-energy high-frequency detail that a faint distant call consists of, and it also introduces artefacts that a classifier may key on.

What duty cycling actually costs you

The standard mitigation is to record on a schedule — one minute in five is common. The arithmetic is linear:

Duty cycle 1 min in 5  =  20% of wall-clock time

Audio per day    = 86,400 * 0.20            =  17,280 s
Bytes per day    = 8.29 GB * 0.20           =   1.66 GB/day
Per 90-day season                           = 149.3 GB
After FLAC at an assumed 55%                =  82.1 GB

Twenty recorders, one season, compressed    =   1.64 TB

What that buys in storage it spends in statistics, and the spend is not uniform. For a common, frequently vocalising species, a 20% sample gives you roughly a 20% sample of its calls and your occupancy estimates barely move. For a species that vocalises a handful of times per night, the probability of catching any given call is 0.2, so the probability of catching none of five calls is 0.8⁵ = 0.328 — a one-in-three chance of recording the species as absent from a night when it was present. Duty cycling systematically biases against rare and infrequent vocalisers, which are usually the ones the study is about.

Compute for a season

Classification cost scales with audio duration and segment length. The BirdNET-Analyzer documentation gives 0.826 GFLOPs per three-second segment for the V2.4 model, which is enough to bound the work:

Continuous, one recorder, 90 days:
  audio seconds  = 86,400 * 90                = 7,776,000 s
  segments (3 s) = 7,776,000 / 3              = 2,592,000
  FLOPs          = 2,592,000 * 0.826 GFLOP    =     2.14 PFLOP

At 20% duty cycle:
  audio seconds  = 1,555,200 s
  segments       =   518,400
  FLOPs          =   428 TFLOP

Wall clock, at an ASSUMED 20x real-time on one CPU core:
  continuous  = 7,776,000 / 20 = 388,800 s = 4.5 core-days
  duty-cycled = 1,555,200 / 20 =  77,760 s = 0.9 core-days

The 20× real-time factor is an assumption and the single number in this page you should replace with your own measurement — it depends on the core, the runtime, the batch size and whether the segments overlap. Halving it doubles the wall clock. Overlapping segments with a one-second hop rather than a three-second one triples the segment count, and therefore triples both the FLOPs and the time.

What the numbers establish regardless of the assumption is the shape: 2.14 PFLOP is a trivial amount of arithmetic by modern standards. A single consumer GPU does that in minutes. Inference is not the bottleneck in this work and optimising it is usually misdirected effort.

What dominates the budget

Put the three costs side by side using labelled unit-price assumptions, because there is no public price list that covers this and the point is the ratio, not the total.

Twenty recorders, one 90-day season, 20% duty cycle,
FLAC-compressed: 20 * 82.1 GB = 1,642 GB.

Storage, at an ASSUMED $0.02 per GB-month object storage:
  1,642 GB * $0.02 * 12 months    =  $394 / year, growing
                                     by that much every season

Compute, at an ASSUMED $0.05 per core-hour:
  20 * 0.9 core-days * 24 h * $0.05 =  $21.60 per season

Human verification, at an ASSUMED 1,500 detections above
threshold per recorder-season, 15 s each to review, and a
person-hour costed at $30:
  20 * 1,500 * 15 s = 450,000 s = 125 h * $30 = $3,750

Every dollar figure above is an assumption stated in the line that uses it, and none of them is a quoted price. The ratio is the finding: verification costs roughly ten times storage and roughly 170 times compute. That ordering is robust to fairly large changes in any of the assumed rates, and it is the opposite of where most project plans put their attention.

What the arithmetic changes

• Raise the threshold before you raise the budget. Verification cost is linear in detections above threshold, so the confidence threshold is a direct financial lever — and, since precision rises with it, one that improves data quality while reducing cost. The trade is recall, which you must estimate separately; see verifying a bird detection.
• Sample the verification, do not census it. A stratified random sample of a few hundred detections per species per site gives you a precision estimate with an interval. Reviewing all 1,500 gives you a slightly better estimate for eight times the money.
• Run the classifier on the device where you can. The compute is negligible; the storage and the field visit to swap SD cards are not. A recorder that stores detections plus short audio clips around them, rather than continuous audio, changes the storage line by an order of magnitude — at the price of being unable to re-analyse the season with a better model next year, which is a real loss and frequently the deciding argument for keeping the raw audio.
• Budget for the archive, not the season. Storage is recurring and cumulative; a five-year programme at twenty recorders is storing every season it has ever recorded. That is the line that grows without anyone deciding it should.