Short answer: the file usually has no tempo event in it at all. This site writes none. With no FF 51 03 Set Tempo event, each player falls back to its own default — commonly 120 BPM — and the notes land at the wrong time even though every note is correct. Fix it by setting the tempo in your DAW before you quantise, not by stretching the notes.
Below is exactly what we found in 24 downloaded .mid files, and a one-variable test showing what a single tempo event does to a file whose notes have not changed by one byte. Everything was parsed independently with @tonejs/midi 2.0.28 on 5 November 2026.
| File set | Files | Set Tempo events | Tempo written | PPQ | First note (tick / s) |
|---|---|---|---|---|---|
| This site, 28 October 2026 build | 6 | 0 | none | 480 | 245–312 / 0.255–0.325 |
| This site, current build (3 November 2026) | 6 | 0 | none | 480 | 312 / 0.325 |
| SoundToMIDI, 28 October 2026 | 6 | 6 (one each) | 120 BPM | 480 | 312 / 0.325 |
| Stayput, 28 October 2026 | 6 | 6 (one each) | 120 BPM | 480 | 267–312 / 0.278–0.325 |
The two other converters wrote 120 BPM into all six of their files. This site wrote a tempo into none of its twelve. All 24 files use 480 ticks per quarter note. That difference — a seven-byte event, present or absent — is the whole subject of this page.
The six clips are the same synthetic test set described on the accuracy test page: single notes, three-note chords and a drum pattern, each in a dry and an echo-added version. Events occur every 0.5 seconds starting at 0.3 seconds; the clips are five seconds long at 120 BPM. Each clip was converted, the .mid file downloaded, and the file parsed from its bytes. No number here is taken from a converter's marketing copy or from a screenshot.
Two limitations belong with that sentence. The clips are synthetic and contain a deliberately added second harmonic; they are not recordings of real instruments. Each clip was converted once per site. That is enough to say what these particular files contain, and not enough to say which converter is better at anything.
These six are from the current build, the one that runs outputToNotesPoly(frames, onsets, 0.5, 0.3, 5) followed by a same-pitch merge at 3 frames (about 35 ms). Parsed 5 November 2026. "First note" is the earliest note event in the file.
| Clip | File size | PPQ | Tempo events | Notes | First note (tick) | First note (s) | End (s) |
|---|---|---|---|---|---|---|---|
| Single notes, dry | 129 B | 480 | 0 | 8 | 312 | 0.325000 | 3.984375 |
| Single notes, with echoes | 122 B | 480 | 0 | 8 | 312 | 0.325000 | 4.379167 |
| Three-note chords, dry | 257 B | 480 | 0 | 24 | 312 | 0.325000 | 3.984375 |
| Three-note chords, with echoes | 258 B | 480 | 0 | 25 | 312 | 0.325000 | 4.367708 |
| Drum pattern, dry | 129 B | 480 | 0 | 8 | 312 | 0.325000 | 3.995833 |
| Drum pattern, with echoes | 122 B | 480 | 0 | 8 | 312 | 0.325000 | 4.379167 |
Every first note sits at tick 312. At 480 ticks per quarter note, 312 ticks is 0.65 of a quarter note, which at 120 BPM is 0.325 seconds. The number is identical in all six files because the clips all start the same way, not because the converter knows the tempo. A converter that writes notes in ticks has no need to know the tempo at all.
A Standard MIDI File stores tempo as a meta event: FF 51 03 followed by three bytes giving microseconds per quarter note. The two other converters' files contain ff 51 03 07 a1 20 in each of their six files. 07 a1 20 is 500,000 microseconds; 60,000,000 / 500,000 = 120 BPM.
We searched all twelve files from this site for those bytes and found zero matches. That is the entire difference. There is no tempo map in these files: the header's tempo list is empty in all twelve.
What the player does instead. When a MIDI file has no tempo event, software picks its own default. Most DAWs and the parser used here use 120 BPM, which is why a file with no tempo often sounds right by luck on 120 BPM material. "Usually 120" is not a value stored in the file. A different host with a different default will place the same 312 ticks somewhere else in time.
To separate "the notes moved" from "the tempo changed", we took one 129-byte file (the current build's single-notes-dry output, 8 notes, PPQ 480) and inserted a single seven-byte Set Tempo event at the start of its track. The note bytes were not touched. We then parsed the original and the three variants with the same parser on 5 November 2026.
| File | Tempo bytes | Microseconds / quarter | First tick | First note (s) | Whole file (s) |
|---|---|---|---|---|---|
| Original (no tempo event) | none | not stored | 312 | 0.325000 | 3.984375 |
| 60 BPM inserted | ff51030f4240 | 1,000,000 | 312 | 0.650000 | 7.968750 |
| 120 BPM inserted | ff510307a120 | 500,000 | 312 | 0.325000 | 3.984375 |
| 240 BPM inserted | ff510303d090 | 250,000 | 312 | 0.162500 | 1.992188 |
The tick position never moves. The seconds double at 60 BPM and halve at 240 BPM. Inserting an explicit 120 BPM reproduces the original timings exactly, which is how we know this parser's fallback is 120. It also shows why "the file plays too fast" is a tempo problem and not a note-placement problem: stretching the notes would move the ticks, and the ticks are fine.
The arithmetic is reversible, so you can check any row yourself. With seconds = ticks × 60 / (BPM × PPQ) and 312 ticks at 480 PPQ:
The inverse, ticks = seconds × BPM / 60 × PPQ, is what you need when you know where a note should land in time and want to check whether your grid is set correctly.
It is tempting to read the two other converters' 120 BPM as evidence that they detected the beat. This test cannot support that conclusion, and we are not going to imply it.
All six source clips are 120 BPM by construction, with a note every 0.5 seconds. A converter that always writes 120 and a converter that correctly detects 120 produce the same bytes here. Separating the two would require input at several different tempos, which this test did not run. The 120 in those files is a fact about the files; what produced it is unmeasured.
This site takes the other route: it writes no tempo event and leaves the decision to the player. Neither behaviour is a tempo estimate. If your source is not 120 BPM, you will need to set the tempo yourself in either case.
.mid to recover..mid contains an FF 51 03 event. Otherwise the next program to open it will silently fall back to its own default again..mid files at 480 PPQ. That is what these four converters produced for these clips; another converter may choose a different PPQ, and then the tick column will differ.To try this with your own audio, use the MP3 to MIDI converter, the WAV converter or the piano converter. The MIDI to MP3 tool renders a .mid back to audio if you want to hear the timing difference. The accuracy test page describes the six clips and the matching method in full.