I don't think that you can argue that changing volume is "not a change to the digital data". MC's volume changes, absolutely positively change the digital data. Using words like "destructive" or "harmful" are meaningless in this context because a change is a change.
Hendrick's argument that the volume may be changed by other gear outside of MC, in the digital domain, is ancillary. That may, or may not happen. But we can be sure when MC is changing the volume and thus changing the digital samples.
Now why would anyone care? Perhaps if you use a multi-bit DAC and you want to be really really sure you deliver the as-recorded samples to your DAC. Or maybe keeping all samples intact just makes you feel better about the digital playback process. Or maybe you think you hear a difference between manipulated samples and original samples. Whatever the reason, when MC makes volume changes, it changes the samples.
So as I said, the blue light is not a "bit perfect" or "no changes" light. It's something else. I'm not upset about it or anything, because I know how to read the playback path window. I just think it's important to be accurate about what something is or is not.
Brian.
Brian, I think you're missing a key part of what Hendrik said:
The EQ icon will turn blue when no processing is being performed other than volume, and the output bitdepth is sufficiently high for the input to be properly represented.
MC automatically sends output to the DAC at the highest bitdepth the DAC supports (typically 24 bit these days, but sometimes 32 bit). Most source material is 16-bit. Passing 16-bit audio data as 24-bit data is lossless because the extra eight bits are just padded with zeroes. You can argue whether that's "bitperfect," but most people agree that it is because all of the original audio data is present and recoverable in its original form.
If you digitally change the volume on such a signal it's no different than zero padding the bottom unless you add more than 8 bits of attenuation. If you attenuate by, say 18dB you'll have 3 bits of zeroes at the "top" and 5 bits of zeroes at the "bottom." All the original audio data is still present and recoverable in its original form. It's every bit as "bit perfect" as the basic bitdepth padding case. The samples aren't changed except with respect to scale. We know this because JRiver can do thousands of volume manipulations on a signal and (as long as it doesn't run out of "pad") can output a full-scale signal that is bit identical to the original signal (this has been tested).
Now if you're dealing with special encoding, or attenuating more than the "pad" allows, then you're correct, you're losing some very quiet portions of the original audio data, but for someone listening to Red Book CD on a 24-bit DAC, JRiver is still bitperfect (in the sense of all original audio data being present and recoverable) down to -48dB of attenuation.
So I think it's a little misleading to say that "samples are being altered." In the case of redbook audio with a typical DAC, the samples are not being altered anymore than they're being altered by lossless compression (which also "changes the digital data" in the strict sense, but only in ways that allow perfect reconstitution of the original). They're being altered with respect to their volume, but in no other respect, and all original data is (except in the special cases mentioned) still present in the output stream.
None of this applies to higher bitdepth material or with lots of attenuation, but based on Hendriks comment the light should turn off in those cases (I'm not in front of MC so cannot test)? In any case, my point is that merely adjusting volume doesn't
necessarily affect "bitperfectness" anymore than lossless compression or bitdepth padding do.