Wrong notes after conversion? Check three things before you blame the file.

Wrong notes usually come from one of three things: a second voice or instrument inside the same recording, a pitch that slides instead of holding, or the detector locking onto a harmonic instead of the fundamental. The notes are not random. Each one is a specific decision the estimator made, and you can usually predict which decision it made by looking at the input.

There is also a hard case worth knowing about. In a controlled test, pure tones from 40 Hz up to 150 Hz all came out as the same single wrong note, MIDI 89. If your source sits in that register, no amount of note editing fixes the cause; the input has to be moved before conversion.

Select a recording to create a MIDI draft locally.

The selected audio is decoded in your browser; it is not uploaded to a server.

Three causes, three signatures

Match the symptom to the input, not to the tool.

Signature one: one steady wrong note replaces a phrase. A second voice was present, or the fundamental fell outside what the search can resolve. The estimator returns one pitch per frame, so the loudest stable period wins and everything else is discarded. You see fewer notes than you played, all at the same wrong pitch.

Signature two: a correct note breaks into several short notes. The pitch moved. The current converter only continues an existing note when the next frame stays within one semitone of it, so a bend, a slide, a wide vibrato, or a pitch that drifts between two semitones opens a new note each time it crosses the boundary. On the highest sensitivity setting the minimum note length is long enough that those fragments are dropped instead, which looks like missing notes rather than extra ones.

Signature three: the octave is wrong but the melody is right. The estimator chose a harmonic. This is the most common outcome on low, harmonically rich material, and it is also the one that looks most like a bug because the contour of the phrase is preserved.

These are different failures. Editing the piano roll will not help the first one, quantising will not help the second, and transposing every note down twelve semitones only helps the third if the detector was consistently one octave high.

One rule explains most of it

A note continues only if the next frame stays within one semitone.

The detector analyses the audio in short overlapping frames, estimates one pitch per frame, rounds that estimate to the nearest semitone, and then groups consecutive frames into notes. The grouping rule is narrow: if the new frame's pitch differs from the note in progress by one semitone or less, the note is extended. Anything larger starts a new note.

Two consequences follow directly from that rule, and both are visible in real output. First, a slow slide across two semitones becomes two notes with a seam at the crossing point, not one note with a bend, because the exported file has no pitch-bend data at all. Second, a note that is briefly interrupted, by a consonant in a vocal take or by a re-articulation on a guitar, becomes two notes even when the pitch never changed.

The same code path decides velocity: each note carries a single value taken from the loudest frame inside it, capped well below the MIDI maximum. A phrase that swells and fades exports as one flat dynamic level, which is another reason converted parts sound mechanical before you touch them.

Measured on this converter

Below roughly 170 Hz, a pure tone collapses to one wrong note.

I generated pure sine tones at 44,100 Hz, mono, two seconds each, with short fades at both ends, and ran them through the same detection logic the page uses. Every tone was tested at all three sensitivity settings. The results below are the notes that came out, not the notes that went in.

Input toneNote it should beNotes exportedWhat came out
40 HzE1 (MIDI 28)1MIDI 89, about 1,423 Hz
55 HzA1 (MIDI 33)1MIDI 89, about 1,423 Hz
110 HzA2 (MIDI 45)1MIDI 89, about 1,423 Hz
150 HzD3 (MIDI 50)1MIDI 89, about 1,423 Hz
160 HzE3 (MIDI 52)0No notes at all
170 HzF3 (MIDI 53)1MIDI 53, about 197 Hz
220 HzA3 (MIDI 57)1MIDI 57, about 222 Hz
440 HzA4 (MIDI 69)1MIDI 69, about 444 Hz

How to read this table. The 40 Hz row matches a reading already published on this site, which is why the method is stated in full: these are offline runs of the detector logic, not a recording of the browser's output, and the published three-tone test reproduces exactly under the same harness. The constant 1,423 Hz result below 160 Hz is the estimate sitting at the shortest lag the search evaluates, which is the signature of a period that is too long to be found inside the analysis window.

What this does not say. These are pure tones with no harmonics. A real bass note or a low piano note carries strong overtones, and the estimator may lock onto one of those instead, which produces a different wrong answer rather than the same one. Treat the table as the clean-signal case and test your own material.

What actually helps

Change the input before you change the notes.

  • Transpose the part up an octave before converting. Then move the exported notes back down in your DAW. This moves the fundamental into the range the detector can resolve, and it keeps the timing you already had.
  • Convert one line at a time. If the recording contains a chord or two instruments, separate it first. A single tracked pitch cannot represent two simultaneous fundamentals, and no sensitivity setting changes that.
  • Flatten the dynamics of the source, not the output. Because each exported note carries one velocity value, a take with heavy compression converts to something closer to what you played than a very dynamic take does.
  • Expect seams at slides. If the phrase bends, plan to redraw that section. The exported file stores discrete notes only, with no continuous pitch information, so a bend cannot survive the round trip.

If the part is genuinely polyphonic, a monophonic estimator is the wrong tool regardless of tuning. Compare the polyphonic workflows in the polyphonic audio to MIDI guide before spending time on cleanup, and use the measured converter boundaries to see which inputs are excluded by design.

FAQ

Wrong-note questions

Why does every note come out as the same pitch?

That is the signature of a pitch estimate that cannot resolve the period it is looking for. In the test above, pure tones from 40 Hz to 150 Hz all exported as MIDI 89. Transpose the source up an octave, convert again, and move the result back down.

Is the octave error a bug I can report?

It is a limit of a single-pitch estimator on harmonically rich material, not a crash. The exported contour is usually right while the octave is wrong, which is why the fix is to move notes by twelve semitones in the DAW rather than to re-record.

Would a different sensitivity setting fix wrong notes?

Sensitivity changes the loudness threshold and the minimum note length, so it changes which frames count. It does not change the pitch decision inside a frame. If the pitch itself is wrong, the setting will not repair it.

Can I convert a chord and delete the extra notes?

Not usefully. The detector returns one pitch per frame, so a chord is not stored as several notes waiting to be filtered. Separate the parts first, or use a tool built for polyphonic transcription.