MP3 to Sheet Music: Does the Codec Change the Page? (Measured)

The short answer: no — and we measured it rather than assumed it. This tool reads an MP3 and returns the notes inside it as a MIDI file; the staff is drawn later by MuseScore, Dorico or a DAW's score editor, because no notation renderer runs on this site. The question worth asking about the MP3 route is whether the lossy codec moves anything a score would show, so the same four block chords went through the analyser as a WAV and as MP3 at 128, 64, 24 and 16 kbps. Every written pitch came back at every bitrate — 13 of 13 pitch classes — the chord roll stayed at 33 ticks all the way down to 24 kbps, and the note lengths were unchanged. The stray notes you will want to delete are in the WAV too: 9 of them in both, so they come from the detector rather than from the codec. Only at 16 kbps did anything move.

1. The half that runs here

Your browser decodes the MP3, the analysis happens on your own machine, and what leaves the tool is a note list. The constants behind that pass are fixed and open to inspection:

Pitch window: detection reaches from A1 (55 Hz) to A6 (1800 Hz). Material outside that band never becomes a note, however audible it is.
Polyphony: polyphonic mode holds up to 6 notes per analysis frame, which is the mode a chord progression needs; monophonic mode tracks a single line.
Velocity and timing: velocity is read from loudness and tops out at 127 at −2.22 dBFS; the CSV that ships alongside the MIDI prints each note's time to 4 decimal places.
What lands in your downloads folder: a format-1 MIDI, 2 tracks, TPQ 480 — the shape a notation app expects.

On 11 known-answer clips the audio→MIDI step scored 86.7% recall and 91.5% precision. That covers the listening half only; the codec is a separate question, and it is the next section.

2. The measurement: one clip, five encodings

Four block chords were synthesised so that every note of a chord begins on the same sample and every written note lasts 0.700 s — 13 distinct pitch classes in all. That clip was saved as a 22 050 Hz WAV, encoded with a real MP3 encoder at four bitrates, and decoded back at the same rate so that no resampling sits between the versions; each version then went through this site's own dsp.js in polyphonic mode at the default settings.

Same four block chords, five encodings, identical analyser settings. “Written hit” counts the 13 pitch classes that were actually played; “extra notes” are notes returned that were never written.
Source	Notes returned	Written hit	Extra notes	Chord roll (ticks)	Note lengths
WAV (reference)	27	13 / 13	9	33 / 33 / 33 / 33	0.058 – 1.509 s
MP3 128 kbps	27	13 / 13	9	33 / 33 / 33 / 33	0.058 – 1.509 s
MP3 64 kbps	26	13 / 13	8	33 / 33 / 33 / 33	0.070 – 1.509 s
MP3 24 kbps	25	13 / 13	7	33 / 33 / 33 / 33	0.058 – 1.509 s
MP3 16 kbps	29	13 / 13	9	33 / 33 / 33 / 22	0.058 – 0.848 s

Read across the rows and the codec is close to invisible:

The written music survives every bitrate. All 13 pitch classes turned up at 128, 64, 24 and 16 kbps. Not one written note went missing, however thin the file got.
The chord roll holds still. Each chord's notes are stamped across 33 ticks — roughly 34 ms — and that figure was the same at 128, 64 and 24 kbps as on the WAV. Only 16 kbps nudged a chord, from 33 ticks to 22.
Lengths hold until 16 kbps. From the WAV down to 24 kbps the returned note lengths agree to three decimal places. At 16 kbps the longest note is cut from 1.509 s to 0.848 s, so a very low bitrate really can shorten a held note.
Nothing drifts. Against the WAV, every note at 128 kbps sat on precisely the same start time — a mean difference of 0.00 ms — so the codec does not shift a piece along the page.

One further figure, because a score prints it as a dynamic mark: the MP3 returned velocity about 0.8 of a step lower than the WAV at 128, 64 and 24 kbps, and about 0.96 of a step lower at 16 kbps. Under one step out of 127 is a nudge, not a different piece.

3. The stray notes are not the MP3's fault

This is the part worth knowing before you blame the file format. Every row of that table shows extra notes — and the reference row is a plain WAV. Nine notes came back from the WAV and nine from the 128 kbps MP3: the same nine, all of them pitches that were never played (A#4, C#4, C5, D5, D#5, F5, G#3 and two more sitting above the top written note).

Those notes belong to the detector, and they will appear whatever you feed it. Polyphonic mode keeps several spectral peaks per frame and discards a peak only when it lands on an exact multiple of a stronger one; harmonics that are not exact multiples therefore survive as notes in their own right. Re-encoding cannot remove them and neither can a higher bitrate — the WAV row settles that. They get deleted in the notation app, by hand or by selecting the top of the chord.

4. Who owns each leg of an MP3-to-score job

Three legs, and the one people expect to be trouble
Leg	Who does it	What comes out
1. MP3 → notes	This converter, in your browser	Format-1 MIDI, 2 tracks, TPQ 480, plus a CSV
2. Notes → a readable score	Your notation app	The staff, the clefs, the key, the beaming, the rests
3. What the codec contributes	Measured here, and the answer is almost nothing	The same written notes, the same chord roll, the same lengths

Nothing on this site draws notation: there is no staff renderer, no PDF and no MusicXML. Leg 2 happens when MuseScore, Dorico, Sibelius or a DAW's score editor opens the MIDI. Leg 3 is the one people brace for, and on these measurements it is a non-event.

5. Reproducing it on your own file

You should not trust an accuracy figure you cannot check, including ours. This takes a few minutes:

Take a WAV you own and make an MP3 from it at whatever bitrate you usually use.
Convert both here using identical settings: the same detection mode, the same sensitivity, the same shortest-note length.
Download both .csv files and sort each one by start_sec. Every row is a single note; the pitch sits in note_name and the times in start_sec and end_sec.
Compare the note_name columns line by line. On this material the two lists agree note for note; where they differ, look for the same stray notes showing up on both sides.
If a stray note appears in both files it belongs to the detector, so delete it once. If it appears only in the MP3, go back to the WAV for that conversion.

Questions

Does an MP3 give a worse score than a WAV?

On our measurements, no. Every written pitch came back at every bitrate tested, the chord roll stayed at 33 ticks down to 24 kbps, and the note lengths were identical. The visible differences begin at 16 kbps, where one chord's roll shifted and the longest note was cut short.

Why are there notes on the page I never played?

Because polyphonic mode keeps extra spectral peaks. The same nine stray notes came back from the WAV as from the 128 kbps MP3, so the detector produces them and the codec does not. Delete them in the notation app; changing bitrate will not remove them.

Which bitrate should I convert from?

Anything from about 24 kbps upward returned the same written music in our test. Below that the file starts to change the result: 16 kbps shortened the longest note and moved one chord's alignment. If the original lossless file is still on your disk, convert that and stop guessing.

What exactly does this site hand me for an MP3?

A format-1 MIDI, 2 tracks, TPQ 480, holding up to 6 notes per frame, covering pitches from A1 (55 Hz) up to A6 (1800 Hz), with velocity reaching 127 at −2.22 dBFS. Beside it you get a CSV of the same notes, timed to 4 decimal places.

Why can I not download a score directly?

Because drawing a score is a notation job and this site runs audio analysis only. The MIDI is the handover point: it is the file those apps open to produce the staff.

The measured conclusion is short: for the page in front of you, an MP3 behaves like its WAV. Run a file through the converter and set the CSV beside your own WAV export — comparing the two lists is the quickest way to see it.

MP3 to sheet music: does the codec change what lands on the page?