It would be great to make any normalization work generic enough to work with 
all formats, since it seems every format has its own method - although many use 
some form of replaygain.

Bonus points if it can select among various tagged values depending on the
current state of various parts of the system. For example, systems based on
replaygain will typically have seperate values tagged for track/radio/mix use
and album/audiofile use, and a user may wish the system to use the former value
when the playlist is shuffled and the latter value when it isn't.

Would be nice to have Replay Gain switchable in and out from the remote (via 
Settings perhaps) so that RG tagged files (flac in my case) could be played 
with or without application of volume normalization.

I think I'm highly confused. There are two bugs I am cc'd under now - and I 
just don't understand how any user can actually effectively use Squeezebox 
without them. One is the "Various Artists" tagging issue. The other - this 
one - is essential. MC10 - like many programmes - analyzes audio when is rips 
the CD, so compilation CDs can be "attenuated" based on the volume of the 
track being burned. In this way, old and new CD tracks sound similar in 
volume. My wife keeps asking why some tracks are quiet, some are very loud. I 
explained to her, and he said "well, thats just stupid. It seems so 
obvious !". Agreed - lets get it in there !

I also use MC10 to rip my CDs into Windows Lossless format which supports the 
Replay Gain Tag.

Having the SB support Replay Gain in WMA files would be very useful.

Just to be clear, the normalize program
http://www1.cs.columbia.edu/~cvaill/normalize/ uses ID3v2.4 RVA2 tags to
indicate the replay gain value.

I hope this feature gets into the firmware at some point...

/Simon

Since Squeezebox 2 supports native FLAC decoding, I guess Replay Gain support on 
the SB2 device would be needed to allow FLAC to be sent over the network (rather 
than decode to PCM with "--apply-replaygain-which-is-not-lossless=a") *and* 
Replay Gain to be used. Sean recently mentioned that Vidur was looking in to 
this (but not for the initial SB2 release).

Off the top of my head, a SlimServer work-around might be add a decode-encode 
step in SlimServer, i.e. FLAC with RG comments gets decoded with "--apply-
replaygain-which-is-not-lossless=a" then gets re-encoded at low compression with 
FLAC, then streamed over network and then decoded in the SB2. Hopefully native 
RG support will be added soon to SB2 so this isn't needed.

I believe the popular MP3Gain app uses APEv2 tags for its ReplayGain tags, so 
this should be read from those too I guess... :-)

I also vote for MP3Gain compatibility. It's the only way I've found thus far to
circumvent this problem.

Moving bugs that won't be immediately fixed in 6.1 release. Please review and update if this is an error 
or if this bug has already been fixed.  Thanks.

This came through from Sonos today. Slim Devices should take note. They have 
stolen a march on SlimServer. This was in a mailer sent out today from them.

Volume Normalization
Music CDs are mastered at different volumes, when listening traditionally this 
is not an issue because all of the tracks on a given CD will be level relative 
to each other. Add in the power of digital music, and the ability to have 
queues of music that pull from 10s or 100s of different CDs and the result is 
that tracks with different volume levels get played next to each other 
resulting in changes in relative playback volume. Volume normalization is the 
solution to having to manually adjust the volume to have level playback volumes 
across multiple tracks. Volume normalization scans tracks and applies an up or 
down volume adjustment (in dB) so that all tracks play back with a level peak 
volume. The best way to achieve volume normalization is through a process that 
does not cause the tracks to be re-encoded (since that loses quality and is 
time consuming). This is normally done with metadata tags that are added to the 
file to tell the device playing it back how much the volume needs to be 
adjusted. Sonos now supports these tags and volume adjustment. It is important 
to note that Sonos does NOT apply the tags to the tracks. The files are 
analyzed by various 3rd party programs. The specific supported tags are listed 
below with the common programs that apply them.

Sonos will now recognize and comply with volume normalization specified by the 
following tags: iTunNORM (added by iTunes Sound Check), AverageLevel (added by 
Windows Media Player Volume Leveling to MP3 tracks), WM/WMADRCAverageReference 
(added by Windows Media Player Volume Leveling to WMA tracks), ReplayGain 
(added by FLAC or ReplayGain to FLAC tracks).

Considering for 6.2

*** Bug 127 has been marked as a duplicate of this bug. ***

This should be completely functional in tonight's 6.2 nightly release.   If you discover problems with it, 
please open new bugs.  Thanks!