MP3 to MIDI Tempo: What a Tempo Map Stores That a BPM Number Cannot
A MIDI file does not store beats per minute. It stores microseconds per quarter note as a three-byte integer, and every tempo you read out of a converted file is sixty million divided by that integer. One event gives the file one ruler; a tempo map lets the ruler change partway through, so only a map can follow a performance that speeds up.
Tempo, answered
- Time per beat, not beats per time. The event carries microseconds per quarter note in three bytes, so the file contains 500000 and never 120. Sixty million divided by that integer is the BPM you read.
- One number means one ruler. A single event fixes one tempo for the whole file. A map carries one per stretch, so "the tempo" is only defined when the list has one entry.
- Ticks are tempo-free. Tick positions come from the division field and the delta-times. The same 384 ticks are 2.0 seconds at 120 BPM and 4.0 seconds at 60 BPM, with no note changed.
- Three fields have to agree. Tempo, time signature and division are separate, and the grid a quantize step snaps to is the product of all three.
The file stores time per beat, not beats per time
Set Tempo is FF 51 03 tttttt, microseconds per MIDI quarter-note. The specification's own example carries 500000 and comments it as 500,000 usec per quarter note, or 120 beats per minute, so the file never holds the number 120: sixty million divided by 500,000 gives it. The specification calls the inversion deliberate, for exact synchronisation with a time-based protocol.
Three bytes is 24 bits, so the field holds 16,777,216 values. The largest is a tempo of 3.576 BPM; the smallest is 60,000,000 BPM. The musical range sits low: 120 BPM occupies 500,000, or 2.98 percent of the maximum.
A tempo map is a list, and a list has no single value
The specification calls the collection a tempo map: the thing that describes the tempo throughout the track. Each Set Tempo event redefines the ruler from its own position onward, so a file with several is cut into as many stretches, each with its own ticks-to-seconds conversion. Anything before the first event falls back to 4/4 and 120 beats per minute.
So a BPM readout is a summary, not a fact, and a file with one entry cannot express a speed-up. Placement hides it too: tempo information belongs in the first MTrk chunk, so in a format 1 file it sits in a track separate from the notes, while a format 0 file scatters it.
Ticks are tempo-free, seconds are not
With bit 15 of the division field clear, the remaining bits hold ticks per quarter note, and the specification's example uses 96. Delta-times are counted in ticks; only the tempo map turns them into seconds. One 4/4 bar is 384 ticks: 2.0 seconds at 120 BPM, 4.0 seconds at 60 BPM, with no note changed.
Fixing a wrong tempo event changes the duration of everything after it and leaves every tick position and velocity as it was.
Three fields have to agree, and they can disagree
Tempo is FF 51 03. Time signature is FF 58 04 nn dd cc bb, where the denominator is a negative power of two, so 2 means a quarter note. The division is a third field, in the header. A correct tempo with a wrong denominator misplaces the bar lines, and a time signature with the division set to SMPTE ticks has no quarter note at all.
What to check in a converted file
Count the Set Tempo events, not the BPM. One event means the file asserts one constant tempo for its whole length; more than one means it carries a map. Because note positions are ticks, the tempo cannot be recovered from the notes: it lives only in the tempo events, or in the 120 BPM fallback.