Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_truepeak True Peak Scanner (Read 3316 times) previous topic - next topic - Topic derived from Re: Resampling Hi-Res...
0 Members and 1 Guest are viewing this topic.

foo_truepeak True Peak Scanner

@Case, I checked your page with x64 plugins and found no Truepeak there. Could you recompile it, please?
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_truepeak True Peak Scanner

Reply #1 –
The component is obsolete. Native ReplayGain scanner does True Peaks now.

Re: foo_truepeak True Peak Scanner

Reply #2 –
Native one displays Track gain and True peak only,
whereas your component displays valuable extra data:
Peak timestamp and Number of clipping samples.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_truepeak True Peak Scanner

Reply #4 –
@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?



• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_truepeak True Peak Scanner

Reply #5 –
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.

Re: foo_truepeak True Peak Scanner

Reply #6 –
Quote
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. 

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #8 –
Quote from: Kraeved on
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 (by Alexey Lukin, DSP engineer at iZotope): “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 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.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_truepeak True Peak Scanner

Reply #9 –
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.

Re: foo_truepeak True Peak Scanner

Reply #10 –
Quote from: Case on
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?

Re: foo_truepeak True Peak Scanner

Reply #11 –
Quote from: Case on
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've already reported 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?


• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_truepeak True Peak Scanner

Reply #12 –
Quote from: wojak on
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.

Quote from: Kraeved on
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.

Re: foo_truepeak True Peak Scanner

Reply #13 –
@Case, I removed SoX resampler mod and installed your x64 version 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, because the original author (@lvqcl, I guess) never compiled his x64 version, although I asked about it 4 months ago. Quite possible that my recent plea to add x8 upsampling will be ignored too, because this already happened 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.

• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_truepeak True Peak Scanner

Reply #14 –
Quote from: wojak on
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) 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'.

Quote from: Kraeved on
Now your true peak plugin works way faster (min 33x). Consider adding that resampler to your website, 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.

Quote from: Kraeved on
* 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.

Re: foo_truepeak True Peak Scanner

Reply #15 –
Quote from: Case on
Quote from: wojak on
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) 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!!!
 

Re: foo_truepeak True Peak Scanner

Reply #16 –
Quote from: Case on
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.

Re: foo_truepeak True Peak Scanner

Reply #17 –
Quote from: Case on
Quote from: wojak on
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) 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?

Re: foo_truepeak True Peak Scanner

Reply #18 –
Quote from: Bogozo on
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.

Quote from: wojak on
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.

Quote from: wojak on
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.

Re: foo_truepeak True Peak Scanner

Reply #19 –
@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.

Re: foo_truepeak True Peak Scanner

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

Native.


Plugin.
• Join our efforts to make Helix MP3 encoder great again
• Opus complexity & qAAC dependence on Apple is an aberration from Vorbis & Musepack breakthroughs
• Let's pray that D. Bryant improve WavPack hybrid, C. Helmrich update FSLAC, M. van Beurden teach FLAC to handle non-audio data

Re: foo_truepeak True Peak Scanner

Reply #22 –
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.

Re: foo_truepeak True Peak Scanner

Reply #23 –
Quote from: Case on
New version uploaded to 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.

Re: foo_truepeak True Peak Scanner

Reply #24 –
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.