MP3 to MIDI: Why Triplets Do Not Fit a Tick Grid
The header of a converted .mid file declares one integer: how many ticks make up a quarter note. That number decides whether a triplet can exist in the file at all. If it is not divisible by three, every triplet in the recording was rounded before you saw it, and nothing in the piano roll says so.
Short answer
- The grid is one integer. A triplet needs ticks-per-quarter divisible by 3.
- Five values pass. 96, 120, 192, 384 and 480; 128 and 100 fail.
- 12 is the smallest grid that holds sixteenths and triplet eighths together.
- No byte marks a triplet. Only its position in ticks survives.
The file states a grid, not a rhythm
The specification gives division one job: "If bit 15 of <division> is zero, the bits 14 thru 0 represent the number of delta time "ticks" which make up a quarter-note." That is the container's entire rhythmic vocabulary. No chunk, byte or meta event names a note value; a quarter note is not stored, it is however many ticks the header declares. The one note value the specification works out is a halving: "if division is 96, then a time interval of an eighth-note between two events in the file would be 48." The words triplet, tuplet, sixteenth, swing and shuffle appear zero times in it.
The test is divisibility by three
A triplet eighth takes a third of a quarter, so it needs division divided by three ticks. At 96 that is 32; at 120, 40; at 192, 64; at 384, 128; at 480, 160. At 128 the result is 42.67 and at 100 it is 33.33, and no tick sits at either place. A file whose header declares 128 ticks per quarter has no position for a triplet: the writer must pick tick 42 or 43, and both are wrong.
Sixteenths and triplets barely meet
At division 96, sixteenths land on ticks 24, 48, 72 and 96, and triplet eighths on 32, 64 and 96. They share the beat and nothing else. In a bar of 4/4 that is 16 sixteenth positions plus 12 triplet positions minus 4 shared, so 24 distinct onsets. The two grids do not merge; they touch at the beat.
Twelve is the smallest grid that holds both
Sixteenths need the quarter split by 4, triplet eighths need it split by 3, so the smallest common division is 12: a sixteenth is 3 ticks, a triplet eighth is 4. Every common resolution above it — 24, 48, 96, 192, 384, 480, 960 — is a multiple of 12. A power of two never is.
A finer grid does not buy a shorter note
Note values halve: a sixteenth is a quarter over 4, a 32nd over 8, a 64th over 16, a 128th over 32, a 256th over 64. At 96 the 128th is 3 ticks and the 256th is 1.5, so the shortest note the grid places exactly is a 128th. At 480 the 128th is 15 ticks and the 256th is still 7.5, because 480 is not divisible by 64.
Round positions, not durations
Rounding each triplet onset to the nearest tick keeps the error under half a tick and never lets it build. Rounding one triplet duration and adding it three times does the opposite: 43 ticks times 3 is 129 against a 128-tick quarter, so the beat arrives one tick late, every beat. At 120 BPM in a 128-tick file a tick is 3,906 microseconds, which puts the bar 15.6 milliseconds behind.
What this means for a converted file
songscription says its MIDI is free-time by default and suggests quantizing inside the DAW, and its cleanup guide warns that over-quantizing flattens the feel. Both are fair, and neither says what the grid can hold. Read division first: divide by three, and if the remainder is not zero, the triplet you hear was never in the file. Expect the notation program to re-spell it too. MusicXML defines <divisions> with the instruction that the value must be "chosen to take tuplets into account" — a warning the MIDI specification never gives, because it has no tuplet to warn about.