MIDI Delta Time and Variable-Length Quantities

All six rows are the same file with exactly one byte rewritten. No audio was re-converted, no note was added and no instrument appeared; only the timing bytes moved. The last column is what an independent parser read after re-opening each copy from scratch.

1. Where timing lives in a 169-byte MIDI file

The source is the 169 B MIDI file published on this site on 24 October 2026, alongside the test WAV it came from. Its first 14 bytes are 4D 54 68 64 00 00 00 06 00 01 00 02 01 E0: the MThd chunk declares format 1, two tracks and a division of 01 E0 = 480 ticks per quarter note. The three chunks were read straight from the file's own length fields:

The first MTrk is an 8 B conductor track with a track-name meta event and end-of-track. The second holds 131 B of events: 14 notes plus meta events. Every one of those events begins with its own delta-time, which is why the timing of this file is spread across 33 separate byte fields rather than sitting in one table. The header format field and the PPQ division field are separate measurements on this same published file; this page is about the bytes inside the track.

2. The VLQ rule: how one or two bytes hold a number

A delta-time is a big-endian, 7-bits-per-byte integer. Bit 7 (0x80) is a continuation flag, not data. A value below 128 fits in one byte; 128 through 16,383 needs two. The rule is mechanical: value = ((b0 & 0x7F) << 7) | (b1 & 0x7F) for two bytes, with b0 >= 0x80 and b1 < 0x80. That is why 86 44 is 836 and not 34,372: the high bits are flags.

The seconds column uses the SMF default of 120 BPM because this file contains no tempo event (0 tempo events, read independently). One tick is 60 / (120 × 480) = 1/960 s = 0.001041667 s. PPQ sets how many ticks make a beat; delta-time sets how many ticks pass before the next event. Changing one does not change the other — that distinction is measured separately on the PPQ and ticks page.

3. Every delta-time byte in this file, event by event

The table below is the full scan of both MTrk chunks: 33 events, 25 with a one-byte delta and 8 with a two-byte delta. Each row was produced by reading the VLQ bytes at that file offset and recomputing the value from the 7-bit formula; the parser was then run separately over the whole file. Offsets are absolute byte positions in the 169 B file. One-byte values that actually occur are 0, 1, 10, 12, 23, 78, 89 and 100; two-byte values are 836, 847, 858, 859, 881, 913 and 958.

Read the first few rows together: four events share tick 0 (track name, program change C0 00, and two note-ons at C5 and C4), then 64 = 100 ticks later C5 switches off, then 86 44 = 836 ticks later C4 switches off. C4 therefore lasts 100 + 836 = 936 ticks while C5 lasts 100. Every one of the 14 notes in this file was built from pairs like that.

4. Five single-byte injections, re-parsed independently

Each row changes exactly one byte inside one delta-time field. Nothing else is touched: file length stays 169 B, the other 168 B are byte-for-byte identical, the chunk length fields stay 131 and 6, and the note count stays 14 at PPQ 480. Each copy was written to disk and re-opened with a fresh new Midi(...) so that no parsing state leaked between rows. The duration column is the parser's own durationTicks for the affected note, not a value computed for this page.

Three edits move the same one-byte delta 64: to 101, to 127 (the largest value that still fits in one byte) and to 0 (note-off on the same tick as note-on). Two edits stay inside a two-byte VLQ: changing its low byte 44 to 45 moves 836 to 837, and changing its high byte 86 to 87 moves 836 to 964 because the high byte carries six or seven groups of 128. In all five cases the C5 or C4 duration read back from the parser matches the new delta exactly: 100→101, 100→127, 100→0, 936→937 and 936→1064 ticks.

5. Formula checks and what the parser actually read

Every number on this page can be rebuilt without trusting the prose. The left column is the formula, the middle is the computed result, and the right says where the same value appears independently. Chunk lengths come from the file's own length fields; delta values come from the bytes; seconds come from the tick formula; the 168 B figure is simple subtraction.

The last note in the source ends at tick 7,627, which is 7.944792 s at 1/960 s per tick. Editing the first delta from 100 to 101 pushes the whole remaining timeline by one tick, so the independent parser reports 7,628 ticks; editing it to 0 pulls the timeline in by 100 ticks, giving 7,527. Those totals were read from the parser, not derived here and then asserted. All five injected copies parsed successfully with 14 notes and PPQ 480 — a timing edit alone does not break the file.

6. A structural control: clearing one continuation bit

The sixth edit changes the high byte of a two-byte VLQ from 86 to 06. That is still one byte, still 169 B, still 168 unchanged bytes. It clears bit 7, so the VLQ now ends after 06 and the following 44 is read as the start of the next event instead of as data. The file still parses, but the parser no longer finds the same notes:

This is the useful half of the experiment. A file that still parses is not necessarily a file with the same content. The five timing edits in section 4 each changed one delta value and kept 14 notes; this one changed how all the following bytes were grouped and lost three notes. It is a byte-level demonstration that "able to parse" and "content intact" are different claims, which is also why this page never treats a successful parse as proof of a good conversion.

7. How to repeat this yourself, and what this page does not claim

Download the 169 B source file, open it in any hex editor, and find 64 at offset 53 (0x35) and 86 44 at offsets 57–58 (0x39–0x3A). Write one byte, save, and re-open with a MIDI library that reports note durations. The chunk length fields do not need editing because all six variants are in-place single-byte writes. If you would rather convert audio than edit bytes, the MP3 to MIDI converter and the other format pages run in your browser and produce a single-track .mid you can inspect the same way; the clean-up MIDI page covers the note artefacts that a real conversion leaves behind.

What is not here: no measurement of conversion accuracy, no speed figure, no tempo or BPM detection claim, no multitrack or per-instrument output, no drum track, and no claim that this site is more accurate than anyone else. The numbers are from one 169 B file published on 24 October 2026 and six one-byte edits of it, measured on 9 November 2026. A different audio input produces a different file, and the current engine produces a different byte count from the same WAV. General format facts, method notes, limits and disclaimers are deliberately excluded from the exclusive-material denominators above.