How long a file can an online MP3 cutter open?

Why a browser cutter has a length limit

An online MP3 cutter that works in the browser, like this one, does not edit the MP3 file itself. It decodes the whole file into raw samples first, so that it can draw the waveform, play any point and cut to the millisecond. The page's code keeps those samples as 32-bit floating-point numbers at 44,100 per second, one stream for mono and two for stereo: 4 × 44,100 × 60 = 10.6 MB per minute for mono, 21.2 MB for stereo. One hour of stereo is 1.27 GB before anything else the browser needs. A 128 kbps MP3 is about a tenth of that size, so the MB on disk say little; minutes, and mono or stereo, decide.

On top of the samples the page keeps, the browser needs working memory while it decodes, and saving a file needs room for a copy of the selected part. Those peaks, not the steady state, are what end a tab. And separately from memory, Chromium refused to decode files past a fixed length on every try; we found where that line is but did not find it documented.

How we tested

• Tool: this site's audio cutter (the home page), run in headless Chromium 153 through Playwright 1.63 on a local copy of the page. A fresh browser was started for each file. The script chose the file, waited for the editor or an error, then typed a 10-minute region in the middle of the file and downloaded it as WAV, then did the same with the whole file.
• Machine: a 4-core server (Intel Xeon E5-2699 v4) with 9.9 GB of memory, of which 2.7 to 3.9 GB was free at the start of each run; other programs used the rest. There is no swap. A tab that runs the system out of memory is stopped by the Linux kernel; the kernel log shows each one as Killed process ... (chrome-headless), and no other program was stopped.
• Files: the first movement of Mozart's Symphony No. 40, played by the Musopen Symphony (public domain, on Wikimedia Commons), looped to length with FFmpeg 4.4.2: stereo 128 kbps MP3s at 44.1 and 48 kHz of 10, 30, 60, 90 and 120 minutes; mono 64 kbps MP3s at the boundary lengths and at 120 and 180 minutes; and a 3-hour mono 64 kbps AAC audiobook file (.m4b, 88.7 MB).
• Memory: total resident memory of all Chromium processes, sampled every 0.1 s; an idle browser on the page used 415 to 443 MB.

What opened, and what it cost

Two things stand out. Files at 48 kHz took more than twice as long to open as the same length at 44.1 kHz (30.8 s against 12.7 s for an hour), because the browser decodes at the file's rate and then converts to the 44.1 kHz the page works in. And the two failures are different: "tab killed" depends on how much memory is free and would move on a bigger or smaller device, while "refused" came at the same length every time, with memory to spare in the mono runs.

The fixed ceiling: about 101 minutes at 44.1 kHz

To find where the refusals start without running out of memory first, we used mono files, which need half the memory of stereo:

At both rates the line falls between about 267 and 270 million samples (per side, for stereo), counted at the file's own rate. 2²⁸ = 268,435,456 sits inside both gaps; that many 32-bit samples is exactly 1 GiB. That would put the ceiling at 101 min 26 s at 44.1 kHz and 93 min 12 s at 48 kHz, but we only measured whole minutes either side of it. We read Chromium's audio decoding code and did not find this limit written down, so we report it as measured in Chromium 153 only. We did not test Firefox or Safari.

The ceiling counts each side of a stereo file separately, so stereo does not lower it (our 60-minute stereo files opened with 158.8 million samples per side, 317.5 million in all), but stereo needs twice the memory, and on our server a 90-minute stereo file ran out of memory before it got that far.

Saving: a region is cheap, the whole file is not

Saving builds the selected part again in memory: a copy of the samples, then the 16-bit version, then the WAV file itself, all while the decoded original stays open. For a 10-minute region that is a few hundred MB; for a whole hour it is more than the decoded file again. The same 10-minute region as a 128 kbps MP3 took 82.0 s from the 30-minute file and 76.8 s from the 60-minute file (9.6 MB, 600.03 s long when decoded); we did not try a whole-file MP3 export.

What to do with a long recording

1. Under an hour of stereo, or under about 100 minutes of mono: open it in the audio cutter. Close other heavy tabs first; the decoded file needs about 10.6 MB per minute for mono or 21.2 MB for stereo, and more while it opens.
2. Select only what you need and download that. If you need several parts, use one region per part; see how to split one MP3 into several tracks.
3. If the page says Your browser couldn't decode this file on a long recording, or the tab crashes, split the file first. With FFmpeg, this copies the MP3 into 45-minute pieces without re-encoding:
   ffmpeg -i long.mp3 -c copy -f segment -segment_time 2700 part%02d.mp3
   We split our 120-minute stereo file this way (FFmpeg 4.4.2) into pieces of 45:00, 45:00 and 30:00; the first opened in the cutter in 10.9 s. The pieces are cut at MP3 frame edges, so the first decoded to 44:59.991.

The page sets no size or length limit of its own, and the file is not uploaded, so the limits above are the browser's and the device's. We did not test a phone, so we cannot say where its limits are.

Questions

Is the limit in MB or in minutes?

In minutes, and whether the file is mono or stereo. In our tests a 3-hour mono audiobook of 88.7 MB crashed the tab, while a 90-minute mono MP3 of 86.4 MB opened in the splitting test. The decoded size is the same per minute whatever the bitrate.

Does a lower bitrate MP3 let me open a longer file?

No. Bitrate changes the file on disk, not the decoded samples. Mono halves the memory; the length ceiling stays the same.

Can I open a 3-hour audiobook?

Not in one piece in Chromium: three hours is past the length the browser decoded in our tests, and our 3-hour .m4b ran out of memory first. Split it into pieces under 90 minutes and open each one.