The Drop · September 10, 2026

Long visualizer renders: full albums, DJ mixes and hour long uploads

Most guides here are about what to put on screen. This one is about time, disk and the fact that an hour of music costs you an hour of afternoon.

Photo via Unsplash

An hour of music takes an hour

There is no fast export. The app plays your file, draws each frame as the audio reaches it, and records both together while that happens, so a 58 minute mix takes 58 minutes. It cannot go quicker: the visuals come from a live reading of the audio, and that reading only exists while the audio is playing.

The one convenience is that you do not have to watch the clock. The recorder is tied to the end of the audio, so it stops itself, assembles the file and puts a download button in front of you. Start a long render, walk away, come back to a finished file. With one condition.

The tab has to stay in front for all of it

The drawing loop runs on requestAnimationFrame, and MDN is blunt about what happens to that in a tab you are not looking at: requestAnimationFrame() calls are paused in most browsers when running in background tabs or hidden iframes.

Audio does not run on that clock. Switch to another tab halfway through and the music keeps playing, the recorder keeps writing, and the picture stops moving. You get a full length file with correct audio over a still frame from the moment you looked away. Nothing warns you. You find out on playback.

So leave the tab active and the window on screen. A second monitor solves it. If you have one screen, an hour long render is an hour you are not using the computer for anything else, which is worth knowing before you start rather than 40 minutes in.

Roughly two megabytes a second

The recorder targets 16 Mbps of video, about 2 MB every second, so the arithmetic is easy:

• One minute is around 120 MB.
• Ten minutes is around 1.2 GB.
• A full hour is somewhere near 7 GB, plus the audio track and the container around it.

Those are targets, not promises. A mostly black strobe video compresses better than an hour of moving photographs, and the app prints the real size once the render finishes.

There is a second limit underneath. Chrome's own blob storage documentation puts the in memory ceiling on 64 bit desktop at 2 GB, past which data pages out to disk with an allowance of one tenth of the drive. Your render crosses 2 GB at around the seventeen minute mark and lives on disk after that. That is by design, but a nearly full drive becomes a real reason a long render dies partway through.

The tempo is decided in the first minute

When a file loads, the tempo is worked out offline by scanning an energy envelope for the spacing that best lines the onsets up. How beat detection works covers that properly. The detail that matters here is the window: the scan reads at most the first 60 seconds, however long the file is. One number comes out, and every content change in the render rides it.

For an album track, perfect. For a two hour mix that opens at 122 and ends at 150, you get the opening tempo for the entire set, and by the last hour the grid has nothing to do with what is playing. Two ways around it:

• Switch content changes to the older mode that counts flashes rather than beats. Flashes fire off live energy, so it follows the mix as it moves rather than a number set in the first minute.
• Or split the set and render the pieces separately, which is usually better anyway.

Memory, before you even press play

The file is fully decoded to uncompressed audio when you load it, not streamed. An hour of stereo at a 48 kHz context is 3600 seconds times 48000 samples times two channels times four bytes, about 1.4 GB sitting in memory before a single frame is drawn. The compressed file you dragged in is still there too, and the recording grows alongside both.

With plenty of RAM this is a non event. On a laptop with 8 GB and thirty tabs open it is why the render stutters or the tab falls over. Close things first.

When to split the set

Rendering a whole album or mix in one pass is usually the wrong instinct. Split it when:

1. Different tracks want different looks. Settings apply to the whole render, so one pass means one palette, one font set and one intensity across everything.
2. The tempo moves. See above. One grid for the whole file.
3. You want to fix a mistake. Getting 50 minutes in and deciding the flash duration is wrong means starting the hour again.

The app has no trim control, so splitting happens to the audio before you upload it. One ffmpeg line per piece: ffmpeg -i mix.wav -ss 00:20:00 -t 00:20:00 -c copy part2.wav

The finished file will not know how long it is

Recording happens in 250 millisecond chunks, and chunked WebM from a browser recorder comes out with no duration written into the container. The video plays fine, but players report an unknown or infinite length and the seek bar misbehaves. On a 30 second clip you might not notice. On an hour long file with no working scrub bar, you will.

Running it through ffmpeg rewrites the container and fixes this as a side effect, which you are probably doing anyway to get an MP4. The export guide has the command. Budget for it, because converting an hour of 1080p is not instant either.

Where an hour actually goes

If YouTube is the destination, two of its limits apply. Google's upload help page states that the maximum file size you can upload is 256 GB or 12 hours, whichever is less, so a 7 GB hour is nowhere near the ceiling. The catch is the other one on that page: accounts are capped at 15 minute uploads by default and need verifying to go past it. Sort that out before the render. The YouTube guide covers the rest.

An hour of flashing is a long time

Worth saying plainly here. Flash rates above three per second can trigger seizures in people with photosensitive epilepsy, and a full length render means someone could be exposed for an hour rather than for a 30 second clip. If it is going on a screen behind a DJ set, dial the intensity down and warn people. The strobe guide has the thresholds and the settings for the gentler end of the range.

The short version

• Recording is real time. An hour of audio is an hour of rendering, and it stops itself at the end.
• Keep the tab active and on screen. A backgrounded tab gives you full audio over a frozen picture.
• Budget 2 MB per second, near 7 GB for an hour, and keep a tenth of the drive free.
• The tempo scan reads only the first 60 seconds, so a mix that changes tempo needs the flash counting mode or a split.
• An hour of decoded audio is about 1.4 GB of memory before anything is drawn.
• The WebM comes out with no duration in the container. An ffmpeg pass fixes it.