Daniel sent us this one — he's been thinking about the car horn problem in Jerusalem again, specifically the measurement side of it. The core question is: if you download a spectrogram app on Android, does it give you reliable frequency data out of the box, or do you need to calibrate it? And if you need to identify and verify a specific frequency within a range — say, for legal evidence — what tools actually work across both computer and smartphone? This is one of those questions where the answer changes completely depending on whether you're just curious or you need something that holds up in court.
That distinction — curious versus court-admissible — is where this whole conversation lives. Because the physics of sound measurement is unforgiving. You can't charm your way past the Nyquist theorem.
No, I've tried. The Nyquist theorem is famously charm-proof.
It really is. So let's start with what a spectrogram app on Android is actually doing under the hood. When you open something like Spectroid or Physics Toolbox Suite, you're looking at a Fast Fourier Transform — an FFT — of the audio signal coming through the device's built-in microphone. The app is slicing the incoming sound into time windows, running an FFT on each chunk, and displaying the frequency spectrum as color intensity or amplitude over time. It's the same core math that professional audio analyzers use. The difference is everything that happens before the math.
Everything before the math. That's the title of my autobiography.
It's a long book. So here's what's happening before the math. The microphone on your phone is a microelectromechanical system — a MEMS microphone — designed primarily for voice capture. Its frequency response is not flat. It's tuned to emphasize the range of human speech, roughly three hundred to three thousand four hundred hertz, and it rolls off pretty sharply outside that band. At one hundred hertz, a typical smartphone mic might be down by six to ten decibels. At ten kilohertz, you're seeing similar attenuation. The manufacturer doesn't publish calibration curves for these because voice calls don't need them.
The microphone is basically a bouncer at a club, and only the vocal-range frequencies are on the guest list.
And then you've got the analog-to-digital converter — the ADC — which has its own nonlinearities. Then there's the automatic gain control, which most Android audio subsystems apply by default. AGC is constantly adjusting the input level to keep the signal within a usable range, which is great for phone calls and absolutely catastrophic for accurate amplitude measurement. It's like trying to weigh something on a scale that keeps recalibrating itself mid-measurement.
What you're telling me is that out of the box, a spectrogram app is showing you something that is approximately true in the same way that a child's drawing of a dog is approximately a dog.
That's a generous comparison. Let me give you some actual numbers. When you run an FFT on a typical forty-four point one kilohertz sample rate signal with a one thousand twenty-four point FFT window, each frequency bin is about forty-three hertz wide. That means if your spectrogram shows a peak at four hundred forty hertz, the actual frequency could be anywhere from about four hundred eighteen to four hundred sixty-one hertz. That's your bin width error alone, before we even talk about the microphone's frequency response, the ADC's quirks, or environmental factors.
Forty-three hertz is a lot of wiggle room. If you're trying to prove that a specific car model's horn was the one that honked — and different horns have different fundamental frequencies — being off by forty-three hertz could put you in a completely different vehicle's acoustic signature.
That's the legal problem in a nutshell. Car horns in passenger vehicles typically fall between four hundred and five hundred hertz. A Fiat horn and a Toyota horn might be separated by only twenty or thirty hertz in their fundamental frequency. If your measurement uncertainty is larger than the difference you're trying to detect, you don't have evidence — you have a guess.
The bin width problem alone makes a stock spectrogram app legally useless for precise frequency identification.
For precise identification, yes. For casual detection — "was there a honk or wasn't there" — it's perfectly fine. A honk is a broadband transient with a strong fundamental and harmonics. You don't need precision to know it happened. But if the question is "was this specific horn from this specific vehicle," you need to shrink that uncertainty dramatically.
Which brings us to calibration. What does calibration actually mean in this context?
Calibration means you introduce a known signal and measure how your system distorts it. The gold standard is a reference tone generator that produces a precise frequency at a known sound pressure level. You play that tone — say, a one kilohertz sine wave at ninety-four decibels SPL — through a calibrated sound source, record it with your measurement setup, and then compare what you recorded to what you know you sent. Any difference is your system's error, and you can apply that as a correction curve to future measurements.
A calibrated sound source is not the speaker on your phone.
Smartphone speakers are tiny transducers with wildly nonlinear frequency responses. They're designed for intelligibility and loudness, not accuracy. Using a phone speaker as a reference source is like using a crayon to draw a calibration target for a laser. You can't trust it.
"Using a crayon to draw a calibration target for a laser." I'm putting that on a t-shirt.
What you actually need is something like a Dayton Audio iMM-6 calibrated measurement microphone, which costs about twenty-five dollars and comes with its own calibration file — a frequency response curve measured by the manufacturer against a reference standard. You plug that into your phone via a USB-C to three-point-five-millimeter adapter or OTG cable, and now you've bypassed the phone's internal mic entirely. The calibration file tells your analysis software exactly how this specific microphone deviates from flat response, and the software can compensate.
The twenty-five-dollar microphone is the entry ticket to reliable measurement.
It's the minimum viable hardware. But you still need a reference tone for end-to-end calibration of the whole chain. A good approach is to use a tone generator app on a separate device — or better yet, a dedicated signal generator — to produce a one kilohertz tone, play it through a speaker with a known flat response or through headphones held at a fixed distance from the measurement mic, and record that. Then in post-processing, you can see exactly what your system recorded versus what was actually produced.
This is where we cross over from smartphone to computer, because post-processing is where the heavy lifting happens.
On the computer side, Audacity is the obvious starting point. It's free, open source, and it has a built-in spectrogram view that's surprisingly capable. You can set the FFT size, choose the window function — Hann, Hamming, Blackman — and zoom into specific frequency ranges. More importantly, Audacity has a plot spectrum function that gives you precise frequency and amplitude values for peaks, and it supports importing calibration files for microphones. You can record directly into Audacity with your calibrated USB mic, and you're already in a much better position than any smartphone-only workflow.
For people who need more than Audacity can offer?
Raven Lite is the next step up. It's developed by the Cornell Lab of Ornithology for bioacoustics research — bird call analysis, whale song measurement. Bioacoustics researchers need exactly the kind of precision we're talking about: identifying specific frequencies in noisy environments, often for species identification where a few hertz makes the difference between one bird and another. Raven Lite gives you much finer control over spectrogram parameters, better measurement tools, and it's designed from the ground up for the kind of frequency verification work we're discussing. It's free for the basic version.
So the tools bird scientists use to tell one warbler from another are the same tools you'd use to tell one horn from another in a Jerusalem intersection.
The physics doesn't care whether the sound came from a beak or a bumper. A frequency is a frequency. And the signal processing challenges are remarkably similar: you've got a target sound, you've got background noise, you've got reflections and reverberation, and you need to isolate the fundamental frequency with enough confidence to say "this is species X" or "this is vehicle Y.
Let's talk about those environmental challenges, because Jerusalem intersections are not exactly anechoic chambers.
Far from it. You're dealing with multiple noise sources simultaneously. Bus engines, other traffic, wind, pedestrians, construction — all of that is competing with your target horn. The signal-to-noise ratio can be terrible. And then you've got multipath reflections: the horn sound bounces off buildings, off other vehicles, off the stone walls that Jerusalem is famous for. Each reflection arrives at your microphone at a slightly different time, creating comb filtering effects that can make your spectrogram look like someone dragged a fork across it.
That's when the reflected sound interferes with the direct sound and creates a series of peaks and nulls in the frequency response.
And it's a nightmare for frequency identification because the nulls can completely suppress certain frequencies while the peaks amplify others, making it look like the horn has a completely different spectral signature than it actually does. In practice, this means you can't just set up one microphone at one location and call it a day.
You need triangulation.
You need at least two, ideally three recording positions. With multiple synchronized recordings, you can cross-correlate the signals to identify which spectral features are consistent across all positions — those are likely from the source — and which appear in only one recording — those are likely reflections or local noise. This is standard practice in acoustic gunshot detection systems. ShotSpotter, for example, uses arrays of calibrated microphones distributed across a city, and they triangulate both the location and the acoustic signature of each detected event.
ShotSpotter is admissible in court. So there's a precedent for acoustic evidence meeting legal standards.
There is, but ShotSpotter is a multi-million-dollar municipal system with permanently installed, continuously calibrated sensor networks. The question we're really asking is whether a motivated individual with consumer-grade equipment can produce something that approaches that level of evidentiary rigor.
The answer seems to be: yes, if you're methodical enough, but it's not trivial.
It's not trivial at all. Let me walk through what a legally defensible workflow would actually look like. Step one: hardware. You need a calibrated measurement microphone — the Dayton iMM-6 or a MiniDSP UMIK-1, which is about a hundred dollars and comes with a unique serial-numbered calibration file. The UMIK-1 is USB, so it plugs directly into a laptop or into an Android phone via OTG. Step two: recording software that captures uncompressed WAV at a minimum of forty-eight kilohertz sample rate, twenty-four-bit depth. Audacity on the laptop side, or something like USB Audio Recorder Pro on Android, which bypasses the Android audio stack's automatic gain control and gives you raw access to the USB audio stream.
Bypassing the AGC is crucial, I'm guessing.
AGC is the enemy of calibrated measurement. If the gain is floating, you cannot establish a reliable relationship between the sound pressure level at the microphone and the digital amplitude in your recording. Every three decibel change in the AGC's behavior translates to a doubling or halving of your recorded amplitude, and you have no way to know it happened.
You've got your calibrated mic, you're recording raw WAV with no AGC. What's step three?
Step three is the reference tone. Before and after each recording session — and ideally during, if you can manage it — you record a known reference signal. A one kilohertz tone from a calibrated source, or at minimum from a tone generator app played through headphones at a fixed distance. This gives you a calibration anchor. In post-processing, you can verify that your system recorded one kilohertz as one kilohertz, and if it didn't — if it recorded one thousand five hertz or nine hundred ninety-three hertz — you can quantify the offset and apply a correction.
If you can't produce a calibrated reference tone in the field?
Then you're relying on the microphone's factory calibration alone, which is better than nothing but introduces uncertainty. The microphone calibration tells you how the mic responds across frequencies, but it doesn't account for the ADC in your specific phone or laptop, or for temperature effects, or for humidity, or for any of the other variables that affect real-world measurements. The reference tone closes that loop.
The chain of custody is: calibrated microphone with a serial-numbered calibration file, raw WAV recording with no processing, reference tone recordings bracketing your evidence capture, and ideally multiple simultaneous recording positions. That's the package you'd hand to a court.
You'd document everything. Timestamps, locations, equipment serial numbers, environmental conditions. The metadata matters almost as much as the audio. If you can't show exactly when and where a recording was made, with what equipment, under what conditions, the opposing counsel is going to have a field day.
"Your honor, my client's car horn was recorded on a Tuesday, but was it a humid Tuesday?
I know you're joking, but humidity actually does affect sound propagation. It changes the absorption coefficient of air at different frequencies. At ten kilohertz, the difference between twenty percent humidity and eighty percent humidity is about zero point five decibels per meter of additional attenuation. Over ten meters, that's five decibels — enough to shift your spectral balance noticeably.
Of course it is. Of course humidity matters.
Everything matters when you're trying to establish something beyond reasonable doubt. That's what separates scientific measurement from casual observation. The universe is not obligated to make itself easy to measure.
Let's get practical for a moment. Someone listening to this wants to try this at home — not for court, just to understand their own device's limitations. What's the quick experiment?
Download a tone generator app on a separate device — something like Tone Generator on Android or Signal Generator on iOS. Set it to produce a one kilohertz sine wave. Play that through headphones at a comfortable volume. Now open a spectrogram app on the phone you want to test — Spectroid is good for Android — and hold the phone's microphone near the headphone speaker. Look at the peak frequency on the spectrogram. Is it exactly one thousand hertz? If it's showing ten forty-three, or nine sixty-one, or anything other than one thousand, that's your device's systematic error. And here's the thing: that error might be different at different frequencies. Try it at five hundred hertz, at two kilohertz, at five kilohertz. You'll probably see different offsets at each frequency.
That's a humbling experiment. I did something similar last week with my own phone and got a twelve-hertz offset at one kilohertz.
Twelve hertz is actually pretty typical. And that's in a quiet room with no background noise. Now imagine doing that at a Jerusalem intersection with buses and motorcycles and someone's uncle leaning on their horn because they saw a friend three blocks away.
The social horn. The "shalom, I acknowledge your existence" honk. That's a whole different category of noise pollution.
It is, and it's one of the things that makes Jerusalem uniquely challenging for this kind of measurement. In many cities, a car horn means something specific: danger, frustration, alert. In Jerusalem, the horn is a punctuation mark. It's a conversational tool. The baseline horn frequency is higher than in most cities, which means your signal-to-noise problem is worse because the thing you're trying to measure is also the thing that's constantly occurring as background.
You're trying to isolate one specific horn in an environment where horns are essentially ambient sound.
Which is why the frequency precision matters so much. If you can narrow down to a specific fundamental frequency plus its harmonic series, you can potentially distinguish one horn from the general honk-soup. A particular car model's horn might have a fundamental at four hundred forty hertz with harmonics at eight hundred eighty, one thousand three hundred twenty, and seventeen hundred sixty hertz. If you can detect that exact harmonic pattern across multiple recording positions, and it's consistent with the known acoustic signature of that vehicle model's factory horn, you're building a case.
Known acoustic signature. Is there a database of car horn frequencies?
Not a comprehensive public one, which is part of the problem. Vehicle manufacturers don't publish spectral specifications for their horns. There are some academic studies — one from the Journal of the Acoustical Society of America measured horn frequencies across thirty common vehicle models and found fundamentals ranging from three hundred eighty to five hundred twenty hertz, with distinct harmonic profiles for each. But that's research data, not an accessible reference database. For legal purposes, you'd probably need to obtain an exemplar recording from the actual vehicle in question, under controlled conditions, and demonstrate that your field recording matches it.
Which means you need access to the vehicle. Which means you need law enforcement cooperation. Which brings us back to the institutional problem.
This is where the Israeli Ministry of Environmental Protection's pilot program is instructive. Their twenty twenty-five Tel Aviv pilot used fixed-location calibrated microphone arrays — professional-grade equipment, permanently installed, continuously monitored. They weren't trying to do this with smartphones. They recognized that the evidentiary standard requires instrumentation that can be validated and certified.
The gap between what a citizen can do with consumer gear and what a municipality can do with a funded program is significant, but not infinite. The physics is the same either way.
The physics is the same. The difference is in the documentation, the calibration traceability, and the institutional credibility. A well-documented citizen measurement with calibrated equipment and proper methodology is not inherently less accurate than a municipal system. But it faces a higher burden of proof because the court doesn't have an institutional relationship with the person who took the measurement.
Let's talk about the software tools more specifically, because the prompt asks what's available across computer and smartphone. We've mentioned Audacity and Raven Lite for desktop. What about the smartphone side beyond basic spectrogram apps?
On iOS, the landscape is better than Android for this specific use case. SignalScope by Faber Acoustical is a professional-grade audio analysis app that supports external calibrated microphones, offers real-time FFT with selectable window functions and averaging, and can export calibrated measurement data. AudioTools from Studio Six Digital is another option — it's essentially a full acoustic test and measurement suite in app form. Both of these are used by audio engineers and acoustics consultants in professional contexts.
Android is trickier because of the audio subsystem fragmentation. Different manufacturers implement the USB audio stack differently, and some impose processing that you can't bypass. Physics Toolbox Suite is good for raw sensor access and can export data for post-processing. Spectroid is the best free spectrogram viewer. But for calibrated measurement on Android, you really need an app that specifically supports USB audio class-compliant devices and bypasses the system audio processing — USB Audio Recorder Pro is the closest thing to a solution, but it's primarily a recorder, not an analyzer. You'd record with it and then analyze on a computer.
The practical Android workflow is: record clean with a calibrated mic, analyze later on desktop.
That's the most reliable approach. And honestly, even on iOS, for anything that might end up in a legal context, you want the post-processing step on a computer. Audacity or Raven Lite give you a level of control and documentation that a mobile app simply can't match. You can annotate your analysis, export the spectrogram as a high-resolution image with scale bars, save the FFT data as a CSV file for independent verification. That's the kind of transparency that holds up under cross-examination.
"Can you explain to the court why peak number three in exhibit B is exactly four hundred forty-two hertz and not four hundred forty-one?
You want to be able to answer that question by pointing to your calibration data, your reference tone measurements, and your documented methodology. Not by saying "well, that's what the app showed.
Let's address a misconception that I think a lot of people have about spectrogram apps. The colorful display looks so precise — there's a bright line at a specific frequency, it's clearly showing you exactly what's happening. But that bright line is an artifact of the FFT binning.
The spectrogram is showing you the frequency bin with the highest energy, not the actual frequency of the signal. With a one thousand twenty-four point FFT at forty-four point one kilohertz, each bin covers forty-three hertz. The app is essentially rounding to the nearest forty-three-hertz bucket. If the true frequency is four hundred fifty hertz, and your bin centers are at four hundred thirty and four hundred seventy-three, the app is going to show the peak at whichever bin captures more energy — and it could easily show four hundred seventy-three even though the actual frequency is four hundred fifty.
The precision is an illusion created by pixel density.
You can improve this by increasing the FFT size. An eight thousand one hundred ninety-two point FFT at forty-eight kilohertz gives you bins that are about five point nine hertz wide. That's much better. But it costs you in time resolution — larger FFT windows mean you're averaging over a longer time period, so short transient events get smeared out. It's a fundamental trade-off. You cannot have arbitrarily fine resolution in both frequency and time simultaneously. That's the Gabor limit, which is the acoustic equivalent of the Heisenberg uncertainty principle.
The Heisenberg uncertainty principle of car horns. We've really arrived somewhere.
And this is actually where AI-based approaches start to look interesting for the future. Machine learning models can be trained to identify specific acoustic signatures even in spectrograms with relatively coarse frequency resolution. They're not limited by bin width in the same way a simple peak-detection algorithm is, because they can learn the overall spectral shape — the relationship between the fundamental and the harmonics, the attack and decay envelope, the subtle timbral characteristics that distinguish one horn from another even when the measured fundamental frequency is ambiguous.
An AI model could theoretically say "this pattern of harmonics, with this attack envelope, is consistent with a two thousand nineteen Toyota Corolla horn" even if the fundamental frequency measurement is fuzzy.
And the nice thing about this approach is that it could work with consumer-grade hardware, because it's learning to recognize patterns that survive the limitations of the microphone and the ADC. You'd still need a training dataset of known horn recordings, ideally captured with the same class of device you're using for field measurements. But once you have that, the model could potentially achieve useful accuracy without requiring per-device calibration.
Which brings us to the open question: could crowdsourced, calibrated smartphone data ever meet the evidentiary standard for municipal enforcement?
I think the answer is: not yet, but the trajectory is pointing there. What's missing is a standardized calibration protocol that's simple enough for non-experts to follow, and an institutional framework for validating and certifying citizen-collected data. The technical pieces exist — calibrated USB microphones are cheap, analysis software is free, the signal processing math is well understood. What doesn't exist is the social and legal infrastructure to turn individual measurements into collective evidence.
It's a trust problem, not a technology problem.
It's always a trust problem. Can the court trust that the person who made this recording followed the protocol? Can the city trust that the data hasn't been manipulated? Can the public trust that automated enforcement based on citizen measurements won't be abused? Those are harder questions than "what's the frequency response of a MEMS microphone.
To bring this back to the practical question that started the episode: if you want to measure car horn frequencies with enough precision to identify a specific vehicle, and you want that measurement to potentially hold up in a legal challenge, what's the minimum viable setup?
A calibrated USB measurement microphone — the Dayton Audio iMM-6 at twenty-five dollars or the MiniDSP UMIK-1 at a hundred dollars — connected to a laptop running Audacity, recording uncompressed forty-eight kilohertz twenty-four-bit WAV. A reference tone generator for calibration checks before and after recording. At least two recording positions to control for reflections and multipath. And meticulous documentation of equipment, conditions, and methodology. That's the floor.
If you just want to satisfy your curiosity about whether your neighbor's horn is unusually obnoxious?
Download Spectroid, point your phone at the street, and enjoy the pretty colors. Just don't expect the numbers to mean anything in court.
The spectrum of approaches runs from "free app and a shrug" to "hundred-dollar microphone and a chain of custody binder." And where you need to be on that spectrum depends entirely on what you're trying to prove.
That's the whole thing. Measurement without purpose is just data collection. The precision you need is a function of the decision you're trying to make. If the decision is "should I be annoyed," your ears are calibrated enough. If the decision is "should this person be fined," you need a lot more than that.
The gap between those two standards is where Jerusalem's noise enforcement is currently stuck. The ears say there's a problem. The legal system says "prove it.
Proving it requires understanding the physics well enough to know what you don't know. The bin width. The microphone response. The reflections off the limestone walls. All of it.
The actionable takeaways here are pretty clear. One: for casual detection, a stock spectrogram app tells you that a honk happened, and that's about it. For legal evidence, you must calibrate with a known reference tone and use an external calibrated microphone. Two: the minimum viable setup is a calibrated USB mic, a recording app that outputs raw uncompressed WAV with no automatic gain control, and a post-processing tool like Audacity for FFT analysis with documented methodology. And three: if listeners want to see their own device's limitations firsthand, download a tone generator app, play a one kilohertz tone through headphones, and check what the spectrogram actually reads. The offset might surprise you.
That last one is genuinely worth doing. It takes five minutes and it'll permanently change how you think about the numbers your phone shows you.
The open question I keep coming back to is whether AI-based frequency fingerprinting could eventually automate this well enough to make per-device calibration unnecessary. If a model can learn to recognize specific horn signatures despite the quirks of consumer microphones, you could potentially deploy a crowdsourced enforcement system that actually works. But that's a research problem, not something you can download today.
It's coming though. The acoustic event detection literature from the last two years shows rapid progress on exactly this kind of problem — identifying specific sound sources in noisy environments using deep learning on spectrograms. Give it a few years and your phone might be able to tell you not just that someone honked, but which neighbor it was.
Which is either a privacy nightmare or a civic dream, depending on your relationship with your neighbors.
In Jerusalem, probably both.
Now: Hilbert's daily fun fact.
Hilbert: In the early medieval period, sailors near Mauritius occasionally encountered sharks whose electroreceptive ampullae of Lorenzini contained a gel chemically similar to the semiconductor gallium arsenide, with trace amounts of zinc oxide crystals that may have functioned as primitive piezoelectric transducers.
...right.
The ampullae of Lorenzini as semiconductor.
This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop for keeping the facts weird and the microphones uncalibrated. If you enjoyed this episode, leave us a review wherever you get your podcasts — it helps other people find the show. We're at myweirdprompts.I'm Corn.
I'm Herman Poppleberry. Measure twice, honk never.
