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 13570 times) previous topic - next topic - Topic derived from Re: Resampling Hi-Res...
0 Members and 1 Guest are viewing this topic.

Re: foo_truepeak True Peak Scanner

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

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

Re: foo_truepeak True Peak Scanner

Reply #151 –
Quote from: ngs428 on
  • 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.

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

Re: foo_truepeak True Peak Scanner

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

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

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #154 –
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. I figured it's like the DR number that people want to see as integer.

Re: foo_truepeak True Peak Scanner

Reply #155 –
Quote from: Case on
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. 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),?)

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #158 –
Quote from: Case on
And this 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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #164 –
Awesome, I replaced replaygain keyboard shortcuts by this. Time information cannot be saved to a tag? EDIT: Found it in the advanced options.
It would be nice if this could be added to the converter, as an alternative for RG in the "when finished" section.

Re: foo_truepeak True Peak Scanner

Reply #165 –
Quote from: ngs428 on
Quote from: Case on
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.
I spent some time today to think about what kind of statistics to gather from clipping, here's an experimental implementation: https://foobar.hyv.fi/foo_truepeak_clip_report_testing.fb2k-component
I hope people don't quote this link as the component will be nuked once testing is done, leaving quotes with bad links behind.

The new experimental statistics aren't shown on the result dialog or tagged, they are only printed to foobar's console. So it's best to test that with only one track.

Example results:
Code: [Select]
True Peak Scanning track: G:\Music\Lossless\Metallica\(2008) Death Magnetic\05. All Nightmare Long.flac
Oversampling to 352800 Hz with Resampler (SoX)
Clip stats: ch0: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 16.0000000 (0:00.000 s), total clipping samples: 377258 (0:01.069 s)
Clip stats: ch1: peak: 1.2273319 (1.7792406 dB), pos: 0:19.988, max clip rms: 1.0105605 dB, pos: 1:01.660, max consecutive clipping samples: 17.0000000 (0:00.000 s), total clipping samples: 781139 (0:02.214 s)
Clip stats track:: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 17 (0:00.000 s), total clipping: 1158397 (0:03.283 s)
Clip histogram:
peak at 0.0 - 0.1 dB: 1038987 samples (89.69 %)
peak at 0.1 - 0.2 dB: 78387 samples (6.77 %)
peak at 0.2 - 0.3 dB: 21630 samples (1.87 %)
peak at 0.3 - 0.4 dB: 8597 samples (0.74 %)
peak at 0.4 - 0.5 dB: 4253 samples (0.37 %)
peak at 0.5 - 0.6 dB: 2362 samples (0.20 %)
peak at 0.6 - 0.7 dB: 1473 samples (0.13 %)
peak at 0.7 - 0.8 dB: 910 samples (0.08 %)
peak at 0.8 - 0.9 dB: 605 samples (0.05 %)
peak at 0.9 - 1.0 dB: 394 samples (0.03 %)
peak at 1.0 - 1.1 dB: 293 samples (0.03 %)
peak at 1.1 - 1.2 dB: 188 samples (0.02 %)
peak at 1.2 - 1.3 dB: 138 samples (0.01 %)
peak at 1.3 - 1.4 dB: 76 samples (0.01 %)
peak at 1.4 - 1.5 dB: 49 samples (0.00 %)
peak at 1.5 - 1.6 dB: 23 samples (0.00 %)
peak at 1.6 - 1.7 dB: 13 samples (0.00 %)
peak at 1.7 - 1.8 dB: 5 samples (0.00 %)
peak at 1.8 - 1.9 dB: 4 samples (0.00 %)
peak at 2.0 - 2.1 dB: 4 samples (0.00 %)
peak at 2.1 - 2.2 dB: 3 samples (0.00 %)
peak at 2.2 - 2.3 dB: 2 samples (0.00 %)
peak at 1.9 - 2.0 dB: 1 samples (0.00 %)

Re: foo_truepeak True Peak Scanner

Reply #166 –
Quote from: Case on
Quote from: ngs428 on
Quote from: Case on
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.
I spent some time today to think about what kind of statistics to gather from clipping, here's an experimental implementation: https://foobar.hyv.fi/foo_truepeak_clip_report_testing.fb2k-component
I hope people don't quote this link as the component will be nuked once testing is done, leaving quotes with bad links behind.

The new experimental statistics aren't shown on the result dialog or tagged, they are only printed to foobar's console. So it's best to test that with only one track.

Example results:
Code: [Select]
True Peak Scanning track: G:\Music\Lossless\Metallica\(2008) Death Magnetic\05. All Nightmare Long.flac
Oversampling to 352800 Hz with Resampler (SoX)
Clip stats: ch0: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 16.0000000 (0:00.000 s), total clipping samples: 377258 (0:01.069 s)
Clip stats: ch1: peak: 1.2273319 (1.7792406 dB), pos: 0:19.988, max clip rms: 1.0105605 dB, pos: 1:01.660, max consecutive clipping samples: 17.0000000 (0:00.000 s), total clipping samples: 781139 (0:02.214 s)
Clip stats track:: peak: 1.3002197 (2.2803346 dB), pos: 0:30.708, max clip rms: 1.2160325 dB, pos: 0:30.708, max consecutive clipping samples: 17 (0:00.000 s), total clipping: 1158397 (0:03.283 s)
Clip histogram:
peak at 0.0 - 0.1 dB: 1038987 samples (89.69 %)
peak at 0.1 - 0.2 dB: 78387 samples (6.77 %)
peak at 0.2 - 0.3 dB: 21630 samples (1.87 %)
peak at 0.3 - 0.4 dB: 8597 samples (0.74 %)
peak at 0.4 - 0.5 dB: 4253 samples (0.37 %)
peak at 0.5 - 0.6 dB: 2362 samples (0.20 %)
peak at 0.6 - 0.7 dB: 1473 samples (0.13 %)
peak at 0.7 - 0.8 dB: 910 samples (0.08 %)
peak at 0.8 - 0.9 dB: 605 samples (0.05 %)
peak at 0.9 - 1.0 dB: 394 samples (0.03 %)
peak at 1.0 - 1.1 dB: 293 samples (0.03 %)
peak at 1.1 - 1.2 dB: 188 samples (0.02 %)
peak at 1.2 - 1.3 dB: 138 samples (0.01 %)
peak at 1.3 - 1.4 dB: 76 samples (0.01 %)
peak at 1.4 - 1.5 dB: 49 samples (0.00 %)
peak at 1.5 - 1.6 dB: 23 samples (0.00 %)
peak at 1.6 - 1.7 dB: 13 samples (0.00 %)
peak at 1.7 - 1.8 dB: 5 samples (0.00 %)
peak at 1.8 - 1.9 dB: 4 samples (0.00 %)
peak at 2.0 - 2.1 dB: 4 samples (0.00 %)
peak at 2.1 - 2.2 dB: 3 samples (0.00 %)
peak at 2.2 - 2.3 dB: 2 samples (0.00 %)
peak at 1.9 - 2.0 dB: 1 samples (0.00 %)

I think you are on to something.  How granular the histogram has to be is a good question.  Do we need it by 0.1?  Is sure does show that your file have a ton of clips, but approx 90% are 0.1 or lower.  I think this helps explain the impact of the clip result.

Example results:
Code: [Select]
Oversampling to 192000 Hz with Resampler (SoX)
Clip stats: ch0: peak: 1.0216434 (0.1859869 dB), pos: 0:34.500, max clip rms: -0.0615525 dB, pos: 0:32.646, max consecutive clipping samples: 1.0000000 (0:00.000 s), total clipping samples: 3 (0:00.000 s)
Clip stats: ch1: peak: 1.0251275 (0.2155575 dB), pos: 0:34.500, max clip rms: -0.0170493 dB, pos: 0:26.200, max consecutive clipping samples: 1.0000000 (0:00.000 s), total clipping samples: 2 (0:00.000 s)
Clip stats track:: peak: 1.0251275 (0.2155575 dB), pos: 0:34.500, max clip rms: -0.0170493 dB, pos: 0:26.200, max consecutive clipping samples: 1 (0:00.000 s), total clipping: 5 (0:00.000 s)
Clip histogram:
peak at 0.0 - 0.1 dB: 2 samples (40.00 %)
peak at 0.1 - 0.2 dB: 2 samples (40.00 %)
peak at 0.2 - 0.3 dB: 1 samples (20.00 %)
True Peaks calculated in: 0:01.280, speed: 31.15x

How this is presented is another story.  You can't write 20 tag values for this..  Output .txt file?  That would get to be a lot of data.  I like what you have here.  Thanks for spending time on it. 


I see you are Oversampling to 352800.  I left mine at the default of 192000.  Higher the more accurate and most of my files are 44100, so I could probably look to change it to 352800....  Factor of 8.  I thought it would pick an even factor when oversampling.  My 44.1k resampled to 192k.

Re: foo_truepeak True Peak Scanner

Reply #167 –
Hi
May I ask only 2 questions ?

1) what could i do with all the information provided by the True Peak Scanner component ?
I mean should I use them with some normalization /replay gain or components or foobar features?

2) are there some old version avaible ? I liked the first version

Re: foo_truepeak True Peak Scanner

Reply #168 –
Boy, I see I have to do some major housekeeping in my compontents section, True Peak Meter looks great.
Got a question though... running FB2K 1.6.17 with True Peak Scanner 0.6.10
Was hoping I could use it to ditch DR Meter but looks like I'll need to hang on to that one a bit longer...
At first, I thought it had a problem with SACD releases (24bit/88.2kHz) as some columns stay empty.
But I get the same with a lot of my mp3's as well.  In the Status Column it says: "Failed to instantiate ReplayGain scanner". 
Likely as a result, the replay gain, LUFS-I and PLR columns are always empty.

Console says:
Error: failed to instantiate ReplayGain scanner.
Oversampling to 192000 (sometimes 220500) Hz with Resampler (RetroArch)

Default ReplayGain is configured to use RetroArch at 192000

Re: foo_truepeak True Peak Scanner

Reply #169 –
Quote from: Just_Addict on
Boy, I see I have to do some major housekeeping in my compontents section, True Peak Meter looks great.
Got a question though... running FB2K 1.6.17 with True Peak Scanner 0.6.10
Was hoping I could use it to ditch DR Meter but looks like I'll need to hang on to that one a bit longer...
At first, I thought it had a problem with SACD releases (24bit/88.2kHz) as some columns stay empty.
But I get the same with a lot of my mp3's as well.  In the Status Column it says: "Failed to instantiate ReplayGain scanner". 
Likely as a result, the replay gain, LUFS-I and PLR columns are always empty.

Console says:
Error: failed to instantiate ReplayGain scanner.
Oversampling to 192000 (sometimes 220500) Hz with Resampler (RetroArch)

Default ReplayGain is configured to use RetroArch at 192000



First off, I would install this SoX resampler component. I see you are using RetroArch to oversample.  Sox is preferred.
https://foobar.hyv.fi/?view=foo_dsp_resampler

Then in Foobar go to File > Preferences > Advanced > Enter "True" in the filter and at the top, change the minimum peak sample rate to 352800.  Higher rate the more accurate the results.  Also you want have even multiples of yor sampling rate, so 88.2k*4 = 352800.

I just scanned a SACD release (24bit/88.2kHz) with my Foobar 2.1.5 64 bit and the latest True Peak Scanner 0.6.10.  Worked just fine....

Console stated:
True Peak Scanning track: D:\Music\FLAC HD\Davis, Miles\1959 Kind of Blue (SACD 2.0) (88.2kHz-24bit)\Miles Davis - Kind of Blue (SACD 2.0) (88.2kHz-24bit) - 01 - So What.flac
Oversampling to 352800 Hz with Resampler (SoX)

Maybe, like you said, you need to clean some components up too...  Good Luck!

Re: foo_truepeak True Peak Scanner

Reply #170 –
Quote from: francesco on
Hi
May I ask only 2 questions ?

1) what could i do with all the information provided by the True Peak Scanner component ?
I mean should I use them with some normalization /replay gain or components or foobar features?

2) are there some old version avaible ? I liked the first version

I don't see any old versions available.  Not sure what you like better in those?  In the settings in the latest version you can turn on and off anything you want. 

There is a lot of info.  I have a post a few back which outlines some definitions for the scanned values.  The ones in bold below ar ethe ones I care about most and have added them as a column in my Foobar playlist.  I slightly revised it and pasted it here:

1.   Track and Album Peak- This is the common RG value. Very short-lived peaks in the audio.  Can be used to prevent gain adjustments from inducing clipping in the playback device.  True Peaks: Overshoots that can occur when the D/A converter is recreating the analog waveform, that don't normally show as peaks in the DAW. These become more likely the more something is smashed up near 0 dBFS and basically not going to happen if you aren't getting that close to 0.

2.   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
3.   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).  A complex algorithm measures loudness, analyzes how it's distributed throughout a song, determines a song's dynamics properties, and represents that with a number. The lower the number, the less dynamics. (Note that this is not about dynamic range, but rather, musical dynamics.)
4.   Track and Album Max LUFS-M - Momentary (0.4 seconds) measurement, as opposed to "I" which is the whole song.  The shown values are the highest readings recorded inside the track. Currently values are checked every 100 ms.
5.   Track and Album Max LUFS-S - Short Term (3 seconds) measurement, as opposed to "I" which is the whole song.  The shown values are the highest readings recorded inside the track. Currently values are checked every 100 ms.
6.   Track and Album LUFS-I - Similar to RG.  Measures perceived loudness of the entire song.  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.
7.   Track and Album PLR – Peak to long-term Loudness Ratio (PLR) is the difference between a signal's maximum true-peak level and its program loudness level. It's a long-term measurement that provides an overall value for a song, album, or section of audio. PLR is also known as the crest factor and is often used to describe a track's dynamics. Larger the number the more dynamic the track is. 
8.   Track and Album DR - The distance in dB between the softest sound and the loudest sound.
9.   Track and Album Clipped Samples - Any sample value that is beyond digital full-scale.  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.  If your file has 1 clipping sample it means it has a single peak above digital full-scale and only on one channel.  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. 
10.   Peak Timestamp - Time in track which contains the highest peak value.

Re: foo_truepeak True Peak Scanner

Reply #171 –
Quote from: Just_Addict on
Error: failed to instantiate ReplayGain scanner.
Oversampling to 192000 (sometimes 220500) Hz with Resampler (RetroArch)

Default ReplayGain is configured to use RetroArch at 192000
I can only think of two reasons why instantiation fails: foo_rgscan component isn't installed or the system is out of memory and can't allocate a few kilobytes. But sounds like you have ReplayGain scanner component installed if you can adjust its settings. The API doesn't return any extended information about failure reason.
And the reason I use core ReplayGain scanner instead of libebur is that Peter's code is much more optimized. I can perform all the extra work and still get results faster than just loudness estimation with libebur alone would be.

Re: foo_truepeak True Peak Scanner

Reply #172 –
@ngs428

hi
Quote
I don't see any old versions available.  Not sure what you like better in those?  In the settings in the latest version you can turn on and off anything you want. 
just because it was more simple , but after your post ,it 's everything more clear

Quote
There is a lot of info.  I have a post a few back which outlines some definitions for the scanned values.  The ones in bold below ar ethe ones I care about most and have added them as a column in my Foobar playlist.  I slightly revised it and pasted it here:
I know , but do you use all these informations for obtain some knowledge about audio files
or just to apply album/track replaygain ?

thanks , really appreciate your exhaustive answer , really

Re: foo_truepeak True Peak Scanner

Reply #173 –
Quote from: ngs428 on
I just scanned a SACD release (24bit/88.2kHz) with my Foobar 2.1.5 64 bit and the latest True Peak Scanner 0.6.10.  Worked just fine....

Console stated:
True Peak Scanning track: D:\Music\FLAC HD\Davis, Miles\1959 Kind of Blue (SACD 2.0) (88.2kHz-24bit)\Miles Davis - Kind of Blue (SACD 2.0) (88.2kHz-24bit) - 01 - So What.flac
Oversampling to 352800 Hz with Resampler (SoX)
You are scanning FLAC files in 88kHz/24bit/2ch which were originally converted from a SACD (iso), not the actual SACD (iso).
Scanning an SACD iso is a lot slower than just scanning hires FLAC.

Re: foo_truepeak True Peak Scanner

Reply #174 –
Quote from: Defender on
You are scanning FLAC files in 88kHz/24bit/2ch which were originally converted from a SACD (iso), not the actual SACD (iso).
Scanning an SACD iso is a lot slower than just scanning hires FLAC.
To quantify a lot slower ... here some results:

Testset is only 1x ISO with 12 tracks or 12 FLAC8 files, so utilization of CPU cores/threads is not optimal, but it gives a rough idea of what to expect.
All TP-scans with SOX resampler including LUFS-I, PLR, LRA, LUFS-S/M, DR and Clipping.