[mythtv] ReplayGain support for MythMusic

Steven Adeff adeffs.mythtv at gmail.com
Tue Feb 26 16:03:53 UTC 2008

On Mon, Feb 25, 2008 at 6:33 PM, Stuart Morgan <stuart at tase.co.uk> wrote:
> On Monday 25 February 2008 22:50:58 Chris Hamilton wrote:
>  > (Obviously, replaygain support needs to be added to each of the metaio*
>  > classes. I've only added it to the two media types commonly found on my
>  > system for the time being. I'd appreciate pointers to documentation for
>  > how replay gain info is embedded in other media types, and even sample
>  > files containing replaygain info.)
>  After 0.21 I intend to start using taglib for all tag types that it supports,
>  this may have an impact on what you are planning. All the metaio classes will
>  likely receive large rewrites or be replaced completely.
>  Taglib has native support for reading/writing RVA2 frames. If we support
>  writing tags, then we should use RVA2 (we write 2.4 tags).
>  You missed the XRVA tag, it's exactly the same as RVA2 but is a backported
>  feature to the id3 2.3 spec.
>  > - Currently, I'm storing a 'track_gain' and an 'album_gain' parameter in
>  > the music_songs table.  The 'album_gain' parameter is theoretically the
>  > same for an entire album, and could be stored in the music_albums table
>  > instead.  Should I move the 'album_gain' to the albums table, or should
>  > we handle the possibility that people customize 'album_gain' on a per
>  > track basis? (in which case it won't be the same for all tracks in an
>  > album)
>  album_gain should be in the albums table.
>  > - Application of the replaygain correction directly to the samples
>  > before they are fed to the sound-card.  This is currently manually
>  > hooked in for each decoder class, but I was thinking about making an
>  > abstract AudioOutput class that handles an 'amplification' affect, or
>  > adding such functionality to the AudioOutputBase class.  Ideas here?
>  > Should I even be doing the amplification myself, or should I modify the
>  > sound-card volume directly?
>  Don't think we want to modify the sound card volume and adjusting
>  amplification is probably best done in AudioOutputBase, but you may want to
>  submit this first as a separate patch/ticket.

Just remember that some of us use S/PDIF and the soundcard's "volume"
doesn't actually do anything! (ie I'd much prefer it does it in
'software' like most other apps do).

>  > - Somewhat intelligent decision of whether to use the track_gain or the
>  > album_gain depending on the shuffle mode. (Use track_gain always, and
>  > album_gain when in album mode.)  I was thinking this should be smarter
>  > still, and probably use album_gain when the player notices it is playing
>  > in any sequential mode and that there is more than one successive track
>  > from the same album.  Ideas here?
>  I've no idea of the intended effect of having two different gain values.
>  However instinctively I'd say that track gain should always trump album gain
>  where it is defined. If track gain doesn't exist for that track, then use
>  album gain. I wouldn't complicate things by looking at shuffle modes and
>  playlist orders, unless I'm missing something about having two different
>  values?

album gain is the gain for the whole album, so each track is scanned
and the lowest gain value from all the tracks is used. This is so when
you play an album through you don't have each track having a different
peak level and it sounds like it would if you were playing it back
without replaygain enabled and the volume just turned up a little

track gain is the gain value for just that track.

so Chris has it right in my mind (and how I use replygain). What is
being played should be looked at to determine the correct one to use.
I would say default to track gain "unless" a whole album is being
played which hopefully can be determined by looking at what the
playing play list contains and if it matches say >80% of the tracks in
that album as determined by the db. It would probably also be good to
have an override ability. A small icon displaying the current replay
gain status (a "T" or an "A" or blank) would probably also be helpful
and fairly non-intrusive.

>  > - Add replaygain support to CD ripping. Would be easiest to use external
>  > tools (vorbisgain, mp3gain, etc) but maybe it would be better to use
>  > some library that can work directly on the raw PCM audio.  Do such
>  > libraries exist?
>  We encode to mp3 using lame which implements replaygain. I don't know about
>  other formats, but it may be that those encoders already support replaygain
>  in some fashion.

also, don't forget that replaygain *can* cause clipping if a gain
value is too great. I believe it will tell you both the suggested gain
to reach the target and the greatest gain that will not cause

I'd highly suggest using the greatest non-clipping gain, or if made an
option using that as the default.


More information about the mythtv-dev mailing list