Youlean Loudness Meter 2 - V2.5.2 - April 25, 2022 update

[heavymetalmixer]

and this isn't handled by a proper ISP peak limiter because...?

ISP limiters aren't 100% trustworthy for their work, also, they sound worse that normal limiters.

[Compyfox]

<on topic ISP measurement>

So you want to bring back a technique that was in old Elemental Audio InspectorXL (now AXISplugins - who seem to have also vanished) in form of a plugin called "Statistics".

There is sadly no screenshot of that dedicated plugin anymore, neither do I have the old version still installed, but there was a "simplified" version in InspectorXL that showed Clip Incidents, Max Runs and Clips. And you could set the maximum allowed occurrence until red lights went off. See the following screenshot:



HOWEVER... this was only important at times of peak limiting, prior to the K-System (recommendation) and the (re)introduction of Leq(m) type measurement (in our case - ITU-R BS.1770-x or in the Europe more pushed EBU R-128). At times where people still pushed the content loudness wise.

At times where we barely reach(!) -1dBTP at values of -23LUFS ILk or only the occasional overs at -16LUFS ILk, like we should if we'd actually stop fueling the Loudness War, do we really need a so called "ISP Density" (which is really nothing else than this upper mentioned old counter type)?

ISP analysis in form of "True Peak" measurement is part of the specs since pretty much day 1.
Isn't the visual representation on the Histogram enough to see when and how often it happens?



Again, I've been using this meter type (ITU-R BS.1770-x) for years at this point. I've been through various iterations, participated in endless debates with developers and users. I still try to see a need (!!!!) for such an indicator.

If the signal goes over, it's not within spec, do better limiting. Plain and simple.

Why introducing something "off-spec" with extra work and extra testing, just to have yet another(!) unnecessary readout and to confuse non-skilled users in this field even more?



Please - explain in a way so that everyone can understand your reasoning behind this.

Because currently, to me it sounds you want to continue to "push" signals beyond recommended specs (-12LUFS and higher) and you consider the available readouts to not be enough still.

and this isn't handled by a proper ISP peak limiter because...?

Asking the very same, Burillo.

Maybe this topic just flies above my head.

and this isn't handled by a proper ISP peak limiter because...?

ISP limiters aren't 100% trustworthy for their work, also, they sound worse that normal limiters.

But that is EXACLTY the point of this discussion.

So called "ISP limiters" (which is a really colored description) are only there for clipping and/or "peak over" protection. If you use the signal as intended, and don't push your signal beyond certain limits (again: the ideal planned goal for music is -16LUFS ILk!), you will never need an oldschool "Maximizer" or "loudness limiter" anymore.

You still limit a signal, true (as in, "clip off" transients). But you're not pushing for perceived loudness anymore - because there is just no need. All you do during (pre)mastering to "compacting the signal", is once more "artistic handling". Nothing more, nothing less.

And again, if the signal goes "over", you're not within specs, adjust your limiter accordingly.



That is the beauty of everything... that is why mastering according to ITU-R BS.1770-x (or it's derivatives) specs is so great. It's also easier to transfer to Tape, Vinyl, BluRay Audio and Broadcast.

We already have(!) the desired extra analysis. Both as numeric readout and(!) as visual indication on the histogram. There is nothing more to add.

[plexuss]

Look I'm not going to get into it with you. My statement below is the best rationale I have. Sorry you disagree. There are those that agree.

[Compyfox]

Who are "those" people? Cite your sources, please - I want to know the names of these people, I want to read myself into this, educate myself, I want to discuss and talk shop.

Yet still, why do you want to reinvent the wheel, if it has already been invented and has been available since day 1 (in fact, since early 2000s)


Honestly - I am starting to think that you do not understand how some of these metering tools, and especially the collection of tools we have at our disposal that make up the ITU-R BS.1770-x specs, actually work. Or something flies km's above my head, beyond my comprehension.


But I get it - you don't want to discuss things - again... can't be helped then

However things like this, debates that don't need a debate cause "it's standardized", is what are the very reason we will never(!) get rid of the Loudness War. Everyone insisting on doing their own thing, everyone thinking "this is the route to go" rather than pulling on one and the same string - together.

YMMNV

[plexuss]

This is not about the rendered file as much as down-stream distribution. If a true peak limiter is used to render the master, there will be no over-shoots in the master. But even that master needs to be converted to analogue to be heard. And there-in lies the risks that clipping can occur. A single sample clip here and there, not a problem. The more clips occur over time, the more likely they will be to be audible. Granted the standards are there to offer guidelines to prevent downstream conversion clipping, but they don't guarantee it. Nothing guarantees it given suffiently bad conversion. ISP warning algorithms can be used to warn of potential sample clipping during downstream conversion. But knowing that an ISP occurred is not enough - audio suffers when the "density" of ISPs is high, then you can hear the resulting distortion.

Yes you can rest assured there will be no clipping in your master if you use a true peak limiter. That same clip-less file may cause clipping in either a CODEC or DAC or both. The ISP metering helps predict this. ISP density will help predict when it will become audible.

Does that help? I think you are fixated on the final file. The issues with respect to ISPs are related to the playback of the file.

Regarding, tools - perhaps something like the tool you mentioned. Right now the only tool I know of that can measure something resembling ISP density is Apple's roundtripAAC which counts clips and so you can see how many warnings occur over time. However it's not measuring density (over time) - its just a counter so you have to watch it and see how quickly the counting occurs. I am talking about a tool that measure this density of ISP warnings over time.

Regarding people, Bob Katz and Ian Shephard and all those that are in the same camp of engineers that concern themselves with loudness and intricacies of the end to end technology (analogue in to analogue out).

[Compyfox]

Now we're getting somewhere - albeit we're still walking in circles.

This is not about the rendered file as much as down-stream distribution. If a true peak limiter is used to render the master, there will be no over-shoots in the master. But even that master needs to be converted to analogue to be heard. And there-in lies the risks that clipping can occur. A single sample clip here and there, not a problem. The more clips occur over time, the more likely they will be to be audible.

This is none of our concern as:
a) Broadcast stations use an additional safety protection mechanism until the signal reaches the listener
b) the signal remains < 14LUFS (ideally -16LUFS, broacasting even -23/-24LUFS), so clipping is basically a non-issue and you won't hear anything
c) we have no influence of the "Listeners" devices, and how they set them up. If clipping happens there, it's their issue - not the one by the Audio Engineer.

Granted the standards are there to offer guidelines to prevent downstream conversion clipping, but they don't guarantee it. Nothing guarantees it given suffiently bad conversion. ISP warning algorithms can be used to warn of potential sample clipping during downstream conversion. But knowing that an ISP occurred is not enough - audio suffers when the "density" of ISPs is high, then you can hear the resulting distortion.

What old DAC's are we even talking about? Late 90s?!

Come on, you're beating the dead horse on an absolute non-issue unless you clearly exceed a certain loudness - which, the more and more I read your argumentation, is what I think you're actually still trying to do.

Yes you can rest assured there will be no clipping in your master if you use a true peak limiter. That same clip-less file may cause clipping in either a CODEC or DAC or both. The ISP metering helps predict this. ISP density will help predict when it will become audible.

Clipping post file encoding can happen because you've pushed the CODEC too hard. There is a reason why you should pull down the ceiling the stronger the the average signal strength (what we call "loudness") is. Especially if we talk -8LUFS and up.

HOWEVER - and again (and again, and again, and again....), this is a non issue if
a) you use suitable LUFS values (like you should)
b) you use the appropriate CODEC settings (and not "starve" the signal on purpose)

Does that help? I think you are fixated on the final file. The issues with respect to ISPs are related to the playback of the file.

*rubs eyes*
Once more...

For broadcast streams, that's not of our concern.

For CD release, that is not our concern if you properly limited the material - at most the used DAC (enduser) is to blame and we have no influence on that

For encoded material, that is not our concern if you properly encoded the file and worked within it's known limits (see Nugen Audio MasterCheck Pro and Fraunhofer ProCodec's analysis features)

Regarding, tools - perhaps something like the tool you mentioned. Right now the only tool I know of that can measure something resembling ISP density is Apple's roundtripAAC which counts clips and so you can see how many warnings occur over time. However it's not measuring density (over time) - its just a counter so you have to watch it and see how quickly the counting occurs. I am talking about a tool that measure this density of ISP warnings over time.

Again, we don't need it! Because we already have that feature!


In case of Youlean Loudness Meter, we have that in two forms:
dBTP meter (numeric readout, which actually gives a higher readout than most other tools on the market - so I assume a differen OS/math scheme), and histogram "dBTP warning indicator" (little red dots on top of the histogram). Example:


In case of Nugen Audio MasterCheck, this does exactly what you want from Apple's roundtripAAC with the "CODEC check" (bottom half of the UI)


There is even such a feature built into Fraunhofer ProCodec for "roundtrip checks".



Which in turn is an absolute non-issue if we talk -16LUFS or lower, and proper ISP limiting. The higher you go loudness wise, the more troublesome it gets.

But as the specs clearly state:
-23LUFS/-1dBTP (EBU R-128, France insists on -24LUFS +-2LU/-2dBTP)
-24LUFS/-2dBTP (ATSC A/85)
-16LUFS/-1dBTP (most streaming services)

If you exceed the dBTP limit during/after your rendering, you're not within specs. Period!
If you checked all files 3 to 7 times and you have no warning readouts, you're within specs and done.

Once you deliver the material, it's non of your concern anymore what the distribution station does, or if the DAC that plays back this file is messed up, if the playback device is 0.001dB louder than your mastering setup.

"Analog to Analog"? Come on, we're talking DAB+ at this point - streams are transferred digitally. The only concern is the broadcast studio microphone and playback devices, which are suitable treated with compressors and then an automatic loudness normalization matrix (on site!), and on the output side the volume dial of the receiver (but the signal is still distributed within specs!). Everything else... I can only repeat myself... none of our concern!.


In summary:
We - don't - need - that - feature - !

And if Julijan is to implement it, he needs to add a crapload of extra code, simulating CODECs and various types of broken DAC's . Meaning, this turns into a whole different beast (think MasterCheck Pro or Fraunhofer ProCodec - which already exist and do exactly that!). And then people start to request more and more, and more, and more, and more, and more "alternative setups" to chase ghosts that just aren't there(!) and are simply none of our concern in the first place. Especially if you stick to the specs.

Do you not(!) see that?


You ultimately want Nugen Audio's AMB, or tc.electronic's Loudness Correct Suite, but at the price of the Youlean LM2 Pro introduction.

Regarding people, Bob Katz and Ian Shephard and all those that are in the same camp of engineers that concern themselves with loudness and intricacies of the end to end technology (analogue in to analogue out).

I'm in that camp. In fact, I'm also swimming in the deep end of the pool, and it's honestly not of any concern. Neither have I seen either of these two write anything about this... "issue".


You are chasing a ghost. Or rather, you want Youlean LM2Pro something to be, that it just can't be without massively adding code and skyrocketing the price to several hundred USD (not to mention years of extra R&D).

I know that some users in here noted their concerns with Nugen Audio MasterCheck (like "bad UI" and what have you). But honestly, this and Fraunhofer ProCodec do exactly what you're requesting, time tested. You also already use the "aacRoundTrip" tool. Granted, these tools are not cheap, or not easy to access for everyone (and quote honestly, it shouldn't be either if you 're not working in that field!).

However, if you can criticize me about "mere 27USD", I can return the criticism about being a cheapskate and asking for features that costs several hundreds and are not aimed at the users of Youlean LM2!

You have to draw a line somewhere. And I think it's deep enough at this point.



My only real FR's are:
- presets
- a dBTP meter bargraph
- maybe (bonus) a PLR bargraph (although, we have numeric values - even though no realtime PLR, and PLR is not not of super high value, so that's already plenty of info)tup

[plexuss]

Now we're getting somewhere - albeit we're still walking in circles. [snip...]

I am not going to address every one of your concerns. The fact is, inter-sample peaks causing clipping downstream with codecs and DACs is an issue that can cause audible distortion. Since all digital audio must go through a DAC to be heard, it is an issue that concerns all digital audio. All modern DACs will over-shoot under certain conditions. We have influence on what happens at the DAC which is one reason we need ISP metering. The tools you cite do not meter the extent of potential ISP issues. In order to mitigate the effects of ISPs we need a reliable way to measure the risks. There are standard methodologies for estimating this without the need to model every codec and dac. Anyway.... that's what it comes down to whether you want to concern yourself with it or not. I do. You don't. That's fine. Whatever works for you.

[Youlean]

@Youlean,

Very good job! The price for the pro version is worth it.

Best luck to you. You did a very fine job on the plugin!

Best,
Jhudstudio

Thanks Jay!

[Youlean]

Can you go a bit more in-depth on the custom presets for saving "default" state? What will this offer? Can will we be able to save multiple presets?

Did you also read what I wrote a couple of posts back regarding an INI file drop for adjusting "hardwired" presets (like Netflix, Spotify, Tinder, Youtube, Broadcast, etc) for easier updating rather than updating the whole plugin with each shift? (which might also offer manual changes for users themselves)

INI file idea is really interesting. I will think about it.

Regarding the PLR Color Codes (what you call Dynamic), I think 3 colors are more than fine. As long as we can save that setting "separate", or there is a button on the UI that says "will be recalled on preset change / preset change will ignore PLR graph settings", I'm more than okay with that.

So, you want to have separate presets for PLR and LU? That does make sense.

Maybe "inserting numeric values" for the Histogram Time Window would be nice, or numeric insertion on the config panel in general. Just to speed up things instead of dragging values.

I will think about this!

[Youlean]

Unfortunately ISP density feature will require a lot of work to be implemented. I took a look at the code. Also, it will have a hit on the CPU too.

This feature seems nice, but I will put it on low priority for now. There are much more important features needed to be done first.

[Youlean]

i feel the discussion around the price or people unwilling to pay 27$ is unfair.
ihmo, the free product is like a shareware, and an awesome one, so i wanted to pay for the pro version instantly.
it's a no brainer !

Thanks carrieres!

[plexuss]

Unfortunately ISP density feature will require a lot of work to be implemented. I took a look at the code. Also, it will have a hit on the CPU too.

This feature seems nice, but I will put it on low priority for now. There are much more important features needed to be done first.

THe user should be able to turn this metering on and off as needed so the CPU hit can be controlled. In the meantime, back to Apple rounttripAAC.

[heavymetalmixer]

I see that now the title says v2.0.2. Could you please update the OP with the changelog?

[Compyfox]

Sorry for the late response, was busy with my side project "Mix Challenge".

I am not going to address every one of your concerns. The fact is, inter-sample peaks causing clipping downstream with codecs and DACs is an issue that can cause audible distortion. Since all digital audio must go through a DAC to be heard, it is an issue that concerns all digital audio. All modern DACs will over-shoot under certain conditions.

>snip<

But again - this is none of our concern. Like seriously - none, nada, zero, zilch.
This is a problem that can(!) happen outside of our boundaries.


Look:
On the input side of things, it's a non-issue because what goes in, will be loudness adjusted with compression/auto gain/limiting/etc. Think a radio station with various stages of compression and auto gain before this even hits the broadcast rack.

So basically:
Player / Mic > Console > AGC/Loudness Adjustments > Broadcast Setup > transmitter

The specifications(!) are clearly laid out to monitor until the point of the transmitter. What happens after that on the so called "output side" - as in "receiver > DAC" is none of our business.

If a consumer complaints, the broadcast station (no matter what it will be) is in the clean since it can proof "nothing went beyond our given boundaries".


CODEC issues?
This is why we have things like Nugen Audio MasterCheck, Fraunhofer ProCodec and Apple rounttripAAC. A dedicated tool for this task. Else Youlean LM2Pro would move away from a "loudness measurement suite".



We also have to take into consideration, that as of 2018, we're looking at two(!) major Loudness Targets:

Broadcast: -24LUFS / -2dBTP (France, Asia, half of the US, the rest of Europe is still -23LUFS / -1dBTP)
Streaming (proposed goal): -16LUFS / 1dBTP (Mastered for iTunes - Spotify is on the way)

And since the specs (ITU-R BS.1770-x and especially EBU R-128 S1) insist on using a suitable "maximum signal strength limitation", aka "ISP Limiting" - and we're doing that properly (considering we use a proper ISP limiter or know their overshooting to adjust accordingly) - none of this is of any concern to us! CODECs used will therefore also barely overshot. And if they do - then pull down the dBTP ceiling to -2dBTP. At -16LUFS ILk that sill gives us a PLR of 12 to 10 (e.g. -12LUFS SLk max to -2dBTP), and the CODEC doesn't barf on us like... at all.

"Client wants it loud" (as in -8LUFS and higher) - then use a suitable limiter but you also have to pull down the dBTP ceiling, which results in less than 6 PLR. (which is counter productive to the whole Loudness Normalization and retaining transients)



Come on, are we really talking about the same, but talking around each other?
I slowly get the impression of that.

We already have(!) all means of measurement for pretty much every eventuality at our disposal. In fact, we do have them for years at this point (Elemental Audio Inspector already used ISP warnings and measurement in early 2000s - only lacked the Leq(m) aspect).

Do we really need to reinvent the wheel?




@Youlean:
Thanks for considering the Feature Requests

[plexuss]

Compy, I think the issue between you and I with respect to ISP workflow, is that you don't think we need it and I do. I use ISP mitigation workflow on every project and I find my masters sound much better. Partly it's because it keeps the audio metrics within the realm of higher quality but also because it does mitigate ISP downstream. The observable evidence on my end validates that the ISP workflow increases audio quality. So someone telling me its not necessary is just "wind". Unless I see proof to the contrary I will continue to promote it as part of a good engineers workflow.