MP3 to MIDI: Why the Divisions Ceiling Cannot Place an Eighth Note
A converted file fixes one integer for the whole grid: how many ticks make up a quarter note. MIDI allows up to 32,767. MusicXML advises staying at or below 16,383. Both ceilings are odd numbers, and an odd grid has no tick exactly halfway through a quarter note.
Short answer
- 15 bits, so 32,767. That is the MIDI header's own limit; 96 is the value its example uses.
- 16,383 is the advice's ceiling. Halve it and you get 8,191.5, which is no tick at all.
- The odd number does hold triplets. 16,383 divided by 3 is exactly 5,461.
- One step up reverses the test. 16,384 halves exactly down to a 256th note, and holds no triplet.
Two ceilings for one integer
When bit 15 of the header's division word is zero, the remaining 15 bits count ticks per quarter note, so the field stops at 32,767. MusicXML, describing its own divisions element, adds a compatibility line: "do not have the divisions value exceed 16383." The same quantity therefore has two limits, and the lower one is not a power of two.
Both ceilings are odd
32,767 is 2 to the 15th minus 1, and 16,383 is 2 to the 14th minus 1, so neither is divisible by 2. At division 16,383 an eighth note falls at 8,191.5 ticks; at 32,767 it falls at 16,383.5. There is no tick at either place, so a writer must choose the one above or the one below. A 32nd note is worse: 2,047.875 ticks on the lower ceiling.
The odd ceiling does hold triplets
Three divides 16,383 exactly, giving 5,461 ticks per triplet eighth, and three of those come to 16,383, which is the whole quarter with nothing left over. That is the opposite of the usual complaint. The ceiling MusicXML recommends is a grid where a triplet is exact and an eighth note is not, so the first subdivision most people check is the one this number cannot express.
One step up reverses the test
16,384 is 2 to the 14th. Halve it six times and every step lands on a whole tick: 8,192, 4,096, 2,048, 1,024, 512 and 256. A 256th note is exact at that division, and so is every longer value. Divide 16,384 by 3 instead and the result is 5,461.33. The two grids fail opposite tests, and neither number is the better grid in general.
Why 16,383 and not 16,384
Neither document says. The MusicXML note gives the number without a reason, and the MIDI specification never mentions 16,383 at all. The value factors as 3 times 43 times 127, which is not a shape anyone designs a clock around. It reads like a compatibility line inherited from somewhere else rather than a resolution chosen for music. A grid is normally picked by what it has to divide; this one looks picked by what another program will accept.
What a converted file usually uses
Converters rarely go near either ceiling. The specification's own example uses 96 ticks per quarter note, and states the consequence: "if division is 96, then a time interval of an eighth-note between two events in the file would be 48." 480 is the other common value. Both halve and both divide by three, which is what makes them workable grids.
What to check
Read the header's division before blaming the converter for timing. If it is 96 or 480, the grid is not your problem. If it is 16,383, expect eighth notes to sit a fraction off, and expect a notation program to round them on re-export. songscription's cleanup guide puts that work inside the DAW — "set the correct tempo and time signature so the bars line up with the music" — and jukeblocks warns that live playing will "drift against a fixed grid" whatever the resolution is.