Why does converted MIDI play at the wrong tempo?

What our original export actually contains

We reused the quiet pitch-60 control from our October 2 velocity experiment. Its audio is a generated sine tone, not a rhythmic song; it has no measured musical BPM. The existing offline MIDI is 100 bytes, with one note beginning at tick 156 and lasting 1,594 ticks. Its header uses 480 ticks per quarter note, also called PPQ.

On October 3 we parsed its raw events with midi-file and its timing with @tonejs/midi 2.0.28. The raw file contained zero Set Tempo events. The installed timing library uses 120 BPM when its tempo list is empty, producing a start of 0.1625 seconds and duration of 1.6604166666666667 seconds. That fallback is not evidence that the source was performed at 120 BPM.

We separately inspected this site's export loop. It creates a MIDI object and copies each detected note's pitch, start seconds, duration and velocity into a track. It does not estimate beats or set a tempo map. The current tool was not changed for this article; the rewritten files below are separate experimental downloads, not new converter modes.

The four-file test: same ticks or same seconds?

The original MIDI was copied unchanged as the baseline. For two controls we set a tempo at tick zero while retaining the note's tick positions. For the final control we created a new file, set its tempo first, and rebuilt the note using the baseline's parsed start and duration in seconds. Every result was serialized and parsed again, rather than inferred from settings alone.

Displayed seconds are rounded to six decimals. The 90-BPM request is represented by an integer tempo value in the written file; its parsed seconds therefore differ slightly from calculation with an ideal exact 90. The raw report retains that difference instead of rounding it away and claiming byte-perfect mathematical equivalence.

Why the result changes

For a constant tempo starting at tick zero, our calculation is seconds = ticks / PPQ × 60 / BPM. The baseline duration is 1594 / 480 × 60 / 120 = 1.6604166666666667. Keeping those 1,594 ticks at 60 BPM gives 1594 / 480 × 60 / 60 = 3.3208333333333333. Each input comes from the parsed file or the explicitly selected experiment setting.

Preserving the baseline duration at 60 BPM instead requires ticks = seconds × BPM / 60 × PPQ. Here that is 1.6604166666666667 × 60 / 60 × 480 = 797. The observed retimed file contains 797 duration ticks and 78 start ticks, compared with 1,594 and 156 in the baseline.

Our inference is limited but useful: writing a new tempo value is not the same as stretching a performance or preserving it. The note ticks and tempo map jointly determine the seconds. This example uses one constant tempo; it does not validate a song with a changing tempo map, swing, free timing or quantization.

Choose the intended result before importing

1. If your goal is to compare the MIDI draft with the original audio, retain an untouched copy and check absolute timing first. Do not assume a displayed default BPM was detected from the recording.
2. If you want the notes to play faster or slower on a new beat grid, changing tempo while retaining tick positions is a different goal. Our same-ticks files demonstrate that distinction without claiming how every DAW handles import.
3. If a file really contains a tempo map you want, use your DAW's documented tempo-import workflow. Ableton's guide describes importing a MIDI file with the necessary tempo changes and notes spanning their range into Arrangement, then accepting its tempo-import prompt.
4. If alignment remains wrong, compare the start offset and individual boundaries against the reference. A tempo change will not repair false or split detections. See the split-note test and DAW handoff guide.

The Ableton step comes from its official tempo-map import guide; we did not run Live here. The parsing library's header implementation explains its tick/second conversion; the installed version was checked separately. No DAW screenshot or compatibility claim is implied.

Repeat and inspect, rather than trust a BPM label

Read the full JSON report, including the exact note values, raw tempo events, file hashes and environment. Download the reproduction script. Inside this site project with its packages and October 2 evidence installed, place it in the scripts directory and run node scripts/reproduce.cjs PATH_TO_SITE_PROJECT. The recorded environment is Node v24.19.0 on Windows.

The baseline is the same generated-source export, not a newly transcribed recording. Its SHA-256 is recorded so you can check that reuse. The other controls preserve pitch and velocity, but their metadata and lengths differ; do not describe their different bytes as transcription-quality differences.

This check does not compare competitor transcription accuracy. Tuneonmusic's inspected converter page already exposes a tempo control and describes tempo estimation; we are not claiming that every converter lacks it. The distinctive evidence here is our unchanged writer's actual empty tempo list and the four downloadable rewrites showing what ticks and seconds do.