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 11731 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 #100
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.

Re: foo_truepeak True Peak Scanner

Reply #101
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)

Re: foo_truepeak True Peak Scanner

Reply #102
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)),))

Re: foo_truepeak True Peak Scanner

Reply #103
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.

Re: foo_truepeak True Peak Scanner

Reply #104
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.

 

Re: foo_truepeak True Peak Scanner

Reply #105
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%)

Re: foo_truepeak True Peak Scanner

Reply #106
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?

Re: foo_truepeak True Peak Scanner

Reply #107
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.


Re: foo_truepeak True Peak Scanner

Reply #109
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! 

Re: foo_truepeak True Peak Scanner

Reply #110
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.

Re: foo_truepeak True Peak Scanner

Reply #111
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.
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.

Re: foo_truepeak True Peak Scanner

Reply #112
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.
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!

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #114
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.

Re: foo_truepeak True Peak Scanner

Reply #115
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.

Re: foo_truepeak True Peak Scanner

Reply #116
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.

Re: foo_truepeak True Peak Scanner

Reply #117
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.

Re: foo_truepeak True Peak Scanner

Reply #118
The LUFS test version at 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.

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #120
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).

Re: foo_truepeak True Peak Scanner

Reply #121
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.

Re: foo_truepeak True Peak Scanner

Reply #122
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.

Re: foo_truepeak True Peak Scanner

Reply #123
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:
Code: [Select]
$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,)
)

Re: foo_truepeak True Peak Scanner

Reply #124
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.