GNOME Bugzilla – Bug 512788
replaygain on mixed playlists should prefer track gain over album gain
Last modified: 2018-05-24 13:08:21 UTC
Please describe the problem: A totally common scenario is a playlist that includes tracks from various artists/albums/folders. The album replay gain that might be set causes RB to adjust to album gain which is wrong since the playlist is a loose collection of different songs and not a consistent album. Steps to reproduce: 1. Create playlist with two songs from different albums/artists 2. Activate RB replaygain 3. Notice that in most cases these two songs are completely different in volume Actual results: Expected results: Does this happen every time? Other information:
Created attachment 103955 [details] [review] Let the user enforce usage of track-replaygain tags only This patch introduces a second gconf key that allows the user to force RB using the track-based replaygain tag instead of the album tag. By default, the old behaviour is selected.
(In reply to comment #0) I know this might be a little related to 335073 but this one seems to be closed because option 2) of this discussion had been committed to the trunk a while ago, so this is a little different.
Bug 335073 isn't closed. As far as I'm concerned, replaygain was disabled (with a gconf key for enabling it) to stop it from annoying people until someone fixes it. All the bugs are still there, just hidden. This is more of a duplicate of 133881, though. (which tells you how long this has been neglected..) That bug has the start of a plan for actually fixing this. Just adding another hidden setting doesn't solve anything, and adding a variety of settings to control it isn't a good solution in my opinion. Apart from anything else, if we did that we'd have to rename the project to rhythmboKs or something.
(In reply to comment #3) > Bug 335073 isn't closed. Well, it's not formally closed, but it ended with the statement that James had written a patch for solution number 2, 14 months ago, so I assumed that this discussion was over :-) > This is more of a duplicate of 133881, though. (which tells you how long this > has been neglected..) That bug has the start of a plan for actually fixing > this. Just adding another hidden setting doesn't solve anything, and adding a > variety of settings to control it isn't a good solution in my opinion. Right, I must have overlooked that one, sorry. Anyways, it ends with the agreement that a magic decision logic has to be implemented that automatically does the right thing. Desirable solution, no doubt about that, but very difficult. I think we need two things here. We need to have that smart decision logic AND we need to have the possibility to override this logic. If we don't give the user the "Just do what I tell you. I know what I am doing." option, then we can rename the project to iRhythmunes. So, I would really like to keep the option to let the user decide ultimately what he wants. OTOH I'd really like to have a closer look at that decision logic idea and work on it if, and only if, the project is actually interested in getting it done. I am not keen on spending time with it if hell freezes over before it gets committed to the trunk.
As I see it, the whole point of replaygain is to set the right volume level without making the user think about it, so it seems to me that adding configuration settings for it is counterproductive. We are certainly interested in having working non-annoying replaygain support that can be enabled by default.
(In reply to comment #5) > As I see it, the whole point of replaygain is to set the right volume level > without making the user think about it, so it seems to me that adding > configuration settings for it is counterproductive. I can't completely agree. You are certainly right in the sense that a smart decision logic should work reasonably well to allow replaygain enabled by default. But in my opinion there should be the always-use-track-replaygain switch. Anyways, that doesn't have to be a core functionality. Replaygain control could be interfaced by plugins. In fact, we can code (and I will if you agree) this entire decision logic thing as a plugin. > We are certainly interested in having working non-annoying replaygain support > that can be enabled by default. Good, so how do we decide whether to apply track or album gain? We have to guess what the user wants. For playlists and the play queue, it is easier as the user actively pre-selects several tracks. I would probably do something like: - If we are playing in the default view (entire music library is displayed, the user clicks on a track), track-replaygain (because that is often background music and should not vary too much) - If we are playing down the queue or a playlist, decision is made by looking at the entire playlist: Are we playing subsequent tracks by the same artist and album? Album gain! Is it a mixed collection and (almost) no subsequent tracks are played? Track gain! - Does a track lack replaygain tags? Not sure here: Set it to 0? Set it to the average of the playlist? Keen to get feedback on this.
Created attachment 105977 [details] [review] Patch contains a suggestion to handle 'smart' logic to decide whether to use album replay gain or track replay gain
This code is very difficult to read. I can't figure out what's happening in the playlist branch of rb_shell_player_smart_album_replaygain, let alone why it's happening. It seems a bit weird for the shell-player to have source-specific code in it. It might be better to add a new method on the source class to determine the type of replay gain to be used. The list of entries returned from rb_shell_player_get_entries_from_source will not necessarily be in the order those entries will be played, as you seem to be assuming. Instead, you'd need to get the next entry from the play order.
(In reply to comment #8) That was useful feedback, thanks! Especially this one, > It seems a bit weird for the shell-player to have source-specific code in it. > It might be better to add a new method on the source class to determine the > type of replay gain to be used. is an idea I like very much. I will definitely look at this possibility. > The list of entries returned from rb_shell_player_get_entries_from_source will > not necessarily be in the order those entries will be played, as you seem to be > assuming. Instead, you'd need to get the next entry from the play order. Okay, thanks for the heads up. I'll also try to get the code more friendly to read in the next iteration.
Created attachment 106831 [details] [review] Suggestion to handle 'smart' replaygain logic, second iteration This revised patch introduces a method in the rb-source base class 'want_album_replaygain'. This allows every derived class to decide whether it wants to be played with the 'album'-replaygain or 'track'-replaygain settings. This requires only tiny changes to rb-shell-player.c. This patch implements the new method in two classes, namely the default library source and the static playlist source. In both cases, the decision is made by evaluating if consecutive tracks by the same artist, album and increasing track number are played consecutively. The static playlist source has an additional routine that tries to detect 'mixed' playlists (many different artists/albums, like party collections) and always wants 'track' replaygain on such playlists.
Created attachment 109111 [details] [review] Suggestion to handle 'smart' replaygain logic, third iteration Almost identical to attachment #106831 [details], but * patch versus up-to-date svn * fix a problem that an entry does not necessarily have an associated query model
Bug 133881 appears to be a duplicate of this bug
*** Bug 406444 has been marked as a duplicate of this bug. ***
Comment on attachment 109111 [details] [review] Suggestion to handle 'smart' replaygain logic, third iteration At some point I'm going to implement something like this in the new replaygain plugin.
*** Bug 133881 has been marked as a duplicate of this bug. ***
I apologise if this is a really silly comment, but to me the "logical" approach is for it to always use track gain unless I am playing one album (i.e. have a single album selected in the top right box). Surely this would be a lot simpler to implement than the approaches mentioned so far.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/501.