The Drop · October 6, 2026

Why your music visualizer looks blurry after you upload it

It was sharp in the browser. Then it went up, came back smeared on the fast sections and blocky on the flashes, and the usual advice is to raise the bitrate. Here you cannot, and it would not be the fix anyway.

Photo via Unsplash

A visualizer getting blurry after upload is not usually a mistake you made in the export. It is the collision between what this kind of video is made of and what compression is good at, and once you can see the collision you can decide which parts of the look are worth paying for.

Your file is not short of bitrate

The app records at a fixed 16 Mbps, 1920 by 1080, 60 frames per second. There is no quality slider anywhere, so every render you have ever made from it left the browser at that number.

YouTube publishes what it wants from an upload. For SDR video at 1080p the recommended bitrate is 8 Mbps at 24, 25 or 30 frames per second, and 12 Mbps at 48, 50 or 60. The same page says, in its own words, that no bitrate limit is required and the figures are there for reference.

So a render leaves here at a third more than the platform asks for at this resolution and frame rate. Whatever makes it soft, a starved file is not it, and there is no number to turn up.

What costs bits is change nothing can predict

A video codec does not store 60 pictures a second. It stores one picture, then the difference from it, then the difference from that. A frame that mostly repeats the frame before it is close to free. A frame that shares nothing with it has to be sent almost from scratch.

A flashing, glitching visualizer is near the worst case anyone can hand that system. So I measured it. Same four second clip at 1080p60, encoded four ways at the same fixed quality setting, with the encoder free to spend whatever it needed to hold that quality.

The last row is the one that matters. To look as good as the steady clip looks at 1.24 Mbps, the same footage with a noise layer over it wants roughly 42 Mbps. The recorder has 16. It cannot get there, so it does the only thing it can and throws away detail everywhere until the frames fit.

Film grain and TV static are the most expensive settings in the app

This is worth knowing because the artifacts menu looks like a free texture and is not. Grain and static are built from a single square of random noise that the app draws tiled across the frame. The square itself never changes, but the position it is drawn from is re-rolled at random on every single frame, so the texture never sits still for even two frames running. Nothing in it can be carried forward.

The other two options in that menu behave completely differently. Scanlines is a small fixed pattern that does not move at all, so it costs almost nothing. VHS is scanlines plus a 50 pixel tall band of the picture redrawn shifted sideways, and that band only jumps every 0.3 to 1.4 seconds, so it is cheap on most frames and expensive on the one where it moves.

If a render came back mushy and the artifacts menu was on grain or static, change that one thing and render again before changing anything else.

Shake and zoom are nearly free, which surprises people

Earthquake shake looks like the most violent thing in the effects menu and cost 1.47 Mbps against the steady clip's 1.24. That is the whole penalty.

The reason is that moving the entire frame is exactly the case compression was designed around. The encoder gets to say "the same picture, 14 pixels to the left" in a handful of bytes. Zoom punch is in the same family. Glitch slices and RGB split are not, because they rebuild the frame out of pieces that each move differently, and strobe and invert are not, because they change every pixel's brightness at once.

So if you want visible energy that survives an upload, shake and zoom give you the most motion per bit of anything in the menu.

The platform re-encodes it, and that is where flashing collapses

Nothing you upload is served to viewers as the file you sent. It is decoded and encoded again into the platform's own set of versions. Your render is therefore a second generation copy before anyone presses play, and compression damage from the first pass gets baked in as source material for the second.

I measured that hand off too, by re-encoding the 16 Mbps renders to H.264 at the 12 Mbps YouTube lists for 1080p60 and scoring each against the original. The score is a structural similarity figure where 1.0 means identical.

• Steady footage: 0.986 after the first encode, 0.980 after the second. The second pass cost it almost nothing.
• Flashing footage: 0.847 after the first encode, 0.651 after the second. Same bitrate, same encoder, a loss more than thirty times larger.

That is my own conversion rather than the platform's pipeline, so treat the exact numbers as a direction and not a promise. The direction is clear enough: steady content barely notices a second encode, and full frame flashing falls apart in it.

What actually helps

• Turn the artifacts layer off, or drop it to scanlines. Biggest single win available, and most people have it on for a texture they would not miss.
• Slow the content change rate. Every 1 or 2 beats instead of every 1/4 gives the encoder whole beats of picture it can reuse.
• Lean on shake and zoom when you want motion, and spend your expensive effects on the moments that earn them rather than the whole track.
• Upload at the full 1080p60 render. Scaling it down yourself adds a compression generation and gives the platform a worse source to work from.
• Convert once, to H.264, if you convert at all. The export guide has the single command, and the WebM against MP4 piece covers why the container itself is not the thing hurting you.

And the things that do not help: re-rendering at a higher bitrate, which you cannot do here and which would not clear 42 Mbps of demand anyway; sharpening the file afterwards, which gives the next encoder more detail to spend bits on and usually makes the blockiness worse; and uploading a bigger file of exactly the same frames.

One more thing worth knowing about the recording itself. The app asks for VP9 first and falls back to VP8 if the browser will not do it. Both are recorded at the same 16 Mbps, but VP8 is an older codec and gets less out of that budget, so the same settings in a browser without VP9 support come out slightly softer before an upload is anywhere in the picture.