MIDI TPQN: 480 ticks per quarter note, and what quantizing does

Updated 13 October 2026 · 6 min read

Where the number lives

Open the header of any .mid from this page and the division field is two bytes: 01 E0, which is 480.

A positive value means ticks per quarter note. A negative value would mean SMPTE frames instead, and this writer only ever writes the positive form, so there is nothing to disambiguate when a DAW opens it.

The rest of the header is short. Format 1, one track, and everything else (the track name, the tempo event, the notes) lives inside that track.

Two numbers, one name

MIDI clock is a live signal. One device broadcasts it and another follows, at 24 pulses per quarter note, so a synth and a sequencer stay in step. Those are single status bytes, 0xF8, going down a cable.

The division field is not a signal. It is a number stored in a file, saying how finely time is counted inside that one file. Here it is 480.

Search for MIDI TPQN and the first result is a page about the clock. Which one is in your file? Only the second, and the file carries no clock bytes at all.

What the writer emits instead is a track name, one tempo event, the notes, and an end of track marker. That is the whole file.

Why 480

Because it divides cleanly. 480 splits evenly by 2, 3, 4, 5, 6, 8, 10, 12, 15 and 16, so an eighth is 240 ticks, a triplet eighth is 160, a sixteenth is 120, a triplet sixteenth is 80, and a thirty-second is 60. Every one of those lands on a whole tick.

That is arithmetic, not a claim about sound. The reference page that ranks first for this term notes that modern software sequencers may use 960 PPQN and beyond, and a larger number still would not move a note that is already in the wrong place.

There is no control for it here, and that is deliberate. Would a bigger number help? Not here, because 480 is already finer than anything the pitch tracker produces.

Quantize is a second rounding, and it is the coarse one

Two roundings happen on the way to a file. The first is the Quantize control, if you set one, and it snaps the start and the end of each note to the nearest step. The second is the writer turning seconds into ticks and rounding to the nearest tick.

Here is what the first one costs, measured by running this page on its own test audio (a C major scale, C4 to C5, 8 notes) at 120 BPM with Min note length at 80 ms.

Measured against the same run with Quantize off, where the onsets came back at 0.07, 0.60, 1.11, 1.63, 2.16, 2.67, 3.20 and 3.72 seconds. Every quantized run put all eight onsets on a multiple of its own step.

So which one moved your note? The number people blame, 480, is the one that barely moves anything. The control people forget, Quantize, moves notes by tens of milliseconds.

The note list on the page shows times rounded to hundredths of a second, so these figures are read off the displayed values. The file holds the unrounded ones.

The order the two roundings happen in

Short notes go first, dropped by the Min note length control. Quantize runs next, on seconds. Only then does the writer convert to ticks.

One consequence is worth knowing. Quantize moves the end of a note as well as the start, and a note that ends up shorter than one step is written as exactly one step long. It is lengthened, not deleted.

And because quantize runs before the tick conversion, a quantized file still lands within half a tick of its own grid. The two roundings do not compound into something worse.

When quantize makes things worse

Quantize builds its grid from the BPM field. If that number is not the real tempo of the recording, every grid line sits in the wrong place, and quantize adds an error rather than removing one.

The step is 15 divided by the BPM, in seconds. At 120 that is 125 ms, and at 100 it is 150 ms, so a wrong tempo moves the entire grid rather than one note.

There is a second case. This build's own tests measured vibrato pushing the first onset by a few hundred milliseconds, which is wider than a 1/16 step, and rounding to the nearest step cannot tell a real late onset from a detected one. That part is reasoning about the rounding, not a separate measurement.

What this file does not carry

No MIDI clock messages, and no song position pointer. Those belong to a live link between devices.

No SMPTE division either, since the writer only writes the positive, ticks per beat form.

Changing the resolution afterwards is an editor's job and not something this page offers, and it means multiplying every tick value by the same factor. That adds no information. For the rest of what a converted file leaves out, see importing converted MIDI into a DAW.

How to set it, in order

1. Find the real tempo first and put it in the BPM field. Everything below depends on that number.
2. Leave Quantize off unless you actually want a grid. Off keeps the timing the tracker found.
3. If you want one, start at 1/16. It cost 55 ms at worst on this build's test audio, against 220 ms for 1/4.
4. Read the note list before you download. The start and duration columns show exactly what the grid did.
5. Convert and download. The file is built in your browser, nothing is uploaded, and there is no sign-up.

Step one is the one that decides whether step three helps or hurts.

FAQ

What does TPQN mean in a MIDI file?

TPQN is ticks per quarter note, the timing resolution of the file, and it is stored in the division field of the header. Every .mid from this page writes 480, so one beat is counted in 480 steps. It is not a quality setting, and there is no control for it here.

Is MIDI TPQN the same thing as 24 PPQN?

No. MIDI clock is a live signal sent between two devices at 24 pulses per quarter note, as the single status byte 0xF8. The 480 in your file is a number inside the header saying how finely time is counted in that file, so the same unit covers two different jobs, and the file itself contains no clock bytes.

Why 480 ticks per quarter note?

Because it divides evenly by the grids that get used: 240 ticks for an eighth, 160 for a triplet eighth, 120 for a sixteenth, 80 for a triplet sixteenth, 60 for a thirty-second. That is arithmetic rather than a claim about sound quality. It is also finer than anything the pitch tracker can produce, so a bigger number would not change the notes you get.

What does the Quantize setting do?

It snaps the start and the end of every note to the nearest step of a grid, before the file is written. The grid comes from the BPM field: 1/4 is a quarter note, 1/8 an eighth, 1/16 a sixteenth. Off keeps the timing the pitch tracker found, and it is the default.

How far can quantizing move a note?

Measured on this build's own test audio at 120 BPM, the worst onset moved 220 ms at 1/4, 120 ms at 1/8 and 55 ms at 1/16. The ceiling is half a step, so 250 ms, 125 ms and 62.5 ms. Tick rounding, the thing 480 controls, has a ceiling of about half a millisecond.

Does quantizing make the conversion more accurate?

No. It makes the timing more regular, not more correct, and it does not recover notes the pitch tracker missed. Quantize builds its grid from the BPM you typed, so with the right tempo it tidies the notes and with a wrong one it moves every note off the performance.

What happens to a note shorter than one quantize step?

It stays, and it is written as exactly one step long. Quantize rounds the start and the end separately, and if the end lands on or before the start, the writer gives the note one full step. Use Min note length first if you want small notes gone.

Does the file contain MIDI clock messages?

No. A clock is a live signal between devices, and what you download is a file holding a track name, one tempo event with the BPM you set, the notes, and an end of track marker. Nothing else.

Do I have to set my DAW to 480?

No. The division travels inside the file header, so whatever reads the file picks the number up on its own. There is nothing to match on either side, and no setting on this page to change it.