Hi, I'm writing my own Picard plugin and some of the metadata I am trying to write include r128_album_gain and r128_track_gain but Picard silently ignores them because they are in the unsupported tags from the looks of it in the source code. Why is that? Is there a reason why r128 was added to the list?
2025-08-07 21940, 2025
cy1der[m]
-# copied from #questions-and-help as suggested :)
2025-08-07 21943, 2025
outsidecontext[m joined the channel
2025-08-07 21944, 2025
outsidecontext[m
cy1der: r128_album_gain is currently limited to Opus files. For other formats replaygain_album_gain and replaygain_track_gain are used. Any specific reason you need r128_album_gain specifically for non-opus files?
Exactly. And the general recommendation is to follow the tags as defined there. I wouldn't expect the r128_album_gain / r128_track_gain to be well supported by players, at least not outside the Opus case. They are only explicitly specified in the Opus spec.
2025-08-07 21904, 2025
outsidecontext[m
The Opus spec also explicitly says not to write the replaygain_* to Opus files. Which is why the ReplayGain plugin doesn't by default. But from my experience it's better for player support to also write them for Opus fiol
2025-08-07 21908, 2025
outsidecontext[m
files
2025-08-07 21936, 2025
cy1der[m]
Thank you both for the clarification
2025-08-07 21916, 2025
Protopia[m] joined the channel
2025-08-07 21917, 2025
Protopia[m]
cy1der: Generally speaking music tagging standards are extremely patchy - there is no official standards body, so you get a mixture of pseudo standards that are widely adopted (like ID3v2.3 - albeit with a few widely adopted modifications), some partly adopted de-facto standards, some proprietary definitions that have had some wider adoption and some proprietary definitions that are purely for one tagger or player
2025-08-07 21917, 2025
Protopia[m]
or micro-group (like Apple).
2025-08-07 21917, 2025
Protopia[m]
In many cases, software developers are afraid to fill gaps with their own proprietary definitions for fear that they *won't* be adopted by anyone else or worse still someone else's definitions will be come the de-facto standard and their own definitions will then be wrong - whereas in reality everyone is waiting for someone else to define more tags so that they can fall in line.
2025-08-07 21941, 2025
Protopia[m]
s/In many cases, software developers are afraid to fill gaps with their own proprietary definitions for fear that they *won't* be adopted by anyone else or worse still someone else's definitions will be come the de-facto standard and their own definitions will then be wrong - whereas in reality everyone is waiting for someone else to define more tags so that they can fall in line./In many cases, software
2025-08-07 21941, 2025
Protopia[m]
developers are afraid to fill gaps with their own proprietary definitions for fear that they _won't_ be adopted by anyone else or worse still someone else's definitions will become the de-facto standard and their own definitions will then be wrong - whereas in reality everyone is waiting for someone else to define more tags so that they can fall in line./
2025-08-07 21912, 2025
Protopia[m]
And replaygain is one of these grey areas.
2025-08-07 21948, 2025
kepstinbrainz
i should note that during the opus spec process i argued against adding the "r128" tags to the spec, but the author decided to go ahead with it anyways because they really wanted gain tags, thought that the replaygain tags were tied to the old replaygain algorithm (even at the time, they weren't) and didn't like the floating point number in the tags :(
2025-08-07 21933, 2025
kepstinbrainz
most players that i've tested with support replaygain tags in opus, since they use generic tag parsing for 'vorbiscomment' style tags (ogg vorbis, ogg opus, flac)
2025-08-07 21921, 2025
outsidecontext[m
Interesting, thanks for the insight
2025-08-07 21917, 2025
outsidecontext[m
I even made the experience that the replaygain tags are better supported than the "official" r128 tags for opus.
