Hi, it would be nice to implement some "normalize volume levels"
function in the Rhythmbox player.
On the IRC channel we had some discussion (pasted below) about it, maybe
could help a bit, but i'm sure you're clever enough :)
{
* Now talking on #rhythmbox
<__8472> hi, does it exist something like "normalize volume levels"
function in the Rhythmbox player?
<Delk> If you have ReplayGain tags in the files, they are probably used,
at least for some formats
Loaded log from Mon Dec 22 16:25:07 2008
* Now talking on #rhythmbox
<Delk> __8472, did you see my response just before you left and re-joined?
<__8472> Delk: yes, i see the history. that lefting of channel was a
mistake, i screwed up something. thx anyway. hm, never heard about those
ReplayGain tags before.
<__8472> i just mean something like what i see e.g. in the k3b burner
when burning "audio cd", there is a function "normalize volume levels"
<__8472> and using some kind of tags in each file have purpose only when
you have few of them. but in the case of thousands files it looks like a
horror
* edgimar (~edgi...@dyndsl-095-033-124-246.ewe-ip-backbone.de) has
joined #rhythmbox
* edgimar has quit (Ex-Chat)
* edgimar (~edgi...@dyndsl-095-033-124-246.ewe-ip-backbone.de) has
joined #rhythmbox
<Delk> __8472, K3b probably goes through all the files and analyzes the
files for their volume level to find out how to change each track's
volume to reach a common average level
<Delk> There's no way to "normalize" the volume of a track without
decoding the entire file first and going through it to find the peak and
mean volumes etc.
<__8472> Delk: probably yes, and is it somehow possible even for
rhythmbox? maybe through some plugin, or something alike?
<Delk> That takes a while, so you really can't do that every time you
start playing a track, so the data would need to be stored somewhere for
future use. That's essentially what ReplayGain does (for some formats
anyway)
<Delk> And yeah, I have replaygain tags in my entire ogg/vorbis library.
It's manageable (from the command line), though there could be nicer
solutions
<Delk> Anyway, AFAIK the replaygain support in RB doesn't even work if
you use crossfading, only if you use the "traditional" engine
<Delk> so it may not be what you want anyway
* tretle__ (~tre...@194.125.95.108) has joined #rhythmbox
* tretle_ has quit (Read error: 145 (Connection timed out))
<__8472> Delk: i understand that, and have thought about that too. so
why not to solve it this way: - in each player, there is something like
playlist. thus the player must know what is going to be played next.
even if he's in shuffle mode. so if he knows what to play next, then the
program can use some kind of CACHE, or TEMP directory where to prepare
entire data's for the "normalize volume levels" function, and maybe even
for another functions what could b
<__8472> e added. no?
<ish___> because the 2nd time you play a track, you end up duplicating
the work - it makes more sense to preprocess everything so that the mp3
will always have the gain attached to it - no matter where you play it
<__8472> isth___: to whom belongs your msg.?
<ish___> you
<ish___> surely there is some replaygain app that you can feed the
folder with all your music and itll recursively walk the directories and
add the gain to everything?
<__8472> isth___: hm, them i'm not sure if i fully understand what you
mean. with your first reply. i'm not a programmer, or such a "sound
processing" guru.
<Delk> __8472, probably possible, yes, but might produce trouble e.g.
with rather long tracks (it takes quite a while to decode and analyze an
hour-long track, so how do you make sure that you've buffered enough?
how much should you buffer?)
<ish___> im not the 2nd either. what youre saying is 'hey, why doesnt
RB have something to automatically tag the GAIN (amoutn of vol to
add/remove to make the sound normalized) - maybe something that would
tag the GAIN on the next track while its playing the current track"
what im saying is "go add the GAIN to all your tracks ahead of time,
and then youre good forever"
<Delk> ish___, the command-line vorbisgain tool allows that. I'm not
sure about mp3. I'd imagine that if there's a tool for setting
replaygain tags for mp3, it'd also allow recursive directory processing
<ish___> delk: id assume so too, i dont personally use replaygain, but
certainly there is some tool to preprocess a folder of songs
<ish___> because 'thats the way to do it'
<ish___> __8472: even in iTunes, if you say 'do sound normalization'
itll sit there and normalize every song in your library, tag them with
the GAIN/normalization information, and then start using that info. it
wont tag them on demand
<Delk> ish___, yeah, maybe players like RB could automagically run
tracks through a gain tool after ripping or something. Anyway, analyzing
the files once and putting the gain information into tags (and then
using it from there when playing) is the Right Way
<Delk> It's a bit of a pity, perhaps, that it's not better integrated to
most players, so you need a separate tool for having the tags set first
<ish___> ill bet you dollars to dimes (or whatever teh phrase is) that
sound-juicer can add gain automatically?
<Delk> Anyway, I just do "vorbisgain -a -s -f -r" or something like that
in my music folder after I've ripped or otherwise imported new music.
Doesn't do a thing to mp3's, though, so that'd need a separate tool.
<ish___> anyways, __8472: for now, the thing to do for sound
normalization is research that replaygain thign - and find an app thatll
add the gain to all your existing tracks. RB (with the right options
checked) should pick up the gain info automatically
<__8472> Delk: well, easy, it could be solved through some preferences,
that normally NORMALIZING funcion will be disabled, and if enabled, it
will enable other options to set-up too. somethink like buffer size, or
storage path, and more. anyway. about that trouble you've said, well,
why not to make some kind of "on the fly" using your words= "decode and
analyze" functions? so if one song will be played, the next will be in
the state of preparing/buffering -
<__8472> somewhere. and if it will be really long/large, then why not
use some kind of mechanism like e.g. when YOUTUBE is playing video - and
on the background it's still in the progress of downloading remaining part.
<Delk> AFAIK there's no standard for storing gain information in mp3s,
so even though some encoders (or players) might add it there in
non-standard tags, I'm not sure if RB supports it
<Delk> Oh, and yes, I think there may have been some trouble with the
replaygain code in RB (though I don't think I've heard any of them in
practice in a long time), so it's probably disabled by default. You can
enable it with a gconf key
<__8472> isth___: i don't use iTunes or any other similar thing.
<Delk> __8472, if you first have a 1-minute track and then a 1-hour
track, and you only start preprocessing the latter one when the first
one starts playing, you probably won't be done preprocessing the next
track before the 1-minute track ends and you need to start playing the
next one
<Delk> Anyway, I'm sure it could be tweaked to more or less work
<Delk> Having better support for replaygain-style tags would IMO be a
better way to spend the time anyway
<Delk> To summarize an answer to your original question regarding the
current status: "maybe, but you need to use a separate tool for setting
the normalization values first"
<Delk> In case you end up trying replaygain with RB, the gconf key is
/apps/rhythmbox/use_replaygain
<__8472> Delk: yes, it's could not be perfect, but it might work. as
i've sai'd, you can put an option to enable NORMALIZING to prefs., and
there can be some warning for "better CPU performance" requirement, and
even some function what will show users "PC Performance" if it's enough
or not. because on today's computers it's not like 10years ago, when you
had to wait for something to finish. today it's much faster, so i don't
think it would take that much tim
<__8472> e it will cause to prepare required data's. of course, it could
consume much more CPU performance, but it could be solved somehow using
CLI's NICE priority for the process - to not slow down other processes
<__8472> anyway, thx for your answers. i don't like that REPLAYGAIN ,
but i will maybe send this to some kind of wish list for rhythmbox ,
maybe people there will find some way to solve this.
<Delk> __8472, I agree that it would be nice if (good) normalizing
support were better integrated
<Delk> I'd just still do it through replaygain or similar ;-)
<__8472> yes indeed it would :) , i hope they won't refuse it.
}
thx
Daniel
_______________________________________________
rhythmbox-devel mailing list
rhythmbox-devel@gnome.org
http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
