Remaster (Loudness) 🎚️

The problem it solves

No music model masters its own output. Ask ACE-Step or YuE2 for a song and you get a take at whatever level it happened to land on - sometimes six dB under, sometimes peaking into the red - and ComfyUI's Save Song writes exactly that. Play two of your generations back to back and you're riding the volume knob.

Remaster (Loudness) is the missing mastering step. Drop it between the sampler and Save Song, and the finished take lands on a loudness target with its peaks held under a ceiling. It's the same story as the rest of the audio layer: the models are good, and the last ten percent of polish is on you.

Put it after Audio SR if you're using the 48 kHz upscale, so the peaks get measured at the rate that actually gets saved.

How it works

Three things happen, in this order, and each is done the boring correct way rather than the convenient one.

It measures. Loudness is BS.1770-4 integrated loudness - the gated, K-weighted mean that streaming services normalise to - and the implementation is torchaudio's, not a hand-rolled approximation. The report also gives loudness range (EBU Tech 3342), which is how far your quiet parts sit from the loud ones; that's the first thing a limiter eats, and printing it before and after shows you exactly what you spent.

It measures peaks between the samples. A waveform can swing higher between two sample points than at either of them, and an MP3 or Opus encoder will happily reproduce that swing. So the ceiling is a true-peak ceiling, read from the signal oversampled 4x as BS.1770 prescribes. That's why the default is -1 dBTP and not 0.

It limits with the whole song in view. This isn't a realtime limiter, so the gain every sample needs is known in advance: it comes down over the 5 ms before a peak instead of clipping its leading edge, recovers at a steady 40 dB per second after it, and both channels share one gain so nothing moves in the stereo image. There's no compressor, deliberately - the take arrives already mixed, and squashing it further is a taste decision, not a default.

Because limiting takes a little loudness off too, the node nudges the gain up and reruns the limiter until it's within 0.05 LU of target or hits the cap.

Inputs worth touching, and the outputs

• target_lufs - default -14, range -40 to -5. Leave it alone unless the file is going to be played as-is. -14 is what Spotify and YouTube normalise to, so a hotter master just gets turned back down by the platform, and you've spent dynamics for nothing.
• true_peak - default -1 dBTP. Keep the headroom for the encoder.
• max_limiting - default 6 dB. This is the interesting one: it's the most the limiter is allowed to shave off a peak to reach the target, so it's your dynamics budget. At 0 the node becomes a plain true-peak normaliser that only turns the song up or down.
• audio - the finished song, AUDIO type, from the sampler or Audio SR.

Out goes audio (straight into Save Song or core's Save Audio) and report, a STRING - wire it to a text preview node or read it in the console. Silence or a clip shorter than one 0.4-second gating block passes through untouched, and a batch gets its report split per clip.

Reading the report

It prints before and after - LUFS, true peak, range - then what it did: gain +X dB, the limiter's maximum cut, and roughly how much of the song needed more than a dB of limiting. That last number is the honest one. A few percent means the limiter caught occasional peaks; thirty percent means it's holding the whole track down and you're listening to the limiter more than the mix.

The other line to watch for is the shortfall warning. If reaching -14 would have needed more peak reduction than max_limiting allows, the node stops short on purpose rather than squashing your song to hit a number. It tells you what the target would have cost. That design choice - master loudly vs. master well, ask the human - comes from Johannes Plenio's production system; the implementation is the pack author's own. Raising max_limiting is a real decision, not a fix.

Install and gotchas

Manager, search Kinburg-Nodes - or:

cd ComfyUI/custom_nodes
git clone https://github.com/Kinburg/Kinburg-Nodes

Restart, then look under Kinburg-Nodes → audio. No models, and nothing to download; the node runs on the CPU, about five seconds for a five-minute stereo track at 48 kHz. Negligible next to generating the song in the first place.

Two things that trip people up. First, install.py fires automatically on a Manager install and installs a CUDA llama-cpp-python wheel for the pack's Local LLM nodes - irrelevant here, and if that step errors on your machine it doesn't affect this node. Second, this is a final step: putting it before Audio SR measures and limits a signal that then gets resampled and changed, which defeats the point of a true-peak ceiling. Master last, then save.

If you want compression or glue, that's a different tool in a different chain. This one exists to get you to a sensible level without flattening anything - and to admit when it can't.