Jellyfin replaygain not applied

Issue description:

Sorry to bother you again, but, I cannot wrap my head around this issue. I have check similar issues but still cannot come to a solution.

For reference:

  • Hi res is turned off
  • LUFS audio normalization in jellyfin turned on
  • Music tagged manually with beets REPLAYGAIN tags
  • Replagain track mode selected
  • Jellyfin Server 10.10.7

It seems Symfonium picks up the tags as seen in logs with:

2025-11-19 21:40:43.394 Verbose/ExoPlayer/16: VC: REPLAYGAIN_ALBUM_GAIN=-13.30 dB
2025-11-19 21:40:43.394 Verbose/ExoPlayer/16: VC: REPLAYGAIN_ALBUM_PEAK=1.603245
2025-11-19 21:40:43.394 Verbose/ExoPlayer/16: VC: REPLAYGAIN_TRACK_GAIN=-13.30 dB
2025-11-19 21:40:43.394 Verbose/ExoPlayer/16: VC: REPLAYGAIN_TRACK_PEAK=1.603245

but then doesnt actually apply it seen with

2025-11-19 21:40:43.402 Verbose/ReplayGainParser: Final gain: 0.0

My issue is I keep getting blasted in the car with music that is way to loud.

What is going on here or what could I be doing wrong?

Any help is appreciated.

Logs:

Upload description: thekingpin

Additional information:

Reproduction steps:

Media provider:

Jellyfin

Screenshots:

You are using FLAC with vorbis tag styles :wink:

The tags on your files says:

2025-11-19 22:19:49.768 Verbose ExoPlayer/1      VC: R128_ALBUM_GAIN=0
2025-11-19 22:19:49.768 Verbose ExoPlayer/1      VC: R128_TRACK_GAIN=0

So it applies the 0 as the tags says for that format of tags.

Thanks but Im still confused. OK my files are using vorbis comments but the REPLAYGAIN tag is there. Can symfonium not just use them instead?

They are replay gain tags … And they say 0 and they are used.

You put 2 different tags for the same purpose that have different values.

Don’t do that and only use one?

1 Like

The problem is beets will automatically add both values by default but only write REPLAYGAIN to the actual metadata it seems. Leaving R128 value as “0” on all my files.

I have to do some more digging to see how to overcome this issue.

Well they need to fix or you need to automate the removal of those or use ID3 tags.

A value of 0 is a valid value, those are the preferred tags for vorbis tag style, all works as expected on Symfonium side.

Understood and I agree now that everything is working on symfnoim side also from what my “digging” has revealed.

I thank you for your assistance and quick response.

Is it possible to allow Symfonium to apply vorbis replaygain tags? The more I dig into this issue the less I get to an actual solution which is to use symfonium and continue using beets.

You have 3 solutions. Put the proper values instead of 0, remove the R128 tags by script, use ID3.

Here’s chatGPT solution (PS: This is 100% outside of Symfonium support …)


Excellent question — this is a known issue with how Beets handles ReplayGain tagging for FLACs (and other lossless formats) when using the replaygain plugin.
Let’s go through what’s happening and how to fix it.


:puzzle_piece: The Problem

When you run:

beet replaygain

on FLAC files, Beets:

  1. Computes ReplayGain values and writes ID3-style tags like REPLAYGAIN_ALBUM_GAIN, REPLAYGAIN_TRACK_GAIN, etc. :white_check_mark:
  2. Also writes EBU R128 tags (R128_TRACK_GAIN, R128_ALBUM_GAIN) but incorrectly sets them to 0. :cross_mark:

Those zeroed R128 tags can override or confuse players that prioritize R128 values (like foobar2000, mpv, etc.), resulting in no volume adjustment.


:wrench: Solution 1: Disable R128 Tagging in Beets

In your Beets config file (~/.config/beets/config.yaml), add or adjust the replaygain section as follows:

replaygain:
  backend: ffmpeg      # or bs1770gain / audiotools / gstreamer
  targetlevel: 89      # or whatever you prefer
  auto: yes
  overwrite: yes
  r128: no             # ⬅️ This disables writing R128 tags

Then re-run:

beet replaygain -f

(-f forces re-calculation and re-tagging.)

This tells Beets not to write R128_* tags at all, sticking only to the classic ReplayGain tags.


:toolbox: Solution 2: Keep R128 but Fix Values (Advanced)

If you want to keep R128 tags (some players prefer them) but ensure they match ReplayGain correctly, you can patch Beets or use a post-processing script.

Beets calculates ReplayGain in LU (R128-style units) internally, so in principle it could write proper values. Unfortunately, as of Beets 2.x/3.x, this is not implemented correctly for FLAC.

You can fix it via plugin patching:

  1. Locate your Beets installation (pip show beetsLocation).

  2. Edit beetsplug/replaygain.py.

  3. Find the _store method (near the end of the file) and comment out the R128 write block:

    if self.config['r128'].get(bool):
        ...
    

    or replace it with a proper conversion (LUFS to dB if desired).

Then re-run beet replaygain -f.


:sponge: Quick Cleanup for Existing Files

To remove broken R128 tags from your existing FLACs:

metaflac --remove-tag=R128_ALBUM_GAIN --remove-tag=R128_TRACK_GAIN *.flac

or recursively:

find . -type f -name '*.flac' -exec metaflac --remove-tag=R128_ALBUM_GAIN --remove-tag=R128_TRACK_GAIN {} +
find . -type f -name '*.flac' -exec metaflac --remove-tag=R128_TRACK_GAIN {} +

Then reapply ReplayGain with Beets after r128: no fix.


:white_check_mark: TL;DR

Action Command / Config Effect
Disable R128 r128: no in config.yaml Stops adding broken R128 tags
Remove bad tags metaflac --remove-tag=R128_* Cleans old zeroed R128 tags
Reapply ReplayGain beet replaygain -f Rewrites correct ReplayGain tags

Would you like me to show the exact patch lines to modify inside Beets’ replaygain.py if you want to keep R128 tags but make them correct instead of removing them?

Thank you again for going out of your way to grant me an answer even outside of Symoniums support scope, which I understand this is. It is appreciated. :slight_smile:

I spent half of my day today trying various patch work fixes and things so leaving this comment here for anyone else who comes up with this issue. But, also have another question for you at the end.

In the end I removed the values using

After removing this the replaygain is working using the REPLAYGAIN_TRACK_PEAK values.

It seems that beets will write R128_ specific gain tags, or at least tracks them as metadata. Another issue is that beets interprets ‘0‘ as no replaygain to be applied it seems. Exact same as the logs:

R128_TRACK_GAIN=0

From my understanding this is a totally different tag, that, if present, is preferred by exoplayer?

Do you think its possible in future release to add an option to replaygain in settings to choose what tags to read from for example either REPLAYGAIN_ or R182_? I think this feature is already present on some other clients from what I read.

The REPLAYGAIN_ tags were already present in my example but exoplayer chose priority on R182_ tags and leaves me in a position where I need to manually remove these tags every time I import new music.

It also leaves me with the question what does symfonium choose if both REPLAYGAIN_ and R182_ are present? As these are different loudness normalisation values.

I am happy to put in a dedicated feature request if we agree. :slight_smile:

I choose what to use and respect the standards as many other apps.

And no I won’t add an option to workaround an app bug that can be fixed on that app side.

As the developer of the app I did not expect anything else :wink:

I think R128_ tags are standard tags to use for Opus codec, and, my files are flac. True the tagging was wrong from my side so I get your point.

I figured out the issue and leaving this reply just in case anyone else stumbles across it in the future. Totally unrelated to symfonium and exclusively to beets.

The root cause for the issue is the “Edit“ plugin I use sometimes to edit metadata after import. To be specific, when using the -all flag (load all metadata) to edit metadata, the R128_ are shown as editable fields, default “0“, and, will be written to the files as empy tags, if you dont actually edit them.