Local vs Cloud Audio-to-MIDI: Privacy, Speed, File Limits and Cost
Last updated 10 October 2026
Measurement scope: Figures below record historical tests of the GAME Vocal/Fast route in desktop Chrome. The original test date and complete device specifications were not recorded. These numbers do not predict Piano, Basic Pitch, Full Song Fast or HQ Local performance. Guidance reviewed 10 October 2026.
In the historical GAME Vocal test below, the source audio was never sent as a request body. We also converted the same test signal in an already open browser tab after disabling the network. That run measured 56.2 MB for its first model download and 118,352 bytes on a return visit. These numbers describe that test, not the current Piano, Basic Pitch or HQ Local routes.
This page is a measurement, not a comparison of marketing pages. We did not sign up for any cloud converter and we are not quoting one — the right-hand column below describes the general shape of an upload-and-wait service, and the left-hand column is what we recorded on this one.
The comparison, with the local side measured
| Local — this page, measured | A cloud converter — general architecture | |
|---|---|---|
| Where your file goes | Nowhere. 0 bytes of request body across a full session of conversions | It is the request payload. The file leaves your device and lands on someone else's disk |
| Where the work happens | Your device, inside the tab; HQ Local also uses WebGPU | The vendor's machines, usually in a queue shared with other users |
| What it costs to start | Depends on mode; the historical GAME test downloaded 56.2 MB on first use | Usually little local setup, but every job waits for a server |
| Recurring cost | Nothing is counted. There is no server-side job to meter | Almost always an allowance — per day or per month — with the free tier the tightest |
| Account | None. Nothing to sign up for and nothing to close | Commonly required, and often required just to get the file back |
| Size limit | None imposed by the page. Bounded by your device's memory | Bounded by the vendor's upload limit, which is usually stated in megabytes |
| Speed | 26.3–28.0 s per 20 s of audio on a 2-core, 4 GB machine. No queue | Depends on queue depth and their hardware. Nothing you can inspect or change |
| Offline | The tested mode worked in an already open tab after its files were loaded | Conversion requires the provider's server |
| What the operator sees | Nothing about your audio. No copy exists to be kept | The file, its name, its size, and whatever your account identifies |
The right-hand column is architecture, not a benchmark. No number in it is a measurement of any particular service — we did not test one. The left-hand column is what the recorder in this tab logged.
How the measurement was taken
The page was loaded from a local copy, and a network recorder was attached to the tab for the entire session. It logged every request with its method, its URL, the bytes actually transferred, and — the column that matters here — the size of any request body. An upload is a request with a body. Across the whole session the sum of those bodies was 0 bytes.
Files were handed to the page the same way a person hands it a file: through the file input, one at a time, waiting for the result or the error to appear. All conversions shared one page instance, so the 51 MB of model weights were loaded once rather than once per file. The machine reports 2 logical cores and 4 GB of device memory.
Historical GAME network test: first use and return visit
The historical GAME Vocal run made 16 requests and downloaded 56,228,831 bytes — 56.2 MB. A second run measured 56,229,173 bytes. These are older-build transfer counts, not current site performance:
| What | Requests | Bytes | Source |
|---|---|---|---|
| Model weights — five ONNX files | 5 | 51,085,616 | Hugging Face CDN |
| ONNX Runtime Web — one script, one module, one 4.7 MB wasm binary | 3 | 4,846,282 | jsDelivr |
| Google's analytics tag script | 1 | 178,581 | googletagmanager.com |
| This page's own HTML, CSS and four scripts | 6 | 118,352 | this site |
| Analytics beacon | 1 | 0 | google-analytics.com |
The largest single file is one of the model weights at 20,918,738 bytes. The whole engine — weights plus runtime — is 55,931,898 bytes, or 99.5% of what a first visit downloads. The page's own files, the part you actually see, are 118,352 bytes.
In that older build, a return visit produced 10 requests and 118,352 bytes; model files came from browser cache. The current page, model routing and asset sizes have changed, so the 475-fold comparison must not be used as today's estimate.
That 51 MB does have to live somewhere on your machine. After the engine loaded, the browser reported 51,055,714 bytes of storage used against a quota of 10,788,473,954 bytes — 0.47% of what the browser is willing to give this site.
The decisive test: convert with the network switched off
Privacy claims are cheap, so here is the version that cannot be faked. Once the engine was warm, the network was disabled at the browser level and conversions were run anyway:
| File | Size | Network | Result | Data in / out | Time |
|---|---|---|---|---|---|
| WAV, 20 s | 1,764,044 B | online | 40 notes, 432 B .mid | 0 B / 0 B | 28,037 ms |
| MP3 192 kbps | 481,532 B | online | 40 notes, 432 B .mid | 0 B / 0 B | 26,497 ms |
| M4A, AAC-LC | 324,389 B | disabled | 40 notes, 432 B .mid | 0 B / 0 B | 26,284 ms |
| MP4, 1920×1080 | 5,098,367 B | online (first video) | 40 notes, 432 B .mid | 185,478 B / 0 B | 27,699 ms |
| MP4, 1920×1080 | 5,098,367 B | disabled | 40 notes, 432 B .mid | 0 B / 0 B | 26,679 ms |
| WAV, 20 s | 1,764,044 B | disabled | 40 notes, 432 B .mid | 0 B / 0 B | 26,654 ms |
Every row produced the same 40 notes over the same range, D4 to A4, written into the same 432-byte file. The input sizes span 324,389 to 5,098,367 bytes — a factor of 15.7 — and the output does not move.
Three things follow from that table, and they are the whole answer to the local-versus-cloud question:
- The transcription does not need a server. If any part of it were remote, a 5.0 MB video could not have converted with the network down.
- File size barely affects the time. The 5.0 MB video took 26,679 ms; the 1.76 MB WAV took 28,037 ms. What costs time is the length of the audio — 20 seconds in every row — because the model works through it in fixed windows, not because of how many bytes the container happens to hold.
- There is no per-file cost to ration. Nothing was counted, because there is no server-side job to count. A limit only makes sense when somebody else's machine is doing the work.
What leaves your device, precisely
Being exact matters here, so: the page is not silent on the network. Inside the conversion windows themselves the log is nearly empty — a single request per file, which is the browser reading back the output blob it just created, at 0 bytes. Over the whole session, the only outbound request that was not a GET was this site's own analytics beacon: a POST with an empty body, whose parameters ride in the URL. It appears on every page of this site, it fired twice in the log, and in neither case did it carry anything derived from the file being converted.
Two consequences worth stating plainly. First, your audio contributes 0 bytes to that, whether it is a 324 KB M4A or a 5.0 MB video. Second, blocking it changes nothing about the conversion — the offline rows above were converted with the network switched off entirely.
What the video path costs that the audio path does not
One honest wrinkle came out of the offline test, and it is the kind of thing a comparison table hides. The MP4 reader — a 185,285-byte script — is not part of the engine and is not downloaded with it. It is fetched only when you first hand the page a video file.
In our first session, no video was converted until the network had already been cut. The result: the MP4 failed in 386 ms with "MP4 reader failed to load." — a failure of the download, not of the transcription. A second session converted one video while online first (185,478 bytes over the wire for that reader), and then converted the same 5.0 MB file with the network disabled: 26,679 ms, 40 notes, 432 bytes, 0 bytes in and out. So if you convert video on a plane, do it once while you still have a connection.
This is also the answer to a reasonable question: why not cache everything up front? Because the reader is dead weight for the majority of visits that only ever convert audio, and the page fetches it at the moment it becomes necessary rather than making every visitor pay for it.
What local conversion genuinely costs you
The local side of the table is not free, and the price is worth naming rather than burying:
- First use needs a connection. The page and selected model must load. The historical GAME test transferred 56.2 MB; current modes have different requirements.
- Your device does the work. The historical GAME test took 26.3–28.0 seconds per 20 seconds of audio on a 2-core, 4 GB machine. Current modes may use CPU or WebGPU and take different amounts of time.
- One file at a time. There is no queue and no parallelism, because there is no pool of machines to spread work across.
- Memory, not a quota, is the real limit. The browser's JavaScript heap sat between 8.7 and 15.3 MB after a conversion, with the model's own tensors living outside it in the WebAssembly heap. Long files are where this bites.
- Browser storage for models. The historical GAME test used about 51 MB against that browser's reported quota. Other modes, especially HQ Local, have different download and storage needs.
Set against that: nothing is uploaded, nothing is metered, there is no account, and there is no vendor whose pricing page can change your workflow next month.
Which one should you actually use
- Use local for audio you want to keep on your device, such as an unreleased demo or voice memo. The historical GAME offline test verified that route in an already open tab; current modes still process source audio locally.
- Use local when you convert a handful of files rather than hundreds. The selected model downloads on first use and can be reused from browser storage; the historical transfer counts above are not current estimates.
- Use local when you want to convert now and not after a queue. The 20-second file above finished in 26 seconds; nobody else's job was ahead of it.
- Use a cloud service when you need high-volume batch jobs, a rendered score rather than a .mid, or multi-track processing on a device without enough memory or WebGPU for this site's HQ Local mode.
- Use a cloud service if your machine is genuinely the bottleneck. A phone converting a five-minute song will be slower than a rented server doing the same thing; that is the trade you are making.
What the file it writes actually is
The following details describe the measured GAME Vocal/Fast output. Current HQ Local Full Song instead writes a six-track MIDI Format 1 file:
| Format in this test | Standard MIDI File, format 0 — one track; HQ Local Full Song uses Format 1 |
| Resolution | 480 ticks per quarter note |
| Tempo | Measured from the note onsets and written into the file; 500,000 µs per quarter note (120 BPM) only when no steady pulse can be found |
| Time signature | 4/4, a constant |
| Track name | mp3 to midi |
| Pitch bend range | ±2 semitones, set explicitly with an RPN 0 message, centre 8192 |
| Velocity | clamp(amplitude × 127, 1, 127), carried over from the model's own confidence value rather than measured from the audio |
| Note-off velocity | Fixed at 0x40 (64) on every note |
| Shortest note | 0.02 s — anything shorter is clamped up to it |
| Timing | ticks = seconds × 8 × BPM, so positions are absolute times rather than bar numbers — 960 ticks per second at the 120 BPM default |
Conversion happens inside your browser tab. The selected engine determines its model, sample rate and hardware requirements. The historical offline result applies to an already open tab with the GAME model and decoder loaded; it is not a guarantee that every mode works offline from a fresh visit.
Frequently asked questions
Is my audio file uploaded anywhere when I convert it?
No. We attached a network recorder to the page and converted four files through the real file input — a WAV, an MP3, an M4A and a 5.0 MB MP4 — while logging every request, its method and the size of its body. The total uploaded request body across the entire session was 0 bytes. The only non-GET request in the whole run was this site's own analytics beacon, which carries an empty body and is not related to your audio. Your file never becomes a request payload.
Does this converter still work with no internet connection?
An already open tab completed historical GAME Vocal conversions after its model and decoder had loaded and the network was disabled. A new visit needs the page and selected model files to load. Other modes and browsers were not verified offline in that test.
How much did the historical GAME test download?
The historical GAME Vocal test downloaded 56.2 MB on first use, including about 51 MB of model weights. Those transfer counts belong to an older build. The current site downloads the selected model on first conversion; Piano, Basic Pitch and HQ Local have different requirements.
Is there a file size limit or a daily conversion limit?
The current page sets no conversion quota or fixed file-size cap. Practical limits depend on the selected mode, browser and device memory. In a historical GAME Vocal test on desktop Chrome, 20 seconds of audio took 26.3 to 28.0 seconds on a machine reporting two logical cores and 4 GB of memory. Its browser-storage measurement was 51,055,714 bytes; that is not a current or total-memory requirement.
What is the downside of converting locally instead of in the cloud?
Your device supplies the CPU or GPU, memory and storage. The selected model downloads on first use, and HQ Local needs about 336 MB of model data. Conversion speed depends on mode and hardware. Source audio stays on the device.
Why does the engine need 51 MB when the page itself is tiny?
In the historical GAME Vocal test, five ONNX files totalled about 51 MB. The current site keeps large models separate from the initial page and loads the selected engine only when a file is converted. Different modes have different model sizes.
Do I need an account or a subscription to convert a file?
No account, no email, no key, and no per-conversion counter, because there is no server-side job to attach any of those to. The measured evidence is the offline test: a 5.0 MB video converted with the network disabled and 0 bytes uploaded, which is not possible if a remote service is doing the transcription or gating the download.
Related: how long a file you can convert in a browser, what happens to the audio track in an MP4, and why the tempo is wrong when you open the file.