How Long Does Audio-to-MIDI Conversion Take?

Budget about 1.4 seconds of conversion for every second of audio, plus a one-time start-up of 12 to 14 seconds. Measured on this machine, with the engine already loaded: a 30-second clip took 44 seconds, one minute took 84 seconds, two minutes took 3 minutes 1 second, and three minutes took 4 minutes 41 seconds. The price per second of audio is not constant, and the reason is specific: the engine works in 8-second windows and feeds each one a second of context on either side, so it processes 1.2 to 1.24 times the audio you gave it.

Those figures come from seven conversions run back to back in the same browser tab, on audio built to be exactly 5, 10, 20, 30, 60, 120 and 180 seconds long and to contain the same music at the same density throughout — two notes per second in every file. Timing starts the moment the file is handed to the page and stops when the download link appears.

The measured table

Desktop Chrome, no other work on the machine, engine loaded and warm. "Audio fed" is what the engine's window planner actually sends to the model — it is the length of the file plus the context around each window.

Read the last two columns together, because they are the whole answer. Total wait rises faster than audio length — from 1,126 ms per second of audio on a 5-second clip to 1,556 ms on a three-minute one. But the number of seconds the model is actually asked to analyse rose from 5.0 to 224.0 over the same range, and the cost per second of that stayed between 1,126 and 1,250 ms the whole way. Nothing is slowing down as files get longer. The engine is simply being handed more audio than the file contains.

One repeat, to show how much of this is machine noise rather than structure: a second, independent three-minute conversion in a fresh tab took 4 minutes 20 seconds instead of 4 minutes 41. That is an 8% spread on identical input, so treat every number here as a bracket, not a stopwatch reading.

Where the time actually goes

The page reports four phases, and only one of them matters. These are the same seven conversions, broken down.

Everything outside the model — reading the file, resampling it, writing the .mid — came to between 0.3 and 1.0 seconds per conversion, whatever the length. If you were hoping to speed things up by feeding the tool a smaller file format, that is where the hope dies: the decode step you would be optimising is 0.2% of the wait.

Reason one: start-up is a fixed cost you pay per page, not per file

Before the tool can convert anything it has to fetch and initialise its model. That cost does not scale with your audio at all, which is why short clips feel disproportionately slow.

The gap between the first two rows is the download: about 2 seconds on this connection. Almost all of the start-up is not fetching but initialising — five ONNX models are compiled and five inference sessions are created, sequentially, before the tool will accept a file. The weights themselves are 51,054,395 bytes, about 48.7 MiB, and they are held in the browser's cache, which is why the second row is only slightly faster than the first and why a repeat visit a week later skips the download entirely.

The practical consequence is that the arithmetic people do in their heads is wrong at the short end. A 5-second clip does not take a twelfth of the time of a one-minute file. It takes 6.4 seconds against 84.4 — because the one-minute file amortises the same start-up over twelve times as much audio.

Reason two: the engine works in 8-second windows with context

This is the part that shows up in the numbers and nowhere else. The engine does not analyse your file as one signal. It cuts it into windows of 8 seconds, and for each window it sends 1 second of audio from before and after as context, so the model can hear what is coming. Only the middle 8 seconds of each window are kept as output.

Two things follow. First, the audio fed to the model is longer than your file. Second, the file length is rounded up to a whole number of windows, so crossing an 8-second boundary adds a full extra window's worth of work at once. Here is what the planner does to a range of lengths:

Look at the first two rows. Going from an 8-second clip to a 9-second clip adds 12.5% more audio and 37.5% more model work, because the ninth second forces a second window and that second window arrives with its own context. A 9-second clip is relatively more expensive than a 16-second one. This is the only place in the whole pipeline where the cost is genuinely discontinuous, and it is a boundary you can see: at 120 BPM in 4/4, one window is exactly four bars, and the context is half a bar on each side.

The same effect explains the slow drift in the per-second price. A file that fits in one window pays no context at all — 1.000×. As files get longer, the proportion of audio that is context settles toward the 25% ceiling, so the ratio climbs from 1.000 through 1.200, 1.233 and 1.244 and stays there. Measured, on a clean set of single-file runs, the cost per second of audio fed was 1.09 s at 10 seconds, 1.16 s at 60 seconds and 1.15 s at 180 seconds — flat, while the cost per second of your audio rose from 1.31 s to 1.44 s over the same span. The drift is entirely accounting.

Reason three: your machine, not the file

Everything above was measured on one desktop. To see how much of the result is hardware, we ran two of the same files again with the CPU throttled to a quarter of its speed — an emulated slow device, not a physical phone, and it should be read as a direction rather than a specification.

The throttled run came out about twice as slow, not four times — 1.85× on the 10-second file and 1.98× on the 30-second one. The shape of the curve was unchanged: the 30-second file cost 3.2 times the 10-second file at full speed and 3.4 times when throttled. So if you are on a slower machine, scale the whole table and keep the relationships.

What moved least was start-up. For the same cached-model case, the engine took 14.9 seconds to become ready with the CPU throttled against 11.6 to 11.9 seconds at full speed — about 25% slower rather than twice as slow. Most of that wait is fetching and creating five inference sessions rather than computing, so it is the part of the pipeline a slow CPU hurts least.

What the progress bar is really telling you

The bar moves once per window — 23 steps for a three-minute file, 4 for a 30-second one — and the time estimate next to it is derived from how long the work has taken against how far the bar has got. That method has one structural flaw: progress is reported just before a window runs, not after it finishes, so the estimate is always computed from one window less work than the bar claims.

Here is the three-minute run, panel against reality:

The estimate converges as the run goes on and then overshoots at the end, for the same reason in both directions: it assumes every window costs the same, and the first window costs more than the rest while the last one is usually short. On the 10-second file the flaw is at its worst — the panel said ~1s left at 55% while 13.6 seconds of work remained, because the estimate was computed from the six milliseconds of elapsed time between the analysis starting and the first window being handed off.

Two details of the display are worth knowing before you read anything into it. The bar never shows 0% or 100% during analysis; it is mapped across 12% to 98%. And any estimate under one second is printed as "~1s left" — a floor in the formatting, not a measurement. If you see that, you know the estimate has collapsed, not that the job is nearly done.

Practical answers

• A 3-minute song: about 4½ minutes of analysis on this machine, plus 12 seconds if the tab is new. Two runs: 4:41 and 4:20.
• A 1-minute song: about 84 seconds, plus the same one-time start-up.
• A 30-second clip: about 44 seconds. This is the length where the fixed costs are still visible; below it they dominate.
• A 10-second clip: about 14 seconds — 10 seconds of audio is two windows, and two windows means 12 seconds of model input.
• Cut, do not compress. Feeding a smaller file format changes the 0.2% of the wait spent decoding. Feeding less audio changes all of it.
• Convert the next file in the same tab. The start-up is per page load. Reopening the page pays it again.
• Aim for just under a multiple of 8 seconds if you are choosing a clip length by hand: 8 seconds is one window, 9 is two.

Frequently asked questions

Related: how long a file you can convert before the browser gives up, what local conversion costs you in speed and saves you in privacy, and whether a denser file takes longer.