Excepting an allowance for the effective exaggeration of differences in prose when reviewing something in order to illustrate any difference at all.Īssuming he's not fiddling with the bit level data (which I do not believe he would do), it's unlikely to be something either a) deterministic (any change is more likely down to chance than intent and b) the same between any two systems.Ĭlick to expand. In most cases the differences between major hardware components are rarely what would fit my expectations for a "substantial" difference. "Substantial" is a rather ambiguous term. Personally, I shall remain happy in either their being no discernible differences and/or that I just can't detect them in a the closest to a DBT I can muster, so I don't have to worry about such things and can spend more time simply enjoying music. After all, the point is, well for me at least, all about enjoying music - and anything that helps there (real, imagined or of a "mood changing" nature) works for me.
If you prefer one over the other sonically, there's no reason not to use it. just having a random effect) and even less likely that such effects would be consistent between any two computers that were not absolutely identical in spec/build (which effectively never happens).
#Audirvana plus 3 review code
99.999% of programmers are not even aware of these issues, let alone have to deal with the consequences of them.Īnd what this means is that while different code can result in different sound (through a very limited set of rather theoretical circumstances), it's almost impossible to code in a way that will deterministically improve things (vs. Between the CPU actually re-compiling/interpreting your instructions in it's own internal microcode (hint: X86 CPUs haven't actually executed X8 op-codes directly in at least 20 years) and things like OOE, the actual activity of your CPU is only marginally predictable. no OS running random code at random times), you can design for or achieve any specific or consistent effect on sound quality.Įven coding in assembly language, what instructions you provide and what the CPU actually executes are, except in very specific cases, not predictable. I am saying that you cannot write code in anything above assembly language, for modern CPU architectures, that has enough control over what actually executes when that, even on a dedicated machine (i.e.
#Audirvana plus 3 review software
Nor am I saying that software players cannot sound different. Now, I will not claim that my methodology is a pure and true DBT, but it's a lot closer than any sighted test is going to be.
And when I do that, in this case, Audirvana, Roon and various other players all show up as being indiscernibly different.
While I will, at some point, write up something on the high-degree of improbability that any code changes running on any reasonably modern general purpose computer (that's running more than one task/thread) can yield any specific or intended effect on sound quality within a bit-perfect digital system, in the interim I do my best when comparing things to eliminate as much potential for expectation bias as I can.
Click to expand.Assuming he's not fiddling with the bit level data (which I do not believe he would do), it's unlikely to be something either a) deterministic (any change is more likely down to chance than intent and b) the same between any two systems.
0 kommentar(er)
