MP3 to MIDI: The Header Chunk That Fixes the Grid Before Any Note
A Standard MIDI File opens with fourteen bytes: the type MThd, a length of six, and three 16-bit words named format, ntrks and division. None of the three is a note, a tempo or an instrument. They decide how every delta-time after them is counted, which is why two files holding the same notes can still disagree about where the bar lines fall.
Short answer
- Fourteen bytes come first. Chunk type, a 32-bit length of six, then three 16-bit words, most significant byte first.
- Format has three defined values. 0, 1 and 2, and only format 0 fixes the number of tracks.
- Bit 15 splits division in two. Clear means ticks per quarter-note; set means frames per second plus ticks per frame.
- -29 is 30 drop-frame. The stored integer is neither the real frame rate nor its name.
Fourteen bytes, then nothing but events
The header chunk is spelled out as
<Header Chunk> = <chunk type><length><format><ntrks><division>.
The type is the four ASCII characters MThd, the length is a 32-bit number equal to six written high
byte first, and the data section is three 16-bit words stored most significant byte first. Four
plus four plus six: fourteen, and then the first track chunk begins.
The length is not a constant to hard-code: more header parameters may be added later, and a reader must honour the length even if it exceeds six.
Word one: format says what a track is
Three values are specified. Zero is a single multi-channel track, one is one or more simultaneous tracks of a sequence, two is one or more sequentially independent single-track patterns. The last two differ in time, not layout: in format 2, track two is a separate pattern played instead of track one, not alongside it.
Word two, ntrks, counts track chunks, and is always one in a format 0 file. A converter writing one track per instrument has therefore already left format 0. An unknown format value does not make a file unreadable either: its track chunks may still be read as format 1 or 2.
Word three: one bit changes the unit
If bit 15 of division is zero, bits 14 through 0 count delta-time ticks per quarter-note. Fifteen bits hold up to 32,767, and the specification's own example reads division 96 as an eighth-note interval of 48 ticks.
If bit 15 is one, the same word changes units. Bits 14 through 8 hold one of four negative values, -24, -25, -29 or -30, in two's complement, standing for frames per second; the second byte is the resolution inside a frame; the specification lists 4, 8, 10, 80 and 100. Twenty-five frames per second at 40 units per frame gives millisecond tracks, since 25 times 40 is 1,000 ticks per second.
Why -29 is not 29 frames
The four values match the four standard SMPTE and MIDI Time Code formats; -29 corresponds to 30 drop frame, which runs slightly under 30 frames per second. Its worked example makes the encoding checkable: thirty-frame code at 80 units per frame is E250 hex. E2 sets bit 15 and leaves 0x62, which is 98 unsigned and -30 signed; 50 hex is 80. Thirty times 80 is 2,400 ticks per second, one tick every 0.417 milliseconds.
What a converted file inherits
In metrical mode a tick is a fraction of a quarter-note, so a bar grid follows from the division and the time signature, and a tempo event changes how long a tick lasts without moving a note. In time-code mode delta-times are subdivisions of a second, so the tick keeps its length whatever the tempo map says and the header describes no musical grid at all.
Nothing later repairs a wrong header: track chunks are defined identically in all three formats, and no event restates the division. The six bytes also hold no tempo, time signature, key or instrument. When a converted file imports with notes off the grid, byte thirteen is the first thing to read.