How Long a Song Can You Actually Convert in a Browser?

The page sets no fixed duration limit. In a historical desktop GAME Vocal test, files from 30 seconds to ten minutes completed; the ten-minute run took 17 minutes 40 seconds. The measured 7.6–8.8 MB was JavaScript heap, not the tab's total memory. Decoded audio, WebAssembly models and HQ GPU buffers can use substantially more, so long-file limits depend on your mode and device.

We cut one test signal into 30-second to ten-minute versions and measured the historical GAME Vocal route on one desktop. The memory column records JavaScript heap only; total browser memory was not measured.

The measured numbers

Audio	Notes found	Wall-clock time	Time per audio second	Peak JavaScript heap
0:30	60	54.0 s	1.80×	8.1 MB
1:00	119	2 min 41 s	2.68×	7.6 MB
2:00	239	5 min 8 s	2.57×	7.8 MB
3:00	359	5 min 30 s	1.83×	8.8 MB
5:00	599	9 min 41 s	1.94×	8.5 MB
10:00	1199	17 min 40 s	1.77×	7.7 MB

One file per row, one conversion per row, no other work running in the tab. Desktop Chrome on Windows, headless, no hardware GPU on the test machine. Wall-clock time is what you would sit through: decode, analysis and file writing together. Peak memory is the highest the tab's JavaScript heap reached during the run. Read it as one machine's measurements, not as a specification.

The cost that grows, and the cost that does not

Divide the table by itself and two different pictures fall out. Time per second of audio wanders between 1.77× and 2.68× and averages about two. It does not climb as the file gets longer — the ten-minute row is the fastest per-second row in the table, not the slowest. That is the cost that grows, and it grows linearly at worst.

Measured JavaScript heap stayed between 7.6 and 8.8 MB in these GAME runs. This is only one part of browser memory, so it cannot establish a total-memory ceiling or prove that longer files use no additional memory.

GAME runs inference in eight-second cores with context and releases temporary tensors between windows. The browser still decodes the source file and may retain an audio buffer for preview. The table therefore describes the measured JavaScript heap, not every allocation made during conversion.

In this test, the ten-minute GAME file completed in about 18 minutes without a JavaScript heap increase. A different source, engine or device may have a different memory and timing profile.

The table records JavaScript heap only. It excludes decoded audio buffers, WebAssembly heaps and GPU allocations; do not use the 8 MB figure to size a device for conversion.

What the engine actually is

Worth knowing, because it explains both the time curve and why nothing is uploaded:

Model	GAME (Generative Adaptive MIDI Extractor) — five ONNX modules run in sequence
Model size	About 51 MB across five GAME files, fetched when Vocal mode first converts a file, checksum-verified and cached
Runtime	ONNX Runtime Web, in the same tab as the page
Audio handed to the model	Mono, 44,100 Hz — decoded, down-mixed and resampled first
How it is sliced	Eight-second cores with one second of context either side, processed one at a time
Where it runs	Entirely in your browser. No server sees the file, so there is no upload time, no queue and no per-day quota

That fifth row is the one that matters for length. The model does not hold the whole song in memory at once — it works through it eight seconds at a time and releases each slice's tensors as it goes. That is why the memory figure barely moves with file length, which is the opposite of how the previous engine behaved.

The fourth row is why the page can accept a 44.1 kHz stereo WAV without complaint: it does not analyse it at 44.1 kHz in stereo. It converts it first.

What failure looks like now

Honestly: we could not produce one on memory. That is a change worth being explicit about, because the previous version of this page described a memory wall and the engine has since been rebuilt to remove it. Every file in the table above converted and returned a result, including the ten-minute one, and the peak heap never went above 8.8 MB.

A long conversion can fail because decoding or model buffers exceed available memory, or because a laptop sleeps and the tab is discarded. The historical GAME run did not establish a safe memory limit for other modes. If a run fails, try a shorter clip or a less demanding mode.

Keep the machine awake and the tab open, and leave enough free memory for audio decoding and the selected model.

What about phones?

We measured desktop Chrome only. We did not measure Android or iOS Safari for this test, so we are not going to hand you a phone number that we did not observe. If you see a page elsewhere quoting a precise phone limit, ask what it was measured on.

What does carry over is the shape of the cost, and it is enough to reason with:

Memory still matters. The desktop test measured only JavaScript heap for GAME Vocal. Phones can have tighter limits for decoded audio and model buffers, and HQ Local needs WebGPU and far more memory.

Time is a constraint. The ten-minute GAME file took 17 minutes 40 seconds on the tested desktop. We did not measure a phone, so its speed and maximum practical file length remain unknown. Try a short clip before committing to a long conversion.

Keep the tab in front. Backgrounding a tab is exactly the moment a mobile browser decides it can afford to reclaim it. If you start a long conversion and then switch apps, you have chosen the worst possible moment to look away.

What to do with a long song

You can try a longer file, but splitting it into sections remains useful when your device has limited memory or when you need only part of the recording.

1. Try the whole file when the device can handle it. The ten-minute historical GAME test took 17 minutes 40 seconds; its 7.7 MB figure was JavaScript heap, not total memory.
2. Cut it into sections when needed. This can reduce the wait for feedback and help on devices with limited memory. Two to three minutes per section is a practical starting point, not a measured limit.
3. Convert only the part you need. If you want the intro, the chorus or a solo, trim the audio before you drop it in. There is no benefit to converting four minutes to use forty seconds — and now the saving is measured in your own time rather than in memory.
4. Do not let the machine sleep. A long run is a long wait, and a sleeping laptop ends it. Keep the tab in the foreground, keep the screen awake on a phone, and let it finish.
5. Line the sections up afterwards, if you did cut it up. Every file this converter writes places notes at their true times, so the positions are absolute and not bar numbers. The scale is ticks = seconds × 8 × BPM, where BPM is the tempo written into that file. At the 120 BPM default one second of audio is 960 ticks, so a section starting 4:00 into the original goes at tick 4 × 60 × 960 = 230,400. If the panel reported a different tempo for that file, use it in the formula instead — at 100 BPM the same second is 800 ticks.

That last step works because the writer never quantises to a grid. Positions are computed straight from each note's start time in seconds, so the notes land at absolute times rather than on bar lines. The tempo written into the file is measured from the audio, which is what makes the bar lines line up with the music — see why your converted MIDI opens at the wrong tempo for how that measurement works and when it falls back to 120.

The file you get back is small

In the historical GAME test, ten minutes of audio produced 1,199 notes in a single-track Format 0 file at 480 ticks per quarter note. MIDI stores note events rather than the original audio, so this output was small relative to its input. Current HQ Local instead writes a multi-track Format 1 file.

To estimate performance on your own device, start with a short representative clip in the mode you plan to use. The historical GAME test completed its 30-second file in 54 seconds, but other modes and devices can differ substantially. The piano roll lets you inspect the result before downloading.

Frequently asked questions

Is there a length limit on the file I can convert?

The page sets no fixed duration cap. The historical GAME Vocal test completed up to ten minutes, but its 7.6–8.8 MB measurement covered JavaScript heap only. Available memory, decoding support and processing time still limit practical file length.

What is the longest file that actually works?

The historical GAME Vocal desktop test converted a ten-minute file in 17 minutes 40 seconds and produced 1,199 notes. Its 7.7 MB figure measured JavaScript heap, not total browser memory; it does not guarantee that every ten-minute file or mode will work.

Why does a long song take so much longer than it plays?

More audio means more analysis. The historical GAME Vocal test took roughly 1.8–2.7 seconds per second of audio and showed 7.6–8.8 MB of JavaScript heap. Decoded audio, WebAssembly and GPU memory were not included in that heap measurement.

Will it work on a phone?

Try a short file first. We did not measure phones in this test, so neither the desktop timing nor its JavaScript heap figure predicts a phone limit. Keep the tab foregrounded and the screen awake for longer runs.

What does a failed conversion look like?

The historical GAME test did not fail on memory, but it did not measure total browser memory. Long files can fail from memory pressure, decoding problems or an interrupted tab. Try a shorter section or less demanding mode if needed.

Can I convert a song in sections and line them up afterwards?

Yes. Splitting a file can help a device with limited memory or save processing time. Notes are written at ticks = seconds × 8 × BPM, so at the 120 BPM default a section starting at 4:00 belongs at tick 230,400 in your DAW. If the file uses another tempo, recompute with that tempo.

Convert an audio file to MIDI →