Geolocation by aeroplane sound Doppler shift
- Thread starter GM4AJK
- Start date
It's a cool "I wish I had thought of that" idea. And I think it would be pretty easy for an AI agent to implement once the idea is described. I'll let it have a bash at putting it in Sitrec.That last comment, "No code or tools are being released"... sounds very much like a challenge
GM4AJK
Senior Member.
That would be interesting and useful.
Additionally, remember all those "New Jersey Drone" videos? Well, using this technique would probably allow for much better evidence, when matched with the flight, that it's actually a plane, as it's said to be.
Kyle Ferriter
Senior Member.
This just showed up on my feed and I went to Metabunk immediately to see if there was already a discussion.
NorCal Dave
Senior Member.
I sat down with my cocktail after seeing this earlier to day out in the shop and was going to share it. I thought I was going to be so clever. Of course Mick already has a version in development.
RobertBillyBob
Senior Member.
This could be used for stalking purposes, maybe you should restrict the access if you put it in Sitrec.
Attached is the AI's discussion of how the Sitrec implementation of colsto's idea works.
Codex GPT-6-Astra Ultra, used about 20% of a week's tokens, so it nominally cost $10.
Its time breakdown
Session time breakdown
Recorded work spans approximately 8 hours 2 minutes, from 15:40 to 23:42 PST on November 2, through completion of the illustrated guide. This includes pauses and overlapping work; it is not continuous computation.
Approximate elapsed time by phase
Measured long-running jobs
These main jobs total approximately 89 minutes. Additional recorded preparation, validation, and a stopped baseline run account for roughly another 11 minutes. This is an incomplete inventory, and some jobs overlapped other work.
Main avoidable detours
Builds generally took only 3–4 seconds. I cannot reliably divide the remaining elapsed time into coding, reasoning, user interaction, and idle time.
Codex GPT-6-Astra Ultra, used about 20% of a week's tokens, so it nominally cost $10.
Its time breakdown
Session time breakdown
Recorded work spans approximately 8 hours 2 minutes, from 15:40 to 23:42 PST on November 2, through completion of the illustrated guide. This includes pauses and overlapping work; it is not continuous computation.
Approximate elapsed time by phase
- 15:40–16:45 — 1h 05m: Studying the source material, obtaining data, and developing the initial addon and spectrogram.
- 16:45–18:12 — 1h 27m: Archive searches, audio measurements, and initial location attempts.
- 18:12–22:34 — 4h 22m: Multiple-agent review, accuracy investigation, browser delays, and testing.
- 22:34–23:22 — 48m: Correcting the brightness scoring, optimizing performance, completing the successful countrywide search, and producing output images and the infographic.
- 23:22–23:42 — 20m: Committing the implementation and private records, creating the illustrated guide, and interaction gaps.
Measured long-running jobs
- Original coarse search: 15m 15s
- Corrected coarse search and terrain refinement: 18m 24s
- Browser single-flyover search: 9m 36s
- Countrywide run before a cache-related crash: about 5m
- Final successful countrywide search: 10m 07s
- Full test suite: 31m 01s
These main jobs total approximately 89 minutes. Additional recorded preparation, validation, and a stopped baseline run account for roughly another 11 minutes. This is an incomplete inventory, and some jobs overlapped other work.
Main avoidable detours
- Initially optimizing trace error instead of spectrogram brightness.
- A manually measured trace following interference.
- Measurement bounds that were too restrictive.
- A cache-key collision that forced a search restart.
Builds generally took only 3–4 seconds. I cannot reliably divide the remaining elapsed time into coding, reasoning, user interaction, and idle time.
Yeah, it's Admin only right now (i.e. just me). I
Of course, if I can implement it, then other people can too.
GM4AJK
Senior Member.
The cat is out of the bag. Restricting stuff now is pointless.
jarlrmai
Senior Member.
So what are the practical requirements for this?
The audio has to be fairly clean and obviously the original audio track (although it not matching given details would be a tell that the audio was replaced.)
You have to know the date and a fairly broad approx location, I guess the more data you have to narrow the parameters the quicker it is to run? In his example he has the whole of the USA, but if you knew it was say New Jersey it might be a quicker process.
Also is the reverse possible, knowing the location and the approximate date (say within 30 days) but using the flight data over a longer period to narrow down a day and time?
A lot of cases will have approx location and approx date.
The audio has to be fairly clean and obviously the original audio track (although it not matching given details would be a tell that the audio was replaced.)
You have to know the date and a fairly broad approx location, I guess the more data you have to narrow the parameters the quicker it is to run? In his example he has the whole of the USA, but if you knew it was say New Jersey it might be a quicker process.
Also is the reverse possible, knowing the location and the approximate date (say within 30 days) but using the flight data over a longer period to narrow down a day and time?
A lot of cases will have approx location and approx date.
This discussion reminds me of something I remember reading about it being possible to find the time of recordings by matching fluctuations in the mains electricity "hum". I'm sure it's been used in court to prove the date and time of video or audio recordings. Let me search...
This article is from 2012, so it's not a new thing:
https://www.bbc.co.uk/news/science-environment-20629671
Combining the two could be quite a powerful geolocation tool.
This article is from 2012, so it's not a new thing:
https://www.bbc.co.uk/news/science-environment-20629671
Looks like there is an open source tool that uses ENF, but I haven't got time now to dig into it.External Quote:
Combining the two could be quite a powerful geolocation tool.
GM4AJK
Senior Member.
Four years ago, Tom Scott did a video about extracting the date and time of an audio recording based on variations in the mains "hum" in the background.
External Quote:
GM4AJK
Senior Member.
I see we cross-posted there
GM4AJK
Senior Member.
Yeah, it would just take more processing time to search a wider data set. You probably get more false positives.
Mauro
Senior Member.
IIrc I read about a similar technique years ago, in Science or Nature. I can't remember exactly but it was called something like "acoustic light vision", background sounds being paralled to background illumination in normal sight. But I can find no pertinent references searching for 'acoustic light'.
Impressive job @Mick West !
Impressive job @Mick West !
Impressive job ChatGPT. I just steered it a bit. It's a sad and wonderful time to be a programmer.
RobertBillyBob
Senior Member.
It's not that difficult to copy it, but any hurdle added lessen the amount of time it'll get abused. And you don't want Sitrec being cited in the news as the tool used by a killer to locate his victim.
GM4AJK
Senior Member.
Surely we have already identified New Jersey drones right here on MB as test cases?
Security by obscurity. There will likely be a ton of tools to do this by the end of next week. The best @Mick West can do is hold off on releasing it in Sitrec for a while.
jarlrmai
Senior Member.
Are you wanting real cases?
The Cody ones would be good
https://www.metabunk.org/threads/wyoming-mystery-orbs.15112/post-376754
This sign location was really confusing
Dave51c
Senior Member
There are similar techniques out there. Some fields more esoteric than others I guess.
https://arxiv.org/html/2505.18726v1
The aircraft doppler work is very interesting. I use a spectrograph based app 'Merlin' which captures real-time audio and pattern matches bird song for species ID. I've observed airborne doppler signals but nothing that I couldn't hear myself. Will have to look closer!External Quote:
I'm wondering what the compute requirements would be to 'pre-compile', for each day, what all of the predicted flight line doppler signals would be for all points on, say, a country wide 100m grid from all of the ADBS data.
According to Astra, too much. Tens of terabytes per day. But you could cut it down by not precomputing everything.
The arithmetic is feasible; storing a separate predicted curve at every 100 m point is the expensive part. A useful daily index could run on a workstation or server. A literal nationwide library of sampled curves would produce hundreds of terabytes per day, even after excluding distant aircraft.
Assuming the contiguous US, one listener height at each location, and one sample per second:
ADS-B lets us predict a Doppler multiplier and sound-arrival delay. It does not supply the aircraft's actual emitted frequencies, changing engine RPM, or loudness. We could store range and radial velocity instead, allowing sound speed to be adjusted later.
At eight bytes per sample—two 32-bit values—the approximate requirements are:
These exclude indexes and metadata, and assume full circular footprints; clipping at coastlines and borders reduces them. The radius is a coverage choice, not a guaranteed audibility limit.
Taking "all aircraft at all locations" literally gives approximately 2 exabytes per day.
For the 20 km version, storage throughput becomes a major constraint: writing 344 TB every day requires about 4 GB/s continuously, and retaining a year takes 125 PB, before replication.
I ran a small geometry benchmark here: calculating Doppler factors and delays, including writing results into RAM, reached approximately 476 million predictions/s. That suggests roughly 25 single-core hours of bare arithmetic per recorded day for the 20 km case. This excludes track interpolation, terrain access, indexing, compression, and disk writes. Parallel processing could accelerate calculation substantially, but those hundreds of terabytes still need somewhere to go.
Compression helps most when we avoid repeating the same flight geometry.
For illustration, replacing every sampled curve with a 32-byte passage summary would bring the 20 km case to approximately 6.7 TB/day on the 100 m grid. However, such a summary cannot represent arbitrary turns and speed changes exactly; it must reference the original track.
Using those summaries on a 2 km initial grid reduces that estimate to approximately 17 GB/day, followed by precise calculation around promising locations. That is much more practical.
For Sitrec, I would build this:
A 16–32-core machine, 64–128 GB RAM, and fast NVMe storage would be a reasonable prototype configuration for that indexed approach—not a measured production requirement. Processing can be tiled, so RAM need not hold the nationwide output.
The precomputation worth investing in is a searchable index of possible curve shapes, with shared flight tracks underneath it. Merely saving every curve would leave us with an enormous database that still needs to be searched.
Assuming the contiguous US, one listener height at each location, and one sample per second:
- Roughly 765 million grid points, calculated from about 7.65 million km² of land. Census area measurements
- Our downloaded day's retained tracks contain approximately 95,000 aircraft-hours and 52 million kilometres of movement. I calculated these from intervals no longer than 30 seconds, excluding very slow movement. This is a workload estimate from our archive, not a complete national traffic census.
ADS-B lets us predict a Doppler multiplier and sound-arrival delay. It does not supply the aircraft's actual emitted frequencies, changing engine RPM, or loudness. We could store range and radial velocity instead, allowing sound speed to be adjusted later.
At eight bytes per sample—two 32-bit values—the approximate requirements are:
| Aircraft included at each location | Predictions per recorded day | Uncompressed storage/day | Sustained computation to keep up daily |
|---|---|---|---|
| Within 10 km horizontally | 10.7 trillion | 86 TB | 124 million predictions/s |
| Within 20 km | 43 trillion | 344 TB | 497 million/s |
| Within 50 km | 268 trillion | 2.15 PB | 3.1 billion/s |
These exclude indexes and metadata, and assume full circular footprints; clipping at coastlines and borders reduces them. The radius is a coverage choice, not a guaranteed audibility limit.
Taking "all aircraft at all locations" literally gives approximately 2 exabytes per day.
For the 20 km version, storage throughput becomes a major constraint: writing 344 TB every day requires about 4 GB/s continuously, and retaining a year takes 125 PB, before replication.
I ran a small geometry benchmark here: calculating Doppler factors and delays, including writing results into RAM, reached approximately 476 million predictions/s. That suggests roughly 25 single-core hours of bare arithmetic per recorded day for the 20 km case. This excludes track interpolation, terrain access, indexing, compression, and disk writes. Parallel processing could accelerate calculation substantially, but those hundreds of terabytes still need somewhere to go.
Compression helps most when we avoid repeating the same flight geometry.
For illustration, replacing every sampled curve with a 32-byte passage summary would bring the 20 km case to approximately 6.7 TB/day on the 100 m grid. However, such a summary cannot represent arbitrary turns and speed changes exactly; it must reference the original track.
Using those summaries on a 2 km initial grid reduces that estimate to approximately 17 GB/day, followed by precise calculation around promising locations. That is much more practical.
For Sitrec, I would build this:
- Store each flight once, as compact position/velocity segments. Our day's roughly 54 million fixes imply about 2–4 GB of basic arrays, plus indexes and metadata.
- Precompute geographic/time indexes and coarse curve descriptors, so an observed Doppler shape retrieves plausible flights and regions quickly.
- Generate the detailed curves at query time, refining to 100 m or finer only where the audio supports a match.
- Send the shortlist to the lazy-loaded browser addon for fitting, labelled spectrograms, and inspection.
A 16–32-core machine, 64–128 GB RAM, and fast NVMe storage would be a reasonable prototype configuration for that indexed approach—not a measured production requirement. Processing can be tiled, so RAM need not hold the nationwide output.
The precomputation worth investing in is a searchable index of possible curve shapes, with shared flight tracks underneath it. Merely saving every curve would leave us with an enormous database that still needs to be searched.
jarlrmai
Senior Member.
Just gonna play random distant plane sounds on my phone at all times
GM4AJK
Senior Member.
While I understand the idea here is to test the code, I think the test use case is off. For Sitrec, I would expect it to be a video of "something in the sky". If it's a plane, audio would likely be picked up even if the observer didn't hear it. If it's claimed to be a drone, then again, I'd expect audio.
NorCal Dave
Senior Member.
That's the trick right? If there is no aircraft sound,it doesn't work. What about just 1 aircraft, or a helicopter? I'll try some today. If they're test cases, should it include the actual aircraft being recorded on ADSB?
There were planes flying over, and it did record the audio of at least two.
It seems like there's still some work to do with the Sitrec implementation.
I'll get it working better with known time and location data first. Then try some unknown cases. Right now it's failing where it should succeed, so that needs fixing.
Are you just working with the US at the moment or do you want to test it with a UK file?
Dave51c
Senior Member
Well not too bad, relatively. For a local disk array anyway. I suppose the limit would be N previous days that needed to be stored and maybe of a FIFO basis perhaps.
ooh yeah, this sounds good. Or could the curves be generated as spatial layers in a GIS? Pretty sure a normal desktop GIS would fall over at the amount of data, but PostGIS might work at this scale.
I'm sure there is a comp.sci. PhD here for someone
jjwiseman
New Member
I've been working on the same idea (with Claude Code/Opus 5.5), and tested it on two public live webcams with published camera locations (so I'm not doxxing anyone): the Ashland, VA train station cam and the Cornell Lab of Ornithology feeder cam. Here are the results: https://hexbird.io/a/9DGx3f-UzDY8CblJ5r_lbRKWZakK4F0y
Those tests were more constrained than a full CONUS search over 24 hours. I started with a 40 km radius around the nearest city to each livestream (Richmond for Ashland, Ithaca for Cornell), and used the streams' own timestamps. For each one I searched 3 hours of stream audio. The Ashland estimate is 43 m from the published camera location, Cornell's is 215 m.
Mick's guide and our pipeline share most of the core: the emission-time Doppler model, Earth-centered geometry with terrain and the geoid offset, one shared clock across all flyovers, pair matching when the time is unknown, a coarse grid with refinement, and a silence check.
The main differences:
Like Mick's reference run, mine weren't clean held-out tests, since settings were tuned on these recordings. A nationwide, date-only search on the same streams, with no clock, is in progress.
I am curious about what accepted ethical guidelines say about making tools like this available. The bar is low (anyone with a coding agent can build it in less than a day) but it is still a bar.
Those tests were more constrained than a full CONUS search over 24 hours. I started with a 40 km radius around the nearest city to each livestream (Richmond for Ashland, Ithaca for Cornell), and used the streams' own timestamps. For each one I searched 3 hours of stream audio. The Ashland estimate is 43 m from the published camera location, Cornell's is 215 m.
Mick's guide and our pipeline share most of the core: the emission-time Doppler model, Earth-centered geometry with terrain and the geoid offset, one shared clock across all flyovers, pair matching when the time is unknown, a coarse grid with refinement, and a silence check.
The main differences:
- I eventually implemented automatic detection and measurement of doppler curves. A matched-filter bank of modelled Doppler curves scans the whole recording for candidate flyovers. Each frequency row is normalized against its own background, which turned out to be the key step for faint curves. Curve tracing and acceptance are automatic too. Currently the accuracy is a bit worse than doing the measurements by hand: With no hand steps at all, the current pipeline gets 146 m at Ashland and 267 m at Cornell, in about 7 minutes for 3 hours of audio.
- Atmosphere. I don't assume a constant sound speed. The sound-speed and wind profile comes from the aircraft's own airspeed, Mach and wind reports, anchored to the nearest METAR surface temperature. This made the largest difference at Cornell, where the matched aircraft were 10–13 km away.
- Silence. It's checked automatically against every logged pass near a candidate location, not just a chosen quiet interval.
- Refinement. Sitrec's continuous optimizer that moves position and clock together is better; I refine on a fixed grid and sweep the clock separately.
- Scoring. I score against the traced curve. My brightness-along-the-curve variant did worse, but it used shorter FFT windows and different normalization from Sitrec's hybrid approach (traces to seed, brightness to rank), so we'll retest with that recipe.
Like Mick's reference run, mine weren't clean held-out tests, since settings were tuned on these recordings. A nationwide, date-only search on the same streams, with no clock, is in progress.
I am curious about what accepted ethical guidelines say about making tools like this available. The bar is low (anyone with a coding agent can build it in less than a day) but it is still a bar.
Someone needs to create a phone app that adds small amounts of random and rapidly changing pitch-shifts to the audio - either a video recording app or a post-processing one you can run videos through before sharing online.
UK would be useful.
Similar threads
