VU Meters: What for??

[orthodox]

Going from 16 to 24 bit doesn't require re-sampling since the sample rate stays the same. It should just pad the sample with additional zeros to increase the bit rate. I've never noticed changes in levels with import - anyone care to share a test file, as I'm curious to see if I can find what is causing this.

Yes it does not require resampling. Generally, an s16 file should never clip on import when it is done that way. But Reason seems to perform resampling anyway.

Here is the test file, a 440Hz sine wave, signed 16bit PCM at 44100sps: https://yadi.sk/d/DxsoESA2uC5Zq

[Stranger.]

How would one ever know what the "correct" offset value is?

If someone is willing to illuminate me, please put it is super-layman's terms.

Ok-in most simple terms- look at big meter-it shows you the 'offset' - by default. It shows the ranges of:
VU -70db > +12db
Peak -90db > 0db there is the offset value.
So what you can do is dial in the vu offset to +12 and you will basically being looking at a slow peak meter.
The ppm mode is just a slower peak reading response/release time.
If you have tracks going into the red on vu-- you know it's going to be pretty loud,but lacking fine,fast movement peak wize.
What is also termed dynamic range,crest factor w/e.

*EDIT* i was going to edit this post,but will see if anybody is awake 1st.

[selig]

OK, thanks folks. I think I will simply not display the VU meter any more.

VU + Peak is your friend - shows not only Peak, and average (RMS not VU actually), but also Crest Factor which is the difference between Peak and RMS and is an excellent basic indication of overall loudness.

What is crest factor?

https://en.m.wikipedia.org/wiki/Crest_factor

Crest Factor is read in Reason as the difference between the peak and VU levels. A pure sine wave has a crest factor of 3.01 dB. I personally find a crest factor of around 12 dB to be a good starting place for most dense mixes. Crest factor will move around during the song, as it's not a static value, so you look for the max crest factor typically (the loudest part of your song). In Reason when mastering, your peaks will be at zero dBFS (just below clipping if your brick wall limiter is working correctly). So you can look at the VU (RMS) level to read crest factor in this case - if the VU is at -12 dBFS (and peaks are 0 dBFS) then crest factor is 12 dB.


Sent from my iPad using Tapatalk

So you would put a limiter on the master output to keep the master level at 0dB?

yes, that would be the classic use of a limiter, that is, to keep the audio signal from exceeding a set level.


Sent from my iPad using Tapatalk

[selig]

How would one ever know what the "correct" offset value is?

If someone is willing to illuminate me, please put it is super-layman's terms.

As far as I know there is no correct or standard offset value, you can use whatever you want. But know that some signals have a VU level that is over 20 dB below the peak level, so even an offset of 20 dB won't keep peaks out of the clipping zone.

For reference, some analog systems have well over 20 dB of available headroom above 0 dBVU. In practice you would set all of your VU meters to read 0 dB at the same level in your studio, starting with the console's tone generator, which would be sent out to all tape machines (multi-track and 2-track). In the digital world, the idea of an offset isn't set in stone, when some choosing 18 dB, some 20 dB, and some as low as 12 dB. Depends on your analog chain and your habits really…


Sent from my iPad using Tapatalk

[jonheal]

OK, the VU setting thing I think this is finally starting to make sense to me. When you say an offset of "12 or 18 or 20 dB." I think what I hear you saying is to rotate the knob until the 12 or 18 or 20 dB tick on the VU meter lines up with the 0 dB tick on the Peak meter. Is that correct?

(That's what I meant by put it in super-layman's terms. )

... and then as you glance at both meters, if your level is spending an inordinate amount of time loitering in the red part of the VU meter, it's pretty loud. Or if you want it loud you can keep it loitering there, but maybe put a limiter on it and set it so the peak meter doesn't clip even while the VU meter is blazing red.

Am I on the right track?

[selig]

OK, the VU setting thing I think this is finally starting to make sense to me. When you say an offset of "12 or 18 or 20 dB." I think what I hear you saying is to rotate the knob until the 12 or 18 or 20 dB tick on the VU meter lines up with the 0 dB tick on the Peak meter. Is that correct?

(That's what I meant by put it in super-layman's terms. )

... and then as you glance at both meters, if your level is spending an inordinate amount of time loitering in the red part of the VU meter, it's pretty loud. Or if you want it loud you can keep it loitering there, but maybe put a limiter on it and set it so the peak meter doesn't clip even while the VU meter is blazing red.

Am I on the right track?

Yes, that's it - rotate the knob and watch the changes. Of course you never want to clip as a general rule, so if you are increasing level and the peaks are already "kissing the Reds", you'll have to use a limiter to "protect" the signal from clipping.

VU offset is a just a visual aid - NOTHING audible changes. Whatever makes sense to you! I typically turn OFF the VU offset myself, fwiw.

I use VU + Peak mode and when mastering shoot for a crest factor (difference between peak and VU) of around 12 dB as a starting point. If there's a peak limiter on the output, peaks will be around 0 dBFS, so just look at the VU level to read crest factor (a decent indication of perceived loudness).


Sent from my iPad using Tapatalk

[8cros]

If there's a peak limiter on the output, peaks will be around 0 dBFS, so just look at the VU level to read crest factor (a decent indication of perceived loudness).


Sent from my iPad using Tapatalk

The only parameter gives an indication of perceived loudness - program loudness. As far as I know.
You can not trust me. And I think that there are few people willing to explain why the VU is not appropriate for the perceived loudness.

I wonder what way you use the VU /Crest Factor to determine the perceptual loudness? And that allows you to conclude that you have measured the perception (subjective loudness)?

Using modern technology of measurement is an advantage.
I do not want to argue or prove something.

[selig]

If there's a peak limiter on the output, peaks will be around 0 dBFS, so just look at the VU level to read crest factor (a decent indication of perceived loudness).


Sent from my iPad using Tapatalk

The only parameter gives an indication of perceived loudness - program loudness. As far as I know.
You can not trust me. And I think that there are few people willing to explain why the VU is not appropriate for the perceived loudness.

I wonder what way you use the VU /Crest Factor to determine the perceptual loudness? And that allows you to conclude that you have measured the perception (subjective loudness)?

Using modern technology of measurement is an advantage.
I do not want to argue or prove something.

Perception cannot be measured! So there is no accurate measure of loudness.




Sent from my iPad using Tapatalk

[jonheal]

Anyway, thanks for all of the help, everyone.

[jonheal]

Perception cannot be measured! So there is no accurate measure of loudness.

That said, a supernova going off next to you should be pretty loud on anyone's scale, except no air in space, so you can't hear it. I bet for about one nanosecond, though, as the charged particles shred your being, enough of them strike your eardrums to momentarily get your attention.

[Raveshaper]

While perception is subjective, clearly if a frequency's amplitude is pegging at the top of the analyzer, it's going to stand out. If it's bobbing near the bottom, it's going to sound notched. Clearly, it isn't a matter of perception, but clarification of the science. There is such a thing as quiet and also a thing known as loud. Balancing those to create the desired tone and impact of a track are what people really mean by "how loud is this, really". To achieve expected results, you can follow measurements of real data. This is why VU offset has ruined many of my songs for a long time. It measures, but does nothing.

[8cros]

Perception cannot be measured! So there is no accurate measure of loudness.




Sent from my iPad using Tapatalk

Of course we can not measure the perception. We can not prove the existence of God. But our adepts are ready to accept new members in our sect.

This measurement is extremely important in some areas. For example, in military supersonic aircraft.
Modern measurement came from a military aircraft, if I'm not mistaken.

[selig]

While perception is subjective, clearly if a frequency's amplitude is pegging at the top of the analyzer, it's going to stand out. If it's bobbing near the bottom, it's going to sound notched. Clearly, it isn't a matter of perception, but clarification of the science. There is such a thing as quiet and also a thing known as loud. Balancing those to create the desired tone and impact of a track are what people really mean by "how loud is this, really". To achieve expected results, you can follow measurements of real data. This is why VU offset has ruined many of my songs for a long time. It measures, but does nothing.

Technically speaking, VU offset measures nothing. The meters don't change when you change VU offset. My only gripe is that VU offset is on by default and the chosen color is red (which typically means BAD). So folks think they are distorting or clipping, because that's what red typically signifies in audio. If it was orange and off by default


Sent from my iPad using Tapatalk

[jonheal]

Just curious, but is the "off" position all the way to the left, so that 20 dB is the highest number of the VU meter?

[selig]

Just curious, but is the "off" position all the way to the left, so that 20 dB is the highest number of the VU meter?

I believe the off position is all the way right (not at home right now). In this position there are no "red" LEDs to distract or confuse!


Sent from my iPad using Tapatalk

[eox]

I know that selig has done about a million thread responses on this already, so you can search by author "selig" and look for "VU" to get a bajillion results. But I can give this a try in the mean time.

VU basically means the average loudness of a given sound. So when you open the spectrum analyzer, the VU meter is showing you an average of all those peaks and valleys from left to right.

Also, the offset determines how much overhead you want to have. So if your export needs to have 3-6 dB of headroom for mastering, you would calibrate the offset on the Big Knob inside the Hardware Interface in the rack to read "-6" or "-3" at the top of the meter.

The confusion over seeing red on the channels in the SSL are a result of thinking that anything red means clipping. This is not the case.
The only place where red truly indicates clipping is on the master bus. Channels in the mixer view that show red indicate peaks that could push the output of the master bus up into the desired headroom, causing potential clipping or distortion problems during mastering.

So in summary:
VU = average of frequencies you see in the analyzer.
Offset = headroom of mix for mastering.
Red in Channel(s) = sound might push final mix into headroom.
Red in Master Bus = mix is clipping.

If I'm wrong on any of this, I'm sure I'll be corrected.

In the 10 years I've been using Reason I never once thought about the offset for this. In fact, I never even thought about the offset. This is gold as I've become quite OCD about peaks! Definitely going to start utilizing this method for head room!!

[selig]

I know that selig has done about a million thread responses on this already, so you can search by author "selig" and look for "VU" to get a bajillion results. But I can give this a try in the mean time.

VU basically means the average loudness of a given sound. So when you open the spectrum analyzer, the VU meter is showing you an average of all those peaks and valleys from left to right.

Also, the offset determines how much overhead you want to have. So if your export needs to have 3-6 dB of headroom for mastering, you would calibrate the offset on the Big Knob inside the Hardware Interface in the rack to read "-6" or "-3" at the top of the meter.

The confusion over seeing red on the channels in the SSL are a result of thinking that anything red means clipping. This is not the case.
The only place where red truly indicates clipping is on the master bus. Channels in the mixer view that show red indicate peaks that could push the output of the master bus up into the desired headroom, causing potential clipping or distortion problems during mastering.

So in summary:
VU = average of frequencies you see in the analyzer.
Offset = headroom of mix for mastering.
Red in Channel(s) = sound might push final mix into headroom.
Red in Master Bus = mix is clipping.

If I'm wrong on any of this, I'm sure I'll be corrected.

In the 10 years I've been using Reason I never once thought about the offset for this. In fact, I never even thought about the offset. This is gold as I've become quite OCD about peaks! Definitely going to start utilizing this method for head room!!

To clarify a few things - I'm not sure the Spectrum is VU or Peak - the response is a bit sluggish making it difficult to differentiate - but if I had to guess I'd say peak with slow release (some sort of PPM maybe?).

But for SURE, it's the channel meters that ALWAYS show VU (RMS actually…) and NOT peak response. The other meters can be changed…
The only place you can clip is the final OUTPUT - they may not in some cases be the Master Bus because you can patch a device after the Master Section that could cause (or prevent) clipping.

Seeing "red" in the channels is less meaningful since it's not showing peak levels. VU/RMS can be 20 dB or more lower than peak levels in some cases, meaning that once it's "red" in the channel/VU meters it may be peaking MUCH higher.

"Red" in master bus doesn't mean clipping - there are specific "clip" lights that are the ONLY place you will see clipping. If you have VU offset in effect you can still see "red" in the master meters or big meter and NOT be clipping.

I know all of this can be confusing - bottom line: use the Clip Indicators in the Big Meter to know if you are clipping. Seeing "red" ANYWHERE else may or may not mean "clipping", so either ignore it, use it for helping keep headroom as mentioned by Raveshaper, or just turn VU Offset totally OFF so you don't get distracted!

This is an important and potentially confusing subject, so if there's anything I've left out, or anything that I've made less clear (I've been known to do that by giving too much information), PLEASE let me know!

[WongoTheSane]

But for SURE, it's the channel meters that ALWAYS show VU (RMS actually…) and NOT peak response.

Isn't that a weird choice? I would have thought that it's less informative than Peak, on one hand, and costlier CPU-wise, as VU requires calculating an average (even with an optimized routine it still costs a few cycles). Is there any reason they would implement VU instead of Peak, like mimicking the real-world hardware when needles couldn't move fast enough?

[selig]

But for SURE, it's the channel meters that ALWAYS show VU (RMS actually…) and NOT peak response.

Isn't that a weird choice? I would have thought that it's less informative than Peak, on one hand, and costlier CPU-wise, as VU requires calculating an average (even with an optimized routine it still costs a few cycles). Is there any reason they would implement VU instead of Peak, like mimicking the real-world hardware when needles couldn't move fast enough?

The real SSL had an option for needle style VU meters or LED ladder (plasma really) peak meters. The Props took some liberties here…
They either need to have the channel meters follow the main meter modes (can't imagine why they don't already behave that way), or have them set to peak like the input meters for audio tracks in the sequencer.
Also, change the "red" on VU offset to "orange", and default that feature to OFF please - it has caused SO much confusion since it was introduced in Record…you'd think they would have figured that out by now!

[orthodox]

Isn't that a weird choice? I would have thought that it's less informative than Peak, on one hand, and costlier CPU-wise, as VU requires calculating an average (even with an optimized routine it still costs a few cycles). Is there any reason they would implement VU instead of Peak, like mimicking the real-world hardware when needles couldn't move fast enough?

It is not costlier actually. Peak mode requires tracking the current maximum and comparing to it. Moving average requires one multiplication and one addition. It is even faster.
And just like real-world hardware, digital "needles" can't move fast enough, too. In order to be readable by human eye, the refresh rate should be no more than 10-20fps, while the signal is changing much faster.

[selig]

Isn't that a weird choice? I would have thought that it's less informative than Peak, on one hand, and costlier CPU-wise, as VU requires calculating an average (even with an optimized routine it still costs a few cycles). Is there any reason they would implement VU instead of Peak, like mimicking the real-world hardware when needles couldn't move fast enough?

It is not costlier actually. Peak mode requires tracking the current maximum and comparing to it. Moving average requires one multiplication and one addition. It is even faster.
And just like real-world hardware, digital "needles" can't move fast enough, too. In order to be readable by human eye, the refresh rate should be no more than 10-20fps, while the signal is changing much faster.

Peak mode typically simply reads the highest sample value per "batch" and shows that at the 20fps (or slower) frame rate - so it doesn't miss anything (even though it's only refreshed every few samples or more) and doesn't require any "math" except for a sample/hold.

VU would start with the peak value and apply the time constants (roughly 300 ms attack/release time), so it would require very slightly more "math" than peak, right? But it's hardly a "cost", at least it's not one that would ever be noticed given the previous issues. That's my understanding, anyway.

[WongoTheSane]

Moving average requires one multiplication and one addition.

How do you do that in only two steps?? I can't come up with anything that concise, I'm at 5 instructions right now (move pointer, remove value at pointer from sum of last X samples, place new value at pointer, add it to sum, divide sum by length of buffer)... What's the trick?

[orthodox]

Moving average requires one multiplication and one addition.

How do you do that in only two steps?? I can't come up with anything that concise, I'm at 5 instructions right now (move pointer, remove value at pointer from sum of last X samples, place new value at pointer, add it to sum, divide sum by length of buffer)... What's the trick?

The trick is that nobody cares to faithfully implement the window for arithmetic mean . Most often, the exponential moving average is used, which is much faster and simpler.
https://en.wikipedia.org/wiki/Exponential_smoothing

[selig]

Moving average requires one multiplication and one addition.

How do you do that in only two steps?? I can't come up with anything that concise, I'm at 5 instructions right now (move pointer, remove value at pointer from sum of last X samples, place new value at pointer, add it to sum, divide sum by length of buffer)... What's the trick?

The trick is that nobody cares to faithfully implement the window for arithmetic mean . Most often, the exponential moving average is used, which is much faster and simpler.
https://en.wikipedia.org/wiki/Exponential_smoothing

Interesting - sources? I'm aware of soothing being used for "de-zippering" controls (REs do this, as does Reaktor for example). But for attack/release such as with a VU meter? In Reaktor, an envelope follower is used, which is the same thing used when building a compressor or gate etc. But that's not the same thing as using a filter for smoothing, or is that what you were saying?

[WongoTheSane]

Moving average requires one multiplication and one addition.

How do you do that in only two steps?? I can't come up with anything that concise, I'm at 5 instructions right now (move pointer, remove value at pointer from sum of last X samples, place new value at pointer, add it to sum, divide sum by length of buffer)... What's the trick?

The trick is that nobody cares to faithfully implement the window for arithmetic mean . Most often, the exponential moving average is used, which is much faster and simpler.
https://en.wikipedia.org/wiki/Exponential_smoothing

Well I learned something today. Very interesting, I never would have expected this to give good results, as opposed to a "simple" moving average. Thanks for the info!