TL;DR request: Dear Kilohearts, please update all your plug-ins (including all 33 snapins) to operate at 64-Bit Floating Point internally and also send/receive their data at 64-Bit Floating Point so there would be no need for a 64-Bit to 32-Bit and 32-Bit to 64-Bit conversion either. So a Full End-to-End 64-Bit Floating Point signal path update please? So that there's no need for dither either.EDIT: I changed the title of this thread, because I now understand the bit-transparent issue was caused by rounding error between positive and negative values and not an inherent problem with Kilohearts plug-ins themselves, and therefore it would be unfair to Kilohearts (arguably the greatest audio developers) to leave such a title on.
So please keep that in mind when you read this thread. Thank you.
IKilohearts.
Kilohearts.
You can recreate my test here:
• Open a new project in REAPER.
• Go to Project Settings > Advanced and make sure that mixing bit depth is at 64-Bit Float.
• Go to Project Settings > Media and make sure everything there is also at 64-Bit FP.
• On the master bus insert Schwa's Bitter or REAPER's own Bit Meter plus REAPER's own Frequency Spectrum Analyzer Meter.
• Change the Frequency Spectrum Analyzer Meter's floor to -450dB.
• Load a test audio track (preferably sine sweep without added noise).
• Duplicate this track.
• Switch the polarity on the duplicated track.
• Press play and you should see that both tracks null perfectly (they are bit-perfect (identical)).
• Now insert Kilohearts' simplest plug-in called GAIN on the duplicated track and leave its gain at zero.
• Press play again, you'll see that the tracks won't perfectly null anymore. In fact, if you render the result and boost it by +150dB, you'll hear the (truncation noise?).
• Now let's add a second Kilohearts' Gain plug-in after the first one (both on the same track). Change the gain on the first one to exactly -3dB, and change the gain on the second one to exactly +3dB.
• Press play again, and this time, not only will you see the truncation noise, but you'll see the signal coming through as well (especially if it's a sine sweep). All you need to do to hear it as well, is to render the result and boost it by +129dB.
• Let's go even further and copy/paste the Gain plug-in *pair* a few hundred times. Remember, for each kHs Gain plug-in that is at -3dB, you MUST have a kHs Gain plug-in that is at +3dB. Here are my result:
• 4 kHs Gain plug-ins only null down to -124dB.
• 8 kHs Gain plug-ins only null down to -119dB.
• 16 kHs Gain plug-ins only null down to -113dB.
• 32 kHs Gain plug-ins only null down to -107dB.
• 64 kHs Gain plug-ins only null down to -101dB.
• 128 kHs Gain plug-ins only null down to -95.8dB.
• 256 kHs Gain plug-ins only null down to -89.8dB.
• 512 kHs Gain plug-ins only null down to -83.8dB.
• 1024 kHs Gain plug-ins only null down to -77.8dB.
• ...
A few notes:
• I understand some may say that these are not audible and therefore there's nothing to fix.
• It makes me wonder whether this is because Kilohearts' plug-ins aren't internally working at 64-Bit Floating Point precision that causes this?
• I did the same test with REAPER's own faders. Only when I set the gain at exactly 1-Bit increments, did the two track null perfectly. -/+ 6.02059991327dB to be precise.
• Airwindows BitShiftGain nulls perfectly (obviously).
• I tested this in other DAWs with the same result: Studio One, Ardour...
• My test signal peaks at 0dBFS.
So again, please update all your plug-ins (including all 33 snapins) to operate at 64-Bit Floating Point internally and also send/receive their data at 64-Bit Floating Point so there would be no need for a 64-Bit to 32-Bit and 32-Bit to 64-Bit conversion either. So an End-to-End 64-Bit Floating Point signal path update please?
Only one kHs Gain plug-in with gain at 0dB:
2 kHs Gain plug-ins on the same track, the first one at -3dB and the second one at +3dB:
8 kHs Gain plug-ins on the same track four of which are at -3dB, the other four at +3dB:
