Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

(Replay) Gain adjustments are not applied during the first split second of a song #1905

kaffeeundsalz opened this issue Mar 30, 2016 · 7 comments


Copy link

I have supplied most of my albums with ReplayGain values and have also set a fallback gain of -9.0 dB in the preferences. However, it seems to me that after starting playback, there is a short delay before Quod Libet applies any of these gain adjustments. In my case, this leads to the first split second of a song being played back considerably louder and followed by a sudden volume drop.

I can reproduce this phenomenon in automatic, album and track mode. It obviously happens only on manually starting playback, not when Quod Libet jumps to the next song automatically, e.g. when one song ends and QL plays back the next item in the queue/song list.

QuodLibet 3.6.0 with OS X 10.11.4 El Capitan

Copy link

lazka commented Mar 30, 2016

Thanks. Is this a new problem?

Copy link

No, I observed this in 3.5.x as well. Just couldn't investigate the problem earlier.

@kaffeeundsalz kaffeeundsalz changed the title OS X Bug: ReplayGain is not applied during the first split second of a song (Replay) Gain adjustments are not applied during the first split second of a song Mar 30, 2016
Copy link

lazka commented Mar 30, 2016

OK, thanks.

Copy link

Also seeing this issue on Windows 10 with QL 3.6.0, but not on Arch Linux...

@lazka lazka added the windows label Apr 18, 2016
Copy link

wbiller commented Jul 27, 2016

I've set the standard gain and the pre gain to 6.0dB lately (was 0.0dB) and this is gone, or at least I can't hear any difference anymore.
tested on both systems osx and windows.

Copy link

tin-liu commented Mar 16, 2017

I am using 3.8.1, and tried a certain latest 3.9 development version on OS X 10.11.6 El Capitan. They both have this issue.

I think inserting a short silence into every started song would just help the problem, but I don't know how. I then tried to learn and write a plugin to pause/mute and wait for a short time (for ReplayGain to be applied) then start to play, as a workaround:

import time
import threading

from quodlibet import _
from quodlibet import app
from import EventPlugin

class MyPlugin(EventPlugin):
	PLUGIN_ID = 'myplugin'
	PLUGIN_NAME = _('Gap before play')
	PLUGIN_DESC = _('Mute about .2 second when songs start.')
	_enabled = False
	def _sleep_gap(self):
		app.player.paused = False
		app.player.mute = False
	def sleep_gap(self):
	def plugin_on_changed(self, songs):
		app.player.paused = True
		app.player.mute = True
		if songs is not None and self._enabled:
	def plugin_on_song_started(self, song):
		app.player.mute = True
		app.player.paused = True
	def enabled(self):
		self._enabled = True
	def disabled(self):
		self._enabled = False

With this script, the issue is sort of "suppressed" for some format (like .mp3), while some formats will have no output and stay mute for another few seconds (about 0.1 second for .wma and >10 seconds for some .ape files). And all the threading, (repeated) mute/pause/sleep/seek on plugin_on_song_started and/or plugin_on_changed seem necessary to mute all unexpected sounds.

After all my attempts, I think maybe this issue happens because "ReplayGain" is applied by a second thread?

Besides, "Fall-back gain" has no effect, therefore I think the recognition of "ReplayGain" is fast but applying is slow. Also, my loud songs need about -10 dB ReplayGain, so just setting "Pre-amp gain" to max (+6 dB) would help, however, if the "Pre-amp gain" could be set to +10 dB then this method would be even better in my case.

@lazka lazka closed this as completed in 17b511b Oct 22, 2017
Copy link

lazka commented Oct 22, 2017

Sorry that this took so long :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

No branches or pull requests

5 participants