WACUP

General => Wishlist / Feature Requests => Topic started by: Parshift on November 15, 2017, 08:42:32 PM

Title: EBU R128 loudness normalisation
Post by: Parshift on November 15, 2017, 08:42:32 PM
Hello,

I've had this occasional problem with Winamp that after Replay Gain analysis, the song volume still made a song sound distorted. Albeit in a very small number of songs in my library.
A problem I did not have when calculating Replay Gain in foobar or dBpoweramp, so I have been using them since for analysing RG.
I waited for my acceptance into the WACUP beta to see if something had improved here, but that does not seem to be the case.

So today I dug a little deeper and found out that foobar and dBpoweramp use a standard called EBU R128 (-18 LUFS target) for loudness normalisation, while Winamp uses Replay Gain.

This is all new to me and perhaps this has already been discussed in length somewhere, but how do you feel about this EBU R128 method and is it perhaps possible to implement it into WACUP's 'Calculate Replay Gain'?
That way I can use Winamp again without the need for an external program.

Thanks for your thoughts :)
Title: Re: EBU R128 loudness normalisation
Post by: dro on November 15, 2017, 09:08:37 PM
This is all new to me and perhaps this has already been discussed in length somewhere, but how do you feel about this EBU R128 method and is it perhaps possible to implement it into WACUP's 'Calculate Replay Gain'?
I've briefly mentioned it in some of the beta discussion threads but not as a topic on it's own. Using the newer format is something that is on my list of things I want to do as the existing plug-in that handles it needs to be replaced to allow for it (as well as to resolve some issues with normal RG calculations).

As it seems like the newer format is preferred by other players, I've no problem into eventually getting around to supporting it :)

-dro
Title: Re: EBU R128 loudness normalisation
Post by: dro on November 17, 2017, 04:20:31 PM
Whilst there's a bit of interest about this, I've decided to try & finish off the replacement plug-in I'd started on a few months back - it was able to process files but the UI hadn't been hooked up (which will be similar to the recent replacement format converter UI so it's all done within a single skinned ui instead of separate processing & selection dialogs). Currently I've got it using the original ReplayGain mode but I've just been having a look at libebur128 (used to do the calculation) & it looks like it should be simple enough to make use off.

The attached screenshot is roughly what the config options will be (the dropdown will become enabled when I've got libebur128 being used).

One question I've got, should the default be the original ReplayGain mode or instead use EBU R128 going forward?

-dro
Title: Re: EBU R128 loudness normalisation
Post by: Aminifu on November 17, 2017, 05:49:32 PM
I suggest using the newer calculation method as the default.

Will the ReplayGain Preamp still be available when using the newer method?
Title: Re: EBU R128 loudness normalisation
Post by: dro on November 17, 2017, 07:02:24 PM
Afaik the usage of the values during playback is handled the same, it's just the calculation that's different. So all of the upper options I believe will work the same & due to the range on the preamp values, you should be able to tweak them to what better fits with the newer mode (other than looking at how to use the newer library, I'm not fully up to speed on the key differences).

-dro
Title: Re: EBU R128 loudness normalisation
Post by: CodeLurker on June 05, 2019, 09:11:53 AM
This is a fine idea, IMHO; but it does not go far enough.  IMHO, no players do yet.  Loudness perception is a squirrelly thing, and there are numerous loudness standards out there.  There is also the US measure: ATSC A/85, and the Japanese: TR-B32.  Digital Full Scale (dBFS) with K-weighting can probably be safely ignored, as it is an earlier, less effective attempt.  (See 5 Common Myths About Loudness Metering Debunked (https://ask.audio/articles/5-common-myths-about-loudness-metering-debunked).)

More importantly, foobar2000 allows the editing of ReplayGain settings.  The EBU R128 algorithm is only an approximation of how loud something sounds to the human ear.  It can't always get it right.  Sometimes after I use foobar2000 to set Replay Gain for files, a song just sounds too soft or too loud.  Thus, I need to tweak its Replay Gain to something more appropriate.  It seems to me that this is metadata, and if the medadata editor isn't allowing this number to be hand-adjusted, it isn't complete.

Thus, I strongly recommend allowing Replay Gain to be edited, and to at least be open-minded about alternate loudness measures.
Title: Re: EBU R128 loudness normalisation
Post by: Parshift on June 05, 2019, 11:31:03 AM
Thanks for the implementation, but I have been wondering why the analysis is so much slower in WACUP than it is in Foobar for example?
Title: Re: EBU R128 loudness normalisation
Post by: dro on June 05, 2019, 10:16:53 PM
Parshift: It'll primarily be because it's doing the processing a file at a time instead of multiple files at the same time. When I first got the feature re-implemented, I only did the single file at a time method just to help verify that the processing was correct & not causing issues (which it did for a bit until that was resolved).

I've not come back around to working on the plug-in to finish off the multiple file processing which is why we've got the slow but stable approach still. It will hopefully get some love later this year to bring it up to the expected level of processing multiple files.



CodeLurker:
Quote
Thus, I strongly recommend allowing Replay Gain to be edited, and to at least be open-minded about alternate loudness measures.
I thought I had been open minded in providing the 2 common methods that other players are using so a) I maintain compatibility for those needing it whilst b) adopting what from my research has been deemed the more appropriate solution to use. If there are other options that a decent majority are using then I'm open to trying to add support for them, subject to code & licensing related to it.

With regards to manually editing of the values, its not been done yet as not all of the input plug-ins that are responsible for handling such matters have been replaced &/or modified to make it viable to generically edit that metadata. Once that's done then the singular & batch edit dialogs will get the support added to them.

I know most just see it is disabled edit controls but to have things done consistently (which has been an issue with Winamp not doing that) then there's a few pieces that need to be sorted out which is part of my end goals to have key tagging functionality somewhat isolated from the input plug-ins so things can be done to it without having to update half a dozen plug-ins &/or the duplicated code that comes from some of them using the same tagging format (e.g. ogg vorbis + flac plug-ins).

-dro
Title: Re: EBU R128 loudness normalisation
Post by: Parshift on June 05, 2019, 10:25:35 PM
I can see a big difference per file, as that is what I mostly use. For a random 10 minute song WACUP takes about 6-8 seconds, Foobar finishes it in less than 2.
Title: Re: EBU R128 loudness normalisation
Post by: dro on June 05, 2019, 10:33:00 PM
Are they MP3 files by any chance? As getting the audio data is dependent upon the input plug-in responsible though I've not looked too much into the speed of data acquisition as having it work was more the priority but I'll have to do some testing it seems.

-dro
Title: Re: EBU R128 loudness normalisation
Post by: Parshift on June 05, 2019, 10:34:13 PM
Yes mp3
Title: Re: EBU R128 loudness normalisation
Post by: dro on June 05, 2019, 10:40:22 PM
Ok, I'll see if there's anything obvious from my side that's wrong / causing a slow down but I've a feeling its more likely the mp3 decoding library being used that's causing the bottle-neck in this instance. I should probably also have a look at some of the other formats like FLAC to see how they might also compare.

-dro
Title: Re: EBU R128 loudness normalisation
Post by: Dr.Flay on June 06, 2019, 12:13:55 AM
There could be a chance that Foobar is being more optimal or sloppy with reading the file as it is only looking for the loudest point.
2 seconds is quick to uncompress and scan a 10 min file. If I open in Audacity or similar it takes longer than 2 or 3 seconds.

If WACUP is decoding every frame then perhaps that is the slowdown in comparison.
Could the resolution still be reliable if ignoring ever other frame ?
Title: Re: EBU R128 loudness normalisation
Post by: dro on June 06, 2019, 01:48:47 PM
It's somewhat of an apples & pears comparison as they're using different decoder engines (Fraunhofer's official library vs FFmpeg's) & I know that the FhG instance has issues with handling some seek tables so it's possibly something to do with that (i.e. it goes into slow mode vs using the appropriate mode) or there's locks within the decoding that are hindering the overall throughput of the decoding process (which isn't an issue for normal playback) or its on the other side of the fence & dealing with the data once provided by the input plug-in.

Until I start digging it's hard to know & whether there's an easy 'fix' or if it's more a fundamental aspect of what's being used. If it's in_mp3 & the FhG library then it just gives another reason to look at moving to a different plug-in than relying upon it (since it's a beast already).

-dro
Title: Re: EBU R128 loudness normalisation
Post by: dro on June 06, 2019, 07:55:49 PM
I've made a quick experiment (having hacked up the waveform seeker plug-in as that's using the same method but its simpler to just get running than the replaygain action) & doing as close as I can get for a like-for-like between MP3 & FLAC versions of the same file (~90mins), MP3 decoding takes ~21s vs FLAC decoding takes ~11s.

Again it's still apples vs pears due to format & decoding differences but I am more likely to lean on the relative slowness being down to current in_mp3 from 5.666 7 the FhG decoder library rather than the transcoding API in this instance.

The next test (but not for now as I need to finish off getting a new beta & preview build out this month) will be seeing what the decoding speed is like when using a different MP3 decoder which luckily can be done without a replacement in_mp3 since I've got control over the transcoding api so can make it look at a non plug-in instance instead, muwhahaha :)

-dro
Title: Re: EBU R128 loudness normalisation
Post by: CodeLurker on June 07, 2019, 08:20:05 AM
Quote
I thought I had been open minded in providing the 2 common methods that other players are using so a) I maintain compatibility for those needing it whilst b) adopting what from my research has been deemed the more appropriate solution to use. If there are other options that a decent majority are using then I'm open to trying to add support for them, subject to code & licensing related to it.

I'm not aware of any choice two methods when calculating Replay Gain, or even what is being used now.  I see "Send to|Calculate Replay Gain", and that's it.  Under Replay Gain in options, I don't see a choice of method for calculation.

Quote
With regards to manually editing of the values, its not been done yet as not all of the input plug-ins that are responsible for handling such matters have been replaced &/or modified to make it viable to generically edit that metadata. Once that's done then the singular & batch edit dialogs will get the support added to them.

I'm not sure why editing the Replay Gain setting would require generic editing of metadata; but I'm glad to hear it is in the works.  This is a huge thing foobar2000 has on WinAmp.

Quote
I know most just see it is disabled edit controls but to have things done consistently (which has been an issue with Winamp not doing that) then there's a few pieces that need to be sorted out which is part of my end goals to have key tagging functionality somewhat isolated from the input plug-ins so things can be done to it without having to update half a dozen plug-ins &/or the duplicated code that comes from some of them using the same tagging format (e.g. ogg vorbis + flac plug-ins).

I'm not aware of what disabled edit controls you refer to.  I can certainly see that you wouldn't want to repeat metadata code in all the input plugins.  Sounds like you'll have a .dll plugin that handles them for more than one input plugin; or are putting it in winamp.exe.  That there are only a few pieces to be sorted out sounds like you've been making great progress, and I look forward to its impending arrival.  In short, it all sounds great, and I like where you are saying you are going.
Title: Re: EBU R128 loudness normalisation
Post by: Dr.Flay on June 08, 2019, 01:37:24 AM
I am thinking that maybe this is the wrong forum section, as this is not really a feature request.
More like a bug in an existing feature.
Title: Re: EBU R128 loudness normalisation
Post by: dro on July 05, 2019, 04:43:21 PM
Quote
I thought I had been open minded in providing the 2 common methods that other players are using so a) I maintain compatibility for those needing it whilst b) adopting what from my research has been deemed the more appropriate solution to use. If there are other options that a decent majority are using then I'm open to trying to add support for them, subject to code & licensing related to it.

I'm not aware of any choice two methods when calculating Replay Gain, or even what is being used now.  I see "Send to|Calculate Replay Gain", and that's it.  Under Replay Gain in options, I don't see a choice of method for calculation.
It's only a choice under WACUP - I've attached below & highlighted the mode on the preferences as I provide both options but default to the newer mode by default.

Quote
With regards to manually editing of the values, its not been done yet as not all of the input plug-ins that are responsible for handling such matters have been replaced &/or modified to make it viable to generically edit that metadata. Once that's done then the singular & batch edit dialogs will get the support added to them.

I'm not sure why editing the Replay Gain setting would require generic editing of metadata; but I'm glad to hear it is in the works.  This is a huge thing foobar2000 has on WinAmp.
Its because it's silly to have one plug-in support it & others not hence why I need to make the changes I'm gradually working on so it's dependent upon however many input plug-ins to be updated to the required support & instead just having the core "do it" so from a user viewpoint it just works & what's going on under the hood then doesn't matter :)

Quote
I know most just see it is disabled edit controls but to have things done consistently (which has been an issue with Winamp not doing that) then there's a few pieces that need to be sorted out which is part of my end goals to have key tagging functionality somewhat isolated from the input plug-ins so things can be done to it without having to update half a dozen plug-ins &/or the duplicated code that comes from some of them using the same tagging format (e.g. ogg vorbis + flac plug-ins).

I'm not aware of what disabled edit controls you refer to.  I can certainly see that you wouldn't want to repeat metadata code in all the input plugins.  Sounds like you'll have a .dll plugin that handles them for more than one input plugin; or are putting it in winamp.exe.  That there are only a few pieces to be sorted out sounds like you've been making great progress, and I look forward to its impending arrival.  In short, it all sounds great, and I like where you are saying you are going.
My bad, I'd forgotten when I made that part of the reply that I'd tweaked the alt+3 dialog so it doesn't have bits of edit controls & instead just shows the information that's found (or not) vs what 5.666 was offering. It'll get there in the end, just a lot of things behind the scenes that need to be caught to get it coming together :)

-dro
Title: Re: EBU R128 loudness normalisation
Post by: mint_jr on July 28, 2019, 04:05:26 PM
Looks like the implementation always assumes peak values are 16 bit even at other bit depths resulting in the peak values being 1.5x what they ought to be for 24 bit.