The Drop · September 29, 2026

Music visualizer render problems: black, silent, or out of sync

You sat through the whole track, the file downloaded, and it is wrong. The good news is that a browser render only fails in about four ways, and each one tells you exactly what happened.

Photo via Unsplash

Most music visualizer render problems get reported as "it just broke" and then get fixed by rendering again and hoping. The recording path here is short: the canvas is captured, the audio graph is captured, the two go into one WebM. Every symptom below maps onto one link in that chain.

The whole video is black, but the audio is fine

This is the common one, and it is not a bug in the visuals. The app draws every frame from a requestAnimationFrame loop, and browsers stop running that loop when the page is not on screen. Chrome's own developer blog puts it flatly: "Chrome does not call requestAnimationFrame() when a page is in the background. This behavior has been in place since 2011." MDN says the same thing about every other browser: those calls are paused in background tabs.

Audio does not stop with it. The same Chrome page notes that pages playing audible audio are treated as user visible and exempted from background throttling. So the track plays out in full while nothing is being painted, and that asymmetry is the entire problem.

Why black specifically, rather than a frozen picture? Between flashes the scene is filled solid black, with the text, image or shape drawn on top. At the moment you hit render nothing has been picked yet, so the first painted frames genuinely are just black. Switch tabs in that first second and the recorder captures that black frame for the length of the song, because the capture runs at a fixed 60 frames a second and keeps pulling frames off the canvas whether or not the canvas ever changes. Nothing errors. You get a full length, correctly timed, entirely black video.

It froze on one frame instead

Same cause, later in the timeline. You left the tab thirty seconds in, so you have thirty seconds of real footage and then one still image holding until the track ends.

The cause people miss is the screen going to sleep. MDN's definition of a hidden document is worth reading literally: the page is hidden when "the document is either a background tab or part of a minimized window, or the OS screen lock is active". A display timeout partway through freezes the picture exactly like switching tabs does, so set the screen to stay awake before anything long. The long render post covers the rest of what an hour long recording costs you.

Focused is not really the rule

The app's own hint says to keep the tab focused, which is good advice and slightly stricter than the truth. The rule the browser applies is visibility, not focus. MDN defines a visible page as "the foreground tab of a non-minimized window". Clicking into another application while the browser window stays on screen leaves the page visible, and the loop keeps running. Covering it with a full screen window, minimizing it, switching to another tab, or letting the screen lock are the four things that stop it.

On a second monitor that is genuinely useful: park the render on one screen and work on the other, as long as the window stays uncovered.

The file has no sound

Worth being precise here, because the intuitive explanation is wrong. What gets recorded is not what comes out of your speakers. The decoded track is routed down two separate branches: one to the analyser and on to your output so you can hear it, and a completely separate one into the recorder. Muting the tab, pulling your headphones out, or having the system volume at zero changes the first branch and cannot touch the second.

So a silent file almost always means the audio is in there and something downstream is not reading it. Check before you re-render, if you have ffmpeg installed:

ffprobe -v error -show_entries stream=codec_type,codec_name -of csv=p=0 render.webm

A healthy file prints two lines, vp9,video and opus,audio. If the audio line is there, the render worked and the problem is the player or editor you loaded it into. Converting to MP4 sorts that out, and the export post has the command.

It looks out of sync

The built in recorder has very little room to drift. It takes frames off the canvas and audio off the audio graph, both in real time, with no separate encoder in between holding one of them up. If the machine struggles you get repeated frames, not a picture sliding away from the music.

Two things do cause real sync complaints. The first is screen recording the tab with OBS instead of using the render button: that captures your display and your speakers, adds its own latency to each, and re-encodes footage that was already encoded once. The second is a player with nothing to seek against, which is the next problem.

The scrubber is broken, or an editor refuses the file

A WebM written live by a browser recorder has no duration written into it, because the length was not known when the file started. Players show a blank or wildly wrong timeline, seeking jumps around, and some editors decline it outright. The video and audio are fine. The header is incomplete.

One line fixes it, with no re-encoding and no quality loss:

ffmpeg -i render.webm -c copy fixed.webm

Testing that on a deliberately duration free WebM here: before the remux, ffprobe reported duration=N/A. After it, duration=4.008000, with both streams untouched and the file 63 bytes larger. -c copy means stream copy, so it finishes almost instantly on a long render. If you are converting to MP4 anyway, that conversion writes the duration too and you can skip this step.

It came out looking worse than the preview

The recorder asks for VP9 first, falls back to VP8 if the browser cannot record VP9, and falls back again to whatever WebM it can manage. The target bitrate stays at 16 Mbps in every case, so a fallback spends the same data on an older, less efficient encoder. The downloaded file is named the same and carries the same extension either way, so you cannot tell by looking. The same ffprobe command above tells you: vp9,video or vp8,video.

Flashing, glitching, full frame content is the hardest material any video codec ever gets, since almost nothing in a frame can be predicted from the one before it. The container is a separate subject, covered in the WebM and MP4 post.

Before the next render

• Leave the window uncovered and stop the display sleeping.
• Close anything heavy. The render is real time and wants the same GPU.
• Watch the first few seconds. Content appearing on the flashes means the loop is running.
• Play the finished file once before you start cutting.

None of that is a workaround for a broken tool. Real time browser recording is the trade for something with no upload, no signup and no watermark, and every one of its failure modes is predictable once you know where it comes from.