Why does MP3 to MIDI latency differ between uploaded audio and live input?

The 2003 KNZAudio Midifier help documented a plugin whose usual job was to analyse a prerecorded audio track. The vendor said that this normal file-based use did not expose the same latency problem as feeding the plugin live input. That was a statement about Midifier's own workflow in 2003, not a promise about current browser converters or DAWs.

For live input, the historical vendor reported a delay of about 50 milliseconds and said the product was not suitable for live performance. The archive does not provide a reproducible measurement procedure, test computer, interface configuration, or distribution of results. The figure is therefore useful only as an attributed historical product statement. It must not be read as a present-day target, average, or threshold for MP3 to MIDI software.

The same page described a second timing issue. In some sequencers, it said, the time resolution of generated MIDI could be tied to the audio buffer. The vendor treated buffer latency above 10 milliseconds as capable of degrading Midifier's performance in that host arrangement. Again, this was its own 2003 warning. The document does not establish that every host quantized MIDI to its buffer, that every buffer above that value failed, or that changing a modern buffer produces the same result.

That distinction matters because audible delay and recorded note placement are not identical symptoms. A live player can hear a late instrument even if the captured MIDI notes remain usable after editing. Conversely, a host can place or group generated events poorly even when the chosen synth sounds responsive enough. The archived help connected one of those timing behaviours to particular sequencers rather than calling it a universal MIDI limitation.

Midifier's guide also separated timing trouble from CPU overload. It warned that running the converter together with multiple plugins or virtual instruments could produce cracks, strange noises, or dropouts. Its workaround was to record the converter's MIDI output without running the synth, disable Midifier after capture, and then play the synth from the recorded MIDI. The method divided one heavy real-time chain into two lighter passes.

That two-pass sequence is the most useful part of the archive for diagnosis. Pass one asks whether audio can become a stable MIDI recording when the sound generator is removed from the live path. Pass two asks whether that recorded MIDI can drive the instrument after the recognizer is disabled. If the first pass stops dropping out, CPU load in the combined chain was a plausible contributor. If the recorded MIDI itself is late or uneven, changing only the instrument cannot repair those event times.

The archive supplies no tested accuracy percentage, no sample count, and no modern comparison. It also concerns a plugin receiving an audio signal, not this site's uploaded-file converter. The supported conclusion is narrow: the historical product distinguished normal prerecorded use from live monitoring, warned that one host's buffer could affect generated-event timing, and proposed separating recognition from synthesis when the full chain overloaded the computer.

1. Make a short reference recording. Capture a few clearly separated notes as audio. Keep that track unchanged so each test has the same timing reference.
2. Record the converter's MIDI with the instrument active. Note whether you hear lag, crackles, or dropouts, and inspect where the MIDI events land.
3. Repeat with the software instrument bypassed. Record only the converter's MIDI output. Do not change the phrase, audio source, or host setting in the same pass.
4. Disable the converter and replay the captured MIDI. Feed the same instrument from the recorded events. Compare playback stability with the original complete chain.
5. Interpret one symptom at a time. If bypassing the instrument removes dropouts, the combined processing chain deserves investigation. If the captured events are displaced, inspect recording compensation and routing rather than judging only by the instrument's sound.

Sound On Sound's public latency analysis independently describes how real-time soft-synth timing can vary with buffer-related delay and why measured behaviour can differ from a single theoretical figure. It does not validate Midifier's historical numbers; it supports the testing principle that monitoring delay and event timing should be observed, not assumed.

Choose a short excerpt whose first few note attacks are easy to locate. Convert it, import the downloaded MIDI beside the original audio, and align both to the same start point. Inspect pitch, onset, and duration separately. If a note begins in the wrong place, move that event or test a cleaner source excerpt; changing an audio-interface buffer after the file has already been converted does not rewrite the downloaded MIDI.

If you need an instrument to follow a guitar or microphone while you play, use a workflow that explicitly supports live audio-to-MIDI routing. Test that live setup on its own terms. The waiting time of an uploaded conversion and the round-trip delay of a performance controller answer different questions.