[mythtv] ReplayGain support for MythMusic

[Stuart Morgan]

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.

> - 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?

What defines 'normal' volume range? Are these gain values all relative to a 
single common value no matter which tool is used? If not, then does looking 
for every single possible type of gain header/frame serve any purpose?

> - 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.
-- 
Stuart Morgan