TBProAudio releases AB_LM - Loudness Match and Gain Staging Plugin for Windows and Mac OS X

[Compyfox]

who cares?

As AE, I care.

it matters only for his free meter.. people will use a proper meter in conjunction with this..

No, it does not as ALL of his tools use summed RMS analysis.
And this tool offers RMS and EBU R-128 "type" measurements

this is for the master bus or a track here or there to compare volume matched effect processing. You are going way OTT.

No I'm not. People will abuse it for other purposes, including per-channel gain staging. Even if it's not directly advertised as that... but it's what it's capable off.

yet on his free plugin, lesha showed above that one of the settings matches the other, correct plugins. So what' the problem?

The problem is, that it's off.

The prblem is that you ignore that it's off, since you don't care - and sometimes I know that you go above and beyond "fixes" as well. Metering is an important topic to me, metering has to be(!) accurate. And this developer in question insists that his tools are according to specs. Yet some of them are not.

Am I talking to a wall here?
Are my posts hard to understand?



Look - I get where you come from, I get where the developer comes from. But I'm doing this for several years at this point. If there is a tool on the market, people will not use it as advertised but break it's boundaries. And if we insist(!) in proper metering or signal analysis in order to process further, then stuff needs to work like it should. Else XYZ user comes along, tells the blue from the sky that others believe and then it turns info "facts and standards".

Prime example is EBU R-128. This spec is first and foremost a preset of ITU-R BS.1770-x (I can't stress that enough), second... it's a recommendation, not a standard. It's also mostly used for BROADCASTING and so unfit for music, it's not even funny (I wrote a crapload of articles about this on KVR, remember?!). Yet it's handled as "the ultimate end for all metering issues". The education is lacking in this section, and hear say is being ported as "you only have to use this/that - nothing else". It's "teh sh*t", it's "better than sliced bread". Open magazine XYZ and you only read "EBU R-128, EBU R-128, yadda yadda". Yet people don't even know how to properly use a PPM and VU!

Want another metering related example? The Reaper boards - people INSIST there that the K-System meter is the only true meter to use... during mixing. Well yes, if you're used to the Dorrough 40A Meter (which a K-System meter basically is, with an offset 0 reference but still). Then this is correct. But who even knows this?! Did you?!

Another great example (a bit further OT), is "mixing in surround" - it's still "all the rage", "the future of music consumption". but Surround mixes are just a fraction of the music we consume daily. The market is still not ready for this, and headphone solutions are only slowly on the rise (actually - for 5 years at this point, and only Waves recently jumped on the bandwagon... but I digress).



So there you have it.
YMMV and all that jazz (with jazz hands!)

You know what Metering (as a topic) means to me, and you know how pedantic I am in this case. Just like you are with other plugins.

[ObsoleteAcc99]

No I'm nothing like that. That's the worst argument I've ever read on kvr I reckon. That because a tool is capable of a certain type of abuse even though it's not directly advertised for that use, somehow bothers you. That means by that reasoning, that you should be bothered by every single plugin in existence, especially reverbs, eqs and compressors.. Cause even though they are not advertised as such, they are all capable with one instance on one track somewhere in the project, of completely ruining the entire mix.

This Plugin is a gain audition matching tool and is marketed clearly as such. Why aren't you abusing perception? You have one point here and only one, that the rms reading could be fixed. Sure, fine. There's nothing else wrong with this wonderful plugin that is a lifesaver and completely prevents placebo mastering and track placebo eq/compression.

As far as remembering and reading your other posts you mention, no I never read your rants actually. Not about steinberg and not about metering standards. I have insight and TC radar which I know both are correct, so when and if I ever do commercial work again and need to really worry about this stuff, I have the tools to learn about it.

In the meantime, for my own music, I can now accurately judge the final product better than I ever could before thanks to TB.

I'm sure sos will give this a raving review soon. Almost feels like you have a stake in perception so bagging the single only competition.

Now once again with the free meter, lesha has shown there is an rms mode in that that matches the other correct ones, so what's the problem?

[ObsoleteAcc99]

It is still not according to specs however! (again: the summing of the L and R signal)
And I do insist on that matter

No one said that TBProAudio RMS calculation (summed or not) is according to any specification! Not me! Please be precise, thank you.

Well it probably should be though, no?

[Lesha]

Now once again with the free meter, lesha has shown there is an rms mode in that that matches the other correct ones, so what's the problem?

No, it doesn't, it's still 3 dB off.

[TB-ProAudio]

Well it probably should be though, no?
 

We took the simplest and widest spread definition (+ variable integration time for RMS M):
e.g. http://connect.euphonix.com/documents/S ... tering.pdf
On top we added channel summing.

dpMeter/AB_LM meter RMS readouts are fully comparable with other metering tools e.g. SPAN from Voxengo

So:
mono channel, sinus -12dBFS peak:
SPAN: peak (CH1) = -12dBFS, RMS (CH1) = -15.1dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -15.1dBFS (CH1+CH2, aka summed RMS)

stereo channel, sinus -12dBFS peak:
SPAN: peak (CH1,CH2) = -12dBFS, RMS (CH1, CH2) = -15.1dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -12.0dBFS (CH1+CH2, aka summed RMS)

mono channel, white noise -12dBFS peak:
SPAN: peak (CH1) = -12dBFS, RMS (CH1) = -16.8dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -16.8dBFS (CH1+CH2, aka summed RMS)

stereo channel, white noise -12dBFS peak:
SPAN: peak (CH1,CH2) = -12dBFS, RMS (CH1, CH2) = -16.8dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -13.8dBFS (CH1+CH2, aka summed RMS)

[Compyfox]

*sigh* All right, listen Theo... There seems to be a big(!) communication problem going on, and you bark up my tree unnecessarily. We both know how this usually goes in such threads from then on out. So I'll keep it short.

This Plugin is a gain audition matching tool and is marketed clearly as such.

Yes, it is. But it can be used for more than that. Even even then, the RMS algo is offset by +3dB (even SoS will comment on that, if they do a review and pay attention to detail).

I'm not "abusing" Perception by Ian Shepherd or rather his commissions (coded by MeterPlugs) as I don't have it. Neither do I have any stake in the software company - or any company for that matter. My collaboration with Jeroen Breebaart (EBU Loudness) was also not "finance/sale" based, neither are my beta testing deals. That stab was just low, Theo.

As far as remembering and reading your other posts you mention, no I never read your rants actually. Not about steinberg and not about metering standards. I have insight and TC radar which I know both are correct, so when and if I ever do commercial work again and need to really worry about this stuff, I have the tools to learn about it.

You should maybe read my posts on metering tools once in a while, my KVRMarks are a good starting point.

Now once again with the free meter, lesha has shown there is an rms mode in that that matches the other correct ones, so what's the problem?

It does not match - it's offset by +3dB due to the summing of the signal (made the dev aware of that weeks ago already via mail). And the algo is used for the RMS mode in all TBProAudio plugins.

Well it probably should be though, no?

We took the simplest and widest spread definition (+ variable integration time for RMS M):
e.g. http://connect.euphonix.com/documents/S ... tering.pdf
On top we added channel summing.

Nice old article from 2002, and a good starting point to dig further. But the problem is indeed the "added channel summing", which is not(!) part of the RMS specs (once more, AES-17 rev 2015, even the more freely available r2004 is a start).

Don't take this question wrong - but do you have(!) experience with metering tools? Or did you just code it because it's possible? Because I had a lot of discussions with devs recently that admitted after long mail contacts, that they're "not skilled in that section" and just coded it to add this to their roster. This is where problems arise IMO.

I can switch to German if you like, to get further into detail once more. But I think I made my point clear a couple of times at this point, I can't describe it any better.

dpMeter/AB_LM meter RMS readouts are fully comparable with other metering tools e.g. SPAN from Voxengo

So:
mono channel, sinus -12dBFS peak:
SPAN: peak (CH1) = -12dBFS, RMS (CH1) = -15.1dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -15.1dBFS (CH1+CH2, aka summed RMS)

stereo channel, sinus -12dBFS peak:
SPAN: peak (CH1,CH2) = -12dBFS, RMS (CH1, CH2) = -15.1dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -12.0dBFS (CH1+CH2, aka summed RMS)

Okay, RMS I (or integrated) can and should be ignored, since this does not exist (RMS I is "RMS measurement over time", and I do assume that RMS M was ment to be called "RMS momentary" - this is the very reason why I insist on proper tagging of values, everything else is just confusing). And if it's using the same algo as the R-128 (ITU-R BS.1770-x) one, then it's also gated, uses a weighting filter, etc. So... let us ignore that.


If we talk "pure" RMS signal, then -12dBFS peak should result in -15dBFS peak if we do not(!) talk about the AES-17 compensation (in place since mid/late 90ies), which is +3dB. So -12dBFS = -12dBFS on the meter (AES-17 compensation active).

Your documentation implies that you used SPAN with the RMS+0 mode, and dpMeter with RMS+0 mode. Since dpMeter uses summing of the signal, the readout is +3dB higher than with other meters. Which actually is (or should be) the "RMS+3" mode (AES-17 compensation).

So your meter is wrong tagged, and/or you can simply remove one additional "mode" (your +3 mode, since +0 is already +3dB "compensated" or offset due to the summing).

This is all I've been addressing for a couple of pages at this point.

mono channel, white noise -12dBFS peak:
SPAN: peak (CH1) = -12dBFS, RMS (CH1) = -16.8dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -16.8dBFS (CH1+CH2, aka summed RMS)

stereo channel, white noise -12dBFS peak:
SPAN: peak (CH1,CH2) = -12dBFS, RMS (CH1, CH2) = -16.8dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -13.8dBFS (CH1+CH2, aka summed RMS)

Without the mentioned RMS modes (compensation on/off), I can't make anything out of it. Furthermore, White Noise isn't ideal to test metering tools. At least IMO (YMMV of course).

Also, shouldn't a mono white noise also read -13.8dBFS on dpMeter due to the summing?
Did you just confirm a bug yourself?



So yeah... can't comment on it further.
We're walking in circles otherwise.

[ObsoleteAcc99]

Well it probably should be though, no?
 

We took the simplest and widest spread definition (+ variable integration time for RMS M):
e.g. http://connect.euphonix.com/documents/S ... tering.pdf
On top we added channel summing.

dpMeter/AB_LM meter RMS readouts are fully comparable with other metering tools e.g. SPAN from Voxengo

So:
mono channel, sinus -12dBFS peak:
SPAN: peak (CH1) = -12dBFS, RMS (CH1) = -15.1dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -15.1dBFS (CH1+CH2, aka summed RMS)

stereo channel, sinus -12dBFS peak:
SPAN: peak (CH1,CH2) = -12dBFS, RMS (CH1, CH2) = -15.1dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -12.0dBFS (CH1+CH2, aka summed RMS)

mono channel, white noise -12dBFS peak:
SPAN: peak (CH1) = -12dBFS, RMS (CH1) = -16.8dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -16.8dBFS (CH1+CH2, aka summed RMS)

stereo channel, white noise -12dBFS peak:
SPAN: peak (CH1,CH2) = -12dBFS, RMS (CH1, CH2) = -16.8dBFS
dpMeter: peak (all channels) = -12dBFS, RMS I = -13.8dBFS (CH1+CH2, aka summed RMS)

Right but if it's 3db higher than all the others (and indeed after reading Ian shepherds article , yours would be showing too high), then why not just do it so it's the same and what the me's like Ian consider correct?

[ObsoleteAcc99]

Roland, my basic issue here is your issue with the plugin being more than what it's sold as. I was trying to tell you that that can be said of any plugin almost. Why would someone start to use ab_lm to gain stage their project suddenly undead of vumt/satson/vcc and the like? I use satson with console off to gain stage using the -18 dbfs method. I'm not going to start using ab_lm to gain stage my mix and in fact I wouldn't have even dreamt of trying it as such until your post. I'm simply using it to find out 1) the latency of plugins that don't report their pdc correctly and 2) monitor my fx chains at the same volume once the fx are applied, as the dry sound going in pre fx. ie the plugins main entire purpose and why TB made it!

Going on about plugins making you feel like your toenails are being ripped out is why I got defensive. The TB guy is a GREAT guy and if you had talked to him politely then he would have listened. I believe most of this post's drama is because you were so OTT and "low blow" as you say, to him first. I never meant to insult you or use any low blows Roland, you are a true friend here, but we can't agree on everything, and the only thing that has made me want to rip my toenails out in this otherwise excellent topic, was your posting. I'd love every dev in the universe to do plugins the exact way that suit me too, but it will never happen. With every single plugin and piece of hardware I currently own, there is something not quite right that I'd change about it. Including TB ab_lm.

You could name any one of my hundreds of products, and I'd instantly be able to tell you what needs "fixing" according to my specifications. But since in 99% of cases that will never happen, I use them for their good parts and use alternatives where possible to fill in the gaps.

ab_lm - I wish it would report the measured latency to the daw as a dynamic option. But it doesn't so I'll have to use voxengo latency delay for that

Softube FET- I wish the look ahead mode reported the latency to the daw. But it doesn't so I have to use ab_lm to find out the latency and then manually compensate for it

Aconeq- I wish it had a spectrum grab mode and a dynamic mode. But it doesn't so I use Sonalksis dq1 for dynamic eq.

Sonalksis dq1- I wish it had a solo mode so I could audition just the frequency range I'm honing in on like mcdsp active eq.

Ozone 7- I wish the dynamics had not removed the much needed expander section

Nexus- I wish it had articulation keyswitching and legato scripting

Tone2 synths - I wish they didn't install into folders that no other plugins do, making my OS organization look messy and making my plugin management sets a more difficult task

Waves Metaflanger - I wish it was able to have much slower LFO sync times.

Just some examples of my FAVORITE products and how each and every one of them is not 100% ideal, but that's life! I try look at all the good they do for my workflow instead.

I've wanted something inexpensive to automatch the audible volume of my before and after fx chains for years now. I thought perception was way too much money, now TB answered this for me.

[TB-ProAudio]

Right but if it's 3db higher than all the others (and indeed after reading Ian shepherds article , yours would be showing too high), then why not just do it so it's the same and what the me's like Ian consider correct?

Yes, i think i got it.

[Compyfox]

Going on about plugins making you feel like your toenails are being ripped out is why I got defensive. The TB guy is a GREAT guy and if you had talked to him politely then he would have listened. I believe most of this post's drama is because you were so OTT and "low blow" as you say, to him first.

I think you overread that I did(!) get in touch with him months ago and asked if the "flaw" (summed signal) is still a "feature". And he confirmed it in this case as well.

I've wanted something inexpensive to automatch the audible volume of my before and after fx chains for years now. I thought perception was way too much money, now TB answered this for me.

The answer is there, but one algo is wrong. This is all that has been pointed out.

And as pointed out several times as well, people might not use the plugin as advertised - which in turns spirals out into an own can of worms. Once more, didn't point out anything else.

Right but if it's 3db higher than all the others (and indeed after reading Ian shepherds article , yours would be showing too high), then why not just do it so it's the same and what the me's like Ian consider correct?

Yes, i think i got it.

The EBU R-128 "specs" were pretty fine on my end. But the RMS specs are off.
Shepherd's tools focus on the EBU R-128 or rather ITU-R BS.1770-x specs as well.

Once again - if desired, I can try to explain in German if it's still not understandable

[ObsoleteAcc99]

Going on about plugins making you feel like your toenails are being ripped out is why I got defensive. The TB guy is a GREAT guy and if you had talked to him politely then he would have listened. I believe most of this post's drama is because you were so OTT and "low blow" as you say, to him first.

I think you overread that I did(!) get in touch with him months ago and asked if the "flaw" (summed signal) is still a "feature". And he confirmed it in this case as well.

I've wanted something inexpensive to automatch the audible volume of my before and after fx chains for years now. I thought perception was way too much money, now TB answered this for me.

The answer is there, but one algo is wrong. This is all that has been pointed out.

And as pointed out several times as well, people might not use the plugin as advertised - which in turns spirals out into an own can of worms. Once more, didn't point out anything else.

Right but if it's 3db higher than all the others (and indeed after reading Ian shepherds article , yours would be showing too high), then why not just do it so it's the same and what the me's like Ian consider correct?

Yes, i think i got it.

The EBU R-128 "specs" were pretty fine on my end. But the RMS specs are off.
Shepherd's tools focus on the EBU R-128 or rather ITU-R BS.1770-x specs as well.

Once again - if desired, I can try to explain in German if it's still not understandable

Ok this will never end as you just don't get it. I GET your points and i agree the RMS therefore is not correct. But you can't seem to grasp that ANY plugin can be abused and not used at advertised, then this is just going to go in circles forever. You are obsessed and stuck on the fact that someone might use this plugin for something else other than it's main intended purpose. You're *fixated*. it's driving me crazy, and for as many "several times you have pointed it out" as you say, i have pointed out that ANY plugin can be abused, just as many times and you haven't answered that point a single time. There is something wrong here and I am not going to partake anymore as this is fruitless energy wasting. i'll put you on mute so I can continue to enjoy TB's product topics, and when the talk dies down i will unmute you then, as i no longer want to deal with this.
Peace.

PS it took one polite post from me, for the dev to consider fixing this(and i bet you he will now).. One. Perhaps that answers everything for you and the way you 'ask' for things.

[Lesha]

I think I was polite also?

[Compyfox]

You're *fixated*.

I'm not further commenting on this, Theo. As everything further I could say about "your" behavior will not only be massive OT, but would result in worse things. This is something for the PM realm (if ever).

it's driving me crazy, and for as many "several times you have pointed it out" as you say, i have pointed out that ANY plugin can be abused, just as many times and you haven't answered that point a single time. There is something wrong here and I am not going to partake anymore as this is fruitless energy wasting. i'll put you on mute so I can continue to enjoy TB's product topics, and when the talk dies down i will unmute you then, as i no longer want to deal with this.
Peace.

Think about your "reputation" with in ever thread you bark up a developer's tree maybe, and how many questions you don't answer, or answer then change your mind nearly instantly? But I'm the bad person now, as usual.

PS it took one polite post from me, for the dev to consider fixing this(and i bet you he will now).. One. Perhaps that answers everything for you and the way you 'ask' for things.

Riiiiight... just... pat yourself on the back, Theo. You're such a wonderful person. And the developer only thinks about fixing this because of "you". Not because of a metering specialized audio engineer pointing out to him that "something is off/wrong" months ago via mail already, and then merely asking if that is still the case (with further concerns, which in turn instantly went down the wrong pipe for a more than overprotective user).


Grade A hero material right there.

I think I was polite also?

Yes, you were. Yet apparently I was not.




To the developer (in German):

Ich denke wir haben ziemlich klar gemacht, was mit dem RMS Algorhythmus (nachweislich) nicht in Ordnung ist, und wie man es am einfachsten beheben kann. Falls es weitere Fragen zur Thematik geben sollte, mein PM Postfach ist offen, und meine Mail Addresse ist bekannt. Auch habe ich jahrelange Erfahrung im Beta Testing Bereich falls anderweitig Hilfe gewünscht ist.

Ansonsten bewege ich mich im Kreis in der aktuellen Debatte. Das Tool bzw. die Tools an sich sind gut, haben Potential. Aber der Teufel steckt wie immer im Detail. Nach einer Nachbesserung sollte das allerdings kein Thema mehr darstellen. Sofern das denn gewünscht ist.

[ObsoleteAcc99]

I think I was polite also?

Yes sorry I didn't mean to imply otherwise.

[TB-ProAudio]

I think I was polite also?

Yes, no doubt, thank you. And your report led me finally to the point.