It probably makes more sense for Foobar to provide a pair of new technical info %__fields% than to add generic floating point functions, which don't work in older versions and have the other arithmetic operations confusingly still limited to integers.
That would be my preferred way of dealing with it, perhaps something like %replaygain_track_peak_db% or something?
Last post by rogeriol -
Mostly pissed about the lack of dynamic range nowadays. I have some 80's CDs that actually have quiet passages , something that just doesn't exist for some time (two decades). Brick walls everywhere...
The peak level statistic isn't really related to loudness normalization, except in the name chosen in Vorbis/Ape. The player can derive the required format regardless how it is encoded in the particular format. Renaming the tags serves no purpose. I prefer that the original loudness normalization standard remains.
I wasn't suggesting the tags should be renamed, although I'm boldly assuming there's a method for saving R128 volume information to tags using fields that have nothing to do with ReplayGain. If so, why not do both?
foobar2000 can write SoundCheck tags. I don't know if they include a peak loudness value or if it'd be easier to convert to a True Peak LUFS value for fb2k to display, but Opus decided to do it differently and that's supported by fb2k too, so between ReplayGain, SoundCheck, Opus and R128, the concept of a "universal" volume system is looking a little messy. ReplayGain is the only method not using loudness units as a way to express volume, but considering fb2k no longer uses the original ReplayGain scanning method and supports True Peak scanning, even if the format for saving ReplayGain tags remains unchained for eternity, I'm not sure why moving to loudness units in the GUI isn't a good idea.
In fact fb2k's advanced options for configuring SoundCheck tags allows the SoundCheck target volume to be adjusted to match the ReplayGain target volume, and both volumes are expressed as loudness units, no doubt because choosing between a target volume of -16LUFS and 89dB would meaningless to most mortals, which is pretty much the point I was trying to make.
Last post by kode54 -
That was due to a certificate issue that was not taken care of while it would have been possible to transition seamlessly. The paid certificate was allowed to expire, and the server was configured to pin the certificate vendor that paid certificate came from. What should have happened, is the pinning should have been reduced or even removed two weeks before expiration, so that a seamless transition could occur when the certificate finally expired.
The only alternative for existing users was to either clear their HPKP settings file of any references to this domain, which was fairly straightforward, if not annoying, for desktop browsers, while quite troublesome for mobile browsers. Or wait out the two weeks.
Last post by sveakul -
Thank you Peter I appreciate it! If I may just take this opportunity to ask about another radio-related matter, was the decision to remove the option for a user-adjustable network buffer setting for streams due to some conflict with other functionality? That option was a big assist when dealing with marginal streams/network conditions.
Last post by DVS -
There are incorrect window borders at the first start. When you first run foobar and after the window is minimize. As you can see, after minimize, the borders of the window changed position, and the content took a more correct sentence. In the first picture, the border along the window edges, on the second, the star of the rating is in the middle position. Sorry for my English.