MIDI PPQ and Ticks: What the Two Division Bytes Change

1. Fourteen bytes that decide how long a tick is

The MIDI file used here (169 B, SHA-256 90795f6ff271cb92…) is the actual downloaded output of running this site's test WAV through the browser converter on 24 October 2026. Its first 14 bytes are the MThd header. Read byte by byte:

The whole file is 14 + 4 + 4 + 8 + 4 + 4 + 131 = 169 bytes: a 14-byte header, then a first MTrk chunk (4-byte ID, 4-byte length, 8-byte payload containing only a track name and end-of-track), then a second MTrk chunk (4 + 4 + 131 bytes) holding the note events. Independent parsing with @tonejs/midi 2.0.28 on 8 November 2026 returns 14 notes, 0 tempo events, PPQ 480 and a total of 7627 ticks. Only the second chunk contains notes, which is what "one note track" means for this site's output; the header still declares two track chunks.

Everything that follows changes offset 12–13 and nothing else. That pair of bytes is unsigned big-endian: 01 E0 is 1 × 256 + 224 = 480. It is the number of ticks the file assigns to one quarter note.

2. One two-byte change, three files, 167 identical bytes

Three files were produced from the published source. The 480 version is a byte-for-byte copy; the other two differ only at offset 12–13. Each remains 169 B. Each was re-opened independently with @tonejs/midi 2.0.28 — a structural check, not just a byte comparison — and all three parse to the same 14 notes with identical pitch, velocity, start tick and duration tick values.

Reading the table the other way round: if you only know the bytes, you cannot tell how long the music lasts. The file says "note 3 starts at tick 959"; it does not say how many seconds tick 959 is. That conversion needs both the division and a tempo. This file has no tempo event, so a player falls back to a default of 120 BPM. With 480 ticks per quarter, one tick is 60 / (120 × 480) = 1/960 s; with 960 it is 1/1920 s. Doubling the resolution halves every elapsed time without moving a single event.

The variant files are working research artefacts and are not hosted on this site; the source MIDI above is the one published file you need to reproduce the edit. Changing the division of a file that also contains tempo events changes seconds in the same way, but it does not change the stored BPM.

3. Every note at three resolutions

Each row is one note parsed independently from the 169 B source. The tick columns are raw file values and are identical in all three variants; only the three seconds columns move. The odd rows are the eight intended notes of the C-major scale, the even rows are short octave-ghost artefacts from transcription (see clean up MIDI). Seconds are computed with ticks × 60 / (120 × PPQ).

Note that the last event ends at tick 6713 + 914 = 7627, which is why 7627 ticks is the length of the whole passage. At PPQ 480 that is 7.944792 s; at PPQ 960, 3.972396 s; at PPQ 240, 15.889583 s. No note was added, removed, lengthened or shortened in ticks.

4. The formula, checked against the parser

The conversion is seconds = ticks × 60 / (BPM × PPQ). With the player default of 120 BPM this simplifies to ticks / (2 × PPQ). Every cell in section 3 was recomputed from that formula and then compared with the independent parser's reading of the corresponding variant file; all 42 cells (3 resolutions × 14 notes) agree.

The two ratios are the whole point: elapsed time is inversely proportional to PPQ. The numbers in the table are not rounded from a screenshot — they are the formula evaluated on the tick values read out of the file. If you plug 959, 120 and 480 back in, you get 0.998958333…, which is the 0.998958 shown. A file with an explicit tempo event would use the stored BPM in the same denominator.

5. PPQ is not tempo: a zero-effect injection

To show that these are two independent byte dimensions, a fourth file was built from the 480 source by inserting one tempo event and nothing else: 00 FF 51 03 07 A1 20 (delta 0, tempo meta event, 500,000 microseconds per quarter = 120 BPM) into the first track, just before its end-of-track marker, with that track's length field changed from 8 to 15 bytes. The file grows from 169 B to 176 B. The division bytes stay 01 E0.

Writing 120 BPM explicitly changes no elapsed time at all, because 120 BPM was already the default the parser applied. PPQ sets how many ticks make a quarter note; tempo sets how long that quarter note lasts. Changing one does not change the other. This is also why an exported MIDI can sound "the wrong speed" in a DAW without any note being wrong — see MIDI wrong tempo after conversion for the tempo side of that problem. This site does not detect tempo or BPM from audio; it writes note events and no tempo event.

6. How to reproduce these numbers

• Download the 169 B MIDI file linked above and confirm its SHA-256 starts 90795f6ff271cb92.
• Open it in any hex editor and look at bytes 12 and 13 (zero-based). They read 01 E0. Replace them with 00 F0 for 240 or 03 C0 for 960. Save as a new file; do not touch any other byte or the chunk length fields.
• Parse the original and both variants with @tonejs/midi 2.0.28. Read header.ppq, the notes' ticks and durationTicks, and duration.
• Recompute each start with ticks × 60 / (120 × ppq) and compare with the parser's time. The 14 pitch/velocity/tick tuples should be identical in all three.

These steps describe a method, not a measurement; they are not counted as exclusive material in the denominators above.

7. What this site writes, and what it does not

• Output. The converter produces a Standard MIDI File with a division of 480, one track containing note events, and no tempo event. It does not detect tempo or BPM from the audio, and it does not write a time-signature or key-signature event. If your software assumes a different tempo, that is a player setting, not a value in the file.
• Scope. The output is a single note track. There is no instrument separation and no separate drum track. The tool accepts local MP3, WAV, M4A, FLAC and OGG files; it does not accept URLs or streaming links.
• Honesty. This page makes no accuracy claim and no speed claim. The figures above are measurements of one published file on 8 November 2026, not a performance guarantee.
• Related reading. What is a MIDI file for the byte-level structure, MIDI vs MusicXML for a different kind of size comparison, and MP3 to MIDI accuracy for how the note events were evaluated.