[mythtv] ReplayGain support for MythMusic

[Chris Hamilton]

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

Okay.  My changes thus far are quite simple, so I don't feel so bad
about throwing them away.  When is the rewrite taking place?

> Taglib has native support for reading/writing RVA2 frames. If we support 
> writing tags, then we should use RVA2 (we write 2.4 tags).

Yes.  I hadn't thought about writing tags, but we'll likely want to
create ReplayGain tags when ripping CDs and at least preserve existing
values when modifying tags.  I doubt anybody will need the ability to
change them manually.

> You missed the XRVA tag, it's exactly the same as RVA2 but is a backported 
> feature to the id3 2.3 spec.

Thanks.

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

Simple enough.

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

That sounds like the best idea.  I'll follow your suggestion and make
this a separate ticket and patch, and add the functionality directly to
AudioOutputBase.

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

Personally, I use the album gain almost always, and prefer it to trump
the track gain.  But that's because I'm an 'album' listener, and almost
always listen to entire albums at a time.  The 'album' gain is
calculated such that the average volume of the entire album is
normalized to 89 dB, rather than per-track individually.  This becomes
especially important for albums where tracks merge seamlessly into each
other, as you don't want to have volume differences at track boundaries.

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

The ReplayGain spec defines how to calculate 'perceived volume', and
calculates the gain differences with respect to 89 dB.  All tools that I
know of use the same standard.  Early versions of LAME using 83 dB as a
reference, but you can tell what version of LAME is being used from the
headers. As long as the gain stored in the database is wrt to the same
reference, all is well.

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

Good enough.  A little investigation may be warranted.  Also, it may be
useful to have  a utility for calculating replay gain for any tracks
that don't have it already (for in the Utilities/Setup > Music Tools menu).

Cheers,

Chris