Print

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

[Matt]

As discussed here, we're opening up the Audio Analyzer for video files in MC19.

Currently it analyzes these values:
Volume Level (R128)
Dynamic Range (R128)
Peak Level

My question is if there are any other useful metrics people would like for audio analysis?

Thanks for any suggestions.

[MrC]

I suppose I've been waiting for this type of question, to follow-up with one regarding BPM.  I'm wondering if something might not be right.  Fleetwood Mac's Over & Over (from Tusk) is analyzed to have 166 BPM.  It is a very slow BPM song (with Intensity 1), so I'm wondering what beats are being counted.

Lowest priority.

[Matt]

BPM algorithms are tricky.

It's not easy, sometimes even for a human, to tell between multiples like 50, 100, and 150 bpm.

I think we could improve our algorithm, and it's the type of things I love getting lost on, but I also don't think it's very important compared to some of the other opportunities we have.

[mojave]

Average Level
Crest Factor (probably not really necessary since you have Dynamic Range)

Will it provide data for each channel?

[Matt]

Average Level

Isn't that similar to the loudness (ie. ReplayGain / R128 Loudness)?

Will it provide data for each channel?

The R128 numbers are one overall number.

What do you have in mind?

[mojave]

Isn't that similar to the loudness (ie. ReplayGain / R128 Loudness)?

Yes it is. Nevermind.

The R128 numbers are one overall number.

What do you have in mind?

I was thinking that when using active crossovers or other system setup it could be useful to know the peak level of each channel so you can easily find the worst case scenario with at least your current media. I like how the analyzer displays RMS levels of each channel, but have often wanted it to also show the maximum RMS level during playback. Having that done during audio analysis makes more sense since real time analysis takes too much time.

I'm also wondering if a channel peak level could better help with convolution normalization. I've seen reports on both the Audiolense and Acourate forums that JRiver's "normalize filter volume" causes clipping and is recommended to be unchecked.

[Matt]

I've seen reports on both the Audiolense and Acourate forums that JRiver's "normalize filter volume" causes clipping and is recommended to be unchecked.

I know about this.  Currently the normalize system pushes pink noise through the convolution engine and target -6dB of change.

However, with some filters this pushes them too hard and leads to clipping.

A more complicated normalization method would probably work better, but I'm not sure what it would be.

It's possible just changing the default to off and removing the words "recommended" would be enough for now.

[6233638]

I think it's very important to also calculate a "downmix loudness" value for when videos are being downmixed to stereo, rather than just at the "native" number of channels.
If anything, downmixing needs normalization more than outputting multichannel does.

[Matt]

We'll switch the 'Peak Level' field to be a string, use decibels, and show per-channel levels.

Here's an example from a 5.1 music video I just tested:
-0.1 dB (-0.1 Left; -0.1 Right; -1.5 Center; -6.9 Sub; -12.3 SL; -12.4 SR)

Packing it into a single string might make it a little harder to manipulate the data, but the alternative was to create a pile of peak level fields for each channel which seemed a little messy.

[Matt]

I think it's very important to also calculate a "downmix loudness" value for when videos are being downmixed to stereo, rather than just at the "native" number of channels.
If anything, downmixing needs normalization more than outputting multichannel does.

I think this is just a math problem.  Proper down-mixing doesn't change the energy balance, so I don't believe you need two analyze numbers.

The downmixer knows if it turns the volume down to prevent clipping, so it could provide that information to the Volume Leveling code for it to take into account.

[Matt]

We'll switch the 'Peak Level' field to be a string, use decibels, and show per-channel levels.

Here's an example from a 5.1 music video I just tested:
-0.1 dB (-0.1 Left; -0.1 Right; -1.5 Center; -6.9 Sub; -12.3 SL; -12.4 SR)

Packing it into a single string might make it a little harder to manipulate the data, but the alternative was to create a pile of peak level fields for each channel which seemed a little messy.

Should mono videos show:
-5.7 dB (-5.7 Mono)

Or just:
-5.7 dB

[MrC]

Why bother with the parens at all.  How about just making it a list field of the form:

   value description[; ...]

Examples:

   -0.1 dB; -0.1 Left; -0.1 Right; -1.5 Center; -6.9 Sub; -12.3 SL; -12.4 SR
   -0.1 dB Total; -0.1 Left; -0.1 Right; -1.5 Center; -6.9 Sub; -12.3 SL; -12.4 SR
   -5.7 dB Mono

This makes it very easy to parse, show the first value, or select any value (by position or channel pattern).  Format display could be treated like Artist (first only for ,1, all for ,0).

[Matt]

Why bother with the parens at all.  How about just making it a list field of the form:

   value description[; ...]

Examples:

   -0.1 dB; -0.1 Left; -0.1 Right; -1.5 Center; -6.9 Sub; -12.3 SL; -12.4 SR
   -0.1 dB Total; -0.1 Left; -0.1 Right; -1.5 Center; -6.9 Sub; -12.3 SL; -12.4 SR
   -5.7 dB Mono

This makes it very easy to parse, show the first value, or select any value (by position or channel pattern).  Format display could be treated like Artist (first only for ,1, all for ,0).

Good advice.  This is why I ask.

We'll try this format:
   -0.1 dB; -0.1 Left; -0.1 Right; -1.5 Center; -6.9 Sub; -12.3 SL; -12.4 SR
   -5.7 dB; -5.7 Mono

I prefer denoting mono or else we'll get questions "why don't I have per-channel for this video."  Using "-5.7 dB Mono" instead would work, but then mono works differently than all other channel counts which I don't like.

[6233638]

I think this is just a math problem.  Proper down-mixing doesn't change the energy balance, so I don't believe you need two analyze numbers.
The downmixer knows if it turns the volume down to prevent clipping, so it could provide that information to the Volume Leveling code for it to take into account.

According to Tech 3343, downmixes need separate analysis - at least that's how I understood it.

It is also again pointed out that the surround channels are weighted with +1.5 dB⁵ during a loudness measurement according to ITU-R BS.1770. After an automatic downmix this weighting is not applied, as the result is only frontal 2-ch-stereo (Left and Right front). Programmes with a lot of surround content will consequently exhibit potentially larger variations of the loudness of the surround mix vs. the 2-ch-stereo downmix than programmes with more ‘conservative’ use of the surround channels.

Or is this something you are able to calculate after-the-fact? (I was under the impression it would not be)

They also recommend this for the downmix, when the downmix metadata is missing. Currently, LAV filters doesn't read this information. I don't know what JRSS uses for its standard downmix.
L, R front: 0 dB
C, LS, RS: -3 dB

[MrC]

I prefer denoting mono or else we'll get questions "why don't I have per-channel for this video."  Using "-5.7 dB Mono" instead would work, but then mono works differently than all other channel counts which I don't like.

Agreed.  So ListCount([Peak Level]) always returns the number of channels + 1 (a summary value, followed by the channel values), and ListItem([Peak Level], 0) always gives you a simple summary value in the form #.# dB.  I wonder if [Peak Value,1] returns a formatted string #.# dB, or a decimal #.#.  The latter makes Math() easier of course, but then makes your column display harder, but I think you're special casing this anyway.  [No reply necessary]

[Matt]

Agreed.  So ListCount([Peak Level]) always returns the number of channels + 1 (a summary value, followed by the channel values), and ListItem([Peak Level], 0) always gives you a simple summary value in the form #.# dB.

Yes.

I wonder if [Peak Value,1] returns a formatted string #.# dB, or a decimal #.#.  The latter makes Math() easier of course, but then makes your column display harder, but I think you're special casing this anyway.

For now, it's a regular string field.  That means you'd get the string "#.# dB" or "#.# Channel".  However, our string to number handler will ignore stuff after the number so you could make it a number as necessary with an expression.

[mojave]

I know about this.  Currently the normalize system pushes pink noise through the convolution engine and target -6dB of change.

However, with some filters this pushes them too hard and leads to clipping.

A more complicated normalization method would probably work better, but I'm not sure what it would be.

It's possible just changing the default to off and removing the words "recommended" would be enough for now.

Nothing was ever done about "normalize filter volume" in Convolution. I thought I'd bring it up again.