HydrogenAudio

@Case, I checked your page with x64 plugins (https://foobar.hyv.fi/) and found no Truepeak there. Could you recompile it, please?

The component is obsolete. Native ReplayGain scanner does True Peaks now.

Native one displays Track gain and True peak only,
whereas your component displays valuable extra data:
Peak timestamp and Number of clipping samples.

Okay. Haven't written info page for it yet, but here's a refresh: https://foobar.hyv.fi/foo_truepeak.fb2k-component (https://foobar.hyv.fi/foo_truepeak.fb2k-component). Added dark mode support and 64-bit version.

@Case Thank you, it works on my end.
For some reason, it is slower than the built-in true peak scanner.
And the output differs: built-in 1.274055 +2.10 dBTP vs yours 1.265560 +2.00 dBTP.
Any idea why?

(https://i7.imageban.ru/out/2024/03/12/5b8df7e1d40dc09cea5ed4227591d4d4.png)

(https://i1.imageban.ru/out/2024/03/12/a68632862fcf2ddaa560305086ed47c0.png)

For one it requires a minimum of 192 kHz sample rate. If you are testing with 44.1 kHz source material 4x upsampling would only produce 175.4 kHz. This component would request 5x upsampling.

The component also requests a resampler with highest quality. I'm not 100% certain if foobar still uses that API feature, but if it does it may pick a slower resampler.

And the output differs: built-in 1.274055 +2.10 dBTP vs yours 1.265560 +2.00 dBTP.
Any idea why?

Probably because "true peaks" don't exist in the digital data.   The digital audio only contains actual sample values.    It's fairly-easy (for a computer) to scan through the data to find the highest positive & negative peak values.

"True peak" is an estimate of what's going to happen on the analog side when the samples are replaced by a smooth-filtered continuous wave.  And although integer data can't exceed 0dB, there's no reason that the reconstructed analog can't go over 0dB (without clipping).    But it could be a limitation of some DACs. 

Is it possible to write Peak timestamp and Number of clipping samples to tags? If so how?

For some reason, it is slower than the built-in true peak scanner.
And the output differs: built-in 1.274055 +2.10 dBTP vs yours 1.265560 +2.00 dBTP.
Any idea why?

From Gearspace: Different true peak readings (https://gearspace.com/board/post-production-forum/1045590-different-true-peak-readings.html) (by Alexey Lukin, DSP engineer at iZotope (https://techblog.izotope.com/2015/08/24/true-peak-detection/)): “Different true peak meters may register slightly different values, because BS.1770 standard is not fully prescriptive about this measurement and allows some freedom of implementation”.

From ITU-R BS.1770-5 (https://www.itu.int/dms_pubrec/itu-r/rec/bs/R-REC-BS.1770-5-202311-I!!PDF-E.pdf) aka “Algorithms to measure audio programme loudness and true-peak audio level” (page 18): “Higher sampling rates and over-sampling ratios [than minimum of 4x] are preferred. Incoming signals that are at higher sampling rates require proportionately less over-sampling, e.g. 2x would be sufficient for an incoming signal at 96 kHz”.

Okay, I switched SoX upsampling from x4 to 192 kHz, and it's still faster than this plugin. It would be great if @Peter at least added the number of clipping samples to the native true peak scanner window so that you can understand how much the composition requires the attention of, say, a true peak limiter.

I also saw in my own testing that the higher the sampling rate the closer to analog signal the peaks are. The higher quality resampling one uses to closer to ideal analog conversion the peaks will be, but of course no DAC probably does the conversion in a perfect way.

Also like I said, the component picks an integer multiplier to use when resampling if the rate is below 192 kHz. There's old belief that resamplers in general work better and faster when ratios are full interegers without fractions. So that means 44.1 kHz gets resampled to 220.5 kHz.

You can force this component to use SoX by opening 'Preferences' -> 'Advanced' -> 'Tools' -> 'Automatic resampling preference' and enter "Resampler (SoX)" there. One you do that speed should match ReplayGain scanner.

I also saw in my own testing that the higher the sampling rate the closer to analog signal the peaks are. The higher quality resampling one uses to closer to ideal analog conversion the peaks will be, but of course no DAC probably does the conversion in a perfect way.

Also like I said, the component picks an integer multiplier to use when resampling if the rate is below 192 kHz. There's old belief that resamplers in general work better and faster when ratios are full interegers without fractions. So that means 44.1 kHz gets resampled to 220.5 kHz.

You can force this component to use SoX by opening 'Preferences' -> 'Advanced' -> 'Tools' -> 'Automatic resampling preference' and enter "Resampler (SoX)" there. One you do that speed should match ReplayGain scanner.

Hi @Case,
is it possible to write Peak timestamp and Number of clipping samples to tags from your component? If so how?

You can force this component to use SoX by opening 'Preferences' -> 'Advanced' -> 'Tools' -> 'Automatic resampling preference' and enter "Resampler (SoX)" there. One you do that speed should match ReplayGain scanner.

(https://i1.imageban.ru/out/2024/03/12/a68632862fcf2ddaa560305086ed47c0.png)

^ I've already reported (https://hydrogenaud.io/index.php/topic,107693.msg1041025.html#msg1041025) that this method doesn't work on my end. I set as you told, but see no increase in speed.

Your plugin gives 13x speed with 44100 Hz MP3 files, whereas SoX “upsample to 352800 Hz” (44.1×8) gives 33x. Perhaps the problem is not related to the resampler? True peak calculation algorithm involves other manipulations, says ITU-R BS.1770-5. Can we be sure that Foobar2000's built-in function (that utilizes SoX resampler in my case) works correctly?

(https://i5.imageban.ru/out/2024/03/22/cc7cfa50d74155de2d507d18d45ac951.png)

is it possible to write Peak timestamp and Number of clipping samples to tags from your component? If so how?

It isn't. Of course such feature could be added but I don't really see the point.

Your plugin gives 13x speed with 44100 Hz MP3 files, whereas SoX “upsample to 352800 Hz” (44.1×8) gives 33x. Perhaps the problem is not related to the resampler? True peak calculation algorithm involves other manipulations, says ITU-R BS.1770-5. Can we be sure that Foobar2000's built-in function (that utilizes SoX resampler in my case) works correctly?

Console will tell the name of the resampler that gets used by the component. For example here "Automatic resampling: using Resampler (SoX)". I don't use the mod variants and I have never tried them.

Other than resampling there is the matter of parsing the upsampled audio data and checking for the peaks. It's possible Peter has some highly optimized code here, but I don't see that explaining over 50% performance difference.

I actually see faster speed results for my component than for official ReplayGain scanner. I picked a test 13:08 minutes long MP3 and my component scans it at ~430x realtime and official at ~410x. Even setting quality to normal from best doesn't make official go as fast.

Those steps shown in the quoted summary are unnecessary for foobar2000. That 12.04 dB attenuation makes no sense other than to workaround potential clipping, like what would happen if resampling was done with the often mentioned command line sox-frontend that can't do floats. And low-pass filtering is performed by the resampler service that gets called. Process in foobar2000 is simply resample -> scan -> show results.

@Case, I removed SoX resampler mod and installed your x64 version (https://hydrogenaud.io/index.php/topic,67376.msg1014620.html#msg1014620) instead, then changed “Resampler (SoX) mod” to “Resampler (SoX)” in Foobar2000's advanced options. Now your true peak plugin works way faster (min 33x). Consider adding that resampler to your website (https://foobar.hyv.fi/), because the original author (@lvqcl, I guess) never compiled his x64 version, although I asked about it (https://hydrogenaud.io/index.php/topic,67376.msg1035058.html#msg1035058) 4 months ago. Quite possible that my recent plea to add x8 upsampling (http://because this already happened in 2012) will be ignored too, because this already happened (https://hydrogenaud.io/index.php/topic,67376.msg806436.html#msg806436) in 2012. There is a widespread opinion that SoX is the best resampler for Foobar2000 in terms of quality and speed, but how difficult it is to find it!

As for your true peak plugin:
* Why is the scan speed not displayed during the scan, as in Foobar2000's version?
* It would be nice to be able to shrink the results window and copy the results.

(https://i7.imageban.ru/out/2024/03/22/cdc473fe3f30812ce9766bf7927ec2c9.png)

is it possible to write Peak timestamp and Number of clipping samples to tags from your component? If so how?

I uploaded a new build over the same link (https://foobar.hyv.fi/foo_truepeak.fb2k-component (https://foobar.hyv.fi/foo_truepeak.fb2k-component)) that has an advanced preferences setting to also save the information you asked about.
If you enable the option clipped sample count will be saved in field 'truepeak_scanner_clipped_samples' and peak timestamp in 'truepeak_scanner_peak_position'.

Now your true peak plugin works way faster (min 33x). Consider adding that resampler to your website (https://foobar.hyv.fi/), because the original author (@lvqcl, I guess) never compiled his x64 version

Good to hear you got better speed results. Though would be curious to know what caused the big difference earlier. Is there some name mismatch preventing it from getting picked?
It doesn't feel right to upload components of others if they are still alive and active. Also my 64-bit conversion was done hastily, lvqcl will be able to squeeze more speed out of it without having to resort to shortcuts with data handling.

* Why is the scan speed not displayed during the scan, as in Foobar2000's version?
* It would be nice to be able to shrink the results window and copy the results.

I'm not as good at UIs as Peter and for me it's enough to know the speed at the end.

Shrinking enabled. I could not find with quick googling what I'd need to do to handle copying the data from the dialog and the UI helpers from foobar2000 don't seem to support that on their own. Even native ReplayGain dialog doesn't have means to copy the texts from it. Once the SDK has done all the difficult work to support that, I can add it. Or perhaps marc2k3 links to some document I have missed and I can add it sooner.

Quote from: wojak on 2024-03-22 07:36:29

is it possible to write Peak timestamp and Number of clipping samples to tags from your component? If so how?

I uploaded a new build over the same link (https://foobar.hyv.fi/foo_truepeak.fb2k-component (https://foobar.hyv.fi/foo_truepeak.fb2k-component)) that has an advanced preferences setting to also save the information you asked about.
If you enable the option clipped sample count will be saved in field 'truepeak_scanner_clipped_samples' and peak timestamp in 'truepeak_scanner_peak_position'.

Thank you very much!!!

I could not find with quick googling what I'd need to do to handle copying the data from the dialog and the UI helpers from foobar2000 don't seem to support that on their own. Even native ReplayGain dialog doesn't have means to copy the texts from it. Once the SDK has done all the difficult work to support that, I can add it.

At least foo_verifier results dialog has option to export to txt file.

Quote from: wojak on 2024-03-22 07:36:29

is it possible to write Peak timestamp and Number of clipping samples to tags from your component? If so how?

I uploaded a new build over the same link (https://foobar.hyv.fi/foo_truepeak.fb2k-component (https://foobar.hyv.fi/foo_truepeak.fb2k-component)) that has an advanced preferences setting to also save the information you asked about.
If you enable the option clipped sample count will be saved in field 'truepeak_scanner_clipped_samples' and peak timestamp in 'truepeak_scanner_peak_position'.

Hi, could you please explain what do "samples" mean in your measurement in comparison to time. Is one sample equal to sampling-rate of the file (ex. 44,1kHz or 96kHz) or is this "frame" (75 per second) or is this 1/588 of the frame?
PS. Forgive me if I am wrong but I read somewhere that each second cosnists of 75 frames and each frame consists of 588 samples. I do not know if this is true.

Returning to my question: If your component says that the file has 1 clip, how does that relate to real-time music. Is it 1/44,1k of a sesond or something else?

At least foo_verifier results dialog has option to export to txt file.

Adding export would be straightforward, it doesn't need GUI knowledge. I understood Kraeved would like to be able to just select the interesting lines and use ctrl+c to copy the info and paste anywhere, like into Excel.

could you please explain what do "samples" mean in your measurement in comparison to time. Is one sample equal to sampling-rate of the file (ex. 44,1kHz or 96kHz) or is this "frame" (75 per second) or is this 1/588 of the frame?

Samples are the data points the audio is made of. In your example case for 44.1 kHz audio there are 44100 samples per channel in each second. For a typical stereo audio there are in total 88200 samples for every second. The frames you speak about have no relation here, you are thinking about audio CD structure. On an audio CD the data is contained in sectors (also called frames). There are 75 sectors per second and audio CD uses 44100 Hz sampling rate, that means there are 588 samples (per channel) in each sector on the CD (44100/75 = 588).

Note that there are different uses of these terms. When foobar2000 talks about samples (for example in track duration) it means a group of samples containing each channel. A one second long track at 44100 Hz sampling rate would be shown to contain 44100 samples by foobar2000 regardless of how many channels the track has. I prefer to use term 'frame' for this as it makes it clear one isn't talking about individual samples.

Returning to my question: If your component says that the file has 1 clip, how does that relate to real-time music. Is it 1/44,1k of a sesond or something else?

It's not a rate. It is absolute value. If your file has 1 clipping sample it means it has a single peak above digital fullscale and only on one channel.

@Case

Thanks for this tool.

Can you make a small adjustment in the "Scan true-peaks and positions (as albums)" so that it writes the total amount of clipped samples found in tracks in a field like TRUEPEAK_SCANNER_CLIPPED_SAMPLES_ALBUM?

I'd like to be able to show this value in the group header per album.

New version uploaded to https://foobar.hyv.fi/?view=foo_truepeak (https://foobar.hyv.fi/?view=foo_truepeak) with some improvements and this feature implemented.

For some reason, the native RG scanner and this plugin store values in different places. Why? Is it a feature or a bug?

Native.
(https://i6.imageban.ru/out/2024/03/30/fc16ecaac7d989330cc2b65644de399d.png)

Plugin.
(https://i5.imageban.ru/out/2024/03/30/d2de0517979dd775abe9647039105a34.png)

This component predates native RG scanner's True Peak ability by about a year. At the time of creation I wasn't certain what the best course of action should be so I played it safe and prevented overwriting of existing RG values.

The component has an option to save the info in the proper ReplayGain fields. But you need to manually enable it under Preferences -> Advanced -> Tools -> True Peak Scanner.

New version uploaded to https://foobar.hyv.fi/?view=foo_truepeak (https://foobar.hyv.fi/?view=foo_truepeak) with some improvements and this feature implemented.

Thank you very much. I will write some code that will present the total amount of clipping (samples converted to seconds) in the album headers.

If you have the time could you also add a context menu option to remove all truepeak scanner information from selected tracks, similar to the option in the context menu to remove all replaygain information for selected tracks?

I also noticed the following. If you set the advanced option to write both custom and replaygain fields, the replaygain fields are written only when they were empty.
So if there was already replaygain information (scanned by the replaygainscanner), your tool does not overwrite these fields. Your tool however does not write the replaygain gain values.
Which means you need to run the replaygain scanner afterwards. The replaygainscanner however overwrites the peak values that were previously scanned and inserted by your truepeakscanner.

I play files in foobar with replaygain set to track and "apply gain and prevent clipping according to peak".

As a result of the behavior of the replaygain scanner and the truepeak scanner foobar will never use the truepeakscanner peak values for playback.

Solution could be that the truepeakscanner also writes the gain values (or replaygainscanner does not overwrite peak values if they already exist).

What are your thoughts about the above?

PS. There's also a side effect for Regor's LUFS and PLR scanner, but I will address that in the Playlist-Tools-SMP thread.

Did you see tag overwrite issue with the latest 0.5.2 version? The tag update should only by skipped if all the tag information that would be written already perfectly matches what is in the files.

About the tag removal, I can add that. I think it should not touch the standard ReplayGain fields even when configured to write those. I hope you agree.

Did you see tag overwrite issue with the latest 0.5.2 version? The tag update should only by skipped if all the tag information that would be written already perfectly matches what is in the files.

About the tag removal, I can add that. I think it should not touch the standard ReplayGain fields even when configured to write those. I hope you agree.

I do agree with your tag removal approach. Only remove the custom fields.

I've been testing a bit (lot) more and I cannot reproduce the situation that your scanner does not correctly overwrite the Replaygain peak values. But I'm sure that was the case during my initial testing. And no the tag information did not have the correct information before. Must have been a freak incident,
Anyway, nevermind. It's perfect.

The only thing that is a bit of a nuisance is that you have to run the replayscanner first (to get the gain value) and then the truepeakscanner to get the correct peak info. Running the Relpayscanner afterwards to get the gain value overwrites your correct truepeak value.

Would it be much trouble to update your scanner so that it also writes the replaygain gain value?
That would mean you only have to run your scanner and don't have to run replaygainscanner (prior) anymore.

EDIT: If you decide to also write the Replaygain gain value, please also the album value. Also probably best to do custom fields as well. Makes it easy to determine if foobar is playing with old style replaygain or updated truepeak values.

Just to confirm, you do know that foobar's ReplayGain scanner can do True Peak scanning too since 2015? It's just not enabled by default.
I had considered my component obsolete until people mentioned they like the clip count and peak position info.

Edit: the tag saving was bugged in some earlier versions. The filter to check if tag writing is needed didn't check all fields.

Just to confirm, you do know that foobar's ReplayGain scanner can do True Peak scanning too since 2015? It's just not enabled by default.
I had considered my component obsolete until people mentioned they like the clip count and peak position info.

Yes, I had it set to auto-2x for ages. During testing I tested with auto-8x, dbpoweramp and RetroArch. The values for the different settings are different from your tool.

I don't have a clue what is the best value. Your tool or one of the True peak scan options of Replaygain.

I do know that I have been looking for a tool to more or less quantify the quality of albums and their respective remasters. The more I looked/read into that the more confused I became :-). So the amount of clipping per track/album is really helpful. For that I can use your scanner.

And since I want to run your tool from now on for every album, I'd rather have a tool that also corrects the Replaygain fields.

BTW. You mention a button in your release notes. Out of curiosity ... where is this button? I only see the context menu which does not have an export function. Is there a panel/toolbar I'm missing?

Quote from: Case on 2024-03-30 18:20:46

Just to confirm, you do know that foobar's ReplayGain scanner can do True Peak scanning too since 2015? It's just not enabled by default.
I had considered my component obsolete until people mentioned they like the clip count and peak position info.

Yes, I had it set to auto-2x for ages. During testing I tested with auto-8x, dbpoweramp and RetroArch. The values for the different settings are different from your tool.

I don't have a clue what is the best value. Your tool or one of the True peak scan options of Replaygain.

I do know that I have been looking for a tool to more or less quantify the quality of albums and their respective remasters. The more I looked/read into that the more confused I became :-). So the amount of clipping per track/album is really helpful. For that I can use your scanner.

And since I want to run your tool from now on for every album, I'd rather have a tool that also corrects the Replaygain fields.

BTW. You mention a button in your release notes. Out of curiosity ... where is this button? I only see the context menu which does not have an export function. Is there a panel/toolbar I'm missing?

Please do not make your component overwrite RG. I like it as it is. I use RG to scan for RG and TruePeak and I run your component for Clips and Timestamps. Let it be that way.

Quote from: Defender on 2024-03-30 18:37:03

Quote from: Case on 2024-03-30 18:20:46

Just to confirm, you do know that foobar's ReplayGain scanner can do True Peak scanning too since 2015? It's just not enabled by default.
I had considered my component obsolete until people mentioned they like the clip count and peak position info.

Yes, I had it set to auto-2x for ages. During testing I tested with auto-8x, dbpoweramp and RetroArch. The values for the different settings are different from your tool.

I don't have a clue what is the best value. Your tool or one of the True peak scan options of Replaygain.

I do know that I have been looking for a tool to more or less quantify the quality of albums and their respective remasters. The more I looked/read into that the more confused I became :-). So the amount of clipping per track/album is really helpful. For that I can use your scanner.

And since I want to run your tool from now on for every album, I'd rather have a tool that also corrects the Replaygain fields.

BTW. You mention a button in your release notes. Out of curiosity ... where is this button? I only see the context menu which does not have an export function. Is there a panel/toolbar I'm missing?

Please do not make your component overwrite RG. I like it as it is. I use RG to scan for RG and TruePeak and I run your component for Clips and Timestamps. Let it be that way.

It's optional to overwrite ReplayGain values ...

Uploaded a new version with requested features implemented. ReplayGain scanning can be turned on in the advanced preferences, it's disabled by default.
There is now also a context menu command to remove all custom True Peak metadata from tracks.

BTW. You mention a button in your release notes. Out of curiosity ... where is this button? I only see the context menu which does not have an export function. Is there a panel/toolbar I'm missing?

There is a 'Copy' button in the result dialog between the 'Update File Tags' and 'Cancel' buttons. That copies all the information to clipboard and can be pasted to notepad or Excel.

Please do not make your component overwrite RG. I like it as it is. I use RG to scan for RG and TruePeak and I run your component for Clips and Timestamps. Let it be that way.

As @Defender said, default behavior is unchanged. This is just an optional additional feature that can be helpful.

@Case

I noticed that foobar reports the same number of total samples for the same track regardless of the number of channels.
Is it correct to assume you report clipped samples as 1 extra clipped sample even if more channels clip in the same sample?

@All

In order to have a value I can use to compare between albums and has a value that makes a bit of sense I calculate how many seconds the audio is clipped per hour.
The result is displayed with three digits (for instance 0.365s or 32.345s). I colorcode the resulting value.

I now use:
> 20 sec. RED
> 10 sec. ORANGE
> 1  sec. YELLOW
otherwise GREEN

What would be a reasonable colorcode in your opinion?

Values vary a lot between albums. A weird one is the Porcupine DVDA. The 6ch mix has 18x more clipping (still not a lot though) than the 2ch mix both on the same DVDA.
Also converting a flac to mp3 introduces extra clipping.

I noticed that foobar reports the same number of total samples for the same track regardless of the number of channels.
Is it correct to assume you report clipped samples as 1 extra clipped sample even if more channels clip in the same sample?

If I understood your question correctly, no, I don't report extra clipped samples.
In foobar2000 terminology "a sample" actually contains the samples from all channels. I consider "a sample" to be a sample value of a single channel.
So one clipping sample means that only one channel clipped. If same spot clipped on all channels of a 384 (https://github.com/dbry/WavPack/issues/117) channel recording, it would be shown as 384 clipped samples.

One potential improvement would be to show separate clip count for each channel.

For your time calculations the current way causes inaccuracy because there is no distinction if the clipping happened at the same time or at different time positions.

In order to have a value I can use to compare between albums and has a value that makes a bit of sense I calculate how many seconds the audio is clipped per hour.
The result is displayed with three digits (for instance 0.365s or 32.345s). I colorcode the resulting value.

I now use:
> 20 sec. RED
> 10 sec. ORANGE
> 1  sec. YELLOW
otherwise GREEN

What would be a reasonable colorcode in your opinion?

Interesting concept. For correctness and clearness just using seconds as the unit is not correct or clear. Something like 's/h' would be more correct and also clearer that it's relative to length and not absolute clipping amount. A percentage % would perhaps be better.

I think ideally the limits you use for the colors would be based on what sounds annoying or to statistics so only rarest cases go red.

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.

Values vary a lot between albums. A weird one is the Porcupine DVDA. The 6ch mix has 18x more clipping (still not a lot though) than the 2ch mix both on the same DVDA.
Also converting a flac to mp3 introduces extra clipping.

Lossy encoding changes the waveform and almost always causes peaks to go higher. There are scientific explanations for this and it's expected behavior.

So one clipping sample means that only one channel clipped. If same spot clipped on all channels of a 384 (https://github.com/dbry/WavPack/issues/117) channel recording, it would be shown as 384 clipped samples.

I suspect a lot of times both channels clip at the same time. Which means the value I calculate now is inflated up to a factor 2.
Multichannel audio I guess  probably doesn't make a big difference. Pretty much always waveseekbar shows (and my ears hear) way lower levels for Side, Back and Center channel.

For your time calculations the current way causes inaccuracy because there is no distinction if the clipping happened at the same time or at different time positions.

I understand. The value you write is the only thing I have available to work with.

For correctness and clearness just using seconds as the unit is not correct or clear. Something like 's/h' would be more correct and also clearer that it's relative to length and not absolute clipping amount. A percentage % would perhaps be better.

I think ideally the limits you use for the colors would be based on what sounds annoying or to statistics so only rarest cases go red.

With s/h you mean samples per hour? Point is that I also wanted to normalize result so that the samplerate is out of the way. The values that are calculated are in most cases extremely small which makes it very hard to see in one glance what the audiotrack is doing clipping wise. Therefore I recalculated to 1 hour. At least you don't have to count 0's after the decimal point. Percentage is also way to small, maybe promillage would work a bit better.

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.

Yes. These kind of key indicators only need to determined once. The most logical time/place to analyze, create and publish the resulting values is during the initial scanning.

What I'm trying to achieve is just to have a first indicator that is presented in the group headers that roughly gives me an idea about clipping and dynamic range. Especially if I'm checking different versions of the same album. It does not have to be perfect/exact.
In the end of course you have to listen to (preferably only some of) the tracks themselves.

I'm writing this particular code in ELP. As such I only have access to tags and some internal %el_*% variables. If there is no album version of a tag, there's no way to reconstruct that info from the individual tracks.

Anyway, I finished writing the framework. It is very colorful :-) Would help if I knew how to interpret clipping, LRA, LUFS, PLRA and DR. And maybe populate this framework with values that actually makes sense.

Hi @Case,

could you please explain why does your component measure a little differnt than the built in RG? The results differ by about 0,1/0,2.
Is there a different standard or by design those calculations are not precise (guesstimation)?

Plus what exactly Clippings measured in your component mean? Are they embedded clippings in the signal (they are there because they were introduced during the recording/mixing/mastering), which would probably mean we can not do anything with them without altering the material? Or are they hypothetical clips that might occur in the DAC? Or something different?
Then how does RG applying work. If we measure RG, Clips, True Peaks and use Album mode we can then use 4 options:
- none - obvious
- apply gain
- apply gain and prevent clipping from peak value
- prevent clipping from peak value
What does apply gain really mean - does it just turns the volume up or down (usually waaay down)? If we use prevent from clipping does it change the volume but to a degree not to produce clippings so for example it would turn the volume up by 3 but then it would clipp so it turns up by ex. 2 not to clip? Or does it turn up by 3 and compress the peaks?
Does the "prevent clipping" option (without applying gain) mean that if there are 0 clippings on the album it would do nothing but if there were clippings it would turn the volume of the album as much as needed to avoid clipping? In album mode would it do exactly the same amount in every track?

Putting classical music aside and speaking about por/rock/jazz... music. All the records (even those from original '80 CDs) are too loud (judged by RG) (even SADE or Dire Straits records or other "audiophile recordings") so the RG never (or very rarely) would make the albums louder and almost always would make it quieter. Seemingly too quiet so one would have to turn the volume knob on the amp which could hypothetically produce a hiss. So now what would be the best way to make it louder. I use USB-ASIO DAC with foobar and DAC volume at max level so I change the volume with a manual knob othe amplifier. Would it be better to use foobars built-in Preamp (the one below RG section in the preferences) or might that produce Clips?
I never used RG but when first used your component (a few days ago) to find clips I started to think how to get rid of them and for now I use the "prevent clippings" option but as you see from this post I do not fully (or at all:))) understand what exactly do all those options do.
So to sum it up - is applying RG an equivalent of just turning the volume knob on amp up/down or does it do something else? Is "prevent clipping" option just a one-direction option of RG (it would do nothing when no clippings or turn down if clipping). If it turns down - how - first look at "album peak" and turn the whole album as needed or differently?
What is the best way to control the volume nowadays (with 64bit foobar, 32bit DAC and analogue amp)?
Please excuse my ignorance and so many questions but they relate to one topic (I think).

With s/h you mean samples per hour? Point is that I also wanted to normalize result so that the samplerate is out of the way.

I meant just correcting the unit. If an info panel somewhere says there is "1 s" of clipping it would be interpreted as absolute value for the track (or album) in question. Saying that there is 1 second of clipping per hour would be correct way to inform about the situation. The meaning of 's' in my example remained the same: seconds.

Quote from: Defender on 2024-04-01 18:17:35

With s/h you mean samples per hour? Point is that I also wanted to normalize result so that the samplerate is out of the way.

I meant just correcting the unit. If an info panel somewhere says there is "1 s" of clipping it would be interpreted as absolute value for the track (or album) in question. Saying that there is 1 second of clipping per hour would be correct way to inform about the situation. The meaning of 's' in my example remained the same: seconds.

Aaah, that's exactly what I'm doing. I display CH 3.905s. Clipping per hour is 3.905 seconds. Screenspace is valuable though in a horizontal grid. Although this value is not correct since a single sample as you explained can produce as many clipping samples as there are channels.

could you please explain why does your component measure a little differnt than the built in RG? The results differ by about 0,1/0,2.
Is there a different standard or by design those calculations are not precise (guesstimation)?

Native ReplayGain scanner doesn't follow any standard. It just offers an option to upsample using a resampler and settings of your choosing.

True Peak values depend entirely on the used resampling method. If you configure the built-in scanner to do the same resampling operation, the results are 100% identical.

My scanner was made to follow ITU-R BS.1770-3 recommendation. They state that for determining True Peaks a sampling rate of at least 192 kHz should be used. But higher the sampling rate the better. As I have said elsewhere, my component doesn't just resample to 192 kHz. It picks the lowest integer multiplier that reaches at least 192 kHz sampling rate. For a typical 44.1 kHz audio that means 4 x upsampling isn't enough, 5 x is needed.

Plus what exactly Clippings measured in your component mean?

Any sample value that is beyond digital fullscale.

Then how does RG applying work. If we measure RG, Clips, True Peaks and use Album mode we can then use 4 options:
- none - obvious
- apply gain
- apply gain and prevent clipping from peak value
- prevent clipping from peak value
What does apply gain really mean - does it just turns the volume up or down (usually waaay down)?

It means same as volume adjustment. It adjusts the playback level so that each track or each album have identical loudness and listener doesn't have to touch volume settings.

If we use prevent from clipping does it change the volume but to a degree not to produce clippings so for example it would turn the volume up by 3 but then it would clipp so it turns up by ex. 2 not to clip?

The 'apply gain and prevent clipping from peak value' adjusts the level but if the peak value tells things would clip, the level is lowered just enough to keep the peaks inside digital fullscale. In track mode this adjustment is done for each track, in album mode all tracks are adjusted by the same decibel amount as much as is needed to prevent the track with highest peak from clipping.

Does the "prevent clipping" option (without applying gain) mean that if there are 0 clippings on the album it would do nothing but if there were clippings it would turn the volume of the album as much as needed to avoid clipping? In album mode would it do exactly the same amount in every track?

It works exactly like that. If the peaks are below full scale the signal is not touched at all. If the peaks are too high, the level is adjusted. In track mode each track is adjusted separately, in album mode the entire album is adjusted by the same amount.

So now what would be the best way to make it louder. I use USB-ASIO DAC with foobar and DAC volume at max level so I change the volume with a manual knob othe amplifier. Would it be better to use foobars built-in Preamp (the one below RG section in the preferences) or might that produce Clips?

I don't think you need to worry about hiss. Keeping DAC and Windows volumes at maximum will ensure highest signal to noise ratio to the amp, which is of course good. For ReplayGain to work it needs the headroom for the louder material, so it would be best if you didn't try to fight it. But using the preamp slider in foobar2000 is the correct way to increase the loudness of ReplayGained output. Increasing the preamp will of course make clipping more likely, but as long as it's lower than the negative gain values shown for your tracks/albums, it won't introduce any additional clipping.

So to sum it up - is applying RG an equivalent of just turning the volume knob on amp up/down or does it do something else?

It works like volume knob but since it's done before the DAC it can prevent clipping of intersample peaks or floating point material that would clip in the DAC.

I'll attach an old test file that you can use to test and demonstrate the effect of intersample clipping in your DAC. If you play that file unaltered through your DAC at max volume you will hear distortions if the DAC clips. Lowering the volume will let you hear how it should sound without clipping. I have seen some super high end DACs sold that claim they have 3 dB headroom against intersample clipping. This goes beyond that so I don't think there is a DAC that can handle this without help from computer.

@Case

I noticed you write per album clipped sample totals based on discnumber.
For me that doesn't work. I consider albums being in the same folder (and having the same %album%).

I present multicd albums grouped like the picture. which means the total running time is the total of all cd's the album consists of.
I base the clipping rate based on the amount of clipped samples, but that is the value for the first cd only.

So in this case I have individual tracks with bad clipping while the albumrating is ok'ish. It should be twice worse.

The very first option in the component's preferences is the titleformat string that defines how albums are grouped. Remove the discnumber bit if you wish to ignore it.

The very first option in the component's preferences is the titleformat string that defines how albums are grouped. Remove the discnumber bit if you wish to ignore it.

Ah, bit thrown off since regular context replaygain has separate option for folder.

EDIT: That was a quick fix

Would it be possible to make the menu entry which deletes tags always visible, and only grayed out if there are no tags? (exactly like the replaygain entry)

It helps with scripting, since the entry would always be available (even if disabled).

Scripts don't care about menu items being visible or not. The command will return false if not found but who is checking return values?

Me xd and that's why I request it. But anyway, I also think UX is improved with a menu entry always visible and being grayed if not available, since the context menu entries are already integrated on the native replay gain menu anyway... so one would expect similar behavior too.

Back in the day context commands that weren't applicable were hidden. That's still how my main foobar2000 install that has never been nuked still behaves. But I see that a more fresh install grays out the commands. I can change that.

Been playing around with the beta. It's excellent.

I kinda use this tool to validate the quality of the replaygain values that are being used upon playing a file.
The main drawback of the fields that are written by the replaygainscanner that they don't tell you anything about the settings of the replaygainscanner that were current upon writing these values.

Therefore this tool is most welcome. To validate the quality of the settings of replaygain that will be used upon playing I check if your custom fields have the same value. If so I change display in my scan from RG to TG. Quite simple.

The issue I have is that the names of the fields you write are non-mandatory and can be set by the user. I'm developing a skin and I have no way of knowing what the user has set for custom tag field names.

So I'm requesting to make these tagnames non-optional. I don't care if they start with truepeak or all end with truepeak, but the names should be fixed in order for a skin to work.

Usage and writing of these fields will still be optional, but if you use them the tagnames are fixed.

Same for clip count and peak position fields.
And if I may make a suggestion. Start all custom field tags with TruePeak to differentiate more easily from the actual replaygain tags.

Forcing everybody to lose functionality and have specific tags just for your skin doesn't really make sense... Just share the config files if you want to force specific settings or write a readme.

Forcing everybody to lose functionality and have specific tags just for your skin doesn't really make sense... Just share the config files if you want to force specific settings or write a readme.

?

The beta that writes the gain values was just released this afternoon. Don't think many people already made adjustments for the new fields.

I hope that as a minimum the tags truepeak_scanner_album_gain and truepeak_scanner_track_gain that were introduced in the beta get the same name convention upon installation as the earlier replaygain_album_true_peak and replaygain_track_true_peak from the non beta.

Would you like tags like album, title or replaygain_album_peak to be user configurable?

Your question doesn't address you are asking a developer to remove already existing functionality just for you. Again, if you share a skin, share the config files with it with your desired tags conventions. Like everyone else does. Georgia skin shares the entire profile folder and works fine for thousands of people.

Whatever I do with my tag names is my problem, the same like you. And that's my point. Your "problem" doesn't have higher priority than everyone else, specially when tags are already configurable for a reason (since the plugin allows to replace replaygain). This is like saying TF expressions should be removed from foobar, because your skin populates the Album list panel by path xd makes zero sense.

Now, suggesting changing the default tag names, that's another thing.

This is just my opinion. Don't expect people to agree with it or not.

Everybody can choose to use a component or not.
But is you decide to use a component/plugin/whatever and it results in writing tags tag naming should be standardized. Just use the name in the component as part of the tagname and that's it. No confusion.

I'm using Regor's formulas for LUFS and PLR and I'm NOT changing anything in that code. Same for the color coding Regor is using.

The main reason I asked to add gain scanning to TruePeak scanner is because the Replaygainscanner of foobar writes STANDARDIZED tags with values that are based on settings of the replaygainscanner and thus variable. The replaygainscanner does not write a tag with what settings were used. I want something that has a verified quality. If the quality is shit, so be it, but at least I know it's comparable to the values in other tracks. Apples and apples, please.

Your question doesn't address you are asking a developer to remove already existing functionality just for you. Again, if you share a skin, share the config files with it with your desired tags conventions. Like everyone else does. Georgia skin shares the entire profile folder and works fine for thousands of people.

Whatever I do with my tag names is my problem, the same like you. And that's my point. Your "problem" doesn't have higher priority than everyone else, specially when tags are already configurable for a reason (since the plugin allows to replace replaygain). This is like saying TF expressions should be removed from foobar, because your skin populates the Album list panel by path xd makes zero sense.

Now, suggesting changing the default tag names, that's another thing.

Fine. We disagree. My request for change was addressed to Case to consider tag naming (since it's beta) not to you.

Fine. We disagree. My request for change was addressed to Case not to you.

And that's perfectly fine. And as another user using this plugin, I also give feedback to Case to not remove existing functionality for no reason xd Changing tag names? Great. Removing entirely the possibility to change tag names? Nope.

All your "problems" are gone if you share the plugin config files with your skin. Set your tags as you like, and share the config file. Profit.

You seem to ignore that part  ::) If you don't want to share a skin in a proper way, ok... but then don't convert your problem in everyone's problem.

Quote from: Defender on 2024-04-05 01:15:26

Fine. We disagree. My request for change was addressed to Case not to you.

And that's perfectly fine. And as another user using this plugin, I also give feedback to Case to not remove existing functionality for no reason xd Changing tag names? Great. Removing entirely the possibility to change tag names? Nope.

All your "problems" are gone if you share the plugin config files with your skin. Set your tags as you like, and share the config file. Profit.

You seem to ignore that part  ::) If you don't want to share a skin in a proper way, ok... but then don't convert your problem in everyone's problem.

There is no problem :-) I just ask to change a little thing that is still in beta.

Me xd and that's why I request it.

JS aside, it's a perfectly fine feature request and I can see it has been added.

But scripting components are using buggy code inherited from WSH panel mod. Right now, they don't check menu flags so they return true for disabled items simply because they exist, not because you can run them or not.

They really should return false and I've just updated JSP3 to do this...

https://github.com/jscript-panel/FB2K/commit/3350f5b8a66aaeb08085b8cec97e669b0c742d39

For curious browsers, only portions of JSP3 are open source. You can't get anywhere close to compiling it.

I kinda use this tool to validate the quality of the replaygain values that are being used upon playing a file.
The main drawback of the fields that are written by the replaygainscanner that they don't tell you anything about the settings of the replaygainscanner that were current upon writing these values.

The original ReplayGain author actually suggested storing the used calculation method in a tag already over 20 years ago, but it never got wide (or any) adoption. If I can find the suggestion or if there is an existing tag, I could add this to my tool.

The issue I have is that the names of the fields you write are non-mandatory and can be set by the user. I'm developing a skin and I have no way of knowing what the user has set for custom tag field names.

The field names are configurable because there is no standard for them. If there are other tools that do the same I would love to use the same names. Interoperability is important. But if there is no standard or widespread naming convention for something, I don't want to force a potentially silly name.

I'm not skinning expert but if you wish to use non-standard fields, I would make it super easy for users to customize them.

Same for clip count and peak position fields.
And if I may make a suggestion. Start all custom field tags with TruePeak to differentiate more easily from the actual replaygain tags.

You do realize that this component is 10 years old and the default True Peak field names have been "replaygain_track_true_peak" and "replaygain_album_true_peak" all this time? I can't change them lightly.
Also if I change the LRA tag fields to start with "truepeak" that means there is zero chance they have any interoperability with any other tool.

The beta that writes the gain values was just released this afternoon. Don't think many people already made adjustments for the new fields.

The gain values are quite new but they were added for a version released on Sunday, it's not a beta version. This test version added the Loudness Range tags.

I hope that as a minimum the tags truepeak_scanner_album_gain and truepeak_scanner_track_gain that were introduced in the beta get the same name convention upon installation as the earlier replaygain_album_true_peak and replaygain_track_true_peak from the non beta.

Now I'm confused. Earlier you wanted custom tags to start with "truepeak", now you want fields to resemble existing replaygain tags?

Would you like tags like album, title or replaygain_album_peak to be user configurable?

ReplayGain is a standard. That is a different scenario.

Talking about tag names, I would like to change the default "truepeak_scanner_clipped_samples" field to include indicator that it's for a track now that I was asked to add another field for album. With current naming convention the tag should obviously be called "truepeak_scanner_clipped_samples_track".
I'm open to suggestions to all default tag names.

I did some digging and I noticed that the so called ReplayGain 2.0 specification (https://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification) mentions field names "replaygain_track_range" and "replaygain_album_range" as being used by some tools to store LRA. If that's the case I would like to use the same fields, in which case configuration of LRA tag field names can be removed.

The field names are configurable because there is no standard for them. If there are other tools that do the same I would love to use the same names. Interoperability is important. But if there is no standard or widespread naming convention for something, I don't want to force a potentially silly name.

I'm not skinning expert but if you wish to use non-standard fields, I would make it super easy for users to customize them.

Skins based on CUI Panel Splitters and ELP have very limited options for user configurability. In ELP I have a kind of workaround to achieve this, but in PSS it is impossible, which means I have to use $if3(tag,synonym1,synonym2,etc) and add every new tagname for the same thing to the code. I do use a central routine which sanitizes tags like artist, trackartist, albumartist (because tagging is often a mess) and I only use these sanitized tags in the rest of the code. So if I have to I will add the if3's to that routine and create sanitized tags for all user configurable truepeak tags to use in the rest of the code.

You do realize that this component is 10 years old

Nope. Search in this forum has never worked for me which is quite a nuisance because I'm pretty sure I'm asking things that have been asked a million times before.

The gain values are quite new but they were added for a version released on Sunday, it's not a beta version.

Same thing. I did not know. It's not in browse components. Best site I find to follow to check for updates is an external Japanese url.

Now I'm confused. Earlier you wanted custom tags to start with "truepeak", now you want fields to resemble existing replaygain tags?

It is simple. In a perfect world I would like all the tags that are custom to this component to have tagnames starting with truepeak. If you have reasons to not do this, fine. If that is the case and you introduce similar fields for gain then follow the naming convention for the earlier fields. I asked, nothing more than that too it. I just like things to be consistent and standardized. And I'm certainly not a fan of optional tagnames for reasons I think I explained. That said ... If tagnames are optional I will never change the default they come with upon installation, because most people probably won't change them so chances are best to write your code based on this defaults.

Talking about tag names, I would like to change the default "truepeak_scanner_clipped_samples" field to include indicator that it's for a track now that I was asked to add another field for album. With current naming convention the tag should obviously be called "truepeak_scanner_clipped_samples_track".
I'm open to suggestions to all default tag names.

"replaygain_track_range" and "replaygain_album_range" as being used by some tools to store LRA. If that's the case I would like to use the same fields, in which case configuration of LRA tag field names can be removed.

It's consistent, so I'm all for it. And I personally don't mind if you would change tagnames for relatively new fields now. I read these tags  only once in a central routine and the required rescanning to write these renamed tags is fast as well (since I don't want to introduce the dreaded if3's lightly).
The nature of a forum is unfortunately that there's always people that are going to object for valid or obscure reasons.
I like you're open to suggestions, but it is your tool and not a democracy, you decide, I'll follow.

Quote from: Case on 2024-04-05 10:39:22

The field names are configurable because there is no standard for them. If there are other tools that do the same I would love to use the same names. Interoperability is important. But if there is no standard or widespread naming convention for something, I don't want to force a potentially silly name.

I'm not skinning expert but if you wish to use non-standard fields, I would make it super easy for users to customize them.

Skins based on CUI Panel Splitters and ELP have very limited options for user configurability. In ELP I have a kind of workaround to achieve this, but in PSS it is impossible, which means I have to use $if3(tag,synonym1,synonym2,etc) and add every new tagname for the same thing to the code. I do use a central routine which sanitizes tags like artist, trackartist, albumartist (because tagging is often a mess) and I only use these sanitized tags in the rest of the code. So if I have to I will add the if3's to that routine and create sanitized tags for all user configurable truepeak tags to use in the rest of the code.

Quote from: Case on 2024-04-05 10:39:22

You do realize that this component is 10 years old

Nope. Search in this forum has never worked for me which is quite a nuisance because I'm pretty sure I'm asking things that have been asked a million times before.

Quote from: Case on 2024-04-05 10:39:22

The gain values are quite new but they were added for a version released on Sunday, it's not a beta version.

Same thing. I did not know. It's not in browse components. Best site I find to follow to check for updates is an external Japanese url.

Quote from: Case on 2024-04-05 10:39:22

Now I'm confused. Earlier you wanted custom tags to start with "truepeak", now you want fields to resemble existing replaygain tags?

It is simple. In a perfect world I would like all the tags that are custom to this component to have tagnames starting with truepeak. If you have reasons to not do this, fine. If that is the case and you introduce similar fields for gain then follow the naming convention for the earlier fields. I asked, nothing more than that too it. I just like things to be consistent and standardized. And I'm certainly not a fan of optional tagnames for reasons I think I explained. That said ... If tagnames are optional I will never change the default they come with upon installation, because most people probably won't change them so chances are best to write your code based on this defaults.

Quote from: Case on 2024-04-05 10:39:22

Talking about tag names, I would like to change the default "truepeak_scanner_clipped_samples" field to include indicator that it's for a track now that I was asked to add another field for album. With current naming convention the tag should obviously be called "truepeak_scanner_clipped_samples_track".
I'm open to suggestions to all default tag names.

"replaygain_track_range" and "replaygain_album_range" as being used by some tools to store LRA. If that's the case I would like to use the same fields, in which case configuration of LRA tag field names can be removed.

It's consistent, so I'm all for it. And I personally don't mind if you would change tagnames for relatively new fields now. I read these tags  only once in a central routine and the required rescanning to write these renamed tags is fast as well (since I don't want to introduce the dreaded if3's lightly).
The nature of a forum is unfortunately that there's always people that are going to object for valid or obscure reasons.
I like you're open to suggestions, but it is your tool and not a democracy, you decide, I'll follow.

If those changes would mean we have to rescan all files or make some other huge changes I would voto - NO - do not change it. It is good.

If those changes would mean we have to rescan all files or make some other huge changes I would voto - NO - do not change it. It is good.

You misunderstood. You don't have to rescan.

You have the option to use this in your display column:
[$replace($if3(%replaygain_track_range%,%lra_track%,%lra%), LU,)]

Released a new version with the Loudness Range (LRA) ability included. Download from https://foobar.hyv.fi/?view=foo_truepeak (https://foobar.hyv.fi/?view=foo_truepeak).

There are also some internal changes. I did a lot of peak testing and speed testing and noticed that apart from full integer oversample factors being faster in (all) resamplers, SoX resampler really likes when resampling factors are powers of two. Since SoX is also generally fastest I made the component automatically try to pick SoX resampler. If it finds it, it will use a power of two oversample factor for speed. That will also give even better peak accuracy as it means higher sampling rate.

I also improved result dialog by adding a visible status column when needed even for minor issues and not just fatal errors. And results are more pleasant to look at as dialog uses real unicode minus signs so plus and minus have identical widths.

Released a new version with the Loudness Range (LRA) ability included. Download from https://foobar.hyv.fi/?view=foo_truepeak (https://foobar.hyv.fi/?view=foo_truepeak).

There are also some internal changes. I did a lot of peak testing and speed testing and noticed that apart from full integer oversample factors being faster in (all) resamplers, SoX resampler really likes when resampling factors are powers of two. Since SoX is also generally fastest I made the component automatically try to pick SoX resampler. If it finds it, it will use a power of two oversample factor for speed. That will also give even better peak accuracy as it means higher sampling rate.

I also improved resource dialog by adding a visible status column when needed even for minor issues and not just fatal errors. And results are more pleasant to look at as dialog uses real unicode minus signs so plus and minus have identical widths.

I removed the installed beta and installed this version.
Is it intentional you decided not to rename truepeak_scanner_clipped_samples to truepeak_scanner_clipped_samples_track?

Can you give some info about the oversample factors that are in effect for the different source frequencies?
For instance what do you do with 88kHz and 176kHz SACD sourced files?

The default clipped sample field name is changed, but if a configuration already exists it won't get automatically reset. You can right click on the field name and select 'Reset' to get the new default name.

If you look at the console output while the component is scanning or after scanning is done you can see it report information like "Oversampling to 352800 Hz with Resampler (SoX)".
The default oversampling multiplier is calculated by dividing the minimum wanted sampling rate by the source material sampling rate. If the result isn't a full integer, the multiplier gets rounded up to next full integer. For example the 88 kHz source you mentioned would give an oversampling factor of 3 with the default 192 kHz minimum sampling rate (192 kHz ÷ 88 kHz ≅ 2.18, fractional result gets rounded to next full number 3). But if SoX resampler is found, the multiplier gets rounded up to the next number that is a power of two. With these example numbers that would mean 4 x oversampling.
For 176 kHz source file the oversampling factor would be 2 with the default minimum sampling rate target. 2 is a the smallest full integer and it's also a power of two.
But for example 192 kHz ÷ 44.1 kHz ≅ 4.35, normal oversampling ratio would be 5 x but with SoX it would be 8 x.

The default clipped sample field name is changed, but if a configuration already exists it won't get automatically reset. You can right click on the field name and select 'Reset' to get the new default name.

That did the trick.

If you look at the console output while the component is scanning or after scanning is done you can see it report information like "Oversampling to 352800 Hz with Resampler (SoX)".
The default oversampling multiplier is calculated by dividing the minimum wanted sampling rate by the source material sampling rate. If the result isn't a full integer, the multiplier gets rounded up to next full integer. For example the 88 kHz source you mentioned would give an oversampling factor of 3 with the default 192 kHz minimum sampling rate (192 kHz ÷ 88 kHz ≅ 2.18, fractional result gets rounded to next full number 3). But if SoX resampler is found, the multiplier gets rounded up to the next number that is a power of two. With these example numbers that would mean 4 x oversampling.
For 176 kHz source file the oversampling factor would be 2 with the default minimum sampling rate target. 2 is a the smallest full integer and it's also a power of two.
But for example 192 kHz ÷ 44.1 kHz ≅ 4.35, normal oversampling ratio would be 5 x but with SoX it would be 8 x.

Am I correct to assume SoX foo_resampler 0.8.7 is the most current and preferred version?

EDIT: Maybe a good idea after all to also write a (optional) tag that has the name/settings of the upsampler that was used upon the scan.

The default clipped sample field name is changed, but if a configuration already exists it won't get automatically reset. You can right click on the field name and select 'Reset' to get the new default name.

If you look at the console output while the component is scanning or after scanning is done you can see it report information like "Oversampling to 352800 Hz with Resampler (SoX)".
The default oversampling multiplier is calculated by dividing the minimum wanted sampling rate by the source material sampling rate. If the result isn't a full integer, the multiplier gets rounded up to next full integer. For example the 88 kHz source you mentioned would give an oversampling factor of 3 with the default 192 kHz minimum sampling rate (192 kHz ÷ 88 kHz ≅ 2.18, fractional result gets rounded to next full number 3). But if SoX resampler is found, the multiplier gets rounded up to the next number that is a power of two. With these example numbers that would mean 4 x oversampling.
For 176 kHz source file the oversampling factor would be 2 with the default minimum sampling rate target. 2 is a the smallest full integer and it's also a power of two.
But for example 192 kHz ÷ 44.1 kHz ≅ 4.35, normal oversampling ratio would be 5 x but with SoX it would be 8 x.

Where exactly is this "reset" option. I can't find it.

All files that were scanned earlier display everything ok in the columns. Will this change after reset? I do not use any kind of Library. I  Manyally add a folder with the record I want to hear. Will I have to scan/change/reset every LP I already scanned?

After installing the new version of component and scanning new track my columns show only timestamp and album clips. There is no track LRA, album LRS nor track Clips. What exactly do I have to do to see it (what formulas to put in Columns and if I change then will I loose all previously scanned data)?

Please try not to full quote everything. The threads get very annoying to follow when they are mostly filled with just blocks of quotes.

You can reset the "Clipped samples in track" field name to the new default string by right clicking the option name in advanced preferences and select 'Reset':


Note that these changes only affect what the tag fields are called. Files that are already scanned will stay the same. You could use foobar's Properties dialog and its 'Automatically fill values...' feature to copy data from the old field to the new one. Or you could rescan the tracks if there aren't that many.
Another option would be to use titleformat code with fallbacks and support showing data from multiple field names.

As for how to show the data, most field names you can see in the preferences window. For example to show data for the clipped samples, copy the field name and add percentage signs to both sides of the field name, like this:

%truepeak_scanner_clipped_samples_track%

To support also the old name, you can use this:

$if2(%truepeak_scanner_clipped_samples_track%,%truepeak_scanner_clipped_samples%)

Note that foobar2000 displays a question mark by default for a missing field, to hide that use square brackets around the part that will be hidden if metadata isn't present:

[%truepeak_scanner_clipped_samples_track%]

or for the longer one:
[$if2(%truepeak_scanner_clipped_samples_track%,%truepeak_scanner_clipped_samples%)]

The Loudness Range (LRA) gets stored in tag fields that are already used by some tools. The fields are called replaygain_track_range and replaygain_album_range.
Note that capitalization doesn't matter, foobar2000's properties dialog shows them with all caps by default.
To show LRA value for a track, you probably want to use something like this:

[$replace($if3(%replaygain_track_range%,%lra_track%,%lra%), LU,, dB,,)]

The square brackets means it won't show a question mark if the info isn't present. $replace() part removes ' LU' and ' dB' from the end. And $if3() part picks data from any of the given field names, first from quite established %replaygain_track_range%, then it checks %lra_track% and last it checks just %lra%.

Thank you and sorry for the long quotes but I do not know how to qoute just fragments - is it done manually by inserting "qoute.../qoute"?

I use both Track and Album data in one column and while you were kind to help me I managed to do it myself with somethong like this:

$if3(%truepeak_scanner_clipped_samples_track%,%truepeak_scanner_clipped_samples%)/%truepeak_scanner_clipped_samples_album%

and

$replace($if3(%replaygain_track_range%,%lra_track%,%lra%), LU,)/$if3(%replaygain_album_range%,%lra_album%,%lra%)

It look like lratrack/lraalbum LU

What other tools use those fileds (as I would not want to loose smth)?

Once again thank you and sorry for amateur questions but I am not a programmer and this is all new to me.

I think the easiest way to quote a part is to use quote like you do but remove all unwanted text from inside the quote. If you use quote blocks manually you don't get the nice link to the original post you are quoting.

You learn the titleformat syntax best by using it. I'd recommend the following changes to your string:
For clipped samples:

[$if2(%truepeak_scanner_clipped_samples_track%,%truepeak_scanner_clipped_samples%)][/%truepeak_scanner_clipped_samples_album%]

Without the square brackets your string would have shown up as "?/?" for tracks that aren't run through the tool. Or for missing album clip count it would have shown "/?" behind the track clip count. Simple square brackets make the output clean.
I don't know if it matters in reality, but $if2() is meant for cases where there are only two fields to pick from, $if3 supports arbitrary amount. Using $if2 should be faster since there are only two fields, no need for titleformat parser to try to search for missing data.

and for Loudness Ranges:

$replace([$if3(%replaygain_track_range%,%lra_track%,%lra%)][/$if2(%replaygain_album_range%,%lra_album%)], LU,, dB,)

I removed the %lra% field from album part, %lra% field was only used for track based Loudness Range tagging in regor's scripts. Afaik %lra_track% and %lra_album% were very short lived tag fields too, only used by my foo_truepeak test version that was only linked on these forums for testing during few days.
I also added square brackets to hide question marks if the tag fields aren't found from tracks. And both track and album fields are covered by the same $replace() rule to remove the units that you don't want to see. And I added back the 'dB' unit you had removed, at least LoudGain writes dB units here even though LRA is an ITE standard and their units are 'LU'.

I linked this (https://wiki.hydrogenaud.io/index.php?title=ReplayGain_2.0_specification#De-Facto_extensions) in the other thread, LRA is stored in these %replaygain_track_range%/%replaygain_album_range% fields at least by LoudGain and MusicBrainz Picard.

Thank you.
I will try your formulas but will probably leave those "?" (non brackets) because they infrom me at once that I sould scan the files:).

Thanks marc2k3. I certainly don't like bright decorations that don't belong.
I added the DR scanning as an option to True Peak Scanner (https://foobar.hyv.fi/?view=foo_truepeak), and implemented the darkening changes there first. It was surprisingly difficult to make Windows use the new style, I couldn't make it work except by programmatically adjusting the dialog size.

I enabled dr scanning in the settings for truepeak scanner and removed components foo_dynamic_range and foo_dr_meter since they are obsolete (for scanning). Truepeakscanner 0.6.3 works excellent.

There are some minor UI issues though.

The text in the context menu is incomplete. It says Truepeak and positions but nothing about DRA,
I would not if it would only say Truepeak (and does all the things you enable in settings).

The popup window that comes up after the scan does not remember it's last size settings and there is now a couple of columns extra which I cannot see unless I everytime resize the popup window.

Finally ... I cannot clear DRA tags from the context menu, since I removed both foo_dynamic_range and foo_dr_meter.
Same as above I would not mind a context menu item that says remove Truepeak tags which removes all the things you set in truepeak scanner settings (including replaygain stuff).

Thanks for this great addition.

Could be possible to have a menu entry to do only dynamic range scan? It would be very useful to scan albums that already have the others values.

@Defender - Here's a new build that should address your concerns. I didn't replace the old and stable build yet because I may still do some tweaking. I may even re-use the same version number for further experiments.
Download: <link removed>

@paregistrase - I hope you noticed that I made a DR Meter component just for that originally: https://hydrogenaud.io/index.php/topic,123905.msg1044254.html#msg1044254 (https://hydrogenaud.io/index.php/topic,123905.msg1044254.html#msg1044254).

I'm starting to wonder if the name of this component should be renamed to something like Loudness scanner. I could give separate scanners own context menu entries, but the extra stuff has accumulated in because people wanted to scan multiple things at one go.
I'll probably add the extra commands anyway, hidden by default, especially if Defender likes the new idea of moving the context commands into a separate group of their own instead of camping in the ReplayGain menu.

Edit: Obsolete version removed.

@Defender - Here's a new build that should address your concerns. I didn't replace the old and stable build yet because I may still do some tweaking. I may even re-use the same version number for further experiments.
Download: https://foobar.hyv.fi/foo_truepeak_0.6.4.fb2k-component (https://foobar.hyv.fi/foo_truepeak_0.6.4.fb2k-component)

@paregistrase - I hope you noticed that I made a DR Meter component just for that originally: https://hydrogenaud.io/index.php/topic,123905.msg1044254.html#msg1044254 (https://hydrogenaud.io/index.php/topic,123905.msg1044254.html#msg1044254).

I'm starting to wonder if the name of this component should be renamed to something like Loudness scanner. I could give separate scanners own context menu entries, but the extra stuff has accumulated in because people wanted to scan multiple things at one go.
I'll probably add the extra commands anyway, hidden by default, especially if Defender likes the new idea of moving the context commands into a separate group of their own instead of camping in the ReplayGain menu.

There is a standalone one, good.

The idea of make a Loudness scanner menu with all the commands sounds pretty good.

@Defender - Here's a new build that should address your concerns. I didn't replace the old and stable build yet because I may still do some tweaking. I may even re-use the same version number for further experiments.
Download: https://foobar.hyv.fi/foo_truepeak_0.6.4.fb2k-component (https://foobar.hyv.fi/foo_truepeak_0.6.4.fb2k-component)

@paregistrase - I hope you noticed that I made a DR Meter component just for that originally: https://hydrogenaud.io/index.php/topic,123905.msg1044254.html#msg1044254 (https://hydrogenaud.io/index.php/topic,123905.msg1044254.html#msg1044254).

I'm starting to wonder if the name of this component should be renamed to something like Loudness scanner. I could give separate scanners own context menu entries, but the extra stuff has accumulated in because people wanted to scan multiple things at one go.
I'll probably add the extra commands anyway, hidden by default, especially if Defender likes the new idea of moving the context commands into a separate group of their own instead of camping in the ReplayGain menu.

Functionality of 0.6.4 is excellent.

I do not have any input about renaming the component or not a as long as functionality stays like this please.

BTW. I don't understand requests for partially scanning when some information (like rg) is already known.
You do one scan (I assume) to accumulate the various truepeak, clipping, lra and dr stuff. So how much time would be won if for instance the DR part would be excluded?
IMO it's quite efficient to do them all when I request a scan.

Tried this, uninstalling your DR component.

Crashes upon scanning an album (as album) truepeak + DR.


Edit: and it is this component yes. Clean portable:

Illegal operation:
Code: C0000005h, flags: 00000000h, address: 00007FFE92D0A56Dh
Access violation, operation: read, address: 0000000000000000h

Call path:
app_mainloop

Code bytes (00007FFE92D0A56Dh):
00007FFE92D0A52Dh:  00 00 00 4D 8B C6 49 8B D4 49 8B CF E8 42 BC FF
00007FFE92D0A53Dh:  FF 48 01 37 49 8D 85 08 06 00 00 EB 07 4D 8D BD
00007FFE92D0A54Dh:  88 01 00 00 48 8B F8 49 FF C6 48 8B 85 58 05 00
00007FFE92D0A55Dh:  00 80 38 00 74 6A 48 8B CF 49 8B 85 28 01 00 00
00007FFE92D0A56Dh:  42 0F 2F 34 A0 77 53 49 8B 85 48 01 00 00 F3 42
00007FFE92D0A57Dh:  0F 10 04 A0 F3 41 0F 58 C0 F3 4C 0F 2C C0 48 8D
00007FFE92D0A58Dh:  15 AE E5 03 00 48 8D 8D B0 00 00 00 E8 22 81 FF
00007FFE92D0A59Dh:  FF 48 63 F0 48 8B CF 85 C0 78 1F 4C 8D 8D B0 00

Registers:
RAX: 0000000000000000, RBX: 000001EEFF370C60, RCX: 000001EE820B8F98, RDX: 000000E4DC70E220
RSI: 0000000000000001, RDI: 000001EE820B8F98, RBP: 000000E4DC70E370, RSP: 000000E4DC70E270

Timestamp:
54078ms

Crash location:
Module: foo_truepeak
Offset: A56Dh

Sorry about the crash bug, @Porcus. Copy/paste bug. Before printing album DR number the code tried to check if album LRA result was valid. Since you had LRA disabled in the settings it tried to read from unallocated null pointer.
Fixed version with the changes made per Defender's suggestions uploaded to the usual location: https://foobar.hyv.fi/?view=foo_truepeak (https://foobar.hyv.fi/?view=foo_truepeak).

I found some issues with the DR measurement routine, probably only affected super short and quiet test tracks. New version of True Peak Scanner uploaded with the problem fixed: https://foobar.hyv.fi/?view=foo_truepeak (https://foobar.hyv.fi/?view=foo_truepeak).

Would it be possible to make the component scan and produce a tag file for Bluray files? I know that those m2ts files are untaggable but it has been made possible with SACD-iso files by producing xml files that contain tags and are stored in the same folder as corresponding audio file.

Would it be possible to make the component scan and produce a tag file for Bluray files? I know that those m2ts files are untaggable but it has been made possible with SACD-iso files by producing xml files that contain tags and are stored in the same folder as corresponding audio file.

foo_external_tags also by Case?

Quote from: wojak on 2024-05-13 10:03:45

Would it be possible to make the component scan and produce a tag file for Bluray files? I know that those m2ts files are untaggable but it has been made possible with SACD-iso files by producing xml files that contain tags and are stored in the same folder as corresponding audio file.

foo_external_tags also by Case?

Thank you for suggesting external tag, it works great.

Sorry for copy-paste of my post from DR Meter topic but it is related.

@Case, would it be possible to add all features of DR Meter (per-channel DR, RMS and peak) to True Peak Scanner? The output log placed in the folder with actual audio files (as in old component) would also be very much appreciated (I would love to see every measurement in it, including LRA, Clippings and Peakstamps).

How does this plugin behave with files containing several streams (like bluray m2ts with more than one version of the album - ex. stereo, instrumental, DTS, AC3, THD...)? Will it measure the first stream (or which one?) or is it possible to measure all streams (changing the stream with stream-selector and measure them all one by one and getting different results not owerwriting the previous ones)? And if it is possible, how to write such tags with your external tags? In case of SACD-iso we can write an xml containing two sets of tags/measurement (one for stereo and one for 5.1) (I know that those are different, not two streams but separate sets of "audio files").

I have noticed that your component measures slightly different than buil-it RG scanner concerning True Peaks and Gain.  I know that True Peaks are just (gu)esstimation of what would happen in the DAC but tried to manipulate the options in both components and never got exact the same measurements. My RG sacnner always was an 8xupsampling but I tried it with other options (SOX, SRC, 4x..) and yours with 190k and 384k. The results were always slightly different (rarely the differences were quite big, on some mp3 and the differences go both ways - sometimes yours shows less and sometimes more). Why is it so and is there a way to make them as similar as possible?

Sorry for copy-paste of my post from DR Meter topic but it is related.

@Case, would it be possible to add all features of DR Meter (per-channel DR, RMS and peak) to True Peak Scanner? The output log placed in the folder with actual audio files (as in old component) would also be very much appreciated (I would love to see every measurement in it, including LRA, Clippings and Peakstamps).

How does this plugin behave with files containing several streams (like bluray m2ts with more than one version of the album - ex. stereo, instrumental, DTS, AC3, THD...)? Will it measure the first stream (or which one?) or is it possible to measure all streams (changing the stream with stream-selector and measure them all one by one and getting different results not owerwriting the previous ones)? And if it is possible, how to write such tags with your external tags? In case of SACD-iso we can write an xml containing two sets of tags/measurement (one for stereo and one for 5.1) (I know that those are different, not two streams but separate sets of "audio files").

I have noticed that your component measures slightly different than buil-it RG scanner concerning True Peaks and Gain.  I know that True Peaks are just (gu)esstimation of what would happen in the DAC but tried to manipulate the options in both components and never got exact the same measurements. My RG sacnner always was an 8xupsampling but I tried it with other options (SOX, SRC, 4x..) and yours with 190k and 384k. The results were always slightly different (rarely the differences were quite big, on some mp3 and the differences go both ways - sometimes yours shows less and sometimes more). Why is it so and is there a way to make them as similar as possible?

Of course results are different. With RG you can only use a fixed truepeak method. In other words it does not base the amount of upsampling on the content.
The truepeakscanner upsamples based on the content (up to a minimum of 192k if I remember correctly).
So the used upsampling methods differ, therefore also the results.

I don't exactly understand why this tool should give the exact information as the original DR component which is ancient.
Why not use the exact info from the scan resultscreen? Everything including LRA is there.

Only thing that could be better is to remove all Album stuff from the tracklines and show this info (preferably on top) as a separate line.
And it would be nice if tracknumbers&length would be included in the grid (eg total tracks/ total time for the album line).

Of course results are different. With RG you can only use a fixed truepeak method. In other words it does not base the amount of upsampling on the content.
The truepeakscanner upsamples based on the content (up to a minimum of 192k if I remember correctly).
So the used upsampling methods differ, therefore also the results.

I don't exactly understand why this tool should give the exact information as the original DR component which is ancient.
Why not use the exact info from the scan resultscreen? Everything including LRA is there.

Only thing that could be better is to remove all Album stuff from the tracklines and show this info (preferably on top) as a separate line.
And it would be nice if tracknumbers&length would be included in the grid (eg total tracks/ total time for the album line).

I am not sure if upsampling is the only difference, because taking 48kHz file and scanning it with RG with 8x (giving 384k) and scanning it with TP scanner set to 384k gives different Gain and TPeaks (which then give different PLR and LUFS). The only issue with it is that I already have scanned tens of thousands files with RG and started to scan other files with TP scanner and use "prevent clipping" option (without applying gain) so the effect will be different. Moreover I have different releases  of the same albums and check if they are sonically the same (comparing TP, DR, LRA, LUFS, PLR) so having different results on different releases makes it impossible. I have to rescan all the files once again.

I did not say that the text results should look exactly the same as in old comonent. I just suggested that it would be convinient to be able to automatically export the results to the file (not having to clik "copy" than creating plain file and pasting the results - the old component just had an option to do this (or don't)). and if we get that option it would be nice to have everything included.

I am not sure if upsampling is the only difference, because taking 48kHz file and scanning it with RG with 8x (giving 384k) and scanning it with TP scanner set to 384k gives different Gain and TPeaks (which then give different PLR and LUFS).

I did not tinker with TP minimum scanning sample rate so 48kHz sources are upsampled to 192k when scanning. (And 44kHz to a bit higher I guess).

The only issue with it is that I already have scanned tens of thousands files with RG and started to scan other files with TP scanner and use "prevent clipping" option (without applying gain) so the effect will be different. Moreover I have different releases  of the same albums and check if they are sonically the same (comparing TP, DR, LRA, LUFS, PLR) so having different results on different releases makes it impossible. I have to rescan all the files once again.

Same here. So when I want to compare specific releases of the same album I just rescan those fully to get apples and apples. Scanning is rather quick. Then I listen to them with DSP Retain playtime enabled to switch seamlessly.

If you want to compare different albums/artists it really does not matter that much imo with what version those albums were scanned since scanning results don't differ that much.

I did not say that the text results should look exactly the same as in old comonent. I just suggested that it would be convinient to be able to automatically export the results to the file (not having to clik "copy" than creating plain file and pasting the results - the old component just had an option to do this (or don't)). and if we get that option it would be nice to have everything included.

I do agree and already thought about the dr_log file earlier. Then again I'm not a fan of overloading a developer with nice to have (or even silly) requests before the tool itself is bugfree, which is happening unfortunately with some other promising components.

That said, yes, I agree there needs to be a convenient export function whether it is a plain textfile like it used to be with DR or an automatic screendump (png/jpg) of the result screen which is also a custom in (bootleg) releasegroups. I prefer the latter.

That said, yes, I agree there needs to be a convenient export function whether it is a plain textfile like it used to be with DR or an automatic screendump (png/jpg) of the result screen which is also a custom in (bootleg) releasegroups. I prefer the latter.

Why would you prefer a screendump over text?
My preference is a CSV for those of us who like spreadsheets :D

Quote from: Defender on 2024-05-14 11:29:57

That said, yes, I agree there needs to be a convenient export function whether it is a plain textfile like it used to be with DR or an automatic screendump (png/jpg) of the result screen which is also a custom in (bootleg) releasegroups. I prefer the latter.

Why would you prefer a screendump over text?
My preference is a CSV for those of us who like spreadsheets :D

I don't give a damn about logfiles or screendumps as long as I can check (my) rips are accurate.
Would be nice if download content is already properly tagged with relevant info like catalognumber and including this stuff :-)

@Case

There is something off when scanning containers.

For reference: Truepeak scans 30x 96/24 files with a speed of 664x. Foobar RGx8 does 255x.

SACD-ISO with 2&6ch content: Truepeak Scanner extremely slow (speed 46x) and the Abort button does not work until you reach the end of the scan.
Foobar's built-in RGx8 scan is also similarly very slow (speed 42x) but it does respond to it's Cancel button.

DVDA-ISO with MLP 96/24 2&6ch content: Truepeak Scanner is slow (speed 371x). Abort button only works at end of the scan. Foobar RGx8 Scanner is slow (speed 579x) but Cancel works.

MKV with DTS-HD 48/24 content: Truepeak Scanner is slow (speed 333x). Abort button does work. Foobar RGx8 is slow (speed 214x) and Cancel works.

Any ideas?

So far I have determined the DR range values ​​with Dynamic Range Meter 1.1.1. To do this, I previously used the Replay Gain Scanner with the setting from Picture1. Everything with version 1.6.17. The result was the replay scan data also Picture2. The entry in the tags was as seen in Picture3.

Then I installed the True Peak Scanner in f2k-version 1.6.17 and ran it over the same album. The old replay gain values ​​were previously removed. The result can be seen in Picture4.

It should be noted that neither the track peak value nor the album peak value match the previous determination.

I'm not an expert here. Maybe someone can explain to me whether this is normal and whether it is due to a different calculation of the values. The differences don't seem to be that big.

With a few exceptions, the DR values ​​correspond to the values ​​from the Dynamic Range Meter 1.1.1.

My settings in the True Peak Scanner can be seen in Picture5.

Sorry for my Google Translate, but I don't speak English.

THX
mexx

@Case, would it be possible to add all features of DR Meter (per-channel DR, RMS and peak) to True Peak Scanner?

Not planned. I added that extra info to DR Meter as I thought people using DR Meter liked seeing that stuff, also it might be helpful during development to catch bugs (as DR result is not calculated how its documentation says at all). In a multipurpose scanner like this component the output has to concentrate only on actually useful values.

How does this plugin behave with files containing several streams (like bluray m2ts with more than one version of the album - ex. stereo, instrumental, DTS, AC3, THD...)?

It will measure the stream you have chosen. I have never seen any details about this stream variant selection in the SDK, I don't know if input components that do the tagging even have a chance to do things differently depending on the stream. Tools that just ask a tag to be written definitely don't know anything about such deftails nor have any option to do things differently.

I have noticed that your component measures slightly different than buil-it RG scanner concerning True Peaks and Gain.  [...] Why is it so and is there a way to make them as similar as possible?

Different upsampling. If you let built-in RG scanner select resampler on its own it will ask for a fast resampler, not highest quality one. You will get exact same results if you configure the built-in resampler to resample the same way, but there is not a simple built-in switch for that. True Peak Scanner uses SoX if it's installed and it will be used in highest quality mode. I have written how the upsampling is determined in detail here (https://hydrogenaud.io/index.php/topic,125719.msg1042197.html#msg1042197) and about SoX speed related updates here (https://hydrogenaud.io/index.php/topic,125719.msg1042465.html#msg1042465).

There is something off when scanning containers.

[...]Abort button only works at end of the scan. Foobar [...] Cancel works.

Any ideas?

I don't know why speed differences are so big but abort button not working is a result of input not handling it and my component not having safety checks against it. I'll add once I'm home.

Quote from: Defender on 2024-05-14 12:37:05

There is something off when scanning containers.

[...]Abort button only works at end of the scan. Foobar [...] Cancel works.

Any ideas?

I don't know why speed differences are so big but abort button not working is a result of input not handling it and my component not having safety checks against it. I'll add once I'm home.

When I saw the speeds of the SACD scanning I suspected that the RG and TP scan only use a single thread for scanning.
DVDA and MKV scanning however is only half as slow as normal tracks so that cannot be related to single thread scanning I guess.

New version uploaded: https://foobar.hyv.fi/?view=foo_truepeak (https://foobar.hyv.fi/?view=foo_truepeak)
Added extra abort checks. And changed the behavior of info removal. Now if True Peak Scanner is configured to scan and write standard ReplayGain tags the removal will remove those also.
A hint for @Defender: you can hide unwanted context menu entries in Preferences and get them visible by holding shift when you open context menu. That, I think, is a good way to hide seldom used stuff but still have access to it.

New version uploaded: https://foobar.hyv.fi/?view=foo_truepeak (https://foobar.hyv.fi/?view=foo_truepeak)
Added extra abort checks. And changed the behavior of info removal. Now if True Peak Scanner is configured to scan and write standard ReplayGain tags the removal will remove those also.
A hint for @Defender: you can hide unwanted context menu entries in Preferences and get them visible by holding shift when you open context menu. That, I think, is a good way to hide seldom used stuff but still have access to it.

Thx. All ok. And thanks for the shift tip.

I noticed you made an option available in the standalone DR scanner to automatically write values without opening the resultscreen.
Can you please implement that option too in truepeak scanner?

SACD scanning is still slow, but I guess it has to do with the extra conversion of the native DSD format.

When I play SACD (I have to use PCM) and I don't use a lowpass filter artifacts are clearly visible in Channel Spectrum. The moment I enable the lowpass filter those artifacts disappear.
I noticed that you always resample SACD to 352k upon scanning which is good. Do you also apply the lowpass before/upon scanning?
If not, wouldn't it be a good idea to do so?

EDIT: Probably best just to activate the lowpass filter in SACD settings itself. That way a conversion to flac does not inherit the artifacts also.

If you are scanning just one track the scanning speed will be limited by the source file decoder. Scanning is multithreaded but threads are used only for handling multiple tracks at once.
As you figured, the lowpass should be handled by the decoder. Another component has no way to know if it is being fed nonsensical data.

New version released with quiet mode added and configuration dialog tweaks. I think the options are less confusing now. I also published the component on the repository so updating will be easier: https://www.foobar2000.org/components/view/foo_truepeak (https://www.foobar2000.org/components/view/foo_truepeak).

New version released with quiet mode added

Regarding this component I have nothing to wish or nag about anymore. Thx.

As you figured, the lowpass should be handled by the decoder. Another component has no way to know if it is being fed nonsensical data.

Ok, noted.

If you are scanning just one track the scanning speed will be limited by the source file decoder. Scanning is multithreaded but threads are used only for handling multiple tracks at once.

Not sure what you mean. Can truepeakscanner (and/or foobar RG scanner) use multithreaded scanning on multiple tracks/subsongs within a single container (iso/mkv)?

Quote from: Case on 2024-05-16 07:37:25

If you are scanning just one track the scanning speed will be limited by the source file decoder. Scanning is multithreaded but threads are used only for handling multiple tracks at once.

Not sure what you mean. Can truepeakscanner (and/or foobar RG scanner) use multithreaded scanning on multiple tracks/subsongs within a single container (iso/mkv)?

Absolutely. As long as there are separate tracks the work can be spread across multiple threads. You can look at task manager and you should see possibly even 100% CPU usage for foobar2000, as long as you aren't bottlenecked by storage.

As long as there are separate tracks the work can be spread across multiple threads. You can look at task manager and you should see possibly even 100% CPU usage for foobar2000, as long as you aren't bottlenecked by storage.

Can confirm. Ran some more tests (always on NVME Gen4 storage).

Interesting to see that SACD is by far the heaviest to scan (not only for truepeak scanner but also foobar RG). Must be the underlying process of the underlying SACD component I guess.

Roughly speaking SACD scan runs at 49x, DTSMA at 430x, DVDA at 500x and normal FLAC8 at 1500x.
Time that the scanner needs for additional LRA, DR and clipping pos is neglectible (up to 10% extra time).

SoX did speed up scanning quite a bit.  Most values were the same, peak timestamp if different, along with track and album peak.  Is this to be expeced?  1st time using SoX for this so wanted to confirm.  Please see attached. 

I installed  https://foobar.hyv.fi/?view=foo_dsp_resampler
Then went to Preferences>Advanced>Filter, type in Tools, under Automatic resampling preference type in: “Resampler (SoX)”

Colsole info:
True Peak Scanning track: D:\Music\FLAC\P-R\_ and the Mysterians\1966 96 Tears\_ and the Mysterians - 96 Tears - 12 - 96 tears.flac
Oversampling to 352800 Hz with Resampler (SoX)
True Peaks calculated in: 0:01.346, speed: 133.61x

Anything I messed up here?  Don't think so, but checking... 

SoX did speed up scanning quite a bit.  Most values were the same, peak timestamp if different, along with track and album peak.  Is this to be expeced?  1st time using SoX for this so wanted to confirm.  Please see attached. 

I installed  https://foobar.hyv.fi/?view=foo_dsp_resampler
Then went to Preferences>Advanced>Filter, type in Tools, under Automatic resampling preference type in: “Resampler (SoX)”

Colsole info:
True Peak Scanning track: D:\Music\FLAC\P-R\_ and the Mysterians\1966 96 Tears\_ and the Mysterians - 96 Tears - 12 - 96 tears.flac
Oversampling to 352800 Hz with Resampler (SoX)
True Peaks calculated in: 0:01.346, speed: 133.61x

Anything I messed up here?  Don't think so, but checking... 

You enabled SoX for foobar standard RG scanner.
You don't have to enable SoX resampler for Truepeak. When SoX is installed Truepeak will automatically use SoX upon scan.

If you use the settings as in the attached file, you don't have to use standard foobar replaygain scan anymore. Upon scanning truepeak will write TP values also in the standard RG fields and will also calculate LRA, DR and clipping positions.
So in one scan you can have it all.
If you don't want the result window popup, you can also disable it.

BTW. All this info is in this thread if you scroll a bit back.

You enabled SoX for foobar standard RG scanner.
You don't have to enable SoX resampler for Truepeak. When SoX is installed Truepeak will automatically use SoX upon scan.

If you use the settings as in the attached file, you don't have to use standard foobar replaygain scan anymore. Upon scanning truepeak will write TP values also in the standard RG fields and will also calculate LRA, DR and clipping positions.
So in one scan you can have it all.
If you don't want the result window popup, you can also disable it.

BTW. All this info is in this thread if you scroll a bit back.

Thanks for the guidance Defender. What is the benefit to writing to custom tags for peak and gain along with using the ReplayGain tag fields?  Both will have the same values, albeit a different tag name.  I was jus tusing the ReplayGain fields as shown in the attached. 

Quote from: Defender on 2024-05-17 22:54:16

You enabled SoX for foobar standard RG scanner.
You don't have to enable SoX resampler for Truepeak. When SoX is installed Truepeak will automatically use SoX upon scan.

If you use the settings as in the attached file, you don't have to use standard foobar replaygain scan anymore. Upon scanning truepeak will write TP values also in the standard RG fields and will also calculate LRA, DR and clipping positions.
So in one scan you can have it all.
If you don't want the result window popup, you can also disable it.

BTW. All this info is in this thread if you scroll a bit back.

Thanks for the guidance Defender. What is the benefit to writing to custom tags for peak and gain along with using the ReplayGain tag fields?  Both will have the same values, albeit a different tag name.  I was jus tusing the ReplayGain fields as shown in the attached. 

If you don't write the custom fields you don't know how the replaygain values were obtained (with the standard replayscanner for instance and if so whether upsampling was enabled). With upsampling results are more precise.
So in my skin I optionally can show RG values (and LRA, LUFS, PLR and Clipping) I display replaygain values with an indicator if they were obtained with the truepeakscanner (the values of the RG fields are the same as the custom fields in that case).

I show this info in 3 different optional locations: group header (album values), rowlevel (track values) and popup (both album & track values).
When I detect RG info is a result of a Truepeak scan I display TT instead of RG.

It all helps in giving me an idea about the quality of the recording and comparing recordings of the same track on different releases before listening to it.

What are the strings/title formatting we need to enter to get the DR and LRA values to show up in a Playlist column?

Would also be nice to have an easy way to show LUFS Integrated and Max LUFS M and Max LUFS S for each track. I use a long string now for LUFS-I, but be nice to have something that was more easily understandable.

$if(%replaygain_track_gain%,$puts(l,$sub(-1800,$replace(%replaygain_track_gain%,.,)))$div($get(l),100).$right($get(l),2) dB,)

And thanks Case for making this, it's fantastic.

What are the strings/title formatting we need to enter to get the DR and LRA values to show up in a Playlist column?

Would also be nice to have an easy way to show LUFS Integrated and Max LUFS M and Max LUFS S for each track. I use a long string now for LUFS-I, but be nice to have something that was more easily understandable.

$if(%replaygain_track_gain%,$puts(l,$sub(-1800,$replace(%replaygain_track_gain%,.,)))$div($get(l),100).$right($get(l),2) dB,)

And thanks Case for making this, it's fantastic.

LRA:
[$replace(%replaygain_track_range%, LU,)]

DR:
[%dynamic range%]

Doesn't give you colorcoding though.

Don't know about LUFS and PLR . I'm using a much more horrible oneliner than you borrowed from Regor.
I tried to make it more readable but failed miserably.

Thanks for those!

For PLR I'm using this (also posted by someone else on here), which is just nuts:

$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)),))$get(PLR)

Thanks for those!

For PLR I'm using this (also posted by someone else on here), which is just nuts:

$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)),))$get(PLR)

Yep. That's the one :-D

LUFS:
$if(%replaygain_album_peak_db%,$puts(LUFS,$add($mul($replace(%replaygain_album_gain%,.,),10),18000))$puts(LUFS_TEN,$left($right($get(LUFS),3),2))
$puts(LUFS_ROUND,$ifgreater($get(LUFS_TEN),40,$add($get(LUFS),100),$get(LUFS)))$iflonger($get(LUFS_ROUND),4,$left($get(LUFS_ROUND),2).$substr($get(LUFS_ROUND),3,4),$left($get(LUFS_ROUND),1).$substr($get(LUFS_ROUND),2,3)),))

Most values were the same, peak timestamp if different, along with track and album peak.  Is this to be expeced?

Peaks being slightly different is expected with different resamplers. Highest peak position changing entirely was unexpected, I have never noticed that happening. Would be curious to see what goes on in the track in those positions that causes such shift.

You didn't mess up anything as long as you didn't include the quotation marks when you typed the preferred resampler name in advanced preferences. As Defender said, that's step is no longer needed for True Peak Scanner component but now that you have done it, all components that ask for (random) resampler will get SoX. That's good, so all components will get a very fast and high quality option.

When True Peak Scanner scans "...(as albums)" does it take the physical file system Folders into account, or is it only looking at the metadata/album tags? I have all my albums as separate folders, but not all of them are fully tagged. The ReplayGain Scanner has a "Scan as albums (by folders)" option which I always use when scanning a mass of albums in one go. Just wondering if this one does the same as I don't see an option for it.

When True Peak Scanner scans "...(as albums)" does it take the physical file system Folders into account, or is it only looking at the metadata/album tags? I have all my albums as separate folders, but not all of them are fully tagged. The ReplayGain Scanner has a "Scan as albums (by folders)" option which I always use when scanning a mass of albums in one go. Just wondering if this one does the same as I don't see an option for it.

In Advanced you can set album grouping pattern. In your case that would be:
$directory_path(%path%)

Thanks once again! Can I just add that to the current pattern, or should I delete those and replace it with this? Am guessing add it?

Thanks once again! Can I just add that to the current pattern, or should I delete those and replace it with this? Am guessing add it?

If you don't mix tagged stuff with untagged stuff you can add it at the end, but since you organize albums in folders always (like I do) you can just replace the whole thing.

EDIT: Which is also the reason that I don't use subfolders for multicd albums.

Brilliant, thank you!

Quote from: ngs428 on 2024-05-17 21:28:05

Most values were the same, peak timestamp if different, along with track and album peak.  Is this to be expeced?

Peaks being slightly different is expected with different resamplers. Highest peak position changing entirely was unexpected, I have never noticed that happening. Would be curious to see what goes on in the track in those positions that causes such shift.

You didn't mess up anything as long as you didn't include the quotation marks when you typed the preferred resampler name in advanced preferences. As Defender said, that's step is no longer needed for True Peak Scanner component but now that you have done it, all components that ask for (random) resampler will get SoX. That's good, so all components will get a very fast and high quality option.

I sent you the file in your messages that had 2 peak timestamps.  I didn't use the quotes, so I am all good there.  Thanks for this component! 

Would also be nice to have an easy way to show LUFS Integrated and Max LUFS M and Max LUFS S for each track.

Here's an unpublished True Peak Scanner version with max momentary loudness (LUFS-M) and max short-term loudness (LUFS-S) scanning support: [obsolete link removed].
At the moment the component defaults to storing LUFS-M in a tag field "truepeak_scanner_max_lufs_m" and LUFS-S respectively in "truepeak_scanner_max_lufs_s". If there are tag fields already in use by some software I'd happily change to use the same fields.

LUFS-I is computable from the ReplayGain value, but if there's strong will for yet another option, it could be stored in a separate tag field.

edit: obsolete link removed.

Here's an unpublished True Peak Scanner version with max momentary loudness (LUFS-M) and max short-term loudness (LUFS-S) scanning support: https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component (https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component).
At the moment the component defaults to storing LUFS-M in a tag field "truepeak_scanner_max_lufs_m" and LUFS-S respectively in "truepeak_scanner_max_lufs_s". If there are tag fields already in use by some software I'd happily change to use the same fields.

LUFS-I is computable from the ReplayGain value, but if there's strong will for yet another option, it could be stored in a separate tag field.

There is display glitch in settings I think. It says Max LUFS-I in track, but I guess it should state LUFS-S.

I would like you to also publish the LUFS-I value (guess that is the one I already have implemented with the rather long and unreadable one-liner).

Second thing is I would like analogy in behavior, so please do track and album versions of LUFS-M, LUFS-S and LUFS-I. EDIT: And analogy in name convention so the addition of _track and _album in the defaults fieldnames.

Quote from: darkflame23 on 2024-05-18 09:48:53

Would also be nice to have an easy way to show LUFS Integrated and Max LUFS M and Max LUFS S for each track.

Here's an unpublished True Peak Scanner version with max momentary loudness (LUFS-M) and max short-term loudness (LUFS-S) scanning support: https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component (https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component).
At the moment the component defaults to storing LUFS-M in a tag field "truepeak_scanner_max_lufs_m" and LUFS-S respectively in "truepeak_scanner_max_lufs_s". If there are tag fields already in use by some software I'd happily change to use the same fields.

LUFS-I is computable from the ReplayGain value, but if there's strong will for yet another option, it could be stored in a separate tag field.

This is great, thanks, will give it a try!

[EDIT] Yes, working great for LUFS S and LUFS M!

@Case

Normal 44/16 files I scan with 1600x speed without LUFS-S/M, and 1000x speed with LUFS-S/M.
Is it normal to see such a drop in performance?

DVD-A iso  I scan with 500x speed without LUFS-S/M. When I enable LUFS-S/M scanning is deadslow ... I cannot even complete the scan.
How come?

EDIT: SACD iso 45x without LUFS-S/M to 8x with LUFS-S/M.

Is the Clip count based on the PCM sample value, or the True Peak reading? I am assuming the former, as I have scanned a number of albums showing TP levels of above digital zero, but the Clip shows zero too.

The LUFS test version at [edit: obsolete link removed] was just refreshed. Version number intentionally kept the same as I'm still tweaking things for public release.

There's now an option to also include LUFS-I tags when ReplayGain scanning. Album variants of LUFS-M and LUFS-S tags are now also supported.

I too noticed that momentary and short-term loudness evaluation is very slow. First test version called the calculations after each processed audio chunk. Refreshed build runs the calculations approximately every 100 ms. Sadly the results change a bit depending on when the calculations are done. I will need to tweak this behavior still a bit, I don't like that the numbers change for bit-identical data depending on how many samples a decoder produces per decode pass.

There was also a stupid mistake with SoX upsampling setup that was found thanks to @ngs428's sharp eyes. SoX upsampling mistakenly didn't use the power-of-two resampling ratio that it was meant to. Processing speed is now a bit faster as this issue was fixed.

edit: obsolete link removed.

Is the Clip count based on the PCM sample value, or the True Peak reading? I am assuming the former, as I have scanned a number of albums showing TP levels of above digital zero, but the Clip shows zero too.

Clip count is calculated from the upsampled signal currently. Are you certain about clip count showing zero? That should not be possible.

Quote from: darkflame23 on 2024-05-18 18:13:22

Is the Clip count based on the PCM sample value, or the True Peak reading? I am assuming the former, as I have scanned a number of albums showing TP levels of above digital zero, but the Clip shows zero too.

Clip count is calculated from the upsampled signal currently. Are you certain about clip count showing zero? That should not be possible.

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.

The LUFS test version at https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component (https://foobar.hyv.fi/foo_truepeak_0.6.8.fb2k-component) was just refreshed.

Nice.

Just for my understanding. I removed the old version. Restarted foobar and installed the updated version.
I still see the names I entered for LUFS-S/M which are:
truepeak_scanner_max_lufs_s_track
truepeak_scanner_max_lufs_m_track.

Can you confirm that your default names upon first time installation are:
truepeak_scanner_track_max_lufs_s
truepeak_scanner_track_max_lufs_m

Thx for looking into the speed/performance problem as well.

EDIT: Sorry, let me rephrase .. What are all default names for custom fields you provide upon first-time installation?

EDIT2: You just hit one of my major annoyance points in foobar ...  the settings screen is not resizable and you have now more options than one small settings screen.

@Case

Not really a big thing, but during development probably best to address.

I did some compares on your published LUFS-I value to the oneliner calculation based on your published %replaygain_track_peak_db% and %replaygain_track_gain% values. So both methods should be based on the same values and give the same result.

They are not the same in a kind of weird way. Either the values are exactly the same (as I do expect) or the values are exactly 0.1 off.
Can you please confirm that your calculation is correct and not 0.1 off and the problem is the undebugable oneliner?

Oneliner:
$if(%replaygain_track_peak_db%,$puts(LUFS,$add($mul($replace(%replaygain_track_gain%,.,),10),18000))$puts(LUFS_TEN,$left($right($get(LUFS),3),2))$puts(LUFS_ROUND,$ifgreater($get(LUFS_TEN),40,$add($get(LUFS),100),get(LUFS)))$iflonger($get(LUFS_ROUND),4,$left($get(LUFS_ROUND),2).$substr($get(LUFS_ROUND),3,4),$left($get(LUFS_ROUND),1).$substr($get(LUFS_ROUND),2,3)),)

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

Obviously the TF expression has rounding (all my DR,LUFS,PLR expression have rounding). No one should expect a basic TF expression in a totally limited language like foobar TF, which was never meant for math calcs, can output values with a lot of precision without using tons of lines of code. I mean, you should never use that as a "reference" for anything. (not saying the component may not be wrong too, but TF is wrong for sure).

Obviously the TF expression has rounding (all my DR,LUFS,PLR expression have rounding). No one should expect a basic TF expression in a totally limited language like foobar TF, which was never meant for math calcs, can output values with a lot of precision without using tons of lines of code. I mean, you should never use that as a "reference" for anything. (not saying the component may not be wrong too, but TF is wrong for sure).

I totally understand. Funny thing is I take the oneliner and feed it through a proper rounding (not truncating) routine with selectable precision I wrote in TF for general use to present the values for PLR and LUFS rounded to an integer value. If you would use this routine in the oneliner the code would be 10x larger/longer. And does it really matter if results are 0.1 off?

Thing is ... this tool is in development so the time to get results as correct as possible is now imo. Like Case stated, during development of DR code he found bugs in the old DR tool too.

I'm just looking for confirmation his values are correct and then never think about it again.

Then try excel or any other tool for that (with similar expression)  since the TF heavily uses rounding and caching of decimal values to calculate things. Note there is no way to use float numbers on TF, so... it just process the decimals in additional steps.

Then try excel or any other tool for that (with similar expression)  since the TF heavily uses rounding and caching of decimal values to calculate things. Note there is no way to use float numbers on TF, so... it just process the decimals in additional steps.

Bit off-topic ...

Can you shell excel from within splittercode?

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.

For reference the rounding routine:

$puts(cmt, --- CODE.ROUNDPREC ---)

$puts(round.value,$trim($get(round.value)))
$puts(round.precision,$trim($get(round.precision)))

$ifgreater($get(round.precision),9,
	$puts(round.precision,         9)
,
	$ifgreater($get(round.precision),0,
	,
		$if($stricmp($get(round.precision),0),
		,
			$puts(round.precision, 2)
		)
	)
)

$if($get(round.value),
	$puts(round.i,                 $strchr($get(round.value),.))

	$ifgreater($get(round.i),1,
		$puts(round.value,$get(round.value)0000000000)
	,	
		$ifequal($get(round.i),0,
			$puts(round.value,$get(round.value).0000000000)
		,
			$puts(round.value,0$get(round.value)0000000000)
		)
		$puts(round.i,             $strchr($get(round.value),.))
	)
	$puts(round.int,$add($cut($get(round.value),$sub($get(round.i),1)),0))
	$puts(round.fract,$substr($get(round.value),$add($get(round.i),1),$add($get(round.i),1,$get(round.precision))))
	$puts(round.round,$add(1$get(round.fract),5))

	$puts(round.res_int,$add($get(round.int), $if($stricmp($cut($get(round.round),1),1), 0, 1)))
	$puts(round.res_fract,$ifgreater($get(round.precision),0,.$substr($get(round.round), 2, $add(1,$get(round.precision))),))

	$puts(round.result,$get(round.res_int)$get(round.res_fract))
,
	$puts(round.result,)
)

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.

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

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:

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.

Thank you!

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.

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.

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

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.

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.

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%

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? 

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.

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

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.

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

Brilliant, will give it a try!

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?

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

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.

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

@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:

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

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

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.

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.

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.

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?

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.

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.

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.

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

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

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.

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.

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.

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

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

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

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 (https://hydrogenaud.io/index.php/topic,125795.msg1044922.html#msg1044922) 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...

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.

And this (https://hydrogenaud.io/index.php/topic,125795.msg1044922.html#msg1044922) 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

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.

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 (https://hydrogenaud.io/index.php/topic,125795.msg1044922.html#msg1044922) 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).

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.

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

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!