(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.

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?

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

Quote from: darkflame23 on 2024-05-18 18:28:17

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.

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.

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'.

For documentation purposes here are the currently configured tag field names

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?)

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%

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?

$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)

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?

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?

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?

Quote from: Defender on 2024-05-21 14:50:56

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.

• 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.