[WindowsX]

   
Lots of hand waving and distraction for the fact that you still haven't come close to supporting your claim that Fidelizer makes an audible difference outside of the limited scenario where a CPU is oversubscribed, something that is unlikely to happen on a modern PC, particularly one dedicated to audio reproduction.
 
If you believe :"I used to give up at some points because they believe only in measurements of audible range and that's impossible task for Fidelizer.",  then we should just end the conversation because that is a completely inaccurate statement.  Measuring the audible impact of Fidelizer is not particularly difficult, and the measurements have been described in this thread several times.  Instead, you chose to pursue some odd form of "bit perfect" analysis, which is both irrelevant to the discussion and actually produced no results in the audible range.

 
I did say before and I was about to leave because you guys are asking the impossible and you said this.
 

Of course audible differences can be proven. Measurements and/or properly constructed ABX testing would constitute proof that your software is performing as claimed or if it is not.

 

Now show me an example of audible different you can measure from digital domain. I already got measurable data from pure software environment. Let's see if you can come up with something better.
 
Regards,
Windows X

 

[bfreedma]

  
Lots of hand waving and distraction for the fact that you still haven't come close to supporting your claim that Fidelizer makes an audible difference outside of the limited scenario where a CPU is oversubscribed, something that is unlikely to happen on a modern PC, particularly one dedicated to audio reproduction.
 
If you believe :"I used to give up at some points because they believe only in measurements of audible range and that's impossible task for Fidelizer.",  then we should just end the conversation because that is a completely inaccurate statement.  Measuring the audible impact of Fidelizer is not particularly difficult, and the measurements have been described in this thread several times.  Instead, you chose to pursue some odd form of "bit perfect" analysis, which is both irrelevant to the discussion and actually produced no results in the audible range.

 
I did say before and I was about to leave because you guys are asking the impossible and you said this.
 

Of course audible differences can be proven. Measurements and/or properly constructed ABX testing would constitute proof that your software is performing as claimed or if it is not.

 

Now show me an example of audible different you can measure from digital domain. I already got measurable data from pure software environment. Let's see if you can come up with something better.
 
Regards,
Windows X

That's exactly the issue. You're only looking at the digital domain. Why do you insist on avoiding analog measurements which would actually be of value if you want to support your position?

And again, your measurements in the digital domain fall far outside the realm of human audibility, so what value do they add to your claims around Fidelizer's performance?

My bottom line hasn't changed from the start of this thread. Unless your PC is oversubscribed in one of its subsystems, Fidelizer makes zero audible impact. And very, very few systems are oversubscribed. You've done nothing to change my opinion - if anything, your answers have made me more confident in it.

 

[milosingh]

Are the measurements currently predicated on the inability to get a truly bit-perfect loopback recording?

I don't pretend to fully understand the issue at the moment but it appears to be a complicated problem. There was however a particular audio interface mentioned in the thread that did produce a perfectly bit-perfect loopback recording.
https://www.gearslutz.com/board/so-much-gear-so-little-time/471239-getting-bit-perfect-recording.html

Both the output and input of the digital recording chain would be buffered. The inability to get a bit-perfect loopback would seem to be caused by a systematic software error rather than any jitter. After all, it's not like if a "1" on the sending end falls in the crack between two time slots on the receiving end it would be interpolated to two "0.5" samples--either the buffers eliminate the timing differences and produce the original stream, or you get a dropout.

In the limited testing I did I got the same slight volume decrease as Muriel Esteban got in 1a) of post 10 in the above thread. Amplifying to the same amplitude and then comparing the input and output, of course, didn't yield anywhere near a null signal. But the error is very systematic and not at all indicative of a random noise process.

Wouldn't it make more sense to directly compare jitter measurements of the S/PDIF output of a computer with and without Fidelizer?

 
Jitter hasn't been an issue in the last 25 or so years. It may have been audible in the 1970s, but as of late 1990s, that is no longer the case. It is so far off the audible threshold that you probably won't even be able to reproduce it on purpose unless you do something really wrong.

 

[limpidglitch]

To be honest, talking about audibilty and the limits of human perception here is rather pointless, the differences X measured, are just so very very tiny.
As bfreedma said, assuming they are real, the differences are on the scale of real-world resistor noise. In comparison, the Johnson noise produced by a 1kΩ resistor at room temperature will be at a level of -124.8 dBV.

This sets a hard physical limit to what differences are meaningful.

 

[WindowsX]

That's exactly the issue. You're only looking at the digital domain. Why do you insist on avoiding analog measurements which would actually be of value if you want to support your position?

And again, your measurements in the digital domain fall far outside the realm of human audibility, so what value do they add to your claims around Fidelizer's performance?

My bottom line hasn't changed from the start of this thread. Unless your PC is oversubscribed in one of its subsystems, Fidelizer makes zero audible impact. And very, very few systems are oversubscribed. You've done nothing to change my opinion - if anything, your answers have made me more confident in it.

 
I already told you before. It's impossible to measure for audible changes with digital audio transport. Even iPhone digital I/O can do as good as others. Here's RMAA result for pure software evaluation. (Do you understand what pure software means btw?)
 

 
I didn't insist. I already told you it's impossible and you don't believe me. So I tried to make possible ones to show you and you don't accept inaudible result.
 
Instead of avoiding the issue,  try to show definite proof of audible measurements from digital audio transport right here. I already showed my research about detecting the flaws in pure software environment. I tried to play along with you so it's time for you to put some effort now.
 
Regards,
Windows X

 

[nick_charles]

   
Jitter hasn't been an issue in the last 25 or so years. It may have been audible in the 1970s, but as of late 1990s, that is no longer the case. It is so far off the audible threshold that you probably won't even be able to reproduce it on purpose unless you do something really wrong.

 
Well, actually.....Bad Jitter can still be found if you look hard enough
 

and you must be prepared to pay for the privilege 
 
Whether even this is audible is another question of course

 

[milosingh]

   
Well, actually.....Bad Jitter can still be found if you look hard enough
 

and you must be prepared to pay for the privilege 
 
Whether even this is audible is another question of course

lol
 
So you purposely go and find the worst piece of gear ever made?

 

[watchnerd]

 
@watchnerd If I make comparision with audible changes, or even supply diff files that you can hear the result, will you accept that parameters or shoot it down as invalid samples with errors?
 
 

 
I don't understand what you mean.
 
If the diff file says the difference is in the range of -130 dB, and I can hear the difference, then something isn't right.

 

[KeithEmo]

You're ignoring the fact that lots of modern gear STILL makes serious compromises for various reasons....
 
There are still plenty of USB DACs out there that don't use an asynchronous connection - both very cheap ones and niche products that have some "design reason" (whether sensible or not) for avoiding it. In fact, there are still a few very expensive DACs out there that use outmoded PLLs (because their maker insists "they sound better"). And, beyond that, even many modern DACs are at least somewhat affected by extreme amounts of jitter. (Note that a Coax connection from a PC can have what, by modern standards, is an amazingly high amount of jitter - high into the PICOseconds.)
 
Therefore, while I would still agree that a DAC that is very sensitive to jitter is "flawed", plenty of modern ones have that flaw, and there are still plenty of older DACs that are in fact sensitive to jitter that are still in use as well.
 
You should also be aware that J-Test, which is commonly used to measure the response of DACs to jitter, is in fact a very limited test; it actually tests a device for "susceptibility to certain stimuli which tend to cause jitter", but doesn't technically test their response to jitter generated externally. (In other words, the fact that a given DAC scores well on J-Test does NOT rule out the possibility that feeding it from a source with lots of jitter may in fact cause problems for it - even audible ones. It suggests that the device probably isn't very sensitive to jitter, but that conclusion isn't justified as being absolute.)
 
 
Quote:

  lol
 
So you purposely go and find the worst piece of gear ever made?

 

[milosingh]

Please tell me which of the following DACs have audible jitter?

ODAC
Modi
Modi 2
Modi 2 Uber
Any Asus product, specially Asus STX
Schiit Fulla
Any audioengine product
Any apple product

These cover a wide market share. Are cheap and easily available. I don't think any of the above has audible jitter.

 

[KeithEmo]

First of all, in the context of this discussion, you aren't even asking the right question.
 
While it's true that a DAC itself could have or generate jitter internally, and that jitter could then have an audible effect, that is NOT the question here.
We KNOW that a PC will generate significant jitter on its Coax and Toslink outputs (it's been measured); and the same is true for USB - if it's NOT asynchronous.
It is this jitter, generated by the computer, that Fidelizer claims to reduce.
Since Fidelizer alters the computer's configuration in several ways that are widely accepted to minimize jitter, we can assume that it at least might actually do so.
 
Offhand, I have no idea which of those DACs would or wouldn't be most likely to be affected.
If I knew the specific architecture used by any one of them in detail, I could make an educated guess which ones would be sensitive to jitter - but that's all it would be.
(For example, if you're using the USB input, and that USB input is asynchronous - and well designed, then the DAC should be largely insensitive to jitter from the source.)
(Likewise, regardless of the type of input, if it uses a mechanism like an ASRC to filter out jitter - and that was implemented correctly - then it should also be largely immune to jitter.)
 
I BELIEVE that the 0DAC, and the Schiit DACs, all use asynchronous USB as their input - and so should be MOSTLY immune to jitter.
I have no idea about the Apple and AudioEngine products; but you can quite probably find out from the specs.
(Most DACs with Coax or Toslink inputs mention it prominently in their specs if they have any sort of jitter reduction;
if not, then I might suspect that they WOULD be at least somewhat sensitive to jitter.
Most DACs that use the better asynchronous type of USB input also mention it in the specs.)
 
I'm curious, however, as to why "you don't think any of them has audible jitter".....
Have you tested them, or are you simply guessing?
And, if the latter, than on what do you BASE your guesses?
 
Quote:

Please tell me which of the following DACs have audible jitter?

ODAC
Modi
Modi 2
Modi 2 Uber
Any Asus product, specially Asus STX
Schiit Fulla
Any audioengine product
Any apple product

These cover a wide market share. Are cheap and easily available. I don't think any of the above has audible jitter.

 

[milosingh]

All of these except the Schiits have been measured by engineers on the Internet. All of them are known to have inaudible jitter. Nobody has measured the Schiits but I'm sure the can't be terrible either as far as just the basic stuff is concerned.

 

[KeithEmo]

Oh, well, if they said it on the Internet, then it must be true

(sorry, I just couldn't resist).
 
However, it would be interesting to know what tests were used... and the exact test conditions... and the actual results.
 
For example, the very popular AP J-Test, used by most magazines, does NOT in fact measure the sensitivity of a DAC to jitter coming from the source.
(What it actually does is use a "stress test signal" to provoke the DAC to produce jitter internally - then measure the results.)
But the current AP testers, with the appropriate options installed, are actually capable of measuring the response of the DAC to externally generated jitter.
 
However, I would consider even informal tests, showing that a given DAC exhibited no obvious jitter-related flaws with relatively
poor quality source to be at least somewhat indicative that it wasn't especially sensitive to jitter.
 
Quote:

All of these except the Schiits have been measured by engineers on the Internet. All of them are known to have inaudible jitter. Nobody has measured the Schiits but I'm sure the can't be terrible either as far as just the basic stuff is concerned.

 

[Joe Bloggs]

So here's your cue WindowsX--KeithEmo has pointed out that a PC will generate significant amounts of jitter on its S/PDIF coax or optical outputs, and these can be read directly (as opposed to USB audio)--why not directly measure jitter on these with Fidelizer on and off instead?

 

[cjl]

If you can measure something audible on bit-perfect, something must be broken.

But you didn't measure anything audible, and besides which, as soon as it has to be time-aligned, it's no longer completely bit perfect.