A firework bursts over a parking lot, and five people film it on their phones from different spots. Every soundtrack contains the bang. If you know where each phone was, can the audio tell you where the firework exploded? The same question applies to a gunshot or an explosion, and it is the problem we built an open-source tool to work on.

Often the audio can answer it. But in one common situation, when the phones’ clocks disagree, no algorithm can, however clever, and a little counting shows why. To see where that limit comes from, it helps to start with how the location is found when everything goes right.

Arrival time differences point to the source

Sound travels at about 343 meters per second, so each millisecond of delay means about 34 centimeters of extra distance. A phone closer to the burst hears it slightly earlier than a phone farther away.

You don’t know exactly when the firework exploded, so one phone’s arrival time tells you little by itself. The difference between two phones’ arrival times is what helps. If phone A heard the bang 10 ms before phone B, the firework was about 3.4 meters closer to A than to B. The points that fit that description form a curve called a hyperbola. Each pair of phones gives one such curve, and the firework is where the curves cross.

Animation of four microphones on a 20-meter square. A circular wavefront reaches each microphone at a different time. Each pair's time difference traces a curve, and the estimate is shown with a 95% confidence ellipse.
Four microphones on a 20 m square. The sound reaches each microphone at a different time, each pair's time difference limits the source to one curve, and the solver finds the point that fits every curve best. Every frame comes from the same code the tests run.

Our tool, the Acoustic Event Locator, takes the recordings and each device’s position. It finds the start of the bang in each recording, sharpens those times by comparing the recordings against each other, and finds the position that best fits all the timing differences. Instead of a single point, it reports a 95% confidence ellipse, an area sized to contain the true position 95% of the time.

The repository includes synthetic test scenes, computer-generated recordings in which the true source position is known exactly. Among them are a gunshot at an intersection, a firework bursting 25 m up, and a shot from a 9 m-high window. With exactly known phone positions and recordings that share a clock, the locator finds the source to within a few centimeters in each.

Every phone has its own clock

Those centimeter results depend on the recordings sharing a clock, and phones in five different people’s hands do not. A phone starts recording when someone presses a button, so one video might start two seconds before the bang and another eleven seconds before. Nothing in the audio says how far apart the clocks are.

To see why that is fatal for a single bang, count what you know against what you don’t. Each recording gives one measurement, the moment that phone heard the bang by its own clock. Each recording also brings one unknown, how far that phone’s clock is off. On top of those, you don’t know where the firework was or when it exploded. A new phone adds one measurement and one unknown, so the unknowns always outnumber the measurements.

In practice, you can pick any location for the firework, even one a kilometer away, and choose a clock error for each phone that makes its recording match that location exactly. Every location fits perfectly, so the recordings cannot single out the true one.

A single event cannot both locate its source and synchronize recordings whose clocks disagree. This follows from the counting, so better software would not change it.

What helps with the clock problem

The counting assumes a single bang and clocks that could be off by any amount. When either assumption fails, the clock problem shrinks or disappears:

  • If the devices keep the same time, for instance through GPS or network time, or because one recorder captures every microphone, there are no clock errors to solve. The centimeter-level results apply to this case.
  • If the clocks agree to within a known few milliseconds, the locator can use that range as an assumption. On a 20 m array, a 2 ms clock uncertainty costs about a meter of accuracy, and the reported ellipse grows to show it.
  • If there are several events, such as a fireworks show or a series of shots, the count changes. Each new event gives a measurement from every phone but adds only its own position and time, while the clock errors stay the same. With enough phones and events, the clock errors could in principle be solved. This is on the roadmap. The current tool handles one event at a time.

When none of these apply, the locator says it cannot find the source instead of guessing. It still reports the time shift that lines up every recording on the bang, so the videos can at least be played in sync.

Buildings, straight lines and distance

Even with shared clocks, real places add other complications. The locator handles three of them in ways worth knowing: buildings in the way, phones standing in a line, and a source far from all of them.

A building can delay a sound but never make it arrive early. When a building blocks the direct path, the sound bends around it or bounces off a wall and arrives late. The locator uses that one-sided rule. It explains late arrivals as detours and reports the extra distance each one implies, so someone with a map can check it. Impossibly early arrivals are treated as mistakes in finding the bang.

Animation of an urban scene with seven cameras, three of them behind buildings. The late arrivals at the blocked cameras are highlighted as detours, and the estimate lands on the true source.
Seven cameras, three of them behind buildings. The locator identifies the late arrivals (purple) as detours instead of averaging them in, and bases the position on the cameras with a clear line of sight.

Cameras in a straight line can’t tell which side the sound came from, because a source and its mirror image across the line produce the same arrival times. The locator reports both positions and flags the result as ambiguous.

For a faraway source, direction stays accurate while distance gets vague. With the source 100 m from a 20 m array of microphones, the median error across six trials was 11 cm, but the 95% ellipse reached 45 m from the estimate along its long axis. Spreading the microphones over a wider area fixes that. A better algorithm does not.

Tested only on synthetic recordings

One caveat applies to everything above. Every result here comes from synthetic recordings with exactly known microphone positions, in which each microphone hears the same sound apart from added noise and echoes. Real phones add GPS position error, clipping, automatic volume adjustment, directional microphones and reverberation, all of which blur the timing. The locator has not yet been tested on real recordings.

The code, test scenes and animations are in the Acoustic Event Locator repository, released under the MIT License.