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 13749 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 #175
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!

Yeah, that didn't help either...
"[13:22:47] True Peak Scanning track: Z:\Music\AlbumsExt\Frank Sinatra\1957-00-00 - A Swingin' Affair! [2013 SACD] 24-88.2\01. Night And Day.flac
Error: failed to instantiate ReplayGain scanner
Oversampling to 352800 Hz with Resampler (SoX)"

I'm guessing it's the bold part in your msg above that's the kicker... for various reasons I can't (and won't) run the 64bit version...
In Advanced I set this

There's no Minimum Rate setting  in "File > Preferences > Advanced", neither something I can set to True, unless you meant the Aliasing/Imaging tickbox. 

In the regular preferences I could set this in the ReplayGain Scanner section choosing SoX as the resampler for True peak scan.


The dropdown in top has a list of values but doesn't have 352800 as choice, even though it accepts it if I just type it in. 
But even if I choose Upsample 4x (which comes to 352800 for my SACD's as well), I get the same error.

Re: foo_truepeak True Peak Scanner

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

Yeah, that didn't help either...
"[13:22:47] True Peak Scanning track: Z:\Music\AlbumsExt\Frank Sinatra\1957-00-00 - A Swingin' Affair! [2013 SACD] 24-88.2\01. Night And Day.flac
Error: failed to instantiate ReplayGain scanner
Oversampling to 352800 Hz with Resampler (SoX)"

I'm guessing it's the bold part in your msg above that's the kicker... for various reasons I can't (and won't) run the 64bit version...
In Advanced I set this

There's no Minimum Rate setting  in "File > Preferences > Advanced", neither something I can set to True, unless you meant the Aliasing/Imaging tickbox.

In the regular preferences I could set this in the ReplayGain Scanner section choosing SoX as the resampler for True peak scan.


The dropdown in top has a list of values but doesn't have 352800 as choice, even though it accepts it if I just type it in.
But even if I choose Upsample 4x (which comes to 352800 for my SACD's as well), I get the same error.

I am not quite sure what the issue is.  Maybe try a clean portable install and see if that works? 

As far as the preferences and setting to 352800, see attached. But that does not seem to be the issue. 

Re: foo_truepeak True Peak Scanner

Reply #177
@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

Only thing being applied is replay gain.  It is just shown here in LUFS-I.  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.  Now we can see the LUFS-I value and I attenuate to -18 LUFS which is the standard RG value.

Rest is just knowledge on what the "quality" of the file is...
Is there any clipping (clip may just be 0.1dB which may not matter though?  What is the DR?  How wide is the PLR?  Research those terms more if needed to see what works for you. 




Re: foo_truepeak True Peak Scanner

Reply #178
In the regular preferences I could set this in the ReplayGain Scanner section choosing SoX as the resampler for True peak scan.
Upon scan Truepeak scanner will use SOX resampler automatically  and will also automatically choose its upsample rate with a minimum samplerate as you entered in Advanced settings of Truepeak settings.

The dropdown in top has a list of values but doesn't have 352800 as choice, even though it accepts it if I just type it in.
But even if I choose Upsample 4x (which comes to 352800 for my SACD's as well), I get the same error.
See above.

You keep referring to SACD's. Are those (normal 88kHz/24bit/2ch) flac files or an SACD iso? Makes a big difference.

Re: foo_truepeak True Peak Scanner

Reply #179
I'm beginning to wonder if I actually need this one. Given that the replaygain value in foobar2000 is calculated from lufs-i, although I'm not comfortable interpreting lufs values, re-calculating back to lufs-i should be possible, and plr can be calculated again from the replaygain values in virtual columns with a formula. Lufs-m/s have also no real meaning for me. Wouldn't know how to interpret these either. Leaves DR and ALR  values. DR values I already had a component for...so ALR would be the only item I'd miss out on. Knowing how many frames get clipped is also not that big of a plus. Replaygain alone is a good indicator if clipping occurs, without knowing how high dB the clipped part was it's not that valuable info.

oh, almost forgot....
You keep referring to SACD's. Are those (normal 88kHz/24bit/2ch) flac files or an SACD iso? Makes a big difference.
Just normal flac files. But I get the same error with mp3's. I've only had it successfully work one time. But craft if I can find back on which track that was.

Re: foo_truepeak True Peak Scanner

Reply #180
Crap, forgot how archaic this forum software is. Can't edit your own posts... 

Anyways, I'm throwing the towel on this one. Have put way too many hours configuring the 32bit 1.6.17 I' on to risk losing it in upgrading to a 32bit 2.x version.


Re: foo_truepeak True Peak Scanner

Reply #182
ReplayGain scanner instantiation failing has nothing to do with source files.
Code: [Select]
replaygain_scanner_entry_v2::ptr rg_api;
if (replaygain_scanner_entry_v2::tryGet(rg_api)) {
  rg_scanner = rg_api->instantiate(replaygain_scanner_entry_v2::flagScanGain);
}
if (!rg_scanner.is_valid()) // Failed to instantiate ReplayGain scanner.
The code doesn't care about anything else. Core is just asked to give the component a ReplayGain scanner instance and for reasons unknown it fails for you. In my previous post I mentioned the only two reasons I knew of why RG scanner instantiation could fail. foobar2000 version was not a factor, the method has been supported for ages and works on all versions where the component works.

But now I did some more testing as I remembered an old troublemaker. Turns out https://www.foobar2000.org/components/view/foo_arg component breaks RG scanner instantiation. If you have had that component installed all your RG scan results are invalid.

PS: post editing not working after an hour is not about forum software being archaic. It's intentionally limited as editing old posts doesn't help with conversation. No one who follows the discussion would see edits done to old posts as they have already read the original posts and moved on. If you have some meaningful new information make a new post.

Re: foo_truepeak True Peak Scanner

Reply #183
Turns out https://www.foobar2000.org/components/view/foo_arg component breaks RG scanner instantiation. 
Bingo, that was the culprit, completely forgot about that one. 
Nevertheless, like I said in my earlier post, half of the values it shows I have no idea how to interpret, they don't mean anything to me. The ones that I am comfortable interpreting I can derive with title formatting (Album/Track Peak, Album/Track PLR) and DR Meter gives me the rest. Although it's too bad the latter only saves the DR values and not the Peak and RMS dBFS values. If I knew how to calculate those with title formatting script I'd have my cake and eat it too.

Re: foo_truepeak True Peak Scanner

Reply #184
But now I did some more testing as I remembered an old troublemaker. Turns out https://www.foobar2000.org/components/view/foo_arg component breaks RG scanner instantiation. If you have had that component installed all your RG scan results are invalid.

I've been alternating between the alternate RG component and the inbuilt one. I have no idea which I was using at the time of scanning many of my albums., and I've always tagged the files once scanning is done. Does this mean that I will need to rescan and retag them, or does the issue merely prevent the scanning from happening in the first place? If it's the latter then I would have noticed and I don't need to do anything.

Re: foo_truepeak True Peak Scanner

Reply #185
That component completely breaks the math used in RG scanner and the results can have several dB differences to correct loudness estimation. It also seems to break true peak scanning of the first party RG scanner, the results are not from oversampled data. I see no sense in using it at all.

Re: foo_truepeak True Peak Scanner

Reply #186
and DR Meter gives me the rest. Although it's too bad the latter only saves the DR values and not the Peak and RMS dBFS values. If I knew how to calculate those with title formatting script I'd have my cake and eat it too.
You can't calculate this data from anything but the actual audio data. The peak is just PCM peak without oversampling. If you prefer that over true peak the RG scanner can write it. The RMS value used by DR meter is calculated from the PCM in a custom way, it's different from standard RMS calculations and storing it makes no sense.
If there is wish to get standard RMS value of a track, that can be added to True Peak scanner. It already has option overload, one more option wouldn't be a problem at this point.

Re: foo_truepeak True Peak Scanner

Reply #187
and DR Meter gives me the rest. Although it's too bad the latter only saves the DR values and not the Peak and RMS dBFS values. If I knew how to calculate those with title formatting script I'd have my cake and eat it too.
You can't calculate this data from anything but the actual audio data. The peak is just PCM peak without oversampling. If you prefer that over true peak the RG scanner can write it. The RMS value used by DR meter is calculated from the PCM in a custom way, it's different from standard RMS calculations and storing it makes no sense.
If there is wish to get standard RMS value of a track, that can be added to True Peak scanner. It already has option overload, one more option wouldn't be a problem at this point.
The more (optional additions) the merrier.

However it raises two RFC's from my side:

1) Who do I address asking to make the size of the Preferences screen resizable which saving current dimensions upon exiting Preferences. Current fixed size is some 720x512 pixels which is a bit archaic nowadays.

2) "Item properties" and "JSP3 Properties+Other Info" (which I use) have separate groupings for Metadata, General, Location, Enhanced playback statistics, Playback statistics and ReplayGain. Since there are so many (useful) things that TPS can write as tags, it would be quite nice if all metadata created by TPS would have it's own grouping under Truepeak Scanner.
Would that be possible to do this (or alternatively have the TPS tags grouped with Replaygain)?

Re: foo_truepeak True Peak Scanner

Reply #188
That component completely breaks the math used in RG scanner and the results can have several dB differences to correct loudness estimation. It also seems to break true peak scanning of the first party RG scanner, the results are not from oversampled data. I see no sense in using it at all.
Apologies, I had the foo_arg RG component confused with the foo_dsp_replaygain RG component below, as they both describe themselves as "Alternative ReplayGain".
https://foobar.hyv.fi/?view=foo_dsp_replaygain

Re: foo_truepeak True Peak Scanner

Reply #189
1) Who do I address asking to make the size of the Preferences screen resizable which saving current dimensions upon exiting Preferences.
That would be Peter of course. But I'm not certain it can be done. All existing components are coded for the static size. Compatibility is a powerful force with foobar2000 - originally v2.0 was supposed to be a clean break with just 64-bit support but compatibility with old stuff won there too.

2) [...] it would be quite nice if all metadata created by TPS would have it's own grouping under Truepeak Scanner.
Would that be possible to do this (or alternatively have the TPS tags grouped with Replaygain)?
I don't think existing category can be expanded by a third party component, but I can create own category. I'll keep this in mind.

Apologies, I had the foo_arg RG component confused with the foo_dsp_replaygain RG component below, as they both describe themselves as "Alternative ReplayGain".
https://foobar.hyv.fi/?view=foo_dsp_replaygain
That makes sense. My DSP doesn't affect any scanning results as it's just a DSP. It's of course safe to use for applying gain correction during playback or in converter (though smart mode selection only works during playback).

Re: foo_truepeak True Peak Scanner

Reply #190
I'd love to have RMS for whole tracks too, so I vote do it! :) Please also offer the choice of "regular" and "AES +3dB" RMS, to cover all bases.

Re: foo_truepeak True Peak Scanner

Reply #191
Thanks for the great plugin. Very handy for comparing different codecs and settings.

What’s the point of repeating units of measurement in each cell of the table? It would be more convenient to have purely numeric values without text units for copying into a table, so as not to have to parse the brackets/dBTP/LU every time.

Regarding measuring dynamics. If the plugin can measure momentary- and short-term unfiltered true peaks and K-weighted LUFS-M and LUFS-S, you can take the next step and calculate average PMR and PSR values, which would be much more informative than PLR.

Re: foo_truepeak True Peak Scanner

Reply #192
@Case

There's a small bug I'd detected earlier (some 6 versions ago) and is still there.

Starting foobar and first action is TPS on a DVDA-iso, foobar rarely (!) crashes to the desktop. No crashdump is written.
Happened this morning again.

While testing a bit more (first action TPS on DVDA-iso after starting foobar), when I hit abort on the scan scan foobar and the TPS progress window froze. Had to kill via taskmanager. Foobar wrote empty crashfiles.

Did the same test again and this time hitting abort crashed foobar to the desktop. Crashdump was written and hereby attached.

So there is definitely something fishy between the combination of foobar, dvda plugin and tps plugin.
I'm using latest x86 beta with  currently TPS 0.6.11, foo_input_dvda 0.7.3.

Not a big deal of course this bug(s) since I don't scan DVDA-iso that much, but if you have the time you might take a look at it.

Re: foo_truepeak True Peak Scanner

Reply #193
The failure txt call stack shows activity from several components, but mostly and right before errors from foo_input_dvda. No True Peak Scanner activity visible at all. Loading the minidump in debugger doesn't show TPS involvement either. Looks like a problem in DVDA input.

Re: foo_truepeak True Peak Scanner

Reply #194
The failure txt call stack shows activity from several components, but mostly and right before errors from foo_input_dvda. No True Peak Scanner activity visible at all. Loading the minidump in debugger doesn't show TPS involvement either. Looks like a problem in DVDA input.
I was afraid that would be your answer :-)

Re: foo_truepeak True Peak Scanner

Reply #195

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

@Case is there a dB threshold where one can expect to hear this clipping?  That is about the only way I think one could present this into a concise single value, well maybe 2 values.  One being total clips and one being clips beyond a certain dB threhold.

Re: foo_truepeak True Peak Scanner

Reply #196
@Case is there a dB threshold where one can expect to hear this clipping?  That is about the only way I think one could present this into a concise single value, well maybe 2 values.  One being total clips and one being clips beyond a certain dB threhold.
IMO you should normalize total clipping samples also for tracklength/albumlength and samplerate. I now normalize to 44kHz/16bit and show the amount of seconds of clipping per hour. Your remark about dB threshold is of course completely valid and something I struggle(d) with too.

I colorcode the resulting seconds per hour completely arbitrary:
Code: [Select]
	$puts(cht.raw,[%truepeak_scanner_clipped_samples_track%])
$if($get(cht.raw),
$ifgreater($get(cht.raw),0,
$puts(cht.cph_samples, $muldiv($get(cht.raw)000000,3600,%length_seconds_fp%)) $puts(cmt, Clipped samples per hour times 1000000)
$puts(cht.cph_seconds, $div($get(cht.cph_samples),%samplerate%)) $puts(cmt, Clipped seconds per hour times 1000000)

$puts(round.raw,000000$trim($get(cht.cph_seconds)))
$puts(round.value,$add(0,$cut($get(round.raw),$sub($len($get(round.raw)),6))).$right($get(round.raw),6))
$puts(cht.val,%CODE.ROUND3%$get(round.result))

$puts(cht.cd,CH-$get(cht.val)s)

$puts(cht.max,99.999)
$ifgreater($get(cht.val),$get(cht.max),
$puts(cht.cd,CH-$get(cht.max)M)
$puts(col.cht,  %COL.RED%)
,
$ifgreater($get(cht.val),19,
$puts(col.cht,  %COL.RED%)
,
$ifgreater($get(cht.val),9,
$puts(col.cht,  %COL.ORANGE%)
,
$ifgreater($get(cht.val),0,
$puts(col.cht,  %COL.YELLOW%)
,
$puts(col.cht,  %COL.GREEN%)
))))
,
$puts(cht.cd,CH-NONE) $puts(col.cht, %COL.GREEN%)
)
,
$puts(cht.cd,CH-N/A) $puts(col.cht, %COL.YELLOW%)
)

Re: foo_truepeak True Peak Scanner

Reply #197
@Case

TPS 0.6.12.
You can now write RMS. In settings you can choose what method ... whether normal or AES +3dB mode. The tag you write for both methods is the same, so there is no way to determine afterwards which method was used. Kind of the issue I had with the original RG values not being able to determine what settings were used upon scan.

Re: foo_truepeak True Peak Scanner

Reply #198
What’s the point of repeating units of measurement in each cell of the table?
Units need to go somewhere. They take less space behind the numbers than in the column titles.

Regarding measuring dynamics. If the plugin can measure momentary- and short-term unfiltered true peaks and K-weighted LUFS-M and LUFS-S, you can take the next step and calculate average PMR and PSR values, which would be much more informative than PLR.
I fail to see how. Those might be ok in a realtime meter but there are already several proper loudness values that are designed to work for entire track.

is there a dB threshold where one can expect to hear this clipping?  That is about the only way I think one could present this into a concise single value, well maybe 2 values.  One being total clips and one being clips beyond a certain dB threhold.
I'm not aware of studies about clipping audibility. But I think too many factors affect that, for example in loud metal music it would certainly not be as bad as in some smooth violin play.
The functionality for extra clipping data gathering is on hold for now.

PS: New version with RMS scanning option added. I hope I didn't break anything while I simplified some things internally.

Re: foo_truepeak True Peak Scanner

Reply #199
You can now write RMS. In settings you can choose what method ... whether normal or AES +3dB mode. The tag you write for both methods is the same, so there is no way to determine afterwards which method was used.
You can change the tag field name for your own knowledge. Other than that no.