Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[justsomeguy]

I know DR and R128 aren't perfect representations of how good a track will sound and that they calculate their values differently. However would it make any meaningful sense to combine the two to get a better idea of what tracks will have a good range?  I see tracks that will have a DR that is something like 13 but the R128 will be low like 4.5 or flipped with low DR but high R128. I was trying to do something very basic like create a smartlist with a custom rule with something like this so that the addition of the two values is above a certain level...
[Dynamic Range (R128)]+[Dynamic Range (DR)]>15

[mojave]

Instead of adding them, create a Playlist where R128 and DR are both greater than 10.

[justsomeguy]

Actually I have already done that but then that eliminates tracks that have one value high and another low, such as a DR of 13 and an R128 of 5. This track wouldn't be included even though it may be a fairly dynamic track contrary to the low R128 value.

[ferday]

It's far more complicated than simple math, and ends up being subjective anyways.

In general you have short term, medium term, and long term dynamics (Fun reading: http://audiamorous.blogspot.ca/2008/01/pfpf-experimental-estimator-of-dynamic_13.html )

Hydrogenaud.io has a lot of discussions on this topic as well (search for sparkle meter; it's cool)

Because R128 and TT-DR are the standards, that's what MC has built in.  I wouldn't want them to arbitrarily use something else either, but if you come up with some math that makes nice playlists post them here, I know I'd find it interesting!

[pschelbert]

Hi

in the thread "MC21 feature request" I have suggested just to add to the R128 this feature.

First, I am not sure if the MC built in algorithm is calculating R128 long term (3seconds) or medium term (m, 400ms).
Probably its 3 seconds, can anyone comment on it?

Second: as the algorithm is alread implemented, its just to shorten the RMS-time window (in the algorithm) to 400ms (defined as medium RMS-windows) and to 10..50ms for short.

Third: to get what is in the pfpf, just shortening the time window to say 10, 25, 50ms where the time window could be set by an initial setting, using the same algorithm would be the easisets way. However an additional variable R128(short) must be introduced. May be two aditional variables R128 (m, 400ms).

Best would be to have R128(3sec), R128(400ms), R128(10...50ms): the tiem defined by a setting by the customer.


Peter

[Vocalpoint]

Because R128 and TT-DR are the standards, that's what MC has built in. 

I would like MC to consider allowing us to utilize the same LUFS structures as Apple MFIT (iTunes Radio) and Spotify - where both seem to be using an -16LUFS value as their standard normalization zone.

Whilst I agree that R128 is a standard - it's primary design is for broadcast - not for casual listening in a private home or on personal devices. I am finding R128 (with it's standards being a -23LUFS range) can really drive the volume down to a level than is less than enjoyable.

It would be nice to be able to have a variable adjust with Volume Levelling - to dial in a desired LUFS ceiling and then let Analyze Audio do it's thing.

VP

[mojave]

I am finding R128 (with it's standards being a -23LUFS range) can really drive the volume down to a level than is less than enjoyable.

It would be nice to be able to have a variable adjust with Volume Levelling - to dial in a desired LUFS ceiling and then let Analyze Audio do it's thing.

That is what Adaptive Volume > Peak Level Normalize does when used in conjunction with Volume Leveling. It is a dynamic variable adjustment to Volume Leveling that only turns down the volume the minimum amount for all tracks in a playlist to play at the same volume level. When used with single items, like movies, it will make sure that the movie can play as loud as possible without clipping if the user desires to turn up the volume.

Saying "drive the volume down to a level than is less than enjoyable" doesn't mean much to me. Are you saying that with Internal Volume at 100% and Volume leveling that you can't play loud enough? Otherwise Internal Volume plus Volume Leveling equals a variable adjust to Volume Leveling - which is what you are asking for.

[Vocalpoint]

That is what Adaptive Volume > Peak Level Normalize does when used in conjunction with Volume Leveling. It is a dynamic variable adjustment to Volume Leveling that only turns down the volume the minimum amount for all tracks in a playlist to play at the same volume level. When used with single items, like movies, it will make sure that the movie can play as loud as possible without clipping if the user desires to turn up the volume.

I do not use Adaptive Volume and I am not looking for "loud as possible". Adaptive Volume only matters when MC is being used. What I am looking for is the ability to Analyze Audio per normal - but calculate (and store it's values) with -16LUFS as the baseline vs -23LUFS.

Saying "drive the volume down to a level than is less than enjoyable" doesn't mean much to me. Are you saying that with Internal Volume at 100% and Volume leveling that you can't play loud enough?

Example - if I go to burn 80 mins worth of stuff to CD in MC for the road and I engage DSP (Volume leveling) - I end up with a CD that is so low in volume that I need to crank the volume control in the car wayyyyyy up to hear it properly. Then when I pop the CD out and radio comes back on - I get my head blown off.

I have had to resort to taking my 17 tracks over the Presonus Studio One and set up each track to playback with a max LUFS of around -15 or -16 and then burn that mix to CD. I end up with a disc that is perfectly balanced and sits well with the overall volume of the FM channels around here so my head does not come off.

Are you saying that Adaptive Volume may help? Keeping in mind that - if Adaptive Volume attempts to "max" out my mix by cranking everything up - I do not want that either.

Since I see no way to control the baseline "level" (LUFS or otherwise) in Adaptive Volume  - I do not see this as being what I want.

VP

[mojave]

Adaptive Volume > Peak Level Normalize with Volume Leveling will almost always result in some attenuation for a playlist. You can see what happens for several playlists by looking at Audio Path.

You can always just add Parametric Equalizer > Adjust the Volume and set gain to +7 dB for all of your channels. This will change the baseline from -23LUFS to -16LUFS. No need to use Presonus Studio One.  This sounds more like what you want to do.

In summary:
1.  Volume Leveling will always cause attenuation
2.  Adaptive Volume > Peak Level Normalization with Volume Leveling will reduce the attenuation to the amount needed by the loudest song in the playlist instead of targeting -23LUFS. I just tested a few playlists and it ended up targeting -17LUFS to -18.2LUFS.
3.  You can manually add volume back in by using Parametric Equalizer > Adjust the Volume. All volume is done at the final output so it is just math until then anyway. Whatever amount of gain you add changes the baseline.

[Vocalpoint]

You can always just add Parametric Equalizer > Adjust the Volume and set gain to +7 dB for all of your channels. This will change the baseline from -23LUFS to -16LUFS. No need to use Presonus Studio One.  This sounds more like what you want to do.

Coolio. But I do have much more control mixing it myself and knowing that every track is in the pocket. Plus - MC simply cannot create the crossfades that I like - when I need them to occur - Usually with a harder track into soft etc.

In summary:
1.  Volume Leveling will always cause attenuation
2.  Adaptive Volume > Peak Level Normalization with Volume Leveling will reduce the attenuation to the amount needed by the loudest song in the playlist instead of targeting -23LUFS. I just tested a few playlists and it ended up targeting -17LUFS to -18.2LUFS.
3.  You can manually add volume back in by using Parametric Equalizer > Adjust the Volume. All volume is done at the final output so it is just math until then anyway. Whatever amount of gain you add changes the baseline.

Understood. But it seems like adding more and more DSP to the mix is the answer - where I would prefer just leaving Volume Leveling inline - but having an option to set the "leveling" target as -16LUFS (instead of -23LUFS per R128) for use library wide with Analyze Audio.

That said - I have a pretty decent workflow here doing my mixes manually - and having the control I prefer. Will continue along with that for now.

VP

[mojave]

Understood. But it seems like adding more and more DSP to the mix is the answer - where I would prefer just leaving Volume Leveling inline - but having an option to set the "leveling" target as -16LUFS (instead of -23LUFS per R128) for use library wide with Analyze Audio.

That said - I have a pretty decent workflow here doing my mixes manually - and having the control I prefer. Will continue along with that for now.

VP

The difference between -23LUFS and -16LUFS is +7dB. Setting the target in Volume Leveling vs in Parametric Equalizer saves Matt and the other programmers from programming more menu items that people don't understand. You adding 7dB in Parametric Equalizer will run the exact same code as if you could change the target in Volume Leveling.

Also, there is no more DSP being added to the mix. Volume is cumulative regardless of which DSP module it is located in (Volume Leveling, Adaptive Volume, Parametric Equalizer, Room Correction, or Internal Volume). If Volume leveling does -14 dB, either Parametric Equalizer or "Leveling Target" do +7 dB (now targeting -16LUFS) then you now end up with a final volume adjustment by JRiver of -7 dB. Think of it as math first and DSP second. The various DSP modules are really just math modules that end up becoming a single DSP change (in the case of volume). The actual DSP only sees -7 dB and acts accordingly.

Matt even explains this in the wiki and shows the code how he did it. Key part bolded:

To demonstrate the incredible precision of 64bit audio, imagine applying 100 million random volume changes (huge changes from -100 to 100 dB), and then applying those same 100 million volume changes again in the opposite direction.

Amazingly, you will have the exact same signal at 32bit after 200 million huge volume changes as when you started.

In other words, this incredible number of changes results in a bit-perfect output at 32bit, which is the highest hardware output bitdepth (most high-end hardware is 24bit).

This also means one volume change or a series of 100 million volume changes that add up to the same net result is bit-identical.

I just thought of another illustration. Its like having a cookie recipe that calls for 2 Tablespoons of sugar. You could measure using six teaspoons, or three teaspoons and one tablespoon, or two tablespoons, or four 1/4 tablespoons and ten 1/2 tablespoons, etc. Or you could be smart and use 1/8th cup. Nobody eating the cookies really cares, though, since they will all taste the same - bite-identical. 

[Lefisu63]

I know DR and R128 aren't perfect representations of how good a track will sound and that they calculate their values differently. However would it make any meaningful sense to combine the two to get a better idea of what tracks will have a good range?

I think PLR is the new short term which you mean and want (as I do) - the difference between True Peak & Loudness (it replaces the DR value).

PSR = "Peak to Short-term loudness Ratio" = the value at a specific moment.
PLR = "Integrated Peak to Loundess Ratio" = the average over all measured PSR values (as I understood) - over a part of a track or the full track.

See this initial video first: https://www.youtube.com/watch?v=a3cSYFFxM2A

The small follow up regarding PLR shown in this newer video: https://www.youtube.com/watch?v=iv67sjuq2go

Currently it's only available in Ian Shepherd's Dynameter by MeterPlugs and there doesn't exist a "batch" to run over all my 50.000 WAV files and calcs the PLR value.

I requested a batch 3-4 month ago but they have no plans to realize a command-line tool.

Hopefully JRiver can implement this?

[Vocalpoint]

The difference between -23LUFS and -16LUFS is +7dB. Setting the target in Volume Leveling vs in Parametric Equalizer saves Matt and the other programmers from programming more menu items that people don't understand. You adding 7dB in Parametric Equalizer will run the exact same code as if you could change the target in Volume Leveling.

I just tried this - put the PEQ inline with a setting of +7 and my "bit perfect" light (Eq icon upper right) - is no longer illuminated.

Can't have that!

Cheers!

VP

[blgentry]

I just tried this - put the PEQ inline with a setting of +7 and my "bit perfect" light (Eq icon upper right) - is no longer illuminated.

Can't have that!

That's because the blue light does NOT turn on for Volume Leveling or for Adaptive Volume (Peak Level Normalize), OR for volume adjustments made by using MC's built in volume control.  All three of these things inherently are NOT BIT PERFECT.  JRiver just chooses to ignore them.  Your PEQ of +7 dB is no better or no worse than the other 3 things.  But JRiver *does* turn off the blue light when you engage any kind of PEQ.

You're not hearing any different effects in this case.  It's just how the JRiver team has decided to program the behavior of the blue light.  The blue light is NOT A BIT PERFECT LIGHT.  Which is actually pretty strange.

Brian.

[Vocalpoint]

That's because the blue light does NOT turn on for Volume Leveling or for Adaptive Volume (Peak Level Normalize), OR for volume adjustments made by using MC's built in volume control.

Well - I use "Internal volume" with Volume Leveling on - and I get the blue light.

The blue light is key to my OCD well-being

VP

[Awesome Donkey]

Well - I use "Internal volume" with Volume Leveling on - and I get the blue light.

Same, I have both volume leveling and adaptive volume enabled and it lights up blue for me.

[blgentry]

^ Yes, you are both seeing the effect I was describing.

THE BLUE LIGHT IS NOT A BIT PERFECT LIGHT

Read that again. It's true.  The blue light ignores volume changes.  Guess how JRiver MC makes volume changes?  It changes the samples being sent to the DAC. Thus the original bits from the original samples in the song are being altered.

The blue light is not a bit perfect light.

Brian.

[Vocalpoint]

Read that again. It's true.  The blue light ignores volume changes.  Guess how JRiver MC makes volume changes?  It changes the samples being sent to the DAC. Thus the original bits from the original samples in the song are being altered.The blue light is not a bit perfect light.

Wow. This is big news to me.

If this thing is not bit perfect - what's the point?

Hopefully someone from JRiver can confirm.

VP

[RD James]

If this thing is not bit perfect - what's the point?

The point is that volume changes have no effect on audio quality as long as you're set to use TPDF dither.

[Vocalpoint]

As long as you're set to use TPDF dither.

TPDF dither? Clarify?

VP

[JimH]

Please do a search.