Audio to MIDI: Did Changing PPQ Change the Timing?

Check the tick scale before repairing a MIDI phrase that became shorter. In our local test, changing a file header from 480 to 960 ticks per quarter note while retaining its event ticks moved the last note from 1.500 to 0.750 seconds. Scaling the event ticks by two restored 1.500 seconds. All three files contain the same four pitches and are 72 bytes long.

One header change, two different jobs

PPQ describes the resolution of a tempo-based MIDI timeline. It supplies the unit used to interpret a stored tick value. It does not assess how accurately an audio-to-MIDI detector found a note. A larger number can provide a finer coordinate grid, but changing the unit without converting the coordinates can change their meaning.

Imagine a MIDI draft that was correct before it passed through a file utility. The pitches still match, yet the phrase now finishes early. Before stretching individual notes, compare the file's division field, tempo events and event ticks. Keep the original export so you can identify which values changed.

Three saved files with a fixed tempo

We constructed single-track format-0 MIDI files on this computer. Each has one tempo event of 500,000 microseconds per quarter note. The original uses 480 PPQ. Its four note-ons are at ticks 0, 480, 960 and 1440, with pitches 60, 64, 67 and 72, velocity 80, and durations of 240 ticks. No audio detector participates in this control experiment.

At a fixed tempo, seconds = ticks × microseconds per quarter ÷ PPQ ÷ 1,000,000. For the original last note, 1440 × 500,000 ÷ 480 ÷ 1,000,000 gives 1.500 seconds. Keeping 1440 ticks but changing the divisor to 960 gives .750 seconds. In the third file, the note tick is 2880, restoring the original time.

The original and header-only files differ at zero-based offsets 12 and 13. Those two bytes change from 01 E0 to 03 C0. Their entire track chunks match byte for byte. The retimed file also uses 03 C0, but its event deltas change. File length remains 72 bytes because the deltas in this particular fixture still fit the same variable-length encoding widths.

Read the units with the events

An independent JavaScript reader decoded each saved file's header, tempo, deltas, note statuses, pitches and velocities. It calculated the eight note-on/off times from those saved values. The original and retimed files agree on all eight times. The original and header-only files agree on all event ticks, while their calculated times differ by a factor of two.

The Oracle MIDI Sequence documentation defines PPQ resolution using ticks per quarter note and separately describes SMPTE timing. The MIDI Association overview describes event timestamps and tempo information. These are the units used in this experiment. Neither document is evidence that a particular converter or editor caused an import problem.

The division field can also encode SMPTE timing. This page uses positive PPQ values only. Applying the PPQ equation to a SMPTE file would be a different error. With tempo changes, calculate elapsed time over each tempo segment instead of applying one global value.

Check a handoff before moving the notes

1. Keep the original MIDI and source recording, together with the intended clip placement.
2. Compare the division field and tempo events before comparing tick numbers alone. Equal tick values need equal units to represent equal times.
3. Compare several corresponding attacks in seconds. A proportional change points you toward a clock or scale check. A fixed shift warrants checking clip placement and crop origin as well.
4. If a utility changes resolution, verify that it rescales the event timeline. Check both note-on and note-off events. Do not assume it preserved durations because the first note stayed at zero.

Changing resolution is separate from choosing a quantization grid. This fixture preserves coordinates by scaling them exactly. It never snaps them to a musical subdivision. The note-end quantization comparison examines that other operation. The meter comparison holds the clock fixed while bar labels change. This experiment changes the tick unit and tests its effect on seconds.

Reproduce the measurements

Download experiment.py and inspect.mjs into one folder. Run python experiment.py, then node inspect.mjs. The generator writes three local fixtures and their hashes. The independent reader produces the decoded event report. Repeating generation in a fresh directory produced byte-identical MIDI files.

Measured limits. These are constructed event files. We did not measure transcription accuracy, listen to a synthesizer, import into a DAW or test a competitor's resolution conversion. No real recording, variable tempo map, SMPTE file or rounding-sensitive down-conversion was tested. The calculated seconds show the consequences of the stored units under the stated fixed tempo. They do not identify the cause of an unrelated user's timing problem.

For a converted phrase, check the timing representation together with the events before committing to an edit. Once the units agree, remaining discrepancies can be investigated against the source performance.