How Long Does Audio-to-MIDI Conversion Take?

In a historical desktop Chrome test of GAME Vocal, conversion took roughly 1.4 seconds per second of audio after the model was ready. 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 older build also spent 12 to 14 seconds starting its model. These figures are not a timing estimate for current Piano, Basic Pitch or HQ Local modes.

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.

Historical GAME startup: a cost paid once per page

The older GAME build fetched and initialised its model before the first file. The table below records that historical behavior. The current site waits until a file is selected, and startup differs by mode and device.

In that older build, the gap between the first two rows was about 2 seconds of downloading on the test connection. The remaining startup mainly initialised five ONNX sessions. Its 51,054,395 bytes of model weights could be reused from browser cache. Current cache behavior and model size depend on the selected mode and browser storage state.

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

• Historical GAME, 3 minutes: 4:41 and 4:20 in two runs on this desktop, with the model already loaded.
• Historical GAME, 1 minute: about 84 seconds on this desktop.
• Historical GAME, 30 seconds: about 44 seconds on this desktop.
• Historical GAME, 10 seconds: about 14 seconds; this crossed the eight-second window boundary.
• 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. Reusing the selected model may avoid repeated setup; measure your own mode and device for a useful estimate.
• 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.