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 54016 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 #226 –
hi Case, thanks for this awesome scanner plugin.

I am just wondering if we can have an option to save the true peak values in dB format? e.g. when true peak is 0.733081, store the value into a customized tag as -2.7 dB or +2.7 dB?

The reason for this requirement is that I'd like to have a workaround solution for *peak* normalization, which replaygain scanner does not support. i wish to have a replaygain tag of +2.7dB when the peak is -2.7dB, so that it can result into playing the audio with 0dB in its peak.

i've searched thru the forum and there were some posters requiring *peak* normalization solutions, but still there is no solution to write tags for peak normalization. i wish this true peak scanner plugin can be improved to cater for this use case. Many many thanks!

Re: foo_truepeak True Peak Scanner

Reply #227 –
This string will give you the True Peak figure in dB for the column readout, but not sure about tagging:

%replaygain_track_peak_db%

Re: foo_truepeak True Peak Scanner

Reply #228 –
"-8,21 LUFS" - You're using a comma, isn't a period much more common worldwide? Did you take locale into consideration (my os is speaking german)? I prefer a period to keep things more, i.e. compatible. Personally I do not like the german comma approach, for me comma delimits lists.

Re: foo_truepeak True Peak Scanner

Reply #229 –
@Case is there a possibility to get the latest 0.6.14 version with the clipping statistics in the console (as tested here: Reply #165 – 2024-05-23)?  I've found that useful for analyzing individual tracks.

Re: foo_truepeak True Peak Scanner

Reply #230 –
Quote from: Squeller on
"-8,21 LUFS" - You're using a comma, isn't a period much more common worldwide?
That depends. With India and China moving to the dot, you might argue it is. Most of Europe, Africa and South America use comma, at least officially. And Arabic - it has its own Unicode comma though.
Some Brits still use interpunct.

"821e-3" could solve the problem ;-)

Re: foo_truepeak True Peak Scanner

Reply #231 –
HI @Case ,
Can we have this component detected audio beat and write to track's metadata/tag ?

why :
      to some extent, we may consider audio beat as genre pop, rock, waltz . . . but we may not have these tags embedded.  
      we may need these information to build an auto DJ by beat query.

metadata format:  BPM, timestampe1, timestampe2, timestampe3 . . .
where:
  + BPM: beat per minute, 'considered' as beat
  + timestamp:  beat detected timestamp (mm:ss:ms)

Thank you in advance.
@ilovefb2k

Re: foo_truepeak True Peak Scanner

Reply #232 –
Sorry, but beat detection is unrelated to what this component wants to measure.

Re: foo_truepeak True Peak Scanner

Reply #233 –
Quote from: Case on
Sorry, but beat detection is unrelated to what this component wants to measure.
Hi @Case,
Thank you for your reply.
Hoping that, just in case, you develop something similar and this comes across your mind.
Regards,
@Ilovefb2k.

Re: foo_truepeak True Peak Scanner

Reply #234 –
Quote from: ngs428 on
@Case is there a possibility to get the latest 0.6.14 version with the clipping statistics in the console (as tested here: Reply #165 – 2024-05-23)?  I've found that useful for analyzing individual tracks.

@Case not sure if you saw my post from a week back?

Re: foo_truepeak True Peak Scanner

Reply #235 –
I saw it but had no time to act. I transplanted the extra reporting code to latest version and refreshed the test component.

Re: foo_truepeak True Peak Scanner

Reply #237 –
Hi!
I recently started using the plugin. Great tool! And I have a couple of questions.
Why are the DR readings higher than the Dynamic Range Meter values? I'm used to certain numbers in the old calculation and I can't figure out the logic of the new one yet.
Is it possible to output a separate DR calculation with two decimal places? As far as I know, this parameter has a very useful internal calculation, judging by the description in old manuals. It calculates the average volume for the 20% loudest parts of the track. Very useful for understanding the distribution of integrated volume. I was always confused by the fact that it is cut down to one digit, I would like to get more accuracy. I tried using LRA. But it does not give the desired impression, since it uses only the minimum and maximum in the calculation, if I understand correctly.

Re: foo_truepeak True Peak Scanner

Reply #238 –
The DR numbers could be higher because at least the old foobar2000 component clipped samples. This one uses the full dynamic range without clipping. I don't know about other DR meters.
More decimals in DR number offer no value, they won't be added here. But if want to see them out of curiosity, you can use my dedicated DR Meter. Note that the other loudness measurements are based on established standards. LRA is not as simple as you mentioned. DR is just a simple ratio between a peak and RMS of the loudest parts. It doesn't care anything about perceived loudness or durations or anything.

Re: foo_truepeak True Peak Scanner

Reply #239 –
Quote from: Case on
The DR numbers could be higher because at least the old foobar2000 component clipped samples. This one uses the full dynamic range without clipping. I don't know about other DR meters.
More decimals in DR number offer no value, they won't be added here. But if want to see them out of curiosity, you can use my dedicated DR Meter. Note that the other loudness measurements are based on established standards. LRA is not as simple as you mentioned. DR is just a simple ratio between a peak and RMS of the loudest parts. It doesn't care anything about perceived loudness or durations or anything.
About LRA, I read the specs. Its not a simple calculation, I agree.
But I see the value of DR in conjunction with RMS. The simplest example is with a hospital and the temperature of patients. LRA is the difference between the temperature of the sickest person with a fever and the temperature of the coldest corpse in the morgue, regardless of the number of patients. It does not say anything about how many healthy people are in the hospital. DR tells you the temperature of 20% of patients with the highest values. Much more informative for understanding the health of the entire hospital.

The best part of calculating DR, in my opinion, is that it takes into account the percentage of time ranked by volume, and not the time itself. Integral characteristic.

If you subtract DR from RMS, this indicator says a lot about the macrodynamics of the track.
You just need to get used to the numbers. Unfortunately, the difference in rounding lets you down. I would really like to be able to write in the DR tag without rounding in order to apply this formula. But unfortunately, even your DR Meter does not allow you to do this. Only manual copying from the analysis results via clipboard, pasting via Massstager. That's how we live :-)

P.S.: A good example of why LRA is not the best indicator of macrodynamics is, for example, Dua Lipa - Future Nostalgia and the song Love Again. Literally one fairly long piece at a very quiet volume at the beginning of the song, and LRA increases from 5-6 average for the album to 11. Although the song does not stand out from the rest of the album in terms of sound.
In any case, thanks for the answer and your plugins.

Re: foo_truepeak True Peak Scanner

Reply #240 –
Your conclusions seem completely backwards. It's DR that would get completely bogus temperature results for the hospital as it only accounts for a minor sample. LRA takes the entire scene into account.
Also your description of the Dua Lipa song perfectly demonstrated that LRA took the unusual silent part into account as it seems to be different track from the others on the album.

Re: foo_truepeak True Peak Scanner

Reply #241 –
I don't understand why the result files are loud after conversion, peaks exceed 1. If you may please have a look? 2 Albums, first album is the first 8 tracks, then the last 7 tracks is the second album.

I have attached ReplayGain resports of the source FLAC file and the target m4a. My goal in this case is just put album levels smaller/close to 0 db. But it turns I cannot really control it.

EDIT: AH, a logical issue. Now I see my flawed thinking. I was expecting RG_Alt to fix everything no matter what - but of course if it acts depending on the source file RG values, but via the VLevel DSP I make gain changes which it doesn't know, the whole idea is flawed.

Well I could let RG_ALT always scan but I remember you wrote, it may not complete the scan... Hmmm.

X
X
X

Re: foo_truepeak True Peak Scanner

Reply #242 –
Yeah, it seems usually the scanning will not be finished, because if I check "Allow volume increase if peak is uncertain" the result is often some distorted loud tracks with +10db etc... So I think indeed the peak was uncertain. I conclude that in a converter chain with (massive) gain changes in between, foo_rg_alternative cannot help. Maybe VLevel DSP spits out reasonable max volumes anyway, I need to look.

Re: foo_truepeak True Peak Scanner

Reply #243 –
@Case

Bug?

TPS 0.6.15 preview 2024-12-02 scans for %replaygain_album_true_peak% but does not write the tag.
TPS 0.6.14 does write the tag.

Re: foo_truepeak True Peak Scanner

Reply #245 –
@Case
newest version shows 28bit for SACD. Earlier one showed 64fp.

Re: foo_truepeak True Peak Scanner

Reply #246 –
BPS measurement code hasn't changed. Also I can't replicate.

Re: foo_truepeak True Peak Scanner

Reply #247 –
Quote from: Case on
BPS measurement code hasn't changed. Also I can't replicate.

I rescanned the same file and it showed 32fp (strange that it changed).
Then I rescanned the same file in my primary FB install which uses sacd_input and it showed 64fp.
So I rescanned it again in my test-portable FB which uses udsd (instead of sacdinput) and it showed 32fp. So I uninstalled udsd and installed sacdinput into portable FB and rescanned and it shows 64fp.
Is this udsd bug to be reported to the developer?  Plus why would values differ within the same udsd version - the only thing I might have changed is output mode DSD vs. PCM and output samplerate. Do you think that matters?

Re: foo_truepeak True Peak Scanner

Reply #248 –
Quote from: wojak on
Quote from: Case on
BPS measurement code hasn't changed. Also I can't replicate.

I rescanned the same file and it showed 32fp (strange that it changed).
Then I rescanned the same file in my primary FB install which uses sacd_input and it showed 64fp.
So I rescanned it again in my test-portable FB which uses udsd (instead of sacdinput) and it showed 32fp. So I uninstalled udsd and installed sacdinput into portable FB and rescanned and it shows 64fp.
Is this udsd bug to be reported to the developer?  Plus why would values differ within the same udsd version - the only thing I might have changed is output mode DSD vs. PCM and output samplerate. Do you think that matters?
I hope you don't encounter the same nonsense I now experience when you create a ticket. Some fooBar user is messing up my ticket for RFC with giving incorrect information about current tag issues regarding UDSD 0.1.16.

Re: foo_truepeak True Peak Scanner

Reply #249 –
Hey Case, when will you bring the beta Truepeak scanner to the main branch?