So Amarok -- IMO the "least worst" music player app for Linux (Foobar2000 is one of the few things I miss from my Windows days) -- has had this one long-standing bug that really... erm... bugs me. When using replaygain, there's a quarter second or so of lag when a track change occurs, before the new gain value kicks in. If you're switching from a track which has a very high replaygain value to one with a very low one, and that track happens to start out loud, you get a quarter-second blast of extremely loud music before the gain adjusts downwards. On a semi-regular basis this has startled me enough to utter an expletive.
This bug has literally existed for YEARS. From what I can gather from forum discussions, Amarok is pointing the finger at the Phonon audio back-end, and refuses to address this on the grounds that any workaround they could implement in Amarok would break gapless playback, since it would involve pausing playback long enough for the gain change to propagate. Or something.
Last night, finally fed up with this issue, I decided to attempt my own workaround. The only time gapless playback REALLY matters is when you've got multiple tracks from the same album queued up, and those tracks segue directly into one another. In that case, you'd want to be using album mode replaygain anyway, so there would be no gain change between the tracks that you want to play back gaplessly. So what if we enable gapless playback (i.e. queue the next song up for playback before the current one has finished) ONLY when there's no gain change? Sounds simple enough...
Of course the devil is in the details, and I have zero familiarity with the Amarok codebase (or with KDE/Qt development in general, for that matter). Rather than dive into how to examine meta-data of tracks in the playlist, I made the simplifying assumption (which works for my music library) that files in the same directory are assumed to have the same replaygain value (and should be played gapless), while files in different directories should not. My first attempt failed miserably. My second attempt worked about 9 times out of 10; the other 1 time out of 10 -- which seemed to occur at random -- playback froze at the track transition where the gain change was supposed to occur. After scratching my head over this, I finally applied another hack on top of my hack -- in the timer callback that updates the progress bar, I check whether playback has gotten "stuck" (we're in "play" mode, but playback has not progressed for 2 timer callback ticks), and force playback of the next track to begin if so.
This "fix" is obviously nowhere near production quality so I have no intention of trying to contribute it back to the Amarok project at this point, but it does what I want, for my use case. For now, I'll use my hacked copy of "Korama" (I reversed the spelling of the application name in the title bar so I can easily tell at a glance if I'm running the hacked version).
If anyone else here uses Amarok and is annoyed by this bug, I'm willing to share the source code modifications if you PM me... but they really are an embarrassment that I'm ashamed to put my name on, so unless/until I figure out a cleaner patch they won't be posted publicly on the web.