BUG: Phase invert is causing samples to 'wraparound'

There currently seems to be an issue with Roon’s phase inversion feature, whereby any clipped samples are ‘wrapped around’ and instead of just clipping at positive 0dBfs, will go to negative 0dBfs, creating significant distortion.

This can be audibly demonstrated very easily by playing a track with samples at 0dBfs, or that contains intersample overs.

If you listen to ‘Bon Voyage’ by Droeloe ( Bon Voyage by DROELOE ) and then enable phase inversion as shown:

Then just listen from 0:20 to 0:35. You can hear obvious and very significant distortion. Which immediately disappears if you disable the inverted phase option.

This can also be shown by looking at the waveform. I recorded this with VB-Hifi cable which is a bit-perfect virtual cable.

Original (phase inverted in audition to more easily compare to Roon’s phase inverted output):

Roon Inverted Phase output:

You can see that at the point where the cursor is (as well as a few other points), samples suddenly wrap-around to negative 0dBfs when that doesn’t happen in the original file or Roon output with phase invert disabled.

It seems to only do this when the waveform hits a positive 0dBfs. If it clips to negative 0dBfs it does not wraparound to positive 0dBfs.

The phase invert feature should not be altering the content like this, both because this sort of distortion/error should never happen anyway, but also because it shouldn’t be altering samples at all other than literally flipping them positive to negative and vice versa.

3 Likes

This doesn’t seem to have been fixed in the latest release.
Is this going to be addressed? :frowning:

Interesting. I suspect Roon doesn’t do any bit depth conversion and just changes the sign of integer samples. But since integer samples are asymmetrical, you need to special-case minimum values. For example, with 16 bits, max value is 32767 and min value is -32768. If you flip the former you correctly get -32767, but if you flip the latter it will remain -32768. You need to clamp -32768 to -32767 before flipping the sign, which will then become 32767. This clipping is tiny and should not be audible. Can you share the signal path to see if there’s any bit depth conversion?

Before this is fixed, you could workaround by turning on headroom management, so that no samples reach the limits.

Yeah that’d make sense as to why it’s happening (and only in one direction).

The signal path has no bit depth conversion, it’s bit-perfect other than the polarity inversion.

Applying headroom does work, but then

a) It’s going to be applying bit depth conversion and dithering which some people may wish to avoid. Perhaps if intending to use HQPlayer’s own dithering etc.

b) It’d be quite annoying to HAVE to apply DSP vol control to mitigate this issue when hopefully it should be relatively simple to fix

I agree, this needs to be fixed. Headroom management is just a workaround, hopefully temporary.

As a side note, it’s not necessary to dither when you quantize to 24 or 32 bits, since the quantization errors would be around -144dB and -196dB, respectively. Nobody can hear that, even if correlated with the signal. If Roon dithers for those depths, it just wastes resources.

Per my understanding, Roon licenses some/all of its DSP engine from a third party. SoX? If that is correct, this signed integer phase inversion bug may extend well beyond Roon – or it may be specific to an interaction between Roon code and third party code. Either way, that may be why a fix is not forthcoming quickly.

AJ

Hi @GoldenSound ,

Can you please upload the files here and let us know once uploaded? Thanks!

https://workdrive.zohoexternal.com/collection/nqcgjac23027d90a441bda2c314de49d7958a/external

I have uploaded the inverted + regular file via the link specified.
Let me know if any further info is needed

This topic was automatically closed 45 days after the last reply. New replies are no longer allowed.