21
3rd Party Plugins - (fb2k) / Re: foo_truepeak True Peak Scanner
Last post by Defender -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.
