Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Dynamic Range plugin (Read 58648 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re: Dynamic Range plugin

Reply #150
@Case , when using "Сopy to clipboard" in foo_dr_meter results window and then pasting it somewhere, it looks like a mess.
Example:
Code: [Select]
Name	Path	Track DR	Album DR	DR (FL)	DR (FR)	RMS (FL)	RMS (FR)	Peak (FL)	Peak (FR)
Reclaiming Decades Erased Y\Serpent Column\Serpent Column - 2024 - Tassel of Ares\01. Reclaiming Decades Erased.flac 6 8 6.13 dB 5.92 dB -7.15 dBFS -6.68 dBFS 0.00 dBFS 0.00 dBFS
Unto Works and Days 6 8 5.88 dB 5.85 dB -7.66 dBFS -7.76 dBFS -0.30 dBFS -0.30 dBFS
The Long War of Essential Struggle r\Serpent Column\Serpent Column - 2024 - Tassel of Ares\03. The Long War of Essential Struggle.flac 7 8 6.47 dB 6.58 dB -8.05 dBFS -8.15 dBFS 0.00 dBFS 0.00 dBFS
In Death I Will Remember the Color of Her Irises U\Serpent Column\Serpent Column - 2024 - Tassel of Ares\04. In Death I Will Remember the Color of Her Irises.flac 12 8 12.32 dB 11.57 dB -15.73 dBFS -14.83 dBFS -0.93 dBFS -0.93 dBFS
Also, note strange symbols instead of disk name (it is simply local disc named G) in files paths.

Re: Dynamic Range plugin

Reply #151
The clipboard report is formatted for pasting in a spreadsheet like Excel. Text is in unicode as widechar and fields are separated by tabs. The paths should contain all the characters too. Can you try pasting for example in LibreOffice's Calc or in a unicode supporting text editor?

Re: Dynamic Range plugin

Reply #152
Thank you for the component case, working perfectly as replacement of the old one. And much faster!

Btw some minor tip, the window button displays a 'cancel' button instead of 'close' which I would say it's more intuitive (since you are not cancelling anything, specially if auto-tagging or auto-write log is enabled).

EDIT: I'm also adding support for this on my auto-tagger tool found at Playlist Tools. So now both DR meters are supported.

Re: Dynamic Range plugin

Reply #153
Dear case,
a big thank you for the DR-meter component.

LUFS-I and PLR was very useless for me and no replacement. After reading the explanation from @omasciarotte it was clear to me.

Markus

Re: Dynamic Range plugin

Reply #154
Very nice tool.
But I'm missing the following in DR Meter Results:
1. Add new columns, remove unnecessary columns (I need - Artist, Title, Filename)
2. Drag and drop columns (or to make some settings to left/right columns)
3. LM click on column - sort
And I found the hidden column path.

Re: Dynamic Range plugin

Reply #155
Hi Case, just noticed a track where the DR provided by this component doesn't match the old one. Probably due to rounding errors.

Not sure if that's expected behavior or a bug. Do you need the track?

Re: Dynamic Range plugin

Reply #156
I think having the track would be helpful. Differences with the old DR meter are expected, but the lack of artificial clipping should show higher DR numbers and not smaller, so this is unexpected.

Re: Dynamic Range plugin

Reply #157
Thanks for the sample. Results were even more different than I expected.

I googled for a couple of random different third party implementations and scanned the file with them. These tools gave DR0 too for the track.
The DRMeter filter in ffmpeg managed to give result close to the old tool, DR of about 0.56. I see ffmpeg uses histrogram, though not in the way described in the document. And it uses highest clipped peak even though the variable is handily named second peak.
Trying to confirm how well ffmpeg's filter fares generally I tried it on a random 16 minute track. It failed to give any results.

I'll see what I can do to improve things once I have the right amount of time and motivation.

Re: Dynamic Range plugin

Reply #158
I released a new version with adjusted DR computation that fixes the DR results for regor's track. Other sample tracks I compared from my library still match with the previous version of the component.

And I added support for customizing the information columns about the source track. Syntax for that is Title=Titleformat[|Width].
Title will be used as column title, Titleformat is the titleformat script you wish to show and optional pipe character separated width in dialog units can be specified at the end. 0 value means hidden by default, if width isn't specified the column will be autoscaling.
And I enabled a basic string sorting support for columns.

Re: Dynamic Range plugin

Reply #159
I released a new version with adjusted DR computation that fixes the DR results for regor's track. Other sample tracks I compared from my library still match with the previous version of the component.

And I added support for customizing the information columns about the source track. Syntax for that is Title=Titleformat[|Width].
Title will be used as column title, Titleformat is the titleformat script you wish to show and optional pipe character separated width in dialog units can be specified at the end. 0 value means hidden by default, if width isn't specified the column will be autoscaling.
And I enabled a basic string sorting support for columns.
Thx. Is the DR computation within TPS changed accordingly?

Re: Dynamic Range plugin

Reply #160
Not yet. There are so many open requests to TPS I don't want to make a hasty release.


Re: Dynamic Range plugin

Reply #162
For testing I'm sending you my tracks with lowest DR, along the logs from the new version, the previous version and the old component.

With the new version the track I sent you is now matching, but note there are 2 tracks not matching. Just in case you are interested on it (otherwise ignore it). Specially interesting the track with 4 secs, which gives totally different results.
Spoiler (click to show/hide)

Have not bothered with anything over DR1, let me know if you want me to further find mismatches on low DRs.

The new column TF is great, and allows to sort by same TF than playlists. Much appreciated.

EDIT: I still think the tagging and write log buttons should be disabled/grayed out when automatic tagging/log writing is enabled on preferences, since it's misleading. It's already done when the window is shown. And the cancel button should be close.

Spoiler (click to show/hide)

Re: Dynamic Range plugin

Reply #163
I renamed the Cancel button to "Close" in TPS. I can't seem to remember to do the same improvements everywhere. Let's hope I manage at some point.

I took a quick look at the results and seems that only "Voices" and "The acid drop" differ from old Dynamic Range component now. These look like bugs in the old component. If you place these problem tracks multiple times in a playlist and use Converter to merge longer tracks from them, the old Dynamic Range Meter component will give same results from the long tracks as my DR Meter.
I hope you can confirm this finding and agree that track length shouldn't affect the result unless the result was wrong.

Re: Dynamic Range plugin

Reply #164
Yes only those 2 tracks differ, as shown in the screenshot. I just shared all for testing.

I did so with "The acid drop", just copying the track 10 times in audition and yep, they match and show DR16. Did not bother to check the waveform before, it's clearly not DR1, obviously a bug on the old component, you are right.

EDIT: Can confirm that anything below 12 seconds (tested with 44.1Khz) gives wrong results on the old meter.

About "Voices" I think there is a mistake on your side. The track is 2 min. long, but DR differs. Following your notes I don't understand why that result is a bug in this case.

Re: Dynamic Range plugin

Reply #165
I'm not a reverse engineer so I don't know what the old component does, but it seems to get lower results when the track is shorter. When the track is scanned alone, the DR values for channels are 2.39 dB and 0.58 dB, which averages to 1.485 dB.
When the track length is doubled by repetition, the DR values are suddenly 2.44 dB and 0.64 dB. This averages 1.54 dB, which means DR2 (when the length is doubled my scanner actually gives the exactly same DR values for the channels).

The Acid Drop track is a perfect example of original scanner's weirdness. Claims DR1 when the track is alone, when repeated 10 times to 40 seconds it shows DR15. When looped longer it shows DR16. I assume altering the length would allow getting any number between 1 and 16 from this.

Re: Dynamic Range plugin

Reply #166
I'm not a reverse engineer so I don't know what the old component does, but it seems to get lower results when the track is shorter. When the track is scanned alone, the DR values for channels are 2.39 dB and 0.58 dB, which averages to 1.485 dB.
When the track length is doubled by repetition, the DR values are suddenly 2.44 dB and 0.64 dB. This averages 1.54 dB, which means DR2 (when the length is doubled my scanner actually gives the exactly same DR values for the channels).

The Acid Drop track is a perfect example of original scanner's weirdness. Claims DR1 when the track is alone, when repeated 10 times to 40 seconds it shows DR15. When looped longer it shows DR16. I assume altering the length would allow getting any number between 1 and 16 from this.

Yes, cloning multiple times makes DR go higher with numbers anywhere between 1 and 16.

So it's not only affecting really short tracks but in fact anything according to length? I was obviously not expecting a 2min track being affected by this too. Pretty weird implementation. Thanks for looking at this.

Re: Dynamic Range plugin

Reply #167
I uploaded a new DR Meter version, number getting dangerously close to 1.0.

Results dialog adjustments and simple string sorting changed to sort the data columns by actual numbers.

Re: Dynamic Range plugin

Reply #168
Hello,

Is it possible to display a remaining running time or at least a total duration in the process window?

cu
mexx

Re: Dynamic Range plugin

Reply #169
After reading  this thread: "https://www.quadraphonicquad.com/forums/threads/the-dr-meter-multichannel-files.34495/", I think the
the multi-channel surround extension to summarize DR for 7.1 surround, etc. by various DR tools looks pretty sketchy.    The paid MAAT stuff even the $$MKII$$ do not produce official DR numbers for surround source files.  To do so allows for reporting of some pretty weird DR results.  The numbers for the individual channels are great, its just the combination.  I goofed around with a 7.1 audio file and the plugin.  I "silenced" all but two stereo pairs of channels, Front (DR8) and Back (DR16), with the Back RMS -20 dB down from the Front level.   Well it spit out DR11 for the total DR, which doesn't make much sense due to how low the Back level is.
So probably it would be best to not report the summary (N/A) or put a caveat in the log file.

Re: Dynamic Range plugin

Reply #170
@mexx: Possibly, if I ever implement such thing. Though I'm not a huge fan of inaccurate time estimates, and it will be inaccurate for any larger jobs.

@spongebob128: The DR calculation is stricly specified to be performed for each channel and the total DR is the average of these results. Do realize that DR number is not related to how dynamic or good something sounds. It's just a simple peak to partial RMS calculation. Complaining that it's "wrong" for multichannel files is same as complaining that bitrate calculations are wrong for your multichannel files because you don't like what the numbers show.

In case you are not familiar, DR is in no way reliable means to measure audible dynamic range. It can be fooled to give much bigger numbers for example by a simple all-pass filter. That filter doesn't change audio at all but DR can go from low single digits to high two digits.

Re: Dynamic Range plugin

Reply #171
The problem is that you are reporting it as a "Official DR value".   Its an "Average Channel DR Value" and simple channel DR averaging is not in the original DR algorithm and not defined by the current developers (MAAT) which seem to have engineers on their staff.   The problem is probably that the simple scripts out there that process the DR log files may not work anymore without the "Official DR value" tag, so the need for a caveat.     

Its may not be "wrong" but it is misleading.  Suppose you have a surround sound source where the front channels are DR4 and the rear channels are D14 and the rear channel level is -20 dB down.   If you downmix it to stereo its going to be close to DR4.  If you play it in a surround set up, the front channels will dominate the sound and thus be close to DR4 in the listening position.   The only way to get a higher DR sound would be to put your ear on the back speakers.  I believe level balancing the front and rear so simple averaging would make sense would "destroy" the original mix.  So reporting  (DR4+DR14)/2 = DR9 is misleading.   These averaged numbers are being reported in the DR database and other websites.  I recently got fooled and highly confused when I bought a BR TrueHD Atmos disk that (The Cure-Lost Worlds) where it was reported to be DR13 (from two sources), but when I ripped it the DR of the front channels was DR8!  Furthermore, this was where most of the mix was and the front channels were +7.86 dB over the next hightest channel pair so mixing in the higher DR channels only increased the final DR by 1-2 points.

Here is from the "Music Media Helper" Documentation which is probably based on the algoirithm from the original foobar plugin's unofficial multi-channel extension.

MMH ignores a Channel’s DR in the overall file DR calculation if it is zero or the Avg RMS < 30db (too quiet to be heard). The Overall calc is: (Sum of Non-Ignored Channel DR) / (No. of non-ignored Channels). In the above this is (11 + 14 + 15 + 14) / 4 = 13.5 (this is always rounded to nearest integer, so DR is reported as DR14).


Frankly, this does not look like a very (academic) "engineering-y" definition.   The RMS level is only used as a filter.

So again, I think reporting individual channel DR is great!  I am just thinking that a caveat "Overall DR value is a simple average of the DR values of the surround channels." added to the log file might be a good idea.

Re: Dynamic Range plugin

Reply #172
As I said, the calculation of DR is specified and it doesn't tell you to filter out channels by any criteria. There is no "unofficial multi-channel extension", there is only the specification. You can read it here: https://web.archive.org/web/20131206121248/http://www.dynamicrange.de/sites/default/files/Measuring%20DR%20ENv3.pdf.

I see that the the original foobar2000 component actually ignored completely blank channel, though I'd count that as a bug. It for example prints peak and RMS for such channels as "-1.#J".
Simply adding minimal dither noise to the channel triggers the old component to use the channel like it should be used. Just because a channel has DR0 doesn't mean it's not there.

You are right that the exclusion criteria you quoted from MMH isn't academic. It's completely made up. If you are following DR specs you can't invent your own rules.
If you have been scanning your files with MMH you might want to double check the results. I scanned three test files with it and for one it claimed front left and front right channels to be DR2/3 when in reality the channels were around DR10.

Re: Dynamic Range plugin

Reply #173
I didn't know if there was anything that had a status of "official" to be taken literally.

Anyway I think that at least ideally, the average should be volume-weighted in some manner, so that a blank channel counts for nothing. And, for the sake of the argument: what if one "was blank, but dithered in the mastering" so every block has something - then way out in the roundoff.

Though it is maybe a good thing to leave the algorithm for stereo as it is.

Re: Dynamic Range plugin

Reply #174
Feel free to invent your own measurements, but the people who invented DR did publish how to calculate it.
If you deviate from the specs you will no longer get comparable results, which is the whole point of a standard.