How Accurate Is Your Phone Tuner? (The Algorithm Is What Matters)

Every pitch detector does the same job on paper: listen to a sound, work out how fast it repeats, report a frequency. The differences emerge in how each algorithm handles real instrument audio, which is far messier than a pure test tone. A guitar string at A4 produces not one frequency but a stack of them: 440Hz, 880Hz, 1320Hz, 1760Hz, and beyond. The 440Hz fundamental is the note you want. The overtones are louder in some instruments, quieter in others, and they shift in proportion as the string decays. How well a tuner handles that complexity determines whether you can trust what it shows.

Why Simple Autocorrelation Falls Short

Most basic tuner apps use straightforward autocorrelation: take the incoming audio, compare it against delayed copies of itself, and find the delay at which it matches itself best. The matching delay is the period; the reciprocal of the period is the frequency. It is fast and works well for pure, simple tones. It struggles on real instruments.

The reason is the overtone series. A guitar's open low E string vibrates at 82Hz, but it also produces strong harmonics at 164Hz, 246Hz, 328Hz. A naive autocorrelation will often find a strong match at the period corresponding to 164Hz (double the true period, half the frequency) because that half-period is also a point of strong self-similarity in the signal. The result is a tuner that reads an octave high or jumps between the fundamental and its first harmonic. This is the root cause of the flickering you sometimes see on simple tuner apps, and it is why a good algorithm needs a smarter criterion than "find the peak."

MPM: Picking the Right Peak

Metro Gnome's tuner runs the McLeod Pitch Method (MPM). The key difference from basic autocorrelation is the Normalised Square Difference Function (NSDF): instead of raw correlation values, MPM computes a normalised figure bounded between -1 and 1, where a score near 1 means the signal is genuinely periodic at that lag. From that NSDF, MPM then applies a specific selection rule: it looks for the first key maximum that clears 90% of the global peak.

That "first key maximum" rule is precisely what resolves the octave problem. The fundamental period produces the first sufficiently large peak in the NSDF. The double-period (one octave lower) would be the second or third. By choosing the first qualified peak rather than the tallest, the algorithm locks on the fundamental before it can reach the longer-period overtone. In Metro Gnome's code, that threshold is set to 0.9 (90%). Below 0.5, the detection is considered too uncertain to trust, and no reading is shown.

The analysis window is 8192 samples at 44,100Hz, which is about 186 milliseconds per window. That is intentionally long. For a bass note around 80Hz, one period is only about 12ms. A 186ms window captures more than 14 complete cycles, giving the algorithm statistical confidence that what it hears really is periodic. To compute the autocorrelation without circular-aliasing artifacts, the window is zero-padded to 16,384 points before the FFT. Zero-padding keeps the autocorrelation linear rather than circular, which matters for cleanly separating closely spaced overtones.

After the integer lag is found, parabolic interpolation refines it to a fractional sample. Without this step, frequency resolution at the low end would be roughly 3 cents per sample, which is audible. With interpolation, the detector resolves to a small fraction of a cent. At 44,100Hz and 186ms window size, the frequency resolution is already better than 6Hz, but parabolic interpolation pushes it well below 1 cent across the instrument range.

Stabilising the Display

Raw pitch detections at 11 readings per second (the 4096-sample hop gives 50% overlap) are still noisy frame to frame. Metro Gnome runs each new reading through two smoothing layers before the needle moves.

First, a 5-tap running median. Any single frame where a stray overtone hijacks the detection, causing an octave jump, is voted out by the surrounding frames. The median is more robust than an average here because averages are pulled far by outliers; the median simply ignores them.

Second, a per-note exponential moving average with alpha 0.25. Once the median settles, the EMA smooths the display. When you change notes, the EMA resets immediately so the needle does not lag a genuine pitch change. When you hold a note, it damps small fluctuations. The net result is a needle that is steady on a held note but responsive on a change.

The Noise Problem: Profiling the Room

A pitch detector that simply reports any detected frequency is useless in a real room. A voice, a fan, a buzzing amp all have detectable pitch. Metro Gnome's tuner sits an environment analyser between the raw pitch detections and the needle. That analyser makes the decision: is what I am hearing a genuine instrument note, or something else?

At start-up, the tuner spends 900 milliseconds profiling the room. It measures the background amplitude and captures any steady tone already present, such as mains hum at 50Hz or 60Hz, or a fan with a consistent pitch. After profiling, that noise profile is frozen and used in two ways: the background amplitude becomes the gate (signals have to rise clearly above it to be analysed at all), and the spectral shape is subtracted in the presence probe so that a note buried under a background tone can still be confirmed as present.

To lock onto a note, the analyser requires a pitch to stay within 18 cents of itself for 320 milliseconds. A voice does not do this. It glides, slides, and drifts across tens of cents per phrase. An instrument note on a well-intonated instrument holds. Once locked, the analyser rides out gaps of up to 360 milliseconds before dropping the lock. This covers a plucked string decaying to near-silence: the note is still "there" even if the signal briefly dips. If speech overlaps the note, the lock holds for up to 800 milliseconds because the instrument note is physically still present underneath. When the same note returns within 1500 milliseconds of a lock dropping, it re-locks immediately without requiring a full new 320ms acquisition cycle.

Why NoiseSuppressor Is Intentionally Disabled

Android provides a system component called NoiseSuppressor, designed for voice calls. It targets stationary noise, fans, air conditioning, background hum, and cleans it out so voices sound clearer on calls. Applied to a musical instrument, it does exactly the wrong thing. A sustained note looks like stationary noise to a voice-call filter. The NoiseSuppressor attacks it.

Metro Gnome's tuner opens the microphone as a raw MIC source with no automatic voice processing applied. The ambient noise detection and spectral subtraction are done by the tuner's own code, written for instrument signals rather than voices. The noise reduction is adaptive (it learns your room), frequency-aware (it can target a specific hum without blanket attenuation), and operates on a spectral floor of 10% (it never attenuates any bin below 10% of its original energy, preventing "musical noise" artefacts).

Reference Pitch and the In-Tune Window

Standard concert pitch is A4 = 440Hz, but the app's reference is adjustable from 415Hz to 466Hz. Early music ensembles commonly use 415Hz, roughly a semitone below modern concert pitch, because that matches historical instruments. Some orchestras tune to 442Hz or 443Hz. The in-tune window is set to plus or minus 3 cents. A value of 1.5 cents proved too tight in practice: a real note with slight vibrato and natural decay could not hold the green indicator, even when the player was genuinely in tune. Three cents is musically meaningful (a well-trained ear can hear 5-cent deviations) while still registering achievable precision.

What "Accurate Enough" Actually Means

For noodling at home, almost any tuner is fine. The differences between algorithms become significant when you are working on precision intonation: matching equal temperament on a fretless or fretted instrument with worn frets, tuning a piano or a hammered dulcimer, matching pitch with other players in a chamber group. Those are also the conditions where rooms are often noisy, notes are decaying, and the harmonic content of the instrument is most complex.

The engineering described here is not here to impress. It is here because the alternative, a simpler algorithm in a noisier room on a richer instrument, is where tuners visibly fail. And when a tuner shows the wrong note, the most common cause is exactly the harmonic problem that MPM was designed to solve.