MIDI File Type 0 vs 1

People usually ask about "type 0 vs type 1" as if it were a choice made in an export dialog. On disk it is two bytes. This page opens one real .mid, reads its chunk table, changes that one field three times, and re-parses every copy from scratch. No conversion is claimed and no new audio is used.

1. What the 14-byte header actually declares

The source is the 169 B MIDI file published on this site on 24 October 2026 — the actual downloaded output of running the test WAV through the browser converter. Its first 14 bytes are 4D 54 68 64 00 00 00 06 00 01 00 02 01 E0. Read as a Standard MIDI File header:

After the header come two real MTrk chunks: one at offset 14 with a declared length of 8 B (an empty conductor track), and one at offset 30 with a declared length of 131 B (the notes). That is why the whole file is 14 + (8+8) + (8+131) = 169 B. See what is a MIDI file for a beginner-level walk through the same bytes, and single-track vs multitrack MIDI for what the second chunk contains.

2. One variable, three values: the format field

Each injected copy was made by writing a 16-bit value at offset 8 and nothing else. The high byte stays 00, so the only byte that actually differs is offset 9. Every copy was then re-opened with a fresh @tonejs/midi 2.0.28 parser instance; no parsing result was reused between files.

The three copies have different hashes, each is still exactly 169 B, and in each one a byte-for-byte comparison against the source finds a single difference at offset 9 — the remaining 168 B are untouched. All three parse without an exception, all three return 14 notes and PPQ 480, and all three report 2 tracks where the source reports 1. Value 3 is not a legal SMF type, so this is not "type 3 behaves specially": the parser is branching on whether the field equals 1.

3. Why the parser sees 1 or 2 tracks

The extra track is not new music. The source declares two MTrk chunks, and the first one holds only a track-name meta event and an end-of-track event — zero notes. With the format field equal to 1, the independent parser drops that empty conductor track and returns 1 track holding all 14 notes. With any other value it keeps the empty chunk as a separate track, so the result is 2 tracks: one 0-note track and one 14-note track. The note list is identical in all four files:

Seconds use the documented player default of 120 BPM, because this file contains zero tempo events: seconds = ticks × 60 / (120 × 480). The 480 is the division field, not a tempo — separate that distinction in PPQ and ticks and MIDI tempo. Note duration here is a property of note-on/note-off pairs, and changing the format field does not touch a single one of them.

4. Formula check, recomputed from the file

None of the sizes below are estimated. Each is recomputed from the file's own length fields and then compared with the bytes on disk.

The division field is 01 E0 = 480 decimal. Format 1 is 00 01 because the field is big-endian: readUInt16BE(8) returns 1, not 256. Writing 0, 2 or 3 changes only the low byte; writing a value above 255 would also change the high byte, which is why this experiment used small values.

5. The declaration mismatch control

The format field is a declaration, not a container. A second one-byte edit shows what happens when a different declaration disagrees with the physical chunk table. Changing the declared MTrk count at offset 11 from 2 to 1 leaves both real chunks in the file, keeps the format field at 1, and keeps the size at 169 B — but the parser then reads only the first (empty) chunk.

This is the structural check that matters: "the file opens" is not the same claim as "the file still has its notes". The control copy parses without an exception and reports 0 notes even though the 131 B note chunk is still sitting at offset 30, unmodified. A byte-equal test on the header alone would have passed; re-parsing the whole file is what catches the loss. If a DAW import shows an empty project, check the declared chunk count before blaming the notes — then see clean up MIDI after conversion for the artefacts that appear in real conversions.

6. What type 0, 1 and 2 mean when you import

• Type 0 is specified as a single track containing all events, with channel numbers used to keep parts apart. The source file here is not type 0: it declares two chunks and its format field reads 1.
• Type 1 is specified as one or more tracks intended to be played together, usually with tempo and time-signature information in a first conductor track. The published 169 B file uses this form: a conductor chunk plus a note chunk.
• Type 2 is specified as independent tracks that are not meant to be played simultaneously. Nothing in this experiment makes the notes independent — writing 2 into the field changed the parser's track count, not the music.

What the field means to a DAW is a specification question; what it did to this one file is a measurement. This site outputs a single-track .mid with one note track. If you need the same notes as text, compare MIDI vs MusicXML; if you need audio back from a MIDI file, use the MIDI to MP3 tool.

What this page does not cover

• Transcription accuracy or converter comparisons. Every edit here changes a header byte of an already-downloaded file; no audio was re-converted and no tool's performance was measured.
• Stems, source separation or per-instrument transcription. The injected files are byte edits of one single-track MIDI, not multitrack audio analysis.
• MIDI 2.0, UMP or MIDI-CI. Everything on this page is a Standard MIDI File on disk.
• Automatic tempo or BPM detection. The source has zero tempo events; 120 BPM is a documented player default used only in the time formula.
• Guaranteed DAW behaviour. The track counts above are what one independent JavaScript parser returned on 9 November 2026. Other importers may follow the specification more strictly; the byte-level readings do not depend on which importer you use.