Is a 0.8 difference in dynamic range audible?

[Rja4000]

It could even be a DSD to PCM conversation thing in ffmpeg that led to the .8 dB difference. It must convert DSD to do any processing on it.

I was just thinking exactly the same thing (just added to my post above before reading this)

 

[danadam]

Honestly, I don't know. The sparse manual is https://ffmpeg.org/ffmpeg-filters.html#drmeter and the output is:
[Parsed_drmeter_0 @ 0x5629abde1540] Channel 1: DR: 11.3
[Parsed_drmeter_0 @ 0x5629abde1540] Channel 2: DR: 12.2
[Parsed_drmeter_0 @ 0x5629abde1540] Overall DR: 11.7

What it's worth it agrees with what I've seen spit out by foobar, but ffmpeg gives me the decimal places, which is what made me wonder in the first place.

With DR meter differences, the difference in files can be as little as a single sample, if it is the second largest sample (see attachment):

]$ ffmpeg -i a.flac -af drmeter -f null /dev/null
ffmpeg version N-108742-g1f63225f2b79 Copyright (c) 2000-2022 the FFmpeg developers
...
[Parsed_drmeter_0 @ 0x5606be494d00] Channel 1: DR: 9.99416
[Parsed_drmeter_0 @ 0x5606be494d00] Overall DR: 9.99416

]$ ffmpeg -i b.flac -af drmeter -f null /dev/null
ffmpeg version N-108742-g1f63225f2b79 Copyright (c) 2000-2022 the FFmpeg developers
...
[Parsed_drmeter_0 @ 0x55d833febe00] Channel 1: DR: 9.19617
[Parsed_drmeter_0 @ 0x55d833febe00] Overall DR: 9.19617

]$ sox -m -v 1 a.flac -v -1 b.flac null.flac

 

[haen]

Hey, I didn't know that ffmpeg has some kind of 'DR meter'. Thanks!

ffmpeg -i Shellac/\(1994\)\ At\ Action\ Park/01.\ My\ Black\ Ass.flac -af drmeter -f null /dev/null

[Parsed_drmeter_0 @ 0x55f4088f4140] Channel 1: DR: 13.1166
[Parsed_drmeter_0 @ 0x55f4088f4140] Channel 2: DR: 12.8521
[Parsed_drmeter_0 @ 0x55f4088f4140] Overall DR: 12.9843

Apparently Steve Albini knows his stuff ;-)

ffmpeg -i Chat\ Pile/\(2019\)\ Remove\ Your\ Skin\ Please/01.\ Dallas\ Beltway.flac -af drmeter -f null /dev/null

[Parsed_drmeter_0 @ 0x558c7f683740] Channel 1: DR: 6.71194
[Parsed_drmeter_0 @ 0x558c7f683740] Channel 2: DR: 8.26962
[Parsed_drmeter_0 @ 0x558c7f683740] Overall DR: 7.49078

Middling. Love that EP anyway.

ffmpeg -i System\ of\ a\ Down/\(1998\)\ System\ of\ a\ Down/01.\ Suite-Pee.flac -af drmeter -f null /dev/null

[Parsed_drmeter_0 @ 0x5615c3250b40] Channel 1: DR: -2.02685
[Parsed_drmeter_0 @ 0x5615c3250b40] Channel 2: DR: -1.63762
[Parsed_drmeter_0 @ 0x5615c3250b40] Overall DR: -1.83223

LOL. It's Rick Rubin, right?

On more serious note one would need to understand what ffmpeg is actually doing under the hood. The codebase is here - https://github.com/FFmpeg/FFmpeg/blob/master/libavfilter/af_drmeter.c - and the initial commit - https://github.com/FFmpeg/FFmpeg/commit/8fb0e51bd198c996b8932735e8002f0952ef1d06 - does not bring much info...

 

[danadam]

one would need to understand what ffmpeg is actually doing under the hood.

https://web.archive.org/web/2018091....de/sites/default/files/Measuring DR ENv3.pdf

 

[haen]

Thanks a lot.

That page is from http://www.dynamicrange.de which I think came from Pleasurize Music Foundation, so the algorithm is probably the same as in (in)famous TT DR Meter (https://www.kvraudio.com/product/tt-dynamic-range-meter-by-pleasurize-music-foundation etc).

I looked at the algorithm and from a quick glance I don't understand why blocks peak value contribute to the histogram (from the algorithm point of view, I have no idea if in general this approach to calculate DR is reasonable).

 

[bearcatsandor]

What I don't understand is a negative dynamic range. I mean, ok it *is* Meshuggah, but ffmpeg -hide_banner -af drmeter -f wav -y /dev/null -i /home/hometheater/audio/meshuggah/2022-immutab le_\[nocatnum\]/01-01-broken_cog.wv [Parsed_drmeter_0 @ 0x561df99071c0] Channel 1: DR: -18.4 [Parsed_drmeter_0 @ 0x561df99071c0] Channel 2: DR: -18.6 [Parsed_drmeter_0 @ 0x561df99071c0] Overall DR: -18.5
What does that mean? Is that possible in our universe? I mean given their time signatures Mushuggah is probably in another universe anyway ...
Also BE CAREFUL I just tried this command on an entire folder (-i *.wv) and all tracks were overwritten with track 1. Use on single tracks only.

 

[haen]

Looking a little bit more at the code I think that this ffmpeg DR meter tried to implement the algorithm as linked by @danadam but did not do it correctly. The negative values would happen if the (second) peak (most loud moment) of the file is much 'quieter' than the calculated RMS ('average loudness'). It does not make much sense, and when running the tool over various files sometimes I got NaN values, which I suspect means some number overflows in the codebase (wrong types etc.).

 

[haen]

I was curious about DR having values below 0 so I've tried to replicate what ffmpeg is doing by a piece of my own code. I used 'Suite-Pee' from System of a Down as it got DR: -1.83223...

The algorithm calculates peak values for each of 3 seconds long chunks of the song. Then it takes the second largest peak for further calculation. The problem is that almost all chunks has the same big peak value, and 3 other chunks have much lower peaks. So if we take the second largest peak is happens to be smaller ('more quiet') than the average 'loudness', hence the DR value below 0. I suppose that the original TT DR Meter takes into accounts some edge cases...

 

[bearcatsandor]

@haen Do you want to file a bug report to ffmpeg or shall I?

 

[haen]

Too lazy to file a bug report, sorry ;-)

Here is some data for one specific track:

The log from TT DR Meter 1.4:

-----------------------------------------------
 Statistics for:    01. Suite-Pee.wav
 Number of Samples: 6698496
-----------------------------------------------

                  left              right

 Peak value:     -0.10 dB   ---    -0.10 dB
 Avg RMS:        -5.95 dB   ---    -5.96 dB
 DR channel:      4.60 dB   ---     4.46 dB
-----------------------------------------------

 Official DR value:  DR5
===============================================

$ ffmpeg -i System\ of\ a\ Down/\(1998\)\ System\ of\ a\ Down/01.\ Suite-Pee.flac -af drmeter -f null /dev/null

[Parsed_drmeter_0 @ 0x55e1c22a5b40] Channel 1: DR: -2.02685
[Parsed_drmeter_0 @ 0x55e1c22a5b40] Channel 2: DR: -1.63762
[Parsed_drmeter_0 @ 0x55e1c22a5b40] Overall DR: -1.83223

I wrote my version of the algorithm. The per-block peaks calculated for this track are following (absolute values of 16-bit signed samples):

PEAKS List(13359.0, 12779.0, 12670.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 32393.0, 1329.0)

As ffmpeg DR meter puts values in bins/buckets, as described by the PDF attached above, the largest value is 32393.0, and the second largest is 13359.0. This will ultimately give a negative DR, as the second largest peak will be less that the calculated RMS.

Note that TT DR Meter actually gives other values and my take would be that - since my implementation gives the same results - actually no histogram/bins/buckets are used - peaks are sorted and then the second largest value is selected, which will be 32393.0...

Personally I think that this DR algorithm is more a curiosity (or a confusion sower...) than something useful. I would probably try to use some concepts from EBU R 128 like Loudness Range maybe...