Audio normalisation / volume levelling

[HavermansStef]

Would be nice to have, but not easy to implement. Low priority.

[hawken93]

Just wanted to leave the keyword replaygain in here.

https://www.bobulous.org.uk/misc/Replay-Gain-in-Linux.html

You would usually write replaygain information to the file, then utilize it on playback. Different formats have different ways to store this data though.

[JustAMan]

Another approach is re-formatting your media beforehand. I found this to be very useful: https://github.com/slhck/ffmpeg-normalize

[hawken93]

Mp3 is also often normalized by rewriting the files. I won't do this as the music collection already tries to take care to be a bit perfect copy of the cd (flac format). (I'm one of those people...) so would love to see a metadata based solution here.

But point taken thst you could normalize media today for use with jellyfin :)

[onny]

I just hacked this feature into my Jellyfin installation. It's a dirty workaround :) https://blog.project-insanity.org/2019/04/10/hacking-replay-gain-audio-normalization-into-jellyfin/

I enable audio transcoding with ffmpeg and enable the replay gain audio normalization with an additional parameter: "-af volume=replaygain=track". I hardocded this into the Jellyfin source. But it works pretty good!

[joshuaboniface]

That should be pretty easy to hide behind a checkmark! 🎉

[anthonylavado]

The question - does this only apply with transcoding though? I imagine a lot of people have that as direct play. Otherwise, spectacular work @onny!

I’ll have to look at getting things figured out for other formats later. I think FLAC does ReplayGain too?

[dkanada]

@anthonylavado you are correct, and it's a pretty large problem to solve. I think a lot of settings are dependent on the playback being a transcode. Another example of this is that all video streams transcode audio to MP3 last I checked.

[hawken93]

I think the correct way here is to rely on file metadata or generate metadata from the file about its replaygain values. These can be served to the client to perform corrections on the client side. Usually the most important information is the rms values for the track and for the whole album

[topas-rec]

Why in my eyes this is important: The End Of The Loudness War?

Replaygain 2 uses the newer loudness measurement algorithms:

RG2 uses BS.1770-3 for loudness measurement.

See ReplayGain 2.0 specification Jump to: navigation, search
In the end measuring is one thing and then using the tagged values is another, so I just wanted to mention RG2 here because it was mentioned above.

Sources (audio files) should in my opinion stay untouched and only be tagged for example with r128gain and then normalised when played back.

There was a study (Recommendation for loudness normalization by music streaming services) for a big and popular streaming service made by Eelco Grimm in which he suggested to use album gain. The study is linked at Music Loudness Alliance.
But the choice of album or track gain can be left up to the user (settings).

[sjiampojamarn]

Anything can be done here?

[sjiampojamarn]

Thanks @onny for the blog post and idea in the meantime. A few things have changed. Based on the pull as of Nov 24th, here what I did:

in Jellyfin.Api/Helpers/AudioHelper.cs, comment out direct play and always transcode in the code without UI : )
around line 167

+            //if (streamingRequest.Static)
+            //{
+            //    var contentType = state.GetMimeType("." + state.OutputContainer, false) ?? state.GetMimeType(state.MediaPath);
+
+            //    if (state.MediaSource.IsInfiniteStream)
+            //        await new ProgressiveFileCopier(state.MediaPath, null, _transcodingJobHelper, CancellationToken.None)
+            //            {
+            //                AllowEndOfFile = false
+            //            }.WriteToAsync(_httpContextAccessor.HttpContext.Response.Body, CancellationToken.None)
+            //            .ConfigureAwait(false);
+
+            //        return new FileStreamResult(_httpContextAccessor.HttpContext.Response.Body, contentType);
+            //    }
+
+            //    return FileStreamResponseHelpers.GetStaticFileResult(
+            //        state.MediaPath,
+            //        contentType,
+            //        isHeadRequest,
+            //        _httpContextAccessor.HttpContext);
+            //}

in MediaBrowser.Controller/MediaEncoding/EncodingHelper.cs, add ffmpeg args for replaygain; round line 3521

-                "{0} {1}{7}{8} -threads {2}{3} {4} -id3v2_version 3 -write_id3v1 1{6} -y \"{5}\"",
+                "{0} {1}{7}{8} -threads {2}{3} {4} -af volume=replaygain=track -id3v2_version 3 -write_id3v1 1{6} -y \"{5}\"",

[georgek]

Doing the correction in the playback client is preferable to transcoding. When using a playback device that supports doing Replaygain (like Kodi, for example), then conceptually it seems quite simple as we would simply need to pass the metadata to the client. When I've experimented with this, Kodi doesn't apply any gain, so presumably it's not getting any metadata.

Is it as simple as I think? Is there a whitelist for tags that get passed over DLNA?