EBU R128 loudness normalisation

[Parshift]

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

[dro]

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

[dro]

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

[Aminifu]

I suggest using the newer calculation method as the default.

Will the ReplayGain Preamp still be available when using the newer method?

[dro]

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

[CodeLurker]

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.)

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.

[Parshift]

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?

[dro]

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:

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

[Parshift]

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.

[dro]

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

[Parshift]

Yes mp3

[dro]

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

[Dr.Flay]

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 ?

[dro]

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

[dro]

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