The Drop · October 28, 2026

Bass boosted visualizer: why more low end gives the detector less to work with

Bass boosted edits are their own category now, so feeding the boosted bounce to a visualizer and expecting bigger flashes is the obvious move. I measured it on the real app. Up to a point nothing changes at all, and past that point it gets worse.

Photo via Unsplash

The assumption is fair enough: the app flashes off bass energy, so more bass should give it more to bite on. The reason it does not is in how the browser hands the app its numbers rather than in anything the app decides.

The detector runs a contrast test, not a loudness test

Every frame, the app reads a block of low and low mid bins out of the analyser, keeps the last 43 frames as a rolling average, and flashes when the current frame beats that average times your Beat sensitivity setting, which runs 1.05 to 2.00 and opens at 1.35. The beat detection post walks the whole chain and the beat sensitivity post has the exact band and the measured tuning.

The problem is already visible in that sentence. The question is never how big the bass is. It is how much bigger this instant is than the last three quarters of a second, and lifting the whole low end lifts both halves of that comparison.

The ceiling you cannot push through

The analyser does not hand the app raw power. It hands it a byte per bin, and the Web Audio specification defines that byte as the decibel value clipped between minDecibels and maxDecibels and then scaled so the minimum reads 0 and the maximum reads 255. The defaults are -100 and -30, and this app never overrides them. So the entire 0 to 255 scale covers a 70 decibel window, which works out at 3.64 units per decibel.

The bass you want to boost is already sitting at the top of that window. On my unprocessed test file, the lowest three bins averaged 242, 235 and 222 out of 255, and the bottom bins were pinned flat at 255 on roughly one frame in six before any processing at all. There is nowhere for them to go.

What a 12 decibel boost actually did

The test file is 16 seconds at 120 BPM: 32 kicks, a closed hat on every offbeat, and a sustained four note bed so a boost has something to lift. The boosted versions use a low shelf at 100 Hz, applied in floating point so the filter itself does not clip, then peak normalised back to where the original sat. That is the careful bass boost, the one that does not distort.

Here is the mean level the detector saw in each of the first few bins, which was reproducible to within a unit across every playback:

Bin 1 gains six units and then stops, because it has hit the ceiling. Bin 2 goes down. Everything from bin 3 up falls off a cliff. And the amount it falls by is not mysterious: the 12 decibel shelf costs 6.42 decibels of headroom to normalise, which at 3.64 units per decibel predicts a drop of 23, and bins 3 to 5 measured 22 to 25 units down. The 18 decibel shelf costs 10.96 decibels, predicts 40, and measured 36 to 42.

So a bass boost does not raise what the detector reads. It lowers everything else in the band the detector reads, by exactly the headroom you paid for the bass.

The flash count, run three times per file

Every file went through the app three times. At the default sensitivity the original, the 6 decibel version and the 12 decibel version all produced 32 flashes every single time: one per kick, 500 milliseconds apart, nothing gained and nothing lost. The 18 decibel version produced 28, then 15, then 32 across three identical playbacks, which is the point where the contrast has dropped close enough to the threshold that the result stops being repeatable.

The damage shows up properly in the slider rather than at the default:

Flashes over 16 seconds against 32 kicks, range across three playbacks. The boost buys extra false triggers at the bottom of the slider, where the raised floor starts clearing a 1.05 threshold on its own, and costs you the top of it entirely. The original fires through the whole range. The boosted files have no usable room above the default.

The clipped version does flash more, and it is not the bass

Most bass boosted uploads are not politely normalised. They are slammed, limited or just left to clip, which is half of why they sound the way they do. That version goes into the visualizer very differently: same shelf, a limiter instead of a gain reduction.

It flashes differently, and the bins say why. The bottom three were pinned at 255 on 82, 99 and 50 percent of frames against 16, 18 and 9 percent for the original, and the upper half of the band lifted hard, bin 7 going from the high twenties to the low forties. That upper lift is distortion harmonics spreading up the spectrum, not bass.

In two of three playbacks the limited file fired roughly twice per beat, the extra flash landing 250 milliseconds after the kick, which is where the hi-hat is. So I stripped the hats out of the source and ran the clipped version again: 31 flashes, one per kick, the same as the original. The second flash was the hat, and it only crossed the line once distortion had filled the bins above the shelf. If your bass boosted edit really does flash harder than the clean file, what the detector grabbed onto was the clipping.

Turn the Bass drop slider down, not up

Bass drop sensitivity is a separate detector sitting at zero when you open the page, so it is off until you move it. It compares a fast follower against two references, a slow baseline and this track's own running peak, and either one can engage it. Once it holds you get continuous glitch slices, frame shake and scrambled text rather than a hit at the drop.

The running peak path hit its maximum on every file I tested, boosted or not, so that path is always armed and the baseline comparison is what gates it. Replaying the engage arithmetic over each playback, the original needed the slider at 75 percent before it held, while the 12 decibel version engaged at 50 percent in two of three runs and the 18 decibel version engaged at 50 in all three and at 25 in one. The dubstep post covers what that detector is meant to be doing when it is working properly.

What to feed the visualizer instead

Give it the unboosted master if you still have it. The app has no EQ, no gain control and no speed control anywhere, so it only ever sees the file you hand it. You can always boost the audio afterwards in the edit and keep the visuals cut from the clean version.

If the boosted file is all you have, go down on Beat sensitivity rather than up, which is the opposite of what the file sounds like it needs, and watch the preview before committing to a render. Keep Bass drop sensitivity low. And if it is heavily limited and the flashing is landing everywhere, Fixed interval ignores the audio completely and gives you a steady rate you pick, which beats fighting a detector on material that has had its dynamics removed.

One safety note, because this topic lives at the fast end. At the bottom of the slider the boosted files fired 55 to 74 times in 16 seconds, between three and a half and four and a half a second, past the three per second where photosensitivity guidance starts. The strobe and photosensitivity guide has the thresholds, and a bass boosted edit is exactly the kind of upload that ends up autoplaying in somebody's feed.