Why Your Converted MIDI Opens at the Wrong Tempo
Last updated 10 October 2026
Measurement scope: Figures below record historical tests of the GAME Vocal/Fast route in desktop Chrome. The original test date and complete device specifications were not recorded. These numbers do not predict Piano, Basic Pitch, Full Song Fast or HQ Local performance. Guidance reviewed 10 October 2026.
The short answer: most converters write 120 BPM into every file without looking at your audio, and that is the whole reason the grid is wrong. This one measures the tempo from the note onsets and writes the measured value instead. When there is no steady pulse to measure — a spoken-word clip, a free-tempo piano piece, a drum-less ambient track — it falls back to 120 and tells you it did.
Either way the notes are in the right places. The tempo controls the grid drawn over them, and getting it wrong is what makes a perfectly good transcription look like nonsense in a DAW: bar lines in the wrong places, a metronome that drifts, an editor that snaps your notes to beats that are not there.
Why a fixed 120 BPM ruins the grid
A MIDI file carries its tempo as a number of microseconds per quarter note. 500,000 µs is 120 BPM, and it is the value most converters write, for every file, because it is the MIDI standard's own default and it never has to be computed. Your 70 BPM ballad and your 160 BPM drum loop both come out declaring 120.
The notes themselves are stored as tick positions, computed from each note's start time in seconds:
ticks = seconds × 1,000,000 × 480 ÷ tempo
Read that carefully, because the tempo appears on both sides of the problem. If a converter writes 500,000 µs but computes the ticks as if the tempo were something else, the two disagree and the file is internally inconsistent. That is the failure mode to watch for, and it is why "just measure the tempo" is only half the job.
What this converter does instead
Two steps, and the second is the one that matters.
It measures. The note onsets are grouped into rhythmic events — several notes starting together count as one event, because a chord is one beat, not three — and a pulse is fitted to the gaps between those events. The fit is scored, and a confidence value comes out with it. Steady material scores high; rubato, swing and spoken word score low, and the low scores are discarded rather than guessed at.
It uses that one number twice. The measured tempo is written into the file as a real tempo event, and the same value is used to convert every note's start time into ticks. Because both sides use the same tempo, playback at the file's own tempo reproduces the original timing exactly. You get the grid and the sync, which is the combination that a fixed 120 BPM cannot give you.
You can see the result without opening a DAW. Convert a file and the panel reports the tempo and how confident the measurement was — 128 BPM (87% confidence) — or tells you plainly that it could not find a pulse and is using 120.
When it falls back to 120, and how to tell
Three cases, and the panel distinguishes them:
| What the panel says | What it means | What to do |
|---|---|---|
| 120 BPM (92% confidence) | The music really is at 120. The number was measured. | Nothing. The grid should already line up. |
| 104 BPM (61% confidence) | Measured, but the performance is loose enough that the fit is not airtight. | Try it. If the bar lines drift, set the tempo by hand in your DAW. |
| not measurable — using 120 | No regular pulse, or too few notes to fit one to. 120 here is a fallback, not a reading. | Set the tempo yourself, or work without a grid. |
That last row is the honest one. A converter that reports a confident number for a free-tempo piano improvisation is not measuring anything — it is guessing, and a wrong guess is worse than an admitted fallback, because you cannot tell the difference from the number alone.
Why the number may not match the BPM you counted
Half and double time, and this one catches everybody.
A pulse with one onset every half second is described equally correctly as 120 BPM, as 60 BPM, and as 240 BPM. Nothing in the audio says which of those is the "real" tempo — they are the same onsets read at different metrical levels, and which one a musician would write down depends on the genre, the phrasing and the convention, not on the signal.
This converter resolves that by picking the reading closest to 120 BPM, on the grounds that most music lives in that range and it is the least surprising default. So if you tap along and count 60 while the file says 120, you are both right. The notes are identical either way; only the bar lines move. If you want the other reading, set the tempo in your DAW — see the warning below first.
The trap that still applies: changing the tempo breaks the sync
Because note positions are tick values computed from the tempo stored in the file, changing the playback tempo rescales every one of them. Set 90 BPM on a file written at 120 and the whole performance plays 120 ÷ 90 ≈ 1.33× slower than the recording.
So decide which you want before you touch the tempo field:
| What you want | What to do | What you give up |
|---|---|---|
| Play the MIDI against the original recording | Leave the tempo as the converter wrote it. Drop the original audio into the same project and the two line up. | If the measurement landed on the half- or double-time reading, the bar lines will not match your count. |
| Edit on a grid that matches how you count the song | Set the project tempo to the value you want, then quantise the notes and drag the first downbeat onto bar 1. | The notes now play at a different speed from the original audio. |
| Both at once | Set the tempo you want, then time-stretch the reference audio by the ratio between the two tempos so it matches the new playback speed. | You are time-stretching the audio, which is a lossy edit. |
If your DAW asks whether to use the tempo stored in the MIDI file when you import it, say yes. That keeps playback identical to the recording. If your DAW instead plays MIDI clips at the project tempo, the notes stay in sync only while the project sits at the file's own tempo.
The bar lines have a second problem
Even with the tempo right, the bar lines can still be wrong, because the time signature is written as a constant. Every file this converter writes declares 4/4, regardless of what the recording is in. A waltz in 3/4, a piece in 6/8, a riff in 5/4 — all of them get bar lines four beats apart.
Estimating the time signature reliably is a harder problem than estimating the tempo, and guessing it would move the bar lines in a way that is harder to spot than leaving them at a known default. So it is written as 4/4 and said out loud. If your song is not in 4/4, set the time signature in your DAW after importing; the notes are unaffected, only the bar lines move.
If the pitch bends sound exaggerated
One more fixed value worth knowing about. The file sets its pitch bend range to ±2 semitones with an RPN message, and scales the bend data to that range. Many synths default to ±12 semitones. Load the file into one of those and every bend will be roughly six times too wide — vibrato turns into a siren. Set the instrument's bend range to 2 semitones and it snaps back.
What is actually inside the file
Worth having in front of you when something looks odd. Every MIDI file this converter writes contains exactly this:
| Format | 0 — a single track containing every note |
| Division | 480 ticks per quarter note |
| Tempo | Measured from the note onsets; 120 BPM when no steady pulse can be found |
| Note positions | Computed from that same tempo, so they land at their true times in the recording |
| Time signature | 4/4, fixed |
| Track name | mp3 to midi |
| Notes | Note-on with velocity from the detected amplitude; note-off with release velocity 64 |
| Clean-up | Note fragments joined and very short notes dropped; tempo measured from the onsets |
| Pitch bend | Range ±2 semitones, written as RPN 0 |
| Analysis | Audio down-mixed to mono and resampled to 44,100 Hz before the model runs |
The tempo and the notes are both derived from your audio. The time signature and the bend range are fixed, and the panel is the place to check which is which for any given file.
Frequently asked questions
Why does my converted MIDI open at 120 BPM?
Because no steady pulse could be measured, so the file fell back to the MIDI default. This converter estimates the tempo from the note onsets and writes the measured value; it only writes 120 when there is no regular beat to measure, or too few notes to measure one from. The panel says which of the two happened.
Does this converter measure the tempo, or hard-code it?
It measures. Onsets are grouped into rhythmic events, a pulse is fitted to the gaps between them, and the result is written as a real tempo event. The tick positions are computed from that same tempo, so the bar lines match the music and the notes stay at their true times.
Why is the BPM not the number I counted?
Half and double time. One onset every half second is 120, 60 and 240 BPM simultaneously — the same onsets read at different metrical levels. The converter picks the reading closest to 120 BPM. The notes are identical whichever reading wins; only the bar lines and the tempo field change.
Are the notes in the wrong place, or only the tempo?
Neither, for the tempo. Note positions are computed from the same tempo that is written into the file, so playback at the file's own tempo puts each note where it was in the recording. What can still be wrong is the time signature, which is always 4/4.
Should I type the song's real BPM into the tempo box?
Only if you want a different grid, because it costs you the sync. Every note gets rescaled: at 90 BPM a file written at 120 plays about 1.33× slower than the recording.
The pitch bends sound wrong in my synth. Why?
The file sets its bend range to ±2 semitones. If your synth is set to ±12, the same bend data sounds roughly six times too wide. Set the instrument's bend range to 2 semitones.