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 16675 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 #125
(I guess your value is correct and the oneliner does some truncating somewhere instead of rounding)

EDIT: If the first digit after the decimal point in your calculation is between 0 and (including) 3 results are the same, otherwise the oneliner version gives a 0.1 higher result.
It's easy for you to verify that foo_truepeak is correct. ReplayGain result = (-18) - (loudness), so loudness = (-18) - (RG). The values stored in tags are rounded to two decimals, but the component internally calculates it directly from floating point result.

Re: foo_truepeak True Peak Scanner

Reply #126
Just for my understanding. I removed the old version. Restarted foobar and installed the updated version.

[...]

What are all default names for custom fields you provide upon first-time installation?
Removing a component in foobar2000 doesn't touch configuration.

You can reset any setting in advanced preferences by right clicking it and select 'Reset'. And you can reset multiple settings at once by selecting an upper branch to right click and select 'Reset branch'.

But for documentation purposes here are the currently configured tag field names:
Code: [Select]
Custom track peak:          replaygain_track_true_peak
Custom album peak:          replaygain_album_true_peak
Custom track gain           truepeak_scanner_track_gain
Custom album gain           truepeak_scanner_album_gain
Clipped samples in track:   truepeak_scanner_clipped_samples_track
Clipped samples in album:   truepeak_scanner_clipped_samples_album
Peak timestamp:             truepeak_scanner_peak_position
Track max LUFS-M:           truepeak_scanner_track_max_lufs_m
Album max LUFS-M:           truepeak_scanner_album_max_lufs_m
Track max LUFS-S:           truepeak_scanner_track_max_lufs_s
Album max LUFS-S:           truepeak_scanner_album_max_lufs_s
Track LUFS-I:               truepeak_scanner_track_lufs_i
Album LUFS-I:               truepeak_scanner_album_lufs_i

non-configurable fields:
LRA of track:               replaygain_track_range
LRA of album:               replaygain_album_range
DR of track:                dynamic range
DR of album:                album dynamic range

Re: foo_truepeak True Peak Scanner

Reply #127
Yes, using this string to display the Clip count in the playlist:

%truepeak_scanner_clipped_samples_track%

And this King Tubby CD is showing dBTP overs of up to +2.45dB on one track, but the Clip count is zero for every track.
Thanks, there seems to have been a bug ever since I added the option to save the clip info. Originally the clipping info was just displayed on the status dialog but someone wanted an ability to save it to tags, so there's now an option.
I seem to have managed to code it in a way that when save option is enabled the counter values are stored even when nothing was scanned. You see zeroes because you didn't use the "and positions" context menu entry to scan for clipping. I'll fix for the next version.

Thank you!

Re: foo_truepeak True Peak Scanner

Reply #128
It's easy for you to verify that foo_truepeak is correct. ReplayGain result = (-18) - (loudness), so loudness = (-18) - (RG). The values stored in tags are rounded to two decimals, but the component internally calculates it directly from floating point result.
Silly me. No voodoo involved.

Re: foo_truepeak True Peak Scanner

Reply #129
You can reset any setting in advanced preferences by right clicking it and select 'Reset'. And you can reset multiple settings at once by selecting an upper branch to right click and select 'Reset branch'.
Good to know. Thx.

For documentation purposes here are the currently configured tag field names
So the general standardized tagnaming is COMPONENT_SCOPE_PROPERTY, which makes sense.
Only the tags for clipped samples use a different convention.

Re: foo_truepeak True Peak Scanner

Reply #130
I don't know what you mean. Of course you can work in TF with floats, calculations and proper rounding with a selectable number of digits behind the dot. You just have to shift the value to a much larger integer value to work with. Since I decided I don't ever want more than 9 digits after the dot in the result that means the original float (eg text consisting of only digits and only one dot somewhere) has to be enlarged inside the routine by adding 10x 0 to work with.
That's exactly my point:  "TF doesn't work with floats in a natural way without 40 lines of code", not sure what's your point showing exactly what I said xd We already know it "can be done" and anyway you are using integers in the end.

Doing all that every-time you have to operate with 1 float number is ridiculous (what about needing 10?)

Re: foo_truepeak True Peak Scanner

Reply #131
That's exactly my point:  "TF doesn't work with floats in a natural way without 40 lines of code", not sure what's your point showing exactly what I said xd We already know it "can be done" and anyway you are using integers in the end.

Doing all that every-time you have to operate with 1 float number is ridiculous (what about needing 10?)
I'm using this TF code not in a PSS splitter but within ELP.
In ELP I can define "functions". I created a couple of generic functions I can call wherever I want within all different elements of ELP.  This also makes it possible to exceed the 30k code limitation per ELP element. So I really don't care how much code I need for generic multi-purpose functions, since they are only defined in a single place.

I don't find that ridiculous, but quite efficient. I do find this whole discussion OT.

Re: foo_truepeak True Peak Scanner

Reply #132
Version 0.6.8 released properly. LUFS-M and LUFS-S measurements are now performed exactly every 100 ms. Also includes fix for the unmeasured clip counters getting saved to tags.

Re: foo_truepeak True Peak Scanner

Reply #133
Getting blank Clip count in my playlist with this new version. Before it said 0, now it's just blank. Using this string:

%truepeak_scanner_clipped_samples_track%

Re: foo_truepeak True Peak Scanner

Reply #134
Getting blank Clip count in my playlist with this new version. Before it said 0, now it's just blank. Using this string:

%truepeak_scanner_clipped_samples_track%

It works find on my end.  I am using [%truepeak_scanner_clipped_samples_track%].  Brackets don't seem to matter, so not sure why yours would not be working.  Are you writing to your tags? 

Re: foo_truepeak True Peak Scanner

Reply #135
Yes, writing to tags. Tried in Silent Mode and Regular Mode. The Clip count doesn't show up in either, in the playlist or the dialog that pops up after scanning.

Re: foo_truepeak True Peak Scanner

Reply #136
Like I said in the earlier post, you are not using the context command that scans for the clipping information. Historically this component only scanned True Peaks and optionally True Peaks and clipping info + peak positions (that's why there are the different context entries for them). Then feature requests popped up and I didn't want to fill the context menu with all the different modes, so all extra scan modes were toggles in the settings.

If you want the clipping info, you need to use the context command "Scan True Peaks and positions...".

Re: foo_truepeak True Peak Scanner

Reply #137
Yes, thanks Case, it was my brain fart, sorry...

Is there a way to get the "LUFS" text removed from the end of the LUFS scan results/readouts? I just want the number as the LUFS text is already the Column header in my Playlist, and it takes up a lot of unneccesary room.

Re: foo_truepeak True Peak Scanner

Reply #138
You can remove the units on display with $replace function. [$replace(%field%, LUFS,)]


Re: foo_truepeak True Peak Scanner

Reply #140
OK I added it to the end of the LUFS S string like this:

%truepeak_scanner_max_lufs_s% $replace function. [$replace(%field%, LUFS,)]

But the text "LUFS" is still showing after the number in the playlist, see image attached, any ideas?

Re: foo_truepeak True Peak Scanner

Reply #141
OK I added it to the end of the LUFS S string like this:

%truepeak_scanner_max_lufs_s% $replace function. [$replace(%field%, LUFS,)]

But the text "LUFS" is still showing after the number in the playlist, see image attached, any ideas?

Maybe:
[$replace(%truepeak_scanner_max_lufs_s%, LUFS,)]
will work :-)

Re: foo_truepeak True Peak Scanner

Reply #142
It did! Thank you!

Sorry I'm no good with these code thingies, the last time I did anything with code was BASIC in the 80s...

Thanks all, I have it all working exactly how I want it now.

Re: foo_truepeak True Peak Scanner

Reply #143
@Case sorry to bother you again but 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.
Thank you for this (and many other) great component.

 

Re: foo_truepeak True Peak Scanner

Reply #144
@Case

After googling a lot it seems that for LUFS-I positive values and negative values are both used to talk about the same thing.

It seems as if %truepeak_scanner_track_lufs_i% only has negative values.
Is it correct to assume Truepeak Scanner never publishes positive values?

For display purposes I only report positive values.

I want my routine for displaying LUFS-I and PLR as flexible as possible, so when available I use Truepeak tags and otherwise fallback to RG tags.
When %truepeak_scanner_track_lufs_i% exists, I use that value otherwise I calculate it:
Code: [Select]
$puts(keyval_v,[$replace(%truepeak_scanner_track_lufs_i%,-,, LUFS,)])
$if($get(keyval_v),
,
$puts(keyval_p,0)
$puts(keyval_g,[$if2(%truepeak_scanner_track_gain%,%replaygain_track_gain%)])
$if($and($get(keyval_p),$get(keyval_g)),
$puts(keyval_v,$num($add(1800,$replace($get(keyval_p),.,),$replace($get(keyval_g),.,)),3))
$puts(keyval_v,$insert($get(keyval_v),.,$sub($len($get(keyval_v)),2)))
)
)
$get(keyval_v)

Works fine and as far as I can see always gives the same result as the absolute value of %truepeak_scanner_track_lufs_i%.
It also means I can calculate/display LUFS-I if either Truepeak Scanner with/without write RG tags or foobar RG scanner has run.

I use the same function for PLR but in that case I change the first line to:
$puts(keyval_p,[%replaygain_track_peak_db%])

Works fine too.

The issue I'm having is don't see the truepeak equivalent for %replaygain_track_peak_db%. The tag itself is not displayed in Properties.
I know it is available when foobar RG scan has run and also when I use Truepeak scanner with writing RG values enabled. If I use Truepeak without write RG values enabled the tag is not published.

I'd like to be able to calculate PLR even as %replaygain_track_peak_db% is not available. So I would need something like %truepeak_scanner_track_peak_db% or a way to calculate this value based on the already available truepeak tags.

Is there a way to calculate this peak_db value from available truepeak tags?

Re: foo_truepeak True Peak Scanner

Reply #145
@Case

Because scanning with 0.6.8 seemed a lot slower than scanning with 0.6.7 and I was wondering if that was because of the extra LUFS-M/S scanning, I've done some more testing.

I tested version 0.6.7, 0.6.8 with the same scanning options enabled and 0.6.8 with also LUFS-M/S enabled.
Testset is regular FLAC8 44/16 2ch, SACD DST64 2ch&6ch and DVDA MLP 96/24 2ch&ch.

See the attached image.
Scanning with 0.6.8 is as I already suspected quite a bit slower than 0.6.7 and the extra scanning for LUFS-M/S makes no difference in scanning speed at all.
Scanning of normal files is 2x faster and scanning of DVDA is 3x faster in 0.6.7.

Does this make any sense to you?

Re: foo_truepeak True Peak Scanner

Reply #146
After googling a lot it seems that for LUFS-I positive values and negative values are both used to talk about the same thing.
That would be wrong, they are very much different things.

It seems as if %truepeak_scanner_track_lufs_i% only has negative values.
Is it correct to assume Truepeak Scanner never publishes positive values?
For very loud tracks the LUFS-I will be positive. When ReplayGain gain shows -18.00 dB LUFS-I will be exactly 0 LUFS. For louder tracks the LUFS-I will be positive.

I'd like to be able to calculate PLR even as %replaygain_track_peak_db% is not available. So I would need something like %truepeak_scanner_track_peak_db% or a way to calculate this value based on the already available truepeak tags.

Is there a way to calculate this peak_db value from available truepeak tags?
I'm certain there are some titleformat monstrosities posted on these forums that estimate dB value from floating point numbers from the old days. In theory the component could expose a global titleformat string that calculates and exposes this, but I'm not liking the idea at all. It's better to tag things in RG tags and leave hacks out.

Re: foo_truepeak True Peak Scanner

Reply #147
Because scanning with 0.6.8 seemed a lot slower than scanning with 0.6.7 and I was wondering if that was because of the extra LUFS-M/S scanning
[...]
Does this make any sense to you?
LUFS-M / LUFS-S scanning seems to be the reason. I use the libebur128 library for LRA scanning and also for LUFS-M/S. Seems that the extra work required to split the incoming data at precise 100 ms chunks to be fed to the library also hurts LRA scanning speed.

Re: foo_truepeak True Peak Scanner

Reply #148
Because scanning with 0.6.8 seemed a lot slower than scanning with 0.6.7 and I was wondering if that was because of the extra LUFS-M/S scanning
[...]
Does this make any sense to you?
LUFS-M / LUFS-S scanning seems to be the reason. I use the libebur128 library for LRA scanning and also for LUFS-M/S. Seems that the extra work required to split the incoming data at precise 100 ms chunks to be fed to the library also hurts LRA scanning speed.
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?

Re: foo_truepeak True Peak Scanner

Reply #149
This component reports several values.  I am trying to understand what they all mean and how I can use them. I am familiar with RG and DR values, rest is new and trying to learn.  Searching has been hit and miss.  I tried to explain some of what I a using for definitions below.  Ultimately I want to understand how I can apply the values and what are "good" vs "bad" values.  Assistance would be appreciated.  Thanks! 

  • Track and Album Peak- This is the common RG value. Can be used to prevent gain adjustments from inducing clipping in the playback device
  • Track and Album Gain - This is the common RG value in dB.  ReplayGain-capable audio players use the replay gain metadata to automatically attenuate or amplify the signal on a per-track or per-album basis such that tracks or albums play at a similar loudness level
  • Track and Album LRA - Loudness Range in Loudness Units (LU).  Measures the variation of loudness across a song or album.  LRA values can show whether a song has a continuously constant loudness (low LRA values) or a high variation between low and high level components (high LRA values)
  • 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
  • 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?
  • Track and Album DR - The distance in dB between the softest sound and the loudest sound.
  • Track and Album Clipped Samples - Any sample value that is beyond digital fullscale.  One clipping sample means that only one channel clipped. If same spot clipped on all channels of a 384 channel recording, it would be shown as 384 clipped samples.
  • Peak Timestamp - Time in track which contains the highest peak value.