What does a long file failing look like?

It is not an error dialog. The browser discards the tab to get its memory back, the page reloads, and the conversion in progress disappears with it. There is nothing to recover afterwards, which is why the sensible move with a long track is to cut it into sections before you start.

How Long a Song Can You Convert in a Browser? (Measured)

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

The page itself imposes no limit and no file-size cap. The limit is your browser tab. Because nothing is uploaded, there is no server timeout and no queue — the only clock is your own device, and the only wall is how much memory one tab is allowed to hold.

Q: What is the longest file that actually works?

In our own test on a desktop, every file from 30 seconds up to 5 minutes converted successfully, and a 10-minute file never produced a result inside a 30-minute window. The 5-minute file took 15 minutes 58 seconds of wall-clock time and peaked at 593 MB of tab memory. Those are measurements from one machine, not a promise about yours.

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

Two costs grow at once. The model works frame by frame over a mono 22,050 Hz copy of the audio and produces intermediate tensors for each frame, so memory climbs in step with length. Measured peak tab memory went from 54.8 MB at 30 seconds to 593 MB at 5 minutes — about 110 MB per minute of audio. Time tracks memory: 15 minutes 58 seconds for a 5-minute file is 3.2 times real time, and that ratio stays roughly constant as files get longer.

Q: Will it work on a phone?

Short files, yes — the page is built mobile-first. We did not measure Android or iOS in this test, so we are not going to quote a phone number for you. What does carry over is the mechanism: the desktop run spent roughly 110 MB of tab memory per minute of audio, so whatever your phone allows a single tab, divide by that. Keep the tab in the foreground and the screen awake, because backgrounding a tab is what triggers the reclaim.

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

Yes, and the arithmetic is exact. Every file this converter writes places notes using ticks = seconds x 960, so one second of audio is 960 ticks. Convert section two starting at 4:00 of the original and paste it into your DAW at tick 4 x 60 x 960 = 230,400. The sections then sit in the right places.

The short answer: 30 seconds to 5 minutes converted fine in our tests, and a 10-minute file never finished. The cost is steady and predictable — roughly 3.2 seconds of computing for every second of audio, and 110 MB of tab memory for every minute of it — which is exactly why there is a ceiling. A 10-minute song asks for about 1.1 GB of tab memory, and a browser tab does not get that much.

This page does not estimate. We took the same audio, cut it into 30-second, 1-minute, 2-minute, 3-minute, 5-minute and 10-minute versions, ran every one through the converter on this site, and recorded what happened — including the peak memory the tab used and the size of the file that came back.

The measured numbers

Audio	Notes found	Wall-clock time	Peak tab memory	MIDI file
0:30	173	1 min 40 s	54.8 MB	20.7 KB
1:00	349	3 min 5 s	109 MB	41.2 KB
2:00	698	6 min 21 s	243.2 MB	82.8 KB
3:00	1042	9 min 16 s	302.8 MB	123.5 KB
5:00	1744	15 min 58 s	593.2 MB	206.1 KB
10:00	—	no result in 30 min	—	—

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 — so the WebGL path ran through a software renderer. 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 10-minute row is the one entry outside that run: it was tested on its own, same machine, same script, same 30-minute cutoff — and the cutoff expired.

The cost is steady — and that is the problem

Divide the table by itself and the interesting number falls out. Time per minute of audio: 201 seconds for the 30-second file, 185 seconds for the 1-minute file, 192 seconds for the 5-minute file. Memory per minute: about 110 MB at every length. Ten times the audio cost ten times the work, no worse.

That flatness is not reassuring, it is the diagnosis. A cost that scales linearly still runs into an absolute ceiling, and the ceiling is the memory a single tab is allowed to hold. The 5-minute file peaked at 593 MB and returned a result. The 10-minute file would need roughly 1.1 GB by the same rate — past the point where a browser reclaims the tab. It does not fail slowly or warn you first. It just never comes back.

Two costs move together:

The model works frame by frame. Transcription is not one pass over the whole file. The audio is sliced into overlapping frames, and each frame produces intermediate tensors the model holds while it works. More audio means more frames, and the memory those frames occupy is not released until the run is done.

The audio itself is held in a resampled copy. Before the model sees anything, your file is decoded, down-mixed to mono and resampled to 22,050 Hz. That buffer stays in memory for the whole run, and so does the decoded original while the conversion is in flight.

Treat the 110 MB per minute as a rate with a wide error bar, not a constant. Peak memory is a spiky measurement: the same 2-minute file peaked at 176 MB in one run and 243 MB in another on the same machine, a 38% swing for identical input. Budget for the rate, and leave margin on top of it.

What the engine actually is

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

Engine bundle	2.28 MB (2,282,800 bytes) — the transcription model and its runtime, fetched after the first paint so the page itself opens instantly
Runtime	TensorFlow.js, in the same tab as the page
Audio handed to the model	Mono, 22,050 Hz — decoded, down-mixed and resampled first
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 third row is why the page can accept a 44.1 kHz stereo WAV without complaint: it does not analyse it at 44.1 kHz. It converts it first. And the fourth row is why the table above is entirely about your machine — there is no second computer involved that could be fast or slow on your behalf.

What failure looks like

It is not an error message, and that is the part people are unprepared for. When a tab's memory grows past what the browser is willing to give it, the browser discards the tab to reclaim the memory. The page reloads. The conversion that was running disappears with it, and there is nothing to resume. Our 10-minute test never produced a result inside a 30-minute window; the run did not end in a tidy error, it simply never got there.

So the failure is silent, and it is triggered by total pressure on the browser rather than by this page alone. Which means the same 4-minute file can convert cleanly in a fresh window and get discarded when you have thirty other tabs open.

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 mechanism, and it is enough to reason with:

Use the memory rate, not the minutes. The desktop run spent roughly 110 MB of tab memory for every minute of audio — 54.8 MB for 30 seconds, 593 MB for 5 minutes. Whatever your device gives a single tab, divide it by 110 MB and you have a working ceiling in minutes. Leave a wide margin: the rate is a spiky measurement, and a browser is not a controlled environment.

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 4-minute conversion and then switch apps, you have chosen the worst possible moment to look away.

Watch it live. On desktop Chrome, Shift+Esc opens the browser's own task manager, where you can watch this tab's memory climb in real time. That is a better guide to your own device than any table, including this one.

What to do with a long song

The fix is not to find a bigger browser. It is to stop handing one tab an entire album side.

Cut the song into sections of two to three minutes and convert them one at a time. Three minutes converted reliably in our test at 302.8 MB peak; that is the comfortable band, not the edge.
Close the other tabs first. The reclaim is about pressure on the browser as a whole, so freeing memory elsewhere buys you headroom on the run that matters.
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.
Do not touch the tab while it works. Keep it in the foreground, keep the screen awake on a phone, and let it finish.
Line the sections up afterwards. Every file this converter writes places notes using ticks = seconds × 960, so one second of audio is exactly 960 ticks. Convert a section that starts 4:00 into the original and paste it into your DAW at tick 4 × 60 × 960 = 230,400. The sections then land in the right places, because the positions are absolute times, not bar numbers.

That last step works because the writer never quantises to a grid. Positions are computed straight from each note's start time in seconds, which is also why the file opens at a fixed 120 BPM regardless of the song — see why your converted MIDI opens at the wrong tempo for what that does to the bar lines.

The file you get back is small

One reassuring number in all of this: the output does not scale the way the input does. Five minutes of audio produced a 206 KB MIDI file — about 41 KB per minute. Notes carry pitch, start time, duration and velocity, and the whole thing is a single-track format 0 file at 480 ticks per quarter note, so there is no audio data in it at all. That is why the download is instant even after a sixteen-minute wait.

If you want to see where your own device lands, start with something short — 30 seconds converts in under two minutes on the hardware we tested — and work upwards from there. The piano roll tells you what you got before you commit to a download.

Frequently asked questions

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

The page imposes none, and there is no file-size cap. The limit is your browser tab: no upload means no server timeout and no queue, but also no server to do the heavy lifting.

What is the longest file that actually works?

In our test, everything from 30 seconds to 5 minutes converted successfully. The 5-minute file took 15 minutes 58 seconds and peaked at 593 MB of tab memory. A 10-minute file produced no result within 30 minutes.

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

The model works frame by frame and holds intermediate tensors for each frame, and the resampled audio buffer stays in memory for the whole run. Measured cost was about 110 MB of tab memory per minute of audio, and about 3.2 seconds of computing per second of audio — steady, but with a ceiling at the end of it.

Will it work on a phone?

Short files, yes. We did not measure phones in this test, so we are not quoting a phone limit. The desktop run spent roughly 110 MB per minute of audio — divide what your device allows a tab by that, and keep the tab in the foreground.

What does a failed conversion look like?

Not an error dialog. The browser discards the tab, the page reloads, and the run in progress is gone. Nothing is recoverable afterwards, so cut long tracks into sections before you start.

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

Yes. Notes are written at ticks = seconds × 960, so a section starting at 4:00 belongs at tick 230,400 in your DAW. Paste it there and the sections line up.

Convert an audio file to MIDI →

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