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: foo_truepeak True Peak Scanner (Read 8812 times) previous topic - next topic - Topic derived from Re: Resampling Hi-Res...
0 Members and 1 Guest are viewing this topic.

Re: foo_truepeak True Peak Scanner

Reply #150 –
Quote from: wojak on
could you please consider implementing PLR in your scanner. Recently you have incorporated LUFS so now PLR is the last thing we have to calculate with enormously long formula and it does not go to tags.
Added in version 0.6.9.

Quote from: Defender on
Can confirm that 0.6.8 with only RG+DR+POS enabled performs on the same level as 0.6.7 with RG+DR+POS+LRA.

Is your routine for calculating LUFS-S/M pretty much optimized already or do you expect to be able to implement some speedgains in the feature?

And second question: Would it be possible to use in 0.6.8+ the LRA method that was in use in 0.6.7 when scanning LUFS-S/M is not enabled?
I had actually introduced a very silly bug when I created a helper class for handling the libebur128 performed scans. The LUFS-M and LUFS-S values were always calculated every 100 ms even when the option was disabled. That is now fixed in version 0.6.9.

I could make LUFS-M and LUFS-S faster by calculating them less often. But then their accuracy would be somewhat reduced. I don't know at all how often other tools update these values, to my knowledge LUFS-M and LUFS-S were originally meant for live monitoring.

I'd also like to see if I could utilize the Peter's ReplayGain scanner optimizations to speed up the libebur library, I believe there is a lot of room for improvement there.

Re: foo_truepeak True Peak Scanner

Reply #151 –
Quote from: ngs428 on
  • Track and Album Max LUFS-M - Momentary (0.4 seconds?) measurement, as opposed to "I" which is the whole song
  • Track and Album Max LUFS-S - Short Term (3 seconds?) measurement, as opposed to "I" which is the whole song
400 ms (or 0.4 seconds) and 3000 ms (or 3 seconds) are correct. I'd just like to emphasise that the shown values are the highest readings recorded inside the track. Currently values are checked every 100 ms.

Quote from: ngs428 on
  • Track and Album LUFS-I - Similar to RG.  Measures the entire song.  How can I apply this value to normalize song's loudness levels?  When I use Case's ReplayGain DSP, does it use this value?  I can pick a loudness target of -14 LUFS, -18 LUFS, etc, but that is just the target.  What value is is using to match the target?  Is it still using the track and album gain or is it actually using the LUFS-I value, or does it matter?
The foobar2000's ReplayGain scanner in EBU mode has always calculated LUFS-I value, it is just converted into ReplayGain's format with a simple formula. Nothing has changed in ReplayGain or its behavior. I just added ability to show and tag this field for people who want to see it.

Re: foo_truepeak True Peak Scanner

Reply #152 –
Quote from: Case on
The LUFS-M and LUFS-S values were always calculated every 100 ms even when the option was disabled.
That was pretty much my first thought.

Quote from: Case on
I could make LUFS-M and LUFS-S faster by calculating them less often. But then their accuracy would be somewhat reduced. I don't know at all how often other tools update these values, to my knowledge LUFS-M and LUFS-S were originally meant for live monitoring.
Exactly. Live monitoring you can see/do with foo_loudness_peakmeter.
I'm still struggling whether I will display your Max LUFI-S/M values (without the location where they occur in the audiofile) in my playlist grid. This grid is intended to show general helpful information about the audiofile to give you a rough idea what to expect when listening to it and I don't know if Max LUFS-M/S bring something extra to the table.
Showing these (live) values would make more sense as mouseover tooltips in live tools such as the minibar mod. But I sure don't want this functionality in the minibar I'm using in my audiocontrol area. Would only be feasible in the area I designate for monitoring tools.

Quote from: Case on
I'd also like to see if I could utilize the Peter's ReplayGain scanner optimizations to speed up the libebur library, I believe there is a lot of room for improvement there.
Always good to optimize.

Thx again.

Re: foo_truepeak True Peak Scanner

Reply #153 –
@Case

Scanning speed of 0.6.9 with LRA, but without LUFS-S/M, is the same as it was with 0.6.7.

I am confused as a result of the new PLR fields.
In essence PLR is nothing else than applying peak_db on LUFS-I. If I do that based on your LUFS-I value I get a value. In the PLR field you report this value negated and rounded as an integer.

If it was only negated, I could still exactly verify it with my own calculations of LUFS-I and PLR, but because of the rounding I cannot.

Why is your PLR rounded?
Why is your PLR negated?

Re: foo_truepeak True Peak Scanner

Reply #154 –
PLR is difference between highest peak and loudness, calculated as 'peak_db' - 'LUFS-I'. Only way it would be negative is if peak was somehow smaller than loudness.
All places I saw quoting PLR numbers printed them without decimals, like https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Titleformat_Examples#Peak_to_Loudness_Ratio_.28PLR.29. I figured it's like the DR number that people want to see as integer.

Re: foo_truepeak True Peak Scanner

Reply #155 –
Quote from: Case on
PLR is difference between highest peak and loudness, calculated as 'peak_db' - 'LUFS-I'. Only way it would be negative is if peak was somehow smaller than loudness.
All places I saw quoting PLR numbers printed them without decimals, like https://wiki.hydrogenaud.io/index.php?title=Foobar2000:Titleformat_Examples#Peak_to_Loudness_Ratio_.28PLR.29. I figured it's like the DR number that people want to see as integer.

Hi,
Since TP and LUFS are presented with two decimal places, I think PLR should also be that way.

External meters like Youlean also use decimals.

The formula I use in Columns is based on:
$puts(PLR,$if(%replaygain_track_peak_db%, $puts(PLR,$sub($mul($replace(%replaygain_track_peak_db%,.,),10),$sub($mul($replace(%replaygain_track_gain%,.,),-10),18000))) $puts(PLR_TEN,$left($right($get(PLR),3),2)) $puts(PLR_ROUND,$ifgreater($get(PLR_TEN),40,$add($get(PLR),100),$get(PLR)))$iflonger($get(PLR_ROUND),4,<$left($get(PLR_ROUND),2)<.$substr($get(PLR_ROUND),3,3),$left($get(PLR_ROUND),1)<.$substr($get(PLR_ROUND),2,2)),))$if2($get(PLR),?)

Re: foo_truepeak True Peak Scanner

Reply #156 –
I initially had two decimals but I changed it to integer right before release. I'll change it back if that's what people want.

How about the tag field names, does anyone know if some tool already uses some tag field names for these things? I'd like to utilize common tags.
And this worries me a bit, I have been using the latest compiler for about 24 hours now. Any stability issues? I can revert to older toolchain.

And of course I want to know what Defender's comment about negated PLR was about...

Re: foo_truepeak True Peak Scanner

Reply #157 –
PLR works great in the new version here, thanks. It replaced the crazy long thing I had before. I'd also prefer two decimal places if poss.

Re: foo_truepeak True Peak Scanner

Reply #158 –
Quote from: Case on
And this worries me a bit,

I just posted about that...

https://hydrogenaud.io/index.php/topic,125795.msg1044927.html#msg1044927

If you've had no issues so far, you can't be using std::mutex?? It will insta-crash if you do. :P

Re: foo_truepeak True Peak Scanner

Reply #159 –
Quote from: Case on
And of course I want to know what Defender's comment about negated PLR was about...
Originally I used the oneliners I found somewhere on Regor's site to determine LUFS and PLR. So far for all the tracks in my playlist as a result of these oneliners the values have been positive.
When you came up earlier with the formula for LUFS I've written my own code for LUFS and PLR calculation, and backtested them with the original oneliners. All results are the same except for the rounding glitch of 0.1 that exists in the original oneliners.

Then you came up publishing LUFS-I and those values were always negative. Hence my question about that earlier.
In your answer you made a remark that LUFS-I becomes positive when gain is for instance -19 dB.
I decided I still want to see rounded positive integers like before (for tracks with normal gain values) so I had to negate (change the sign of) your values. Your negated value is always the same as my calculated one and after changing my code I now also handle the gain -19dB values.

The PLR I calculate takes peak_db into account and also results in positive values which I display rounded to the nearest integer.
So my code always shows positive values for LUFS and PLR unless crazy tracks appear with gains like -19 dB (or crazy peak_db).

Today 0.6.9 pops up and shows a rounded value for PLR that has the opposite sign of LUFS-I.
The fact that it is rounded makes that I cannot be sure your values and my calculated value match. When I round my PLR value so far they are always the same as yours.

Maybe the confusion comes because of different units (gain and PLR in dB and LUFS-I/S/M in LUFS (and LRA in LU)).
LUFS calculation takes place with a value in dB, but the result is in LUFS.
PLR calculation takes place with values in dB, and the result is in dB.

Anyway, I'd like your tool to publish PLR with two decimals as well.

Re: foo_truepeak True Peak Scanner

Reply #160 –
Quote from: Case on
I initially had two decimals but I changed it to integer right before release. I'll change it back if that's what people want.

How about the tag field names, does anyone know if some tool already uses some tag field names for these things? I'd like to utilize common tags.
And this worries me a bit, I have been using the latest compiler for about 24 hours now. Any stability issues? I can revert to older toolchain.

And of course I want to know what Defender's comment about negated PLR was about...

Yes, please bring back the decimals.
External meters show PLR as positive values. If PLR=TP-LUFS and LUFS are negative, PLR must be positive and more or less PLR=-LUFS (assuming peaks being close to 0).

Re: foo_truepeak True Peak Scanner

Reply #161 –
Uploaded a new version with PLR restored to two decimal accuracy. I also changed the unit from dB to LU as it's mostly dealing with EBU loudness terminology, where the preferred unit is LU.
@Defender : LUFS-I has seen no changes. It's still negative for most if not all sane tracks. You need to boost loudness so high that almost all content is beyond full scale to make things so loud that LUFS-I turns positive. And of course peaks are still higher than the loudness, so PLR will remain positive.

Re: foo_truepeak True Peak Scanner

Reply #162 –
Quote from: Case on
@Defender : LUFS-I has seen no changes. It's still negative for most if not all sane tracks. You need to boost loudness so high that almost all content is beyond full scale to make things so loud that LUFS-I turns positive. And of course peaks are still higher than the loudness, so PLR will remain positive.
Fine. You checked what you are publishing and it is correct.

I will still be displaying the negated version of LUFS because of esthetics and the idea that values are "better" the larger the positive values are. Just like the LRA, PLR and DR values that sit next to LUFS-I in my display. No confusion also because I display them as Li16, so without the units.

Not an issue, but an observation:
I checked the PLR values I calculate with yours and in some cases they differ by either -0.01 or +0.01. In the calculations I don't use $div or $mod and the precision of the peak and gain tags is 2, and since our LUFS values are always the same (negated that is) the difference can only be explained if you calculate PLR with values with a higher precision than 2.

Thx for the swift PLR decimal fix.
 

Re: foo_truepeak True Peak Scanner

Reply #163 –
Quote from: Case on
Would you be interested in more statistics in the output? Just knowing that samples clip doesn't yet tell how bad it is. Exceeding the full scale by 0.1 dB would not matter at all, but exceeding it by 3 dB could be a problem.
I could for example log how large percentage of clipping exceeded full scale by 1 dB, how much by 2 dB, etc.

After reading this, it got me thinking of what the "Clipping Samples" or "Album Clipping" actually tells us.  I have some tracks that show thousands of clips and I have only scanned a handful of tracks, are the clips only 0.1 dB over, hard to say...  Understanding how far the clip exceeds full scale by % of clips makes sense.  Similar to what you described.  % clips >1dB, % clips >2dB, % clips >3dB, etc., would give a user an understating of the impact of the clipping.

Thanks for your continued work on this component!  I'm working to digest what all the terms mean!