VST3 + prevent bit depth reduction = preserve dynamic range

I’m using Acon Digital’s Equalize 2 EQ plugin to apply loudness compensation for low volume listening which works great (in boosting the bass and treble according to relative loudness contours).

I’m streaming a 16-bit 44.1kHz FLAC file, which has the bit depth increased to 64-bit before entering the VST3 plugin (please see screenshot).

However when it leaves the processing chain (to go to a WiiM Ultra streamer) Audirvana applies a bit depth reduction, I imagine to match the original FLAC file (please see screenshot of the DAC input signal).

I have the UPnP settings to maximum bit depth and the streamer can handle 24 bit.

Is there anyway please that there could be a feature that avoids bit depth reduction (to match the input FLAC), but instead could match a predetermined user-configurable value in the settings (i.e. that supported by the DAC)?

(So not another link in the chain as such, like the up-sampling, but more a ‘preserving’ feature on the DAC input settings although actually the Volume Control stage of the screenshot is the stage that shows the bit depth reduction.)

Note also that when streaming an originally 24-bit FLAC the signal leaving the chain is also 24-bit so Audirvana’s doing the bit reduction from 64-bit to 24-bit, as expected. I mention this because if it can do both 64 → 16 bit and 62 → 24 bit then a customisable user setting to determine which (for FLACs with lesser original resolution) might be quite simple to implement?

(In order to preserve the higher dynamic range, and with respect to the higher resolution of the VST3 processing.)

Note:
Your screen shot shows the DAC receiving a 16-bit signal… This does not reflect that the DAC is operating on a 24 or 32-bit signal…

Audirvana is processing the plug-in with 64-bit precision as is the case with every 64-bit application/plug-in, and subsequently decimating the result to a real-world bit-depth associated to the DAC capabilities… You are not losing anything in this process, but you are gaining in mathematical precision of the plug-in DSP… The sample-rate is not affected, … This is different than bit-depth/sample-rate conversion processing for output to your DAC.

:notes: :eye: :headphones: :eye: :notes:

Yes the plug-in is processing with 64-bit precision, and altering the signal with EQ, within the dynamic range that 64-bit offers. It produces a modified waveform within the 64-bit space.

Audirvana is then subsequently (at the end of the processing chain) doing bit depth reduction to 16-bit, presumably to match the original input FLAC’s resolution, which is 16-bit.

My request is: it would be better if Audirvana did bit depth reduction only to 24-bit since 24-bit has a dynamic range of 144 dB, whereas 16-bit only has a dynamic range of 95 dB. So in bit depth reducing all the way down to 16-bit there must be some loss of information, compared to bit depth reducing just to 24-bit.

So, when VST processing (64-bit) is active, rather than Audirvana doing bit depth reduction to match the INPUT file, it should do bit depth reduction to match the OUTPUT capabilities (the input capabilities of the DAC).

When processing a 24-bit input file, the VST plugin processes in 64-bit still, and Audirvana subsequently bit depth reduces to 24-bit (to match the input file).

So my point is: if Audirvana can bit depth reduce to both 16-bit and 24-bit (depending on the input resolution) then it might be straightforward to let the user specify which (based on the DAC capabilities)?

That way a greater dynamic range will be preserved, thus increasing the quality of the music.

Currently the current bit depth reduction is losing information and dynamic range, and therefore the implementation is flawed.

In the DSP calculations the registers/accumulators are capable of handling the buffering of the 64 bit processing operation calculations… It is not simply adding zero’s to the file data… the processing is altering the file data by adding or subtracting bits when the parametric adjustments are defined and applied… The headroom of the DSP calculations are related to the capabilities of the accumulators in a 64 bit calculation where data is buffered during the algorithmic operations of the plug-in.

Bit-depth is relative to the source ADC and not related to the math involved in the DSP calculations.

:notes: :eye: :headphones: :eye: :notes:

I think you misunderstand the issue. Please allow me to explain:

Audirvana increases the bit depth to 64-bit prior to VST processing, which is correct.

VST processing happens in a 64-bit space. It’s adding more precise detail, which is also correct.

Audirvana then reduces the bit depth to 16-bit (to match the INPUT FLAC’s resolution), losing dynamic range and detail in the process, which is wrong.

Audirvana should instead reduce the bit depth to 32-bit or 24-bit, to match the OUTPUT capabilities (the output DAC’s capabilities).

24-bit has more dynamic range than 16-bit. 24-bit has a dynamic range of 144 dB whereas 16-bit has a dynamic range of 95 dB.

You lose detail when bit reducing to 16-bit. Most DACs support 24-bit or even 32-bit and their dynamic ranges are therefore greater than 16-bit.

So Audirvana should have a setting to allow the user to force what resolution is output.

No it does not… it is using 64 bit math to calculate the parametric adjustments altered in the plug-in DSP.

:notes: :eye: :headphones: :eye: :notes:

No the issue isn’t about the VST processing.

The issue is that Audirvana is converting 64-bit to 16-bit AFTER the processing.

It should be converting 64-bit to 32-bit or 24-bit, depending on the DACs capabilities, thus keeping the greater dynamic range.

You are conflating ‘bit-depth’ of the file with the 64 bit math used in the DSP algorithmic calculations and the related accumulator headroom.

Your plug-in will not work on a 64 bit-depth file… (384dB dynamic range)

:notes: :eye: :headphones: :eye: :notes:

The issue is not really about the input file or the processing.

If you notice in the screenshot below the bit depth is reduced from 64-bit to 16-bit at the ‘Volume Control’ stage.

It should only be reduced to 32-bit or 24-bit depending on what the DAC supports. Reducing all the way to 16-bit loses dynamic range.

Again you are conflating ‘bit-depth’ related dynamic range of the file with the 64 bit mathematics employed in the DSP calculations and accumulator/buffers… What is happening with the file, is the bit-depth does not change, otherwise your plug-in won’t operate… the DSP is calculated related to the bit-depth and sample-rate of the file that is introduced to the plug-in…

:notes: :eye: :headphones: :eye: :notes:

Yes agreed. But the DSP still operates in a 64-bit space. The EQ is modifying what’s originally a 16-bit input, and in doing so is creating details and waveforms with more precision than the original 16-bit.

Imagine if 16-bit means 1 decimal place and 64-bit means 2 decimal places.

For simplicity:

Say an input sample has a value of 2.5 (16-bit).

Audirvana converts to 2.50 (64-bit).

Say a gain of 2.50 (64-bit) is applied.

Say the VST calculation is 2.50 x 2.50 = 6.25 (64-bit).

When I reduce the bit depth back to 16-bit (1 decimal place) I get 6.3 when rounded.

So you’re losing 0.05 of detail introduced by the VST plugin.

The resolution of the calculation is the issue… not the dynamic range… the calculations are done out to 64 zero’s and then truncated to a real-world operational resolution… this is intrinsically tied to the capabilities of the plug-in operation…

:notes: :eye: :headphones: :eye: :notes:

Audirvana ties it to the input file resolution (16-bit), not the real-world output DAC resolution (24-bit or 32-bit) or plug-in capability (64-bit).

This is the problem!

No… the 64 bit math is applied to the bit-depth and sample-rate of the file introduced to the plug-in architecture… Again you are conflating the ADC bit-depth with the mathematics used in the plug-in architecture… If you did not use the plug-in architecture, your DAC will only operate on the bit-depth and sample-rate of the source file…

:notes: :eye: :headphones: :eye: :notes:

I think we need a third opinion! - Audirvana support?

It’s easy to understand… Using your logic, if the file is being upsampled to 64 bit-depth before being processed by the plug-in, it (the plug-in) will not work when this 64 bit-depth file is introduced to it.

:notes: :eye: :headphones: :eye: :notes:

VST3 plug-ins are 64 bit!

Only the resolution of the mathematics used in the DSP calculations… Again, you are conflating bit-depth dynamic range of a file with the resolution of the DSP processing calculations.

:notes: :eye: :headphones: :eye: :notes:

I thought they were two of the same thing?

A 16-bit file has numeric samples described by 16-bit numbers.

DSP calculations work on 64-bit numbers or 64-bit ‘samples’…

Prior to DSP processing Audirvana therefore zero-pads the 16-bit numbers to 64-bit?

Do you know of any digital-audio files that are recorded at or upsampled to 64/96kHz…? (your plug-in is good to 96kHz) can you upsample your files to 64/96kHz… No.

:notes: :eye: :headphones: :eye: :notes: