Extra tags (ex. -s e)

[PickNicko13]

I see you ditched support for extra tags, specifically "REPLAYGAIN_REFERENCE_LOUDNESS". I know it's not really standard, but it's adopted widely enough and even appears on hydrogen.io as a de-facto extension. For players unaware of these tags they won't do anything harmful and for ones that do, reference loudness information will help adequately handle libraries with mixed loudness targets.

Were there any issues with it?

[complexlogic]

One of my major design philosophies for this program is stricter adherence to the ReplayGain standard. The loudness range tags have no value at all and only create confusion. I can see how the reference loudness tag could be useful, however, my stance is that you shouldn't have mixed loudness targets in the first place, as that's counter-intuitive to the purpose of ReplayGain.

One major issue with the reference loudness tag is that it's not portable between ReplayGain 1.0 and 2.0 implementations, unlike the standard gain and peak tags. An RG 1.0 tagger will write 89 dB, referring to the obsolete SMPTE loudness definition, while RG 2.0 taggers write in LUFS, e.g. -18.00 LUFS. I'm aware of at least one case where this incompatibility causes a problem.

Personally, I'd dispute the "de-facto extension" claim for those extra tags. Few players read the reference loudness tag, and I'm not aware of a single one that reads the loudness range tags.

[PickNicko13]

Seems reasonable enough.

[ZLima12]

I got onto this because I am working on improving ReplayGain support in opusenc (the reference Opus encoder). I recognize the issues raised, but I still think that at least having an option to write the reference loudness tag would be worthwhile.

I can see how the reference loudness tag could be useful, however, my stance is that you shouldn't have mixed loudness targets in the first place, as that's counter-intuitive to the purpose of ReplayGain.

Ideally yes, we would have always had one loudness target and players could be confident about which one is being used. In Opus, this is the case; instead of REPLAYGAIN_(ALBUM|TRACK)_GAIN, there is R128_(ALBUM|TRACK)_GAIN, which explicitly puts the value in relation to the R128 standard of -23 LUFS. However, as has already been mentioned in this conversation, ReplayGain does have mixed loudness targets; RG 1.0 uses the aforementioned obsolete loudness standard, while 2.0 uses R128 and LUFS. This is one advantage of specifying the tag: a program, or a user managing their library, can tell which system was used when calculating the tag values.

Additionally, rsgain currently supports specifying an alternative target loudness via the --loudness option. When using this option, it would be particularly important to have the REPLAYGAIN_TARGET_LOUDNESS tag, so players can correctly achieve their own desired loudness if they wish to do so.

I'm aware of at least one case where this incompatibility causes a problem.

I would argue that this was a case of sloppy input sanitation. Pre-RG 2.0 programs should notice that the value ends in something other than dB, say "this doesn't look right", and then avoid using the value at all. Since this tag is used to a decent extent, programs that don't handle this properly should be updated to do so.

Personally, I'd dispute the "de-facto extension" claim for those extra tags. Few players read the reference loudness tag, and I'm not aware of a single one that reads the loudness range tags.

I agree regarding the loudness range tags, but I feel like the reference loudness tag has had enough uses for enough time that it could be called de-facto. It is somewhat of an annoyance that RG 1.0 and RG 2.0 have different meanings for the tag, but it seems like it is common for programs to understand both. opusenc, for example, has supported both since 2021.