Replay Gain Tags (existing vs annotated)

[Kerosel]

My current on-air script has an "album" playlist...

album = amplify(1.,override="replaygain_album_gain",merge_tracks(playlist(loop=false,mode="normal",reload_mode="watch","/mnt/media/audio/radiolists/albumlist")))

...designed so I can drop an album's worth of files into a list and they will be played in order, merged (bypasses the crossfade function) and with amplify overridden by the "replaygain_album_gain" tags.

It is prioritized with other sources through a fallback statement and then that result is sent through replaygain, crossfade and mksafe.

juke = fallback(id="jukefall",[request.queue(id="upnext"),album,special,music])
juke = mksafe(crossfade(smart=true,replaygain(juke)))

(Prior to 2.0.0 there was no "replaygain()" function, you had to use "amplify()" instead with the appropriate override tag)

In 1.4.x the "replaygain" protocol either read the "replaygain_track_gain" metadata tag or if that tag was not found, ran it through ffmpeg to get a replay gain reading. The result from either of these was annotated into the source as a "replaygain" tag.

This gave my script a little bit of flexibility:

• Tracks added to the "album" list that had the "replaygain_album_gain" tag would be adjusted by the amplify statement attached to the album playlist. The later amplify statement would stay at 1.0 because there was no "replaygain" tag
• Tracks played with the "replaygain" protocol would get "replaygain" annotated and it would override the later amplify function
• Tracks could be added to the "album" list with the "replaygain" protocol if they didn't have any album gain tags (i.e., a group of unrelated singles, a collection of tracker files, etc). The tracks would still be played in order and merged but the album amplify statement would not override and the later amplify statement would pick up the "replaygain" annotated tag and adjust accordingly

Now in 2.0.0, I've noticed that the "replay_gain" protocol annotates the tag "replaygain_track_gain" into a source, which is the same tag that is present in the file metadata if replay gain has been applied. I think on the surface that sounds like a good idea, however:

• It tangles up the either/or cleverness in my script: tracks played through the album list will get adjusted by both album gain and replay gain
• More importantly, tracks tagged with replay gain will always play back with replay gain even without the "replay_gain" protocol because the amplify statement will override on the already-existing "replaygain_track_gain" tag in the file metadata. There is no way to selectively play tracks with or without replay gain if the tag is present

I propose that the replay_gain protocol annotate a slightly different tag, maybe "liq_replaygain_track_gain" or even just "liq_replaygain" to differentiate annotated replay_gain added by the protocol from the preexisting tag present in the file. The "replaygain()" function could be retooled so the amplification overrides on the new "liq_replaygain" tag. This way tracks with replaygain metadata won't be adjusted unless the "replay_gain" protocol is used. If the protocol is used, it will read the existing "replaygain_track_gain" tag in the metadata and annotate that value as "liq_replaygain".

I'll probably modify my own local files to try this out, but maybe it's something worth making official.

Make sense? Or clear as mud? Comments and suggestions always welcome.

[smimram]

With the commit 507d58a, you can now write something like

settings.protocol.replaygain.tag.set("my_replaygain_tag")

to specify the tag set by the replaygain protocol. This should solve your problems, right?

[Kerosel]

Hey, sorry it took me almost two weeks to realize you'd replied to this. I think that setting is just what I need. I can set a custom tag for the replaygain protocol and then use amplify() to pick it up. Meanwhile, replaygain() still picks up the native tags added to metadata (I assume?) so you can use it to operate on a library that's already tagged.

I'll give it a whirl and see what happens!