Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Does software volume leveling degrade audio quality? (Read 36583 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Does software volume leveling degrade audio quality?

Reply #50 –
I would agree, but the operation that is closest to what is typically done in a DAW is inversion + multiplication (well actually log->ratio + multiplication). IIRC, even to this day, division tends to be more expensive than multiplication.

Does software volume leveling degrade audio quality?

Reply #51 –
I think how computationally "expensive" an operation is, can be ignored so far. The term refers to performance and not precision. Being able to test 1000000 samples within a few seconds is sufficient for the demonstrated purpose. I think simplicity and understandability of the presented sample code is more important than performance tuning to the last micro op. Furthermore, precision is not an issue with the chosen approach, anyway, as I have shown. Mathematically division is identical to multiplication with a reciprocal. Implementation details between both operators are also irrelevant here since all used operations are strictly defined within the bounds of IEEE 754.

So I really can't comprehend your uphold criticism, it neither touches the model's validity nor its generated results. It doesn't actually even matter for the results, how exactly we apply inverse operations or if at all. It is just easier to calculate the results that way. Instead of applying pairs of contrary gain values we could also apply completely arbitrary values for each step. The only thing, that matters, is counting how many gain changes have actually been applied to a sample and how much its actual value differs from the expected value afterwards.

When you touch the issue of actual DAW implementations it is rather going to be the opposite: since they can fully exploit even higher precision FPU capabilities for free, other than what is utilized in strict IEEE 754 code, actual implementations may even surpass the presented results. But since benski's and my presented results were already far better (higher SNR) than any handyman approach presented in this thread so far, I think that is negligible.

I propose you present an alternative implementation with significantly different results, if I have overlooked anything.

Does software volume leveling degrade audio quality?

Reply #52 –
I don't think much of anything divides to do attenuate volume.  Beside it being needlessly slow, that would mean having separate functions for applying positive gain verses negative gain, which is really weird.  All software I've seen just computes a gain coefficient and multiplies.

In Rockbox we just do this:

Code: [Select]
static void dsp_apply_gain(int count, struct dsp_data *data, int32_t *buf[])
{
    const int32_t gain = data->gain;
    int ch;

    for (ch = 0; ch < data->num_channels; ch++)
    {
        int32_t *d = buf[ch];
        int i;

        for (i = 0; i < count; i++)
            d[i] = FRACMUL_SHL(d[i], gain, 8);
    }
}


Where gain is the product of all the other gains in the system (replaygain, precut, etc).

Does software volume leveling degrade audio quality?

Reply #53 –
Could you please look at the specific case instead of just throwing in generalizations as Axon? Of course division is much slower than multiplication! And generally, if you have to do n multiplications with the same divisor d, you can calculate the 1/d once and then apply n multiplications for a huge speedup.

But here the inverse gain is applied only once. So the chosen approach:

Code: [Select]
nextGen *= gain;
nextGen /= gain;


is both faster and more precise than using multiplication only:

Code: [Select]
nextGen *= gain;
float invgain = 1/gain;
nextGen *= invgain;


So, what's the super important point here, really? Do I just not get it? Using inverse gain at all has the sole purpose to keep the exponents stable over many iterations. But that mechanism must not introduce its own unrelated error for proper results (as in the case of the additional 1/gain step). An alternative would be to not use inverse gain at all, but just multiply n times by an arbitrary gain value in both float and double precision (to calculate the expected result) and then compare them at the end. The problem with the latter is that for many passes the sample's value might accumulate into extreme territory (like 1e-30 or 1e30), where resolution is not representative for the usage of float in audio applications anymore.

I repeat, just throwing in only generally related cents just confuses non-technical readers. If you want to contribute to the solution, present a modified or alternative implementation with significantly* different results and add an explanation why it should be better.


*The two, presented so far, were developed independently from each other and produce comparable results within +/- ~1 dB.

Does software volume leveling degrade audio quality?

Reply #54 –
rpp3po, what I think you may be missing is that some integer processors (e.g. DSPs) do not even have a divide instruction. Generally a divide instruction rakes 3x as many processor cycles as a multiply. Therefore, DSP coders do not use divide instructions. Compilers strive to avoid them too.

Does software volume leveling degrade audio quality?

Reply #55 –
Just suggest an alternative implementation, that doesn't add unrelated error, and I'll happily replace the division.

Not that I expect the outcome to be much different.

Again, the division is only in the code because the chosen approach seemed (at least to me) to require the least trade-off regarding the use of inverse gain while keeping everything simple and comprehensible. It is calculated and applied in a single pass. I do not feel any urge to enforce the inclusion of uncommon operators in this experiment, if anyone thinks that's the case!  I just tried to keep the introduction of unrelated error at a minimum.

Does software volume leveling degrade audio quality?

Reply #56 –
To some degree the goal here is to try to second-guess the wanker who said he got 0.1% distortion - not to show the what 32-bit or 64-bit floating point computation ought to do. All Mike and I are saying is that for the vast majority of DAW implementations, in both hardware and software, a divide instruction will never happen. I'd expect a small factor increase in quantization error as a result (but nothing as huge as 0.1%).

So, something truly analogous would be something like (apologies for switching to untested C pseudocode):

Code: [Select]
float compute(float dbGain, float x) {
  float factorGain = fpow(10.0, dbGain/20.0);
  float factorAttenuation = fpow(10, dbGain/-20.0);

  x *= factorGain;
  x *= factorAttenuation;

  return x;
}

float run() {
  float x=1;
  for (int i=0; i<N; i++) {
    x = compute(rand(), x);
  }
  return x;
}



Or in 16-bit fixed point (this is entirely from memory though):
Code: [Select]
// 16-bit number stored in 16 LSBs of unsigned int.
// Numbers greater than 1 stored in upper 16 LSBs - result computed via multiple precision arithmetic.
// Sign bit not handled

unsigned int mult(unsigned int a, unsigned int b) {
  int sign=1;

  if (a<0) {
    sign *= -1;
    a *= -1;
  }

  if (b < 0) {
    sign *= -1;
    b *= -1);
  }
  a = ((a&0xFFFF * b&0xFFFF) >> 16) + \
      (((a&0xFFFF0000 >> 16) * b&0xFFFF)) +
      (((a&0xFFFF) * (b&0xFFFF0000)) +
      (((a&0xFFFF0000 >> 16) * (b&0xFFFF0000 >> 16)) << 16);
  a *= sign;
  return a;
}

int compute(float dbGain, int x) {
  // In reality fpow() would be replaced with a function
  // calculating the exponent directly as a fixed-point integer
  int factorGain = (int) (0x10000*fpow(10.0, dbGain/20.0) + 0.5);
  int factorAttenuation = (int) (0x10000*fpow(10, dbGain/-20.0) + 0.5);

  x = mult(factorGain, x);
  x = mult(factorAttenuation, x);

  return x;
}

int run() {
  int x=0x10000;
  for (int i=0; i<N; i++) {
    x = compute(rand(), x);
  }
  return x;
}


For 24-bit fixed point, just edit the scale factors and bitmasks accordingly.

Does software volume leveling degrade audio quality?

Reply #57 –
To clear the way for a general consensus, I have removed the division from the float pipeline. The samples aren't touched by anything else than multiplication anymore. Attached you'll find the source code and a binary.

You can execute it with 'java -jar FloatLoss.jar <number of iterations>', for example:

Code: [Select]
java -jar FloatLoss.jar 50

The results for the new version are as follows:

It will adjust the number of samples automatically for about 1 minute of number crunching on a 2.4 GHz Core 2 Duo.

Code: [Select]
Peak SNR after     5 iterations: -125,410 dB
 RMS SNR after     5 iterations: -144,166 dB
Peak SNR after    10 iterations: -122,216 dB
 RMS SNR after    10 iterations: -141,154 dB
Peak SNR after    60 iterations: -115,551 dB
 RMS SNR after    60 iterations: -133,167 dB
Peak SNR after   120 iterations: -111,625 dB
 RMS SNR after   120 iterations: -129,867 dB
Peak SNR after   500 iterations: -105,804 dB
 RMS SNR after   500 iterations: -122,141 dB
Peak SNR after  1000 iterations: -102,149 dB
 RMS SNR after  1000 iterations: -117,724 dB
Peak SNR after  5000 iterations: -94,230 dB
 RMS SNR after  5000 iterations: -105,638 dB
Peak SNR after 10000 iterations: -90,009 dB
 RMS SNR after 10000 iterations: -99,916 dB
Peak SNR after 100000 iterations: -74,356 dB
 RMS SNR after 100000 iterations: -80,183 dB

(HA's 'code tag' handling of white space could be improved.)

As before '1 iteration' means one pair of gain and inverse gain has been applied.

Does software volume leveling degrade audio quality?

Reply #58 –
Just figured I'd give you this late-breaking update:

The guy who did that test of 60 volume raise / lower pairs admitted to me in an IM at that other forum that he did it at 16 bits fixed point.

Next!

--Ethan
I believe in Truth, Justice, and the Scientific Method

Does software volume leveling degrade audio quality?

Reply #59 –
Quote from: Ethan Winer on
BTW, anti-science bias is everywhere. After I made a few posts following the above, they started deleting my posts, and now they have me blocked. Last week I was banned from the Stereophile forum for my pro-science position. Life is good.


I guess they don't tolerate arrogance even when it's well-justified:
http://xkcd.com/263/