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

Closed
kaffeeundsalz opened this Issue Mar 30, 2016 · 7 comments

Comments

Projects
None yet
5 participants
@kaffeeundsalz

kaffeeundsalz commented Mar 30, 2016

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

@lazka lazka added bug macOS labels Mar 30, 2016

@lazka

This comment has been minimized.

Member

lazka commented Mar 30, 2016

Thanks. Is this a new problem?

@kaffeeundsalz

This comment has been minimized.

kaffeeundsalz commented Mar 30, 2016

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

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

@lazka

This comment has been minimized.

Member

lazka commented Mar 30, 2016

OK, thanks.

@neersighted

This comment has been minimized.

neersighted commented Apr 18, 2016

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

@wbiller

This comment has been minimized.

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.

@freezelty

This comment has been minimized.

freezelty 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 quodlibet.plugins.events 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):
		time.sleep(.1)
		app.player.seek(0)
		time.sleep(.1)
		app.player.paused = False
		app.player.mute = False
		
	def sleep_gap(self):
		threading.Thread(target=self._sleep_gap).start()
		
	def plugin_on_changed(self, songs):
		app.player.paused = True
		app.player.mute = True
		if songs is not None and self._enabled:
			self.sleep_gap()
			
	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 in 17b511b Oct 22, 2017

@lazka

This comment has been minimized.

Member

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