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.

Fine. We disagree. My request for change was addressed to Case not to you.

Quote from: Defender on 2024-04-05 01:15:26

Fine. We disagree. My request for change was addressed to Case not to you.

And that's perfectly fine. And as another user using this plugin, I also give feedback to Case to not remove existing functionality for no reason xd Changing tag names? Great. Removing entirely the possibility to change tag names? Nope.

All your "problems" are gone if you share the plugin config files with your skin. Set your tags as you like, and share the config file. Profit.

You seem to ignore that part  If you don't want to share a skin in a proper way, ok... but then don't convert your problem in everyone's problem.

Me xd and that's why I request it.

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.

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.

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.

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?

The field names are configurable because there is no standard for them. If there are other tools that do the same I would love to use the same names. Interoperability is important. But if there is no standard or widespread naming convention for something, I don't want to force a potentially silly name.

I'm not skinning expert but if you wish to use non-standard fields, I would make it super easy for users to customize them.

You do realize that this component is 10 years old

The gain values are quite new but they were added for a version released on Sunday, it's not a beta version.

Now I'm confused. Earlier you wanted custom tags to start with "truepeak", now you want fields to resemble existing replaygain tags?

Talking about tag names, I would like to change the default "truepeak_scanner_clipped_samples" field to include indicator that it's for a track now that I was asked to add another field for album. With current naming convention the tag should obviously be called "truepeak_scanner_clipped_samples_track".
I'm open to suggestions to all default tag names.

"replaygain_track_range" and "replaygain_album_range" as being used by some tools to store LRA. If that's the case I would like to use the same fields, in which case configuration of LRA tag field names can be removed.

Quote from: Case on 2024-04-05 10:39:22

The field names are configurable because there is no standard for them. If there are other tools that do the same I would love to use the same names. Interoperability is important. But if there is no standard or widespread naming convention for something, I don't want to force a potentially silly name.

I'm not skinning expert but if you wish to use non-standard fields, I would make it super easy for users to customize them.

Skins based on CUI Panel Splitters and ELP have very limited options for user configurability. In ELP I have a kind of workaround to achieve this, but in PSS it is impossible, which means I have to use $if3(tag,synonym1,synonym2,etc) and add every new tagname for the same thing to the code. I do use a central routine which sanitizes tags like artist, trackartist, albumartist (because tagging is often a mess) and I only use these sanitized tags in the rest of the code. So if I have to I will add the if3's to that routine and create sanitized tags for all user configurable truepeak tags to use in the rest of the code.

Quote from: Case on 2024-04-05 10:39:22

You do realize that this component is 10 years old

Nope. Search in this forum has never worked for me which is quite a nuisance because I'm pretty sure I'm asking things that have been asked a million times before.

Quote from: Case on 2024-04-05 10:39:22

The gain values are quite new but they were added for a version released on Sunday, it's not a beta version.

Same thing. I did not know. It's not in browse components. Best site I find to follow to check for updates is an external Japanese url.

Quote from: Case on 2024-04-05 10:39:22

Now I'm confused. Earlier you wanted custom tags to start with "truepeak", now you want fields to resemble existing replaygain tags?

It is simple. In a perfect world I would like all the tags that are custom to this component to have tagnames starting with truepeak. If you have reasons to not do this, fine. If that is the case and you introduce similar fields for gain then follow the naming convention for the earlier fields. I asked, nothing more than that too it. I just like things to be consistent and standardized. And I'm certainly not a fan of optional tagnames for reasons I think I explained. That said ... If tagnames are optional I will never change the default they come with upon installation, because most people probably won't change them so chances are best to write your code based on this defaults.

Quote from: Case on 2024-04-05 10:39:22

Talking about tag names, I would like to change the default "truepeak_scanner_clipped_samples" field to include indicator that it's for a track now that I was asked to add another field for album. With current naming convention the tag should obviously be called "truepeak_scanner_clipped_samples_track".
I'm open to suggestions to all default tag names.

"replaygain_track_range" and "replaygain_album_range" as being used by some tools to store LRA. If that's the case I would like to use the same fields, in which case configuration of LRA tag field names can be removed.

It's consistent, so I'm all for it. And I personally don't mind if you would change tagnames for relatively new fields now. I read these tags  only once in a central routine and the required rescanning to write these renamed tags is fast as well (since I don't want to introduce the dreaded if3's lightly).
The nature of a forum is unfortunately that there's always people that are going to object for valid or obscure reasons.
I like you're open to suggestions, but it is your tool and not a democracy, you decide, I'll follow.

If those changes would mean we have to rescan all files or make some other huge changes I would voto - NO - do not change it. It is good.

Released a new version with the Loudness Range (LRA) ability included. Download from https://foobar.hyv.fi/?view=foo_truepeak.

There are also some internal changes. I did a lot of peak testing and speed testing and noticed that apart from full integer oversample factors being faster in (all) resamplers, SoX resampler really likes when resampling factors are powers of two. Since SoX is also generally fastest I made the component automatically try to pick SoX resampler. If it finds it, it will use a power of two oversample factor for speed. That will also give even better peak accuracy as it means higher sampling rate.

I also improved resource dialog by adding a visible status column when needed even for minor issues and not just fatal errors. And results are more pleasant to look at as dialog uses real unicode minus signs so plus and minus have identical widths.

The default clipped sample field name is changed, but if a configuration already exists it won't get automatically reset. You can right click on the field name and select 'Reset' to get the new default name.

If you look at the console output while the component is scanning or after scanning is done you can see it report information like "Oversampling to 352800 Hz with Resampler (SoX)".
The default oversampling multiplier is calculated by dividing the minimum wanted sampling rate by the source material sampling rate. If the result isn't a full integer, the multiplier gets rounded up to next full integer. For example the 88 kHz source you mentioned would give an oversampling factor of 3 with the default 192 kHz minimum sampling rate (192 kHz ÷ 88 kHz ≅ 2.18, fractional result gets rounded to next full number 3). But if SoX resampler is found, the multiplier gets rounded up to the next number that is a power of two. With these example numbers that would mean 4 x oversampling.
For 176 kHz source file the oversampling factor would be 2 with the default minimum sampling rate target. 2 is a the smallest full integer and it's also a power of two.
But for example 192 kHz ÷ 44.1 kHz ≅ 4.35, normal oversampling ratio would be 5 x but with SoX it would be 8 x.

The default clipped sample field name is changed, but if a configuration already exists it won't get automatically reset. You can right click on the field name and select 'Reset' to get the new default name.

If you look at the console output while the component is scanning or after scanning is done you can see it report information like "Oversampling to 352800 Hz with Resampler (SoX)".
The default oversampling multiplier is calculated by dividing the minimum wanted sampling rate by the source material sampling rate. If the result isn't a full integer, the multiplier gets rounded up to next full integer. For example the 88 kHz source you mentioned would give an oversampling factor of 3 with the default 192 kHz minimum sampling rate (192 kHz ÷ 88 kHz ≅ 2.18, fractional result gets rounded to next full number 3). But if SoX resampler is found, the multiplier gets rounded up to the next number that is a power of two. With these example numbers that would mean 4 x oversampling.
For 176 kHz source file the oversampling factor would be 2 with the default minimum sampling rate target. 2 is a the smallest full integer and it's also a power of two.
But for example 192 kHz ÷ 44.1 kHz ≅ 4.35, normal oversampling ratio would be 5 x but with SoX it would be 8 x.

%truepeak_scanner_clipped_samples_track%

$if2(%truepeak_scanner_clipped_samples_track%,%truepeak_scanner_clipped_samples%)

[%truepeak_scanner_clipped_samples_track%]

or for the longer one:
[$if2(%truepeak_scanner_clipped_samples_track%,%truepeak_scanner_clipped_samples%)]

[$replace($if3(%replaygain_track_range%,%lra_track%,%lra%), LU,, dB,,)]

[$if2(%truepeak_scanner_clipped_samples_track%,%truepeak_scanner_clipped_samples%)][/%truepeak_scanner_clipped_samples_album%]

$replace([$if3(%replaygain_track_range%,%lra_track%,%lra%)][/$if2(%replaygain_album_range%,%lra_album%)], LU,, dB,)

Thanks marc2k3. I certainly don't like bright decorations that don't belong.
I added the DR scanning as an option to True Peak Scanner, and implemented the darkening changes there first. It was surprisingly difficult to make Windows use the new style, I couldn't make it work except by programmatically adjusting the dialog size.