Only 42 of the 88 piano keys convert correctly.

The test is deliberately mechanical so the numbers can be checked. For each of the 88 keys I synthesised a 0.6-second tone whose spectrum is a fundamental plus five harmonics at decaying amplitudes, which is closer to a struck string than a bare sine wave. Each tone was passed through a copy of the detector's detectNotes() function, taken line for line from the shipped converter.js, at 44.1 kHz with sensitivity set to Balanced. The output pitch was compared with the key that was played.

The correct region turned out to be one unbroken block. There are no holes in the middle: every key from C3 up to F6 came back exactly right, and every failure sits outside that block.

Two control conditions check that the result is not an artefact of the synthesis. With a bare sine wave instead of a harmonic tone, 38 keys are correct and the block tightens to E3–F6. Re-running the harmonic test at 48 kHz gives 41 correct keys, block C♯3–F6. The block moves by one key between sample rates, and the shape of the failure does not change: the middle of the keyboard is fine, both ends are not.

Evidence boundary. These are synthetic single tones, one per key, not recordings of a real instrument. They isolate pitch detection, which is what the error is about. They do not measure note timing, velocity, sustain, or how a full piano piece behaves, and no real piano recording was scored against a note-level reference for this page.

None of this is a note-threshold problem. It comes from how the detector turns a buffer of samples into a single frequency estimate, and all four causes are visible in the shipped code.

1. The declared 55 Hz floor is unreachable

The code sets minFreq = 55 and maxFreq = 1400, then derives the lag range to search:

const minLag = Math.floor(sampleRate / maxFreq);
const maxLag = Math.min(Math.floor(sampleRate / minFreq), frameSize / 2);

At 44.1 kHz the frame size works out to 1,024 samples, so maxLag is capped at 512 no matter what minFreq says. The lowest frequency the search can even test is 44,100 ÷ 512 = 86.1 Hz. The constant 55 is never reached. A 55 Hz A1 is 43 semitones below the usable floor, which is exactly the gap the bass keys fall into.

2. The 1,400 Hz ceiling is not enforced either

minLag is 31, so the highest frequency the search can test is 44,100 ÷ 31 = 1,422.6 Hz, not 1,400. More importantly, any key whose true period is shorter than 31 samples has its period removed from the search entirely. A key above roughly 1,422 Hz cannot be found at its own frequency, so the detector locks onto the first surviving multiple of the period — usually twice the period, which reads as exactly one octave low.

3. The correlation is never normalised

This is the mechanism behind the bass collapse. The loop accumulates a raw sum:

for (let i = 0; i < frameSize - lag; i += 4) correlation += samples[offset + i] * samples[offset + i + lag];

Longer lags have fewer terms in that sum, so they start with a smaller total before any similarity is considered. The code compares the raw totals directly, and the shortest lag tested is 31. For a low key the signal barely changes across 31 samples, so that lag looks strongly correlated and its larger term count wins outright — even though the true period scores better once normalised. The result: every key from A0 up to A♯2 returns lag 31, which is 1,422.6 Hz, which rounds to F6. B2 sits exactly on the boundary and its estimate alternates between B2 and F6 from frame to frame instead of settling.

4. A moving estimate never survives the duration filter

Notes shorter than the minimum duration are discarded, and the threshold at Balanced sensitivity is 0.075 seconds. Because the winning lag can change between frames, three keys never hold a single estimate long enough: B2 stays stable for at most 0.046 seconds, D7 for 0.058 seconds, and F7 for 0.029 seconds. The audio is not silent — the detector simply keeps changing its mind, so no note is ever written.

None of this is fixed by the sensitivity slider. Lowering the threshold admits more frames, but the estimate those frames carry is the same wrong one.

The detector produces one pitch estimate per frame and merges frames only when their estimates sit within one semitone of each other. Two notes sounding at once therefore cannot become two MIDI notes. I checked the common cases with the same tone generator.

Read that table from the bottom up. A single sustained note is handled well: pitch is stable and duration lands within a few hundredths of a second of the real decay. Everything that makes the estimate move is what breaks it. A chord produces a single pitch because two fundamentals compete in the same frame and the search has to pick one. An octave produces a single note because the harmonic series reinforces the lower pitch. Vibrato produces a scatter of notes because the estimate wanders across semitones faster than the duration filter can accept it.

The status message the tool shows after a conversion already says the result can miss notes or confuse chords. This measurement puts numbers on that sentence: on a piano triad, it does both at once.

The measurement is not a reason to abandon piano-to-MIDI work. It is a reason to choose the input deliberately.

1. Stay inside C3–F6. If the part you need sits below C3, transpose the recording up an octave before converting and transpose the MIDI back afterwards. If it sits above F6, take the two or three highest notes and enter them by hand. Every key outside the block was wrong in the test, not merely imprecise.
2. Convert one line at a time. Run the melody, the bass, and the inner voices as separate passes. A single chord will not become a chord no matter which sensitivity you pick, but three single-note passes give you three usable lines.
3. Expect a note count, then verify the pitches. The export tells you how many notes were written. Compare the first note of each region against the recording before you trust a passage — the bass end is where the tool will confidently write the wrong note.
4. For full polyphony, use a different tool. If the job is a piano transcription rather than a draft for repair, a dedicated piano transcriber is the right instrument. This page is about what this browser converter does and does not do.

For a broader view of where a browser converter sits against dedicated products, see the converter accuracy guide. For the repair workflow once a draft exists, see the polyphonic repair workflow. For a single-note source in a different register, the guitar guide covers the same detector against guitar tuning.

The phrase draws about 110 searches a month in the United States with competition rated LOW and a bid range of $0.40 to $2.01, which is why it is worth a page but not a product of its own. Demand is seasonal rather than growing: interest climbed through winter, peaked sharply in April 2026 at a weekly index of 100 and a monthly average of 88, and has since settled back to 29. The 12-month mean is 43.

What is missing from the first page for this phrase is measurement. The results are converter product pages and a couple of explainers; none of them publishes a per-key result, so there is no way for a visitor to know in advance that their bass notes will come back wrong. That is the gap this page fills.