How We Measure Piano Transcription Accuracy

Every transcription tool claims to be accurate, and almost none of them shows a measurement behind the claim. We decided to be the exception — not by quoting a bigger number, but by publishing the method with the numbers attached. This post is what we measured on 16 September 2026, on named test pieces with a stated scoring rule, where our pipeline breaks, and what we changed because of it. The six uncorrected transcriptions on our examples page show the same pipeline's output end to end, wrong key signature and all.

Why we publish measurements instead of a percentage

A percentage needs a denominator: accurate on which pieces, played how, recorded where, scored by which rule? Without those answers, "95% accurate" is marketing, not information. We said as much in why Basic Pitch gives you MIDI, not sheet music — we are not going to publish an accuracy percentage, ours or anyone's — and this post does not change that position. It explains it.

Four test pieces is enough to choose a model and to locate the failure modes. It is nowhere near enough to characterise accuracy for a stranger's recording, and pretending otherwise is how the industry's numbers got meaningless. What a protocol result can honestly tell you is where things break — which, for a tool whose output goes on a music stand, is the more useful thing to know.

The protocol

The ground truth problem in transcription evaluation is alignment: if you record a human playing and transcribe the MIDI by hand, you never quite know the reference matches the audio. We removed the doubt by inverting it — the audio is generated from the reference:

1. Take a public-domain piano MIDI file from the Mutopia Project.
2. Render it with FluidSynth and the FluidR3 GM soundfont at 44.1 kHz.
3. Cut the audio to a 30-second window and cut the reference MIDI to the same window.

For all four clips, the first audible sample landed within 0.3 ms of the first reference onset. The trade-off is real: a sampled-GM render is not a piano recording — no room, no sympathetic resonance — so we also ran one clip of a real human performance (Edward Neeman's public-domain Chopin etude recording) as a qualitative check.

Each piece then got six versions — clean, a phone-mic simulation (band-limited to roughly 200 Hz–6 kHz and compressed), added room reverb, pink noise at 20 dB and 10 dB signal-to-noise, and 64 kbps MP3 — 24 audio files in total. Scoring is mir_eval's transcription module: a note is correct if its onset is within 50 ms at the right pitch, and in the stricter variant its offset must also land within 20% of the reference note's duration.

What we measured

Two engines. The free in-browser preview — the model that transcribes your first 30 seconds on your own device, with nothing uploaded — is Spotify's Basic Pitch. Against it we benchmarked a piano-specialised transcription model, the ByteDance/Kong high-resolution CRNN, as a candidate for a higher-quality tier.

Mean onset F1 per piece, averaged across all six conditions:

When note endings also had to match, the gap widened: Basic Pitch's mean onset-plus-offset F1 sat around 0.25–0.28 — and 0.035 on the Chopin — against 0.54–0.78 for the piano-specialised model. Finding roughly the right notes at roughly the right times is largely solved; knowing how long they last is not. That gap is why our quantisation and rhythm code has to make strong assumptions, and why MIDI-to-notation cleanup is its own problem.

One honest complication about the second column: the CRNN's weights carry a clean CC BY 4.0 licence, but neither upstream code repository ships a licence file, and the two repos assert different licences in prose. Until that is resolved it is a benchmark result, not a shipping feature — which is itself the kind of thing this evaluation exists to catch.

Where transcription actually breaks

The piece matters more than the microphone

Across the five degraded conditions, onset F1 barely moved for either model. Across pieces it swung by 0.32 for Basic Pitch and 0.14 for the CRNN. Our standing advice — quiet room, close mic — is still correct, but the dominant variable is what is being played. The examples page shows the same thing from the product side: the Bach Invention pushed through a simulated phone mic detected 221 notes against 220 clean, with the same measured tempo and the same wrong key signature. A real phone adds room echo and handling noise the simulation leaves out, but band-limiting alone is not what breaks the detector.

Endings are the hard part — and pedal truncates, not smears

Everyone assumes the sustain pedal makes transcribed notes too long. We wrote that advice ourselves. Measured, it is wrong in a specific and useful way: on the heavily pedalled Satie clip, Basic Pitch reported notes at 0.53 times their written length — it does not stretch notes through the pedal, it loses the sustained tail. So on the free preview a pedalled passage comes out with notes too short.

The CRNN held the same pedalled notes at 1.02 times written length — nearly perfect — but over-held short unpedalled Bach notes by 1.26–1.30 times, rising to 1.50 times under added reverb. Reverb, not pedal, is what makes it smear. The fixes are in sustain pedal transcription errors and room echo and transcription; the measurement says the two deserve equal suspicion, in opposite directions.

Invented notes versus missed notes

On clean audio, Basic Pitch emitted octave doublings — a strong overtone reported as a second note — amounting to 11–17% of everything it output, plus further ghost notes. The piano-specialised model emitted zero ghost notes on all four clean pieces; its errors were almost purely misses, with precision of 1.000 on the Chopin. For sheet music that is the right failure direction: a missing note is a gap you fill in, an invented note is a wrong note you have to find first. You can see this on the examples page: the Bach WTC Prelude detected 149 notes against 120 written, and the extras read as doubled notes in the score.

Noise did something counter-intuitive

Adding 10 dB of pink noise removed 39% of Basic Pitch's ghost notes rather than adding any — the noise buried its weak spurious detections, and precision rose on every piece. The model was not improving; the noise was acting as an accidental confidence filter. Which pointed directly at a deliberate version of the same thing.

A free fix we already took

Raising Basic Pitch's thresholds from the defaults (onset 0.5, frame 0.3) to 0.7 and 0.4 raised its onset F1 on the pedalled Satie clip from 0.730 to 0.821 — precision up from 0.605 to 0.742 with recall completely unchanged at 0.920. Everything it dropped above 0.5 confidence was noise. Lowering the thresholds was worse on every metric. Those settings are what runs in your browser today; this measurement is the reason.

What the six public examples show

Note-level F1 cannot see the errors that happen after detection, and the examples page — six real outputs, uncorrected, reports included — is where those live:

• Wrong key signatures. The Bach Invention was written in G major where the piece is in C major, and the report flags the guess. The Chopin Prelude Op. 28 No. 4 came back in C major when the piece is in E minor — with no warning at all. Wrong key signatures in transcription are among the easiest things to check and the most annoying to discover late.
• Tempo doubling. The Joplin measured at 143 BPM against a written 72 — the estimator locked onto the eighth-note pulse, which in a rag is where the syncopation lives. The Chopin doubled too, 111 against about 56.
• Meter falling back to 4/4. When the meter cannot be measured the score is written in 4/4 — which happened to be right for the Bach and wrong for Joplin's 2/4, so each printed bar spans two bars of the original.
• Genuine misses. The Joplin detected 217 notes against roughly 324 written in that window, and the report's own warning shows the strain — 136 notes were shortened to keep each staff reading as one voice.

What this does not prove

Stated plainly, because the temptation to over-read four pieces is real: the test set is four pieces, one soundfont, one renderer, and no amateur playing — every clip is a metronomic render of a masterwork, while our users record themselves with wrong notes and uneven tempo on phones. On the one real human recording we ran, both models behaved plausibly and differently than on the synthetic version — the CRNN's pedal detector, hopeless on rendered audio, produced credible output on the real performance. The ranking is robust; the absolute numbers should not be assumed to transfer to your recording.

And none of it measures whether the score is readable. F1 counts notes in a piano roll; spelling, hand splitting and beaming are invisible to it. That is why the product shows you a transcription report — measured tempo, guessed key, warnings — rather than promising a number, and why the examples ship with their errors uncorrected. The most honest test remains your own hardest 30 seconds: pick the pedalled chords or the fast run, upload the recording, and judge the MusicXML, not the playback.

Frequently asked questions

How accurate is Piano to Sheet Music?

We do not publish a single accuracy percentage, because one number without a named test set and a scoring rule means nothing. What we publish is the protocol and the per-piece measurements: on our four-piece benchmark the in-browser model's mean onset F1 ranged from 0.565 on a dense Chopin etude to 0.882 on a sparse Bach invention.

What is onset F1 in music transcription?

The research-standard metric from the mir_eval library. A detected note counts as correct if it starts within 50 milliseconds at the right pitch, within 50 cents. Precision is the fraction of detected notes that are real, recall is the fraction of real notes found, and F1 balances the two. A stricter variant also requires each note's end to match within 20% of its duration.

Does recording quality matter for transcription accuracy?

Yes, but less than the music itself. Across phone simulation, reverb, pink noise and MP3 compression, our measured onset F1 barely moved, while it swung by 0.32 between pieces for the same model. A quiet room still helps, but a dense, fast, heavily pedalled piece is hard even on clean audio.

What does the sustain pedal do to a transcription?

On our deliberately pedalled test clip, the in-browser model reported notes at roughly half their written length — it loses the sustained ring rather than extending it, so pedalled passages come out with notes too short, not too long. The piano-specialised model we benchmarked did the opposite under room reverb, stretching notes up to 1.5 times.

Where can I see uncorrected transcription output?

Our examples page shows six real outputs — five public-domain pieces plus one phone-mic simulation of the same clip — each with the audio, the engraved score, downloadable MIDI and MusicXML, and the report the pipeline produced, including a wrong key signature we left in on purpose.

Sources

• mir_eval documentation: transcription metrics — the scoring rule used throughout
• Kong et al., "High-Resolution Piano Transcription with Pedals by Regressing Onset and Offset Times" (arXiv 2010.01815) and the CC BY 4.0 checkpoint on Zenodo, record 4034264
• Spotify Basic Pitch repository (Apache-2.0) — the model that runs in the browser preview
• Mutopia Project — public-domain MIDI sources for all test pieces
• Wikimedia Commons: Chopin Etude Op. 10 No. 12, Edward Neeman — the real-recording check

All measurements taken 16 September 2026 on CPU (Apple M5 Pro), 30-second clips, 50 ms onset tolerance. The figures above are protocol results on named test pieces, not a product-level accuracy claim.