[ksie]

Hi folks.   I'm fairly new to PC-audio.  Have been using Windows MP to play ripped files and WAVs I've created by recording Lps real-time through a USB device.   I'm ripping with EAC and compressing with FLAC.  One problem I've had with WMP is with Replay Volume (Gain).  

I have a Squeezebox on order.   A couple of questions regarding how it handles/supports Gain:

1.  What is a Replaygain Tag?  Is this created with a Tagging program?

2. Can I address Replaygain when ripping with EAC?

3. Does Slim Server and/or Squeezebox3 (and for that matter FLAC) recognize Replaygain tags?

4. If I use a Replaygain tag, or somehow else levelize volume among files, does this compromise sound quality?

Thanks much for any information,
Karl

[jakepunk]

1. The tag specifies an attenuation from a reference dB level to be used during playback.  The tag is created by the encoding program, FLAC in this case.

2. Add the option "--replay-gain" to the FLAC command line in EAC.

3. Yes.

4. Yes, by definition.  You are thowing away bits of data at playback time to attenuate the volume.  That is the price you pay for convenience.

This post has some more info about it, and this post talks about problems using it.  You could always encode with it and turn it off at playback time if you don't like it.  Likewise, you could not encode with it now and then decide to add the tags later with metaflac.

Disclaimer: I do not use replay gain, so I do not know how well the SB handles it or if current firmware versions are trouble-free.

[ctviggen]

You might not lose any information.  The replay is operating with 24 bits, while CDs only have 16 bits.  This means there are 8 bits of nothing (although they probably do some algorithm to fill those 8 bits with something) in the 24 bits.  If you take those 24 bits and shift them to the right (assuming the 16 bits from the CD are in the most significant positions), you'll "lose" one bit of resolution, but that bit wasn't valid anyway.  You've just lowered the sound level (by 3db?; by half?) and haven't lost any "real" bits (i.e., the 16 bits you care about).

[ksie]

Thanks guys.  Sounds like another thing with which to experiment.

Karl

[ctviggen]

I came up with an example.  Say you care about two bits.  You can then have the values 00, 01, 10, and 11 (ignore two's complement for now, so that the maximum level is 11, or 3 in base ten).  If you take those bits and add two extra bits onto them, so that you now have four bits, XXYY, where XX are the ones you care about and YY are the extras, then the maximum level will be 1111.  This technique is essentially what taking 16 bits of CD info to create 24 bits of information does.  If you then shift these to have 0XXY, you have lowered the output by one bit (the max level is no longer 1111 but is instead 0111), but the original information -- the XX bits -- are still there.  You've just gotten rid of a Y bit, which you made up anyway. Thus, you've not lost any real information for this shift.

In actual practice, it's more complex.  For instance, I believe that data is stored in two's complement, which means that 11 = -1 and not 3 in base ten).  Also, the link was talking about "1.5" bits; I'm not sure to what the "0.5" bits refers.

[ctviggen]

I think I'm wrong.  After more research, they're mapping 16 bits into 24 bits using an algorithm.  What this means in that my example, the bits XX don't equal XXYY; instead, XX gets mapped to YYYY.  This means that 11 could get mapped to 1111, 1110, 1101, etc., depending on the algorithm (and most likely previous data).  Therefore, when you recompress the data to modify the output, you're going to have to go through a limited version of this process, meaning that some information could be "lost".

[Carlman]

FYI...
Replay gain made my .flac files sound pretty bad compared to .wav files.  I didn't realize I'd set this option to be used but I had... and so I thought flac files sounded thin and flat compared to .wav.