search

lebauce / quodlibet

Automatically exported from code.google.com/p/quodlibet
1 stars 0 forks source link

[PATCH] Enhanced Replaygain configuration #132

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
First of all, thanks to all the QL devs for an excellent music player, and
also the Replaygain plugin which is extremely useful.

One issue I had found, however, was that when playing a very mixed
collection of audio Replaygain would be applied properly on all files
*with* RG tags but of course no change where they didn't exist. This means
files that hadn't yet / couldn't / wouldn't be RG-tagged would typically
play MUCH (up to 10-11db) too loud as a result of the good ol' loudness war
(http://en.wikipedia.org/wiki/Loudness_war). This is a fairly traumatic
experience if you're playing on a big sound system (or even headphones). 

The way I've seen this handled before, and indeed by the gstreamer plugin
(http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-good-plugi
ns/html/gst-plugins-good-plugins-rgvolume.html)
is by having a default or 'fallback' gain to apply when missing track or
album values.

Another small feature I missed, though not appreciated much by true
audiophiles, is a master gain to apply on top of RG tags. This allows a
balance between loss of signal:noise / max volume and total
volume-levelling especially as RG reduces most new rock albums by 9db or more.

Please see the attached patch I've developed to address both of these. Hope
I've done that right.. Please test extensively / tell me where I might have
gone wrong! I'm a newbie at Python, and also have never developed with GTK
so it was a fair amount of guestimation.. still, been using here for about
a month and no problems, and now QL is my perfect audio player...

Nick

Original issue reported on code.google.com by nick.bou...@gmail.com on 17 Feb 2009 at 1:58

GoogleCodeExporter commented 9 years ago 
voilà

Original comment by nick.bou...@gmail.com on 17 Feb 2009 at 1:58

Attachments:

GoogleCodeExporter commented 9 years ago 
I like the concept, but please eliminate the commented code and make the rest 
comply
with PEP-8 at http://www.python.org/dev/peps/pep-0008/ (clear the extra blank 
lines,
mostly).

Original comment by steven.strobe.cc@gmail.com on 17 Mar 2009 at 5:05

GoogleCodeExporter commented 9 years ago 
Issue 103 has been merged into this issue.

Original comment by steven.strobe.cc@gmail.com on 19 Mar 2009 at 8:04

GoogleCodeExporter commented 9 years ago 
OK thanks - my bad for leaving the old code in. Finally got round to clearing 
it up;
hopefully it's a bit more Pythonic now, though I doubt it's perfect...

Original comment by nick.bou...@gmail.com on 25 Mar 2009 at 4:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Works great in my tests, well done. But it still needs a bit more work: First, 
expand
the unit test in test_formats__audio.py to include the new features. (Writing 
tests
is a drag, I know, but it will help your patch make it into SVN.) Drop the space
before the comma in the new 'def replay_gain'. Also, it looks like you merged 
the
BitrateColumn patch into your local branch, which shouldn't be in this bug.

Thanks for the patch(es).

Original comment by steven.strobe.cc@gmail.com on 26 Mar 2009 at 4:51

GoogleCodeExporter commented 9 years ago 
Cool. Getting there slowly - got rid of the other patch (oops*), fixed the 
space, and
added some tests which I reckon cover most combinations of scenarios (and to an
extent a few cases that weren't being explicitly checked, like 
clipping-prevention).
My usual newbie-disclaimer applies here, though they all pass when I run them. 
Here
is the latest.

Nick

* yes oops BUT (slightly O-T).. how best to manage multiple patches without 
checking
things in? Should you just keep a folder of patches separately which you then 
apply
before each build or is there an easy way I'm missing..

Original comment by nick.bou...@gmail.com on 27 Mar 2009 at 8:08

Attachments:

GoogleCodeExporter commented 9 years ago 
I fussed with the strings in the props window a bit for consistency. Otherwise 
it
looks great.

Regarding managing your code: use Git (or Mercurial, or Bazaar). They're 
designed for
that kind of thing. On my repo[1], I've been creating a new branch for each 
issue:

  git checkout -b 132-enhanced-replaygain-support master

(my local master follows the official SVN.) This ensures that every patch works 
on
its own against current SVN. To test them together, I have another branch,
all_patches, which I switch to and merge the other branches into. I'll keep 
updating
the new contributing guide in the wiki as I find more information like this to 
share.

[1] https://github.com/stevenrobertson/quodlibet-testing/tree

Original comment by steven.strobe.cc@gmail.com on 29 Mar 2009 at 5:51

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by steven.strobe.cc@gmail.com on 18 Jun 2009 at 8:11

GoogleCodeExporter commented 9 years ago

Original comment by steven.strobe.cc@gmail.com on 28 Jun 2009 at 4:23

GoogleCodeExporter commented 9 years ago 
This issue was closed by 38e749db42.

Original comment by steven.strobe.cc@gmail.com on 4 Jul 2009 at 11:46