Seems that BASS now has an addon for loudness measurement (based on ITU-R BS.1770-4): https://www.un4seen.com/forum/?topic=20129.0

Something like ReplayGain might end up being more suitable for our use case, but figured it was worth leaving a note here for future reference.

I believe that applying normalization on songs in realtime (such as with BASS) isn't a good idea, as the editor waveform would (probably) remain unchanged while the audio would. Would probably just be a headache all around.

I believe that a better idea would be to use ffmpeg's loudnorm filter which complies with EBU R128 (a standard used by both spotify and apple music). Lazer could replace the original audio file for the map with a normalized one on beatmap import, and also in the background. Letting ffmpeg do this would also probably simplify a lot of the process, as opposed to what was presented in #17486 (having to implement the algorithm ourselves)

The only downsides I could see with using ffmpeg is having to re-encode the audio files on-device. This would probably take longer on low end cpu's, but fortunately audio encoding in itself is relatively quick. Though we would also have to keep track of which files have been normalized and which ones haven't.

I'll probably continue looking at this and I'll see if I can get a new implementation using ffmpeg

Edit: Seems like using ffmpeg is much more rough to maintain than bass. I'll see if I can get a bass implementation in addition to an ffmpeg poc

Okay, so status update.

I've made a PR in ManagedBass which adds bindings for BASSLoud. ManagedBass seems to be unmaintained however, so it might be necessary to fork it and maintain our own version. I hope to get a response within a week, and if not, then I'll probably consider the library to be unmaintained. That being said, I've also decided that BASS is probably the way to go forwards. I can tweak the values of the audio normalization to comply with EBU R128 instead of ITU-R BS.1770-4, which I will likely end up doing since I prefer the former standard to the latter.

Going forwards, I'm going to work on this fulltime, and I hope to get an implementation for it out sometime this spring.

@nekodex If possible, I would also like to discuss the possible implications of this. I've asked some friends and players within the osu community about this, and some of them believe that audio normalization might negatively impact maps. For example, loud meme maps might get nerfed to being just meme maps minus the "funny loudness". It could be wise to maybe add a config value to .osu files which can disable on-client normalization for maps at the mapper's discretion.

@nekodex If possible, I would also like to discuss the possible implications of this. I've asked some friends and players within the osu community about this, and some of them believe that audio normalization might negatively impact maps. For example, loud meme maps might get nerfed to being just meme maps minus the "funny loudness".

Personally, I'm not sure how much we should care about preserving "funny loudness". I think that the shock/humour of loud maps is such a niche edge-case that it's less important than improving the overall experience for the majority of players instead.

It could be wise to maybe add a config value to .osu files which can disable on-client normalization for maps at the mapper's discretion.

I dunno how the rest of the team feels about this, but personally I think that overriding player choice here is a bad idea.

If anything, we could offer a global toggle for players to enable/disable normalisation - but it should be up to the player to disable it if they want to experience "funny loudness", not something mappers are allowed to override on the players' behalf.

In regards to normalisation impacting gameplay, I'd make sure to also consider and adjust hitsound volumes as well. They should be adjusted in line with the track's normalisation amount to preserve the relative volume between the beatmap's music and hitsounds.

So I've got this thing working. It's a little janky in some areas (mostly related to realm) but it works very well for the most part. While I'm still refining it, I've decided to post this video showcasing how loudness normalization sounds in osu!.

In the video, I have all 3 volume sliders set to 100%. The beatmaps are being normalized to -14 LUFS via BASSLoud. I find that tech maps and EDM songs are especially good at showing the effect of normalization, so I mainly show that in the video. Try to focus on how the songs sound volume wise and in comparison to each other, you should find that they all sound the same volume wise.

I've spent a good couple of hours playing with this to find the best target level, and I find that -14 LUFS meet my expectations the most. It makes the audio not too quiet, where the effects are really loud, but also loud enough that 100% volume actually feels like 100% volume. Honestly, it doesn't seem to have too much of an impact on gameplay, so I don't believe we really need to make a setting to disable it, as we were discussing before.

Note that the effects need to be adjusted in line with the volume adjustment.

I think -14 LUFS is a good target - matches Spotify, YouTube and various other streaming services.

Potentially in the future we might want to lower it a bit further to allow greater headroom for hitsounds, but I'd say -14 is fine to begin with.

Note that the effects need to be adjusted in line with the volume adjustment.

I plan on addressing hitsound normalization in a future PR. I don't want to complicate my current one any more than it already is. For the time being, normalizing to -14 LUFS keeps the hitsounds (at least on argon) decently louder than the music.

Potentially in the future we might want to lower it a bit further to allow greater headroom for hitsounds

Apple music uses -16 LUFS, which we can try. I personally feel like -14 LUFS matches my expectations the most but we can definitely look at -16 LUFS.

Anyways, I've more or less finished up. I'm going to go ahead and submit my prerequisite PR's and create a draft PR for the main one (game-sided) so that I can reference it in the prerequisites and also adapt the code once they get merged.