Troubleshooting · How we test and maintain this guide
A permitted input count is only one limit
Twenty short compressed files and twenty long high-resolution sources can require very different amounts of browser memory. The workspace limits the number of links and the size of media, but passing those checks does not guarantee that a particular device can finish every batch. CPU load, decoder support and available memory still matter.
| Current check | Value |
|---|---|
| Distinct links in one batch | 20 |
| Source file bytes | 64 MiB (67,108,864 bytes) |
| Prepared batch audio bytes | 256 MiB (268,435,456 bytes) |
| Song duration limit | 10 minutes per track |
The displayed messages sometimes abbreviate the binary size limits as MB. The byte values above make the implementation precise. These limits describe source and prepared data, not a promise that the browser will use at most 256 MiB of RAM. A collection can need additional working copies while decoding, encoding or assembling an archive.
Compressed size and decoded size are different
A simple estimate illustrates the difference. Ten minutes of stereo audio at 44,100 samples per second, with four-byte floating-point samples, represents 600 × 44,100 × 2 × 4 = 211,680,000 bytes, about 201.9 MiB. This is a calculation for one decoded sample buffer, not a measured peak-memory result. Encoders, source bytes, output bytes and other browser work can add more.
The tool prepares songs sequentially, but retains successful outputs so you can preview and save the collection. Building a ZIP also creates an archive object. JSZip uses STORE rather than recompressing the audio, so archive creation is not a way to shrink all the music substantially. The archive also contains tracks.csv and manifest.json.
In the ten-signal benchmark, the Original archive was 36,395,181 bytes and the MP3 archive was 16,218,985 bytes. Both reopened successfully with matching audio hashes. Those observed sizes are useful examples, but they are far below a promise about a maximum-size batch. We did not measure peak RAM, concurrent users or every twenty-song workload.
Save useful results, then split deliberately
- Keep the tab open if it is still responsive. Save important ready tracks individually before attempting another expensive operation.
- Export the CSV so you retain the source list and the status of unfinished rows.
- If ZIP creation fails, select a smaller group of ready tracks and build that archive. Verify its save before moving to another group.
- If audio preparation itself fails under a size or memory condition, save completed work, then start a smaller fresh batch.
- Keep the smaller archives in separate staging folders until their contents and records have been checked.
Unchecking a prepared track reduces the next ZIP's contents; it does not necessarily free that track's prepared audio from the page. If the page is already under memory pressure, individual saves followed by a deliberate fresh session may be more effective than repeatedly rebuilding a large collection. Refresh only after the files you need have actually reached disk.
Choosing MP3 may reduce output size for a large uncompressed source, but conversion itself needs decoding and encoding work. Original avoids that extra encoding step but can retain larger source files. Test one representative permitted track and choose for your destination rather than assuming either format always minimises memory.
Keep smaller exports traceable
Name staging folders by project and batch, and keep each archive's own records with it. A later CSV can describe a different selection. Before combining folders, check for same-title collisions and repeated source IDs. A browser-added suffix is not proof that two files contain different music.
For a stalled run, report the browser version, approximate number of tracks, chosen format, last visible stage and any exact error. File sizes are more useful than the input count alone. Do not describe the supported link limit as a guarantee that the largest possible batch must complete on every machine; the practical next step is a small reproducible run.