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 5079 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 #25 –
Quote from: Case on
Did you see tag overwrite issue with the latest 0.5.2 version? The tag update should only by skipped if all the tag information that would be written already perfectly matches what is in the files.

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

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

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

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

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

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

Re: foo_truepeak True Peak Scanner

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

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

Re: foo_truepeak True Peak Scanner

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

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

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

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

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

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

Re: foo_truepeak True Peak Scanner

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

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

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

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

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

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

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

Re: foo_truepeak True Peak Scanner

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

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

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

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

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

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

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


It's optional to overwrite ReplayGain values ...

Re: foo_truepeak True Peak Scanner

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

Quote from: Defender on
BTW. You mention a button in your release notes. Out of curiosity ... where is this button? I only see the context menu which does not have an export function. Is there a panel/toolbar I'm missing?
There is a 'Copy' button in the result dialog between the 'Update File Tags' and 'Cancel' buttons. That copies all the information to clipboard and can be pasted to notepad or Excel.

Quote from: wojak on
Please do not make your component overwrite RG. I like it as it is. I use RG to scan for RG and TruePeak and I run your component for Clips and Timestamps. Let it be that way.
As @Defender said, default behavior is unchanged. This is just an optional additional feature that can be helpful.

Re: foo_truepeak True Peak Scanner

Reply #31 –
@Case

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

@All

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

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

What would be a reasonable colorcode in your opinion?

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

Re: foo_truepeak True Peak Scanner

Reply #32 –
Quote from: Defender on
I noticed that foobar reports the same number of total samples for the same track regardless of the number of channels.
Is it correct to assume you report clipped samples as 1 extra clipped sample even if more channels clip in the same sample?
If I understood your question correctly, no, I don't report extra clipped samples.
In foobar2000 terminology "a sample" actually contains the samples from all channels. I consider "a sample" to be a sample value of a single channel.
So one clipping sample means that only one channel clipped. If same spot clipped on all channels of a 384 channel recording, it would be shown as 384 clipped samples.

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

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

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

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

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

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

Would you be interested in more statistics in the output? Just knowing that samples clip doesn't yet tell how bad it is. Exceeding the full scale by 0.1 dB would not matter at all, but exceeding it by 3 dB could be a problem.
I could for example log how large percentage of clipping exceeded full scale by 1 dB, how much by 2 dB, etc.

Quote from: Defender on
Values vary a lot between albums. A weird one is the Porcupine DVDA. The 6ch mix has 18x more clipping (still not a lot though) than the 2ch mix both on the same DVDA.
Also converting a flac to mp3 introduces extra clipping.
Lossy encoding changes the waveform and almost always causes peaks to go higher. There are scientific explanations for this and it's expected behavior.

Re: foo_truepeak True Peak Scanner

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

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

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

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

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

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

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

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.

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

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

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

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

Re: foo_truepeak True Peak Scanner

Reply #34 –
Hi @Case,

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

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

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

Re: foo_truepeak True Peak Scanner

Reply #35 –
Quote from: Defender on
With s/h you mean samples per hour? Point is that I also wanted to normalize result so that the samplerate is out of the way.
I meant just correcting the unit. If an info panel somewhere says there is "1 s" of clipping it would be interpreted as absolute value for the track (or album) in question. Saying that there is 1 second of clipping per hour would be correct way to inform about the situation. The meaning of 's' in my example remained the same: seconds.

Re: foo_truepeak True Peak Scanner

Reply #36 –
Quote from: Case on
Quote from: Defender on
With s/h you mean samples per hour? Point is that I also wanted to normalize result so that the samplerate is out of the way.
I meant just correcting the unit. If an info panel somewhere says there is "1 s" of clipping it would be interpreted as absolute value for the track (or album) in question. Saying that there is 1 second of clipping per hour would be correct way to inform about the situation. The meaning of 's' in my example remained the same: seconds.

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

Re: foo_truepeak True Peak Scanner

Reply #37 –
Quote from: wojak on
could you please explain why does your component measure a little differnt than the built in RG? The results differ by about 0,1/0,2.
Is there a different standard or by design those calculations are not precise (guesstimation)?
Native ReplayGain scanner doesn't follow any standard. It just offers an option to upsample using a resampler and settings of your choosing.

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

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

Quote from: wojak on
Plus what exactly Clippings measured in your component mean?
Any sample value that is beyond digital fullscale.

Quote from: wojak on
Then how does RG applying work. If we measure RG, Clips, True Peaks and use Album mode we can then use 4 options:
- none - obvious
- apply gain
- apply gain and prevent clipping from peak value
- prevent clipping from peak value
What does apply gain really mean - does it just turns the volume up or down (usually waaay down)?
It means same as volume adjustment. It adjusts the playback level so that each track or each album have identical loudness and listener doesn't have to touch volume settings.

Quote from: wojak on
If we use prevent from clipping does it change the volume but to a degree not to produce clippings so for example it would turn the volume up by 3 but then it would clipp so it turns up by ex. 2 not to clip?
The 'apply gain and prevent clipping from peak value' adjusts the level but if the peak value tells things would clip, the level is lowered just enough to keep the peaks inside digital fullscale. In track mode this adjustment is done for each track, in album mode all tracks are adjusted by the same decibel amount as much as is needed to prevent the track with highest peak from clipping.

Quote from: wojak on
Does the "prevent clipping" option (without applying gain) mean that if there are 0 clippings on the album it would do nothing but if there were clippings it would turn the volume of the album as much as needed to avoid clipping? In album mode would it do exactly the same amount in every track?
It works exactly like that. If the peaks are below full scale the signal is not touched at all. If the peaks are too high, the level is adjusted. In track mode each track is adjusted separately, in album mode the entire album is adjusted by the same amount.

Quote from: wojak on
So now what would be the best way to make it louder. I use USB-ASIO DAC with foobar and DAC volume at max level so I change the volume with a manual knob othe amplifier. Would it be better to use foobars built-in Preamp (the one below RG section in the preferences) or might that produce Clips?
I don't think you need to worry about hiss. Keeping DAC and Windows volumes at maximum will ensure highest signal to noise ratio to the amp, which is of course good. For ReplayGain to work it needs the headroom for the louder material, so it would be best if you didn't try to fight it. But using the preamp slider in foobar2000 is the correct way to increase the loudness of ReplayGained output. Increasing the preamp will of course make clipping more likely, but as long as it's lower than the negative gain values shown for your tracks/albums, it won't introduce any additional clipping.

Quote from: wojak on
So to sum it up - is applying RG an equivalent of just turning the volume knob on amp up/down or does it do something else?
It works like volume knob but since it's done before the DAC it can prevent clipping of intersample peaks or floating point material that would clip in the DAC.

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

Re: foo_truepeak True Peak Scanner

Reply #38 –
@Case

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

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

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #40 –
Quote from: Case on
The very first option in the component's preferences is the titleformat string that defines how albums are grouped. Remove the discnumber bit if you wish to ignore it.

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

EDIT: That was a quick fix

Re: foo_truepeak True Peak Scanner

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

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #45 –
Been playing around with the beta. It's excellent.

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

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

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

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

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

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

Re: foo_truepeak True Peak Scanner

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

Re: foo_truepeak True Peak Scanner

Reply #47 –
Quote from: regor on
Forcing everybody to lose functionality and have specific tags just for your skin doesn't really make sense... Just share the config files if you want to force specific settings or write a readme.

?

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

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

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

Re: foo_truepeak True Peak Scanner

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

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

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

Re: foo_truepeak True Peak Scanner

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

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

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

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