Hi All.
At the dawn of 'Arc Prediction', Peter wrote:
Notice that things could really improve for SQ again if I first drop the volume a bit and *then* apply QAP. I'm working in these areas anyway, so I could apply a checkbox for that, so you (we all) can test that.
Notice that I always use attenuated digital volume in the first place, and it is really done in a good/harmless way.
Whenever I use PeakExtend, I seem to lose low-level detail. The ambience of a venue gets lost. Instruments don't quite 'breathe' fully any more. (Of course, I'm taking into account the 3dB attenuation that PE imposes and readjusting the volume control!)
Peter, are you sure that the PE attenuation is done in a good/harmless way??? Could you just check the code when you have a minute please?
Mani.
While this is from well over a year ago, I am sure Mani (again) posted similar about the normal digital attuenation only a few months back. I can't find this post/topic though.
To above message as well as to that other post I responded that everything was checked and found to be OK. For the normal attenuation this still holds, but for the Peak Extension I sure found a problem ...
Low and behold -sit tight- we can be tricked so easily;
While it is a kind of explicit subject the past weeks, here too, something which is WRONG sounds RIGHT;
Engage Peak Extension and all is right, unengage it, and things are rather very wrong. This will have been in there since, well, I can't tell. It could even be right from the start of XXHighEnd, or the digital volume otherwise.
Normal measurement doesn't show a thing to be wrong, but the "special" measurement I use lately, does.
I can't see what is actually happening (I mean, I don't see the logic of what causes the wrongness), and all I can tell is that Peak Extension MUST be ON or otherwise there is a degree of distortion on the high transients.
The cause is about something I can't denote other than a compiler bug, and I don't even know how to solve it. Not in the way the Audio Engine has been setup (and change it throughout is not an option at this time).
The most stupid thing (thinking about the theoretical solution) is that this is about a nice division by 1 (or 1.0000000000000 if you want), and *that* division is working out like an I-don't-know-what. This, while any division by a fraction up till a certain amount of decimals (4 to be exact) makes it work as intended, but NOW the attenuation won't be lossless anymore. So see ? there's no good way out of this.
When Peak Extension is engaged, that fraction is nicely applied (in a fashion that all remains lossless), and the solution looks like applying that same fraction. Small problem : then we'd attenuate at all times (3dB), which is not exactly the intention. Besides, it would be the same as applying Peak Extension.
All 'n all the stupid thing / result of this all is, that at attenuating nothing, the sound will be the worse (meaning : not as good as keeping everything at -0dB).
Regarding the quote above, what will happen theoretically is that the sound is more sharpened. I can't tell how, because any normal sine doesn't show the anomaly up to the upper limit of the audible range. Short pulses do though, and that's why I refer to high transients that might be distorted (whatever it is is what we will be receiving from *that*).
To be honest, I know this for a few weeks by now, as I found something wrong with the NOS1-USB regarding SQ; the damn thing is so much like a razor, that it sounds like one when razor sound is put to it.
So keep Peack Extension On for as long as it takes until I solved it.... or use it as a tweak to most probably perceive a more fresh sound, which can up to more holographic (see quote from Mani's post) but it won't be for real. For the NOS1-USB (not the original NOS1 version I presume) P.E. definitely must be On for the time being) ...
For C++ interestees :
I use float arithmetic here, all driven by a float variable;
Initialize this varibale to 1 or 1.00 or 1.00001 or 1.00000000 and all is wrong; Initiliaze it to 1.1 up to 1.0001 or 2 and all is right. This variable is used in all the further code without further change.
If I ask for the value of the variable all looks right at any time. The result of the divisions where it's used must be wrong though, and they can not be checked (as this is audio data with fairly unknown base numbers, and for sure unknown result numbers of the via-via arithmetic used).
I'm stumped.
Peter
PS: Cudos to Mani who perceived this on whatever system and DAC he had at the time, while it took me until a few weeks back.
Keep in mind : lowering the normal volume doesn't solve this at all. It is pure the Peak Extension implied volume base.
