loudness matching for plugin chains

Cubase
,
1

Understanding the actual effect of plugins on a signal chain, without perception being colored by loudness changes, is crucial.

Use case: User is evaluating the effect of an EQ, compressor, and limiter on a bass track. The user wants to listen to the exact change to the signal without being steered by an increase/decrease in overall volume (which, due to Fletcher-Munson and the effect of loudness itself) can unduly influence perception of the changes being made.

Current workarounds:

  1. The user can buy specialized plugins for this task, such as MeterPlugs Perception, TB Pro Audio’s AB_LM and Melda MCompare. These plugins work pretty well, but they’re a hassle to set up (two instances per channel - a feeder instance at the top of the chain and an evaluator instance at the end of the chain) and they’re expensive relative to their functionality. Advantage is the continuously integrating loudness matching for precision.

  2. More imprecisely, the user can utilize loudness meters to roughly match loudness manually. This is also a bit of a hassle because the user has to set up metering correctly and make manual level compensation changes every time a change is made to the chain.

  3. Also imprecise, the user can “eyeball” it with their ears. This avoids the hassle and expense of setting up meters or specialized plugins, but it will likely be the most frustrating, time-consuming approach.

Feature Request: Include optional loudness compensation as an integrated part of the plugin system in Cubase (similar to the Smart Bypass in WaveLab, but using a more accurate algorithm like MeterPlugs’).

The user could:

  • turn on overall loudness compensation for each track (keeping levels consistent regardless of plugins used); or
  • set numbered “in and out” points for each loudness compensation thread. For example, the user could set the source (starting “in” point) before a specific plugin on a bass track, and set the compensation (adjustment “out” point) after a specific plugin on the master buss. (For lateral-thinking examples of this sort of numbered matching scheme, see Blue Cat Audio’s metering plugins, where tracks can be assigned numbers and all represented within one plugin instance. Not a direct analogy, but the numbering idea is similar.)
2

+1

3

+1

4

+1, agree except for the part in the OP that says,

… and they’re expensive relative to their functionality.

  • Melda MCompare is only$50 on sale several times a year, I consider it one of the best values of any plug-ins I own. It’s on every project, usually multiple instances.
5

You’re right on the usefulness of the plugin - MCompare is excellent. And if you view value through the lens of “how much the plugin helped me do better mixes,” then I agree with your assessment.

Your point is well-taken. Thank you.

When I said “expensive relative to their functionality,” I was looking at value more from a code implementation standpoint. There are other plugins (and software, generally) at similar cost points to the ones listed above which offer significantly more functionality-wise. The implementation of MCompare, for example, is relatively simple compared to many other products at the same price point. You can buy entire entry-level versions of DAWs for around the same price or less than MCompare’s retail price. For that matter, an OEM license for the entire Microsoft Windows OS can be bought at similar prices. I just bought an extremely complex file processing utility (with about 150 discrete features) for less than MCompare, yet the file processing utility clearly required significantly more coding effort.

My main point is that we shouldn’t need workarounds via plugins to get loudness matching for plugin chains. WaveLab already has Smart Bypass; Cubase should have something similar built-in.

6

To underscore the argument here:

HoRNet Plugins just released their own solution to this problem:

HoRNet CLMS

There is such a clear need for this functionality that plugin developers are trying to fill the void in DAWs with plugins. But using these plugins requires significant extra work on the part of users to instantiate and configure numerous instances of the plugins (not forgetting which sender-receivers are associated along the way), plus the increased system overhead associated with running a third-party solution.

I maintain that such core, integral functionality should be included in the DAW host.

7

+1

8

+1