[jdpark]

I'm afraid I don't understand how this shows that Fidelizer Pro works to improve sound quality? I'm not a programmer or engineer, but I can understand basic principles if someone can explain this to me. 
 
Is this basically saying that bit perfect playing doesn't really exist on computers? Or is it saying that the test shows that a new test should be done using a DAC and some sort of analogue output? 
 
Perhaps a test should be done that records what a recording sounds like when computer A is being used at 80-90% CPU capacity to see if there is some kind of audible 'jitter' or whatever versus when no other non-sound related processes are being used, and then thirdly, when Fidelizer Pro is being used to see if there is a difference between the three. Obviously, I can tell you one thing without being a computer guy: when the fan starts it makes noise and vibrations, which I suppose could have a minute effect on the sound. If you can cut down on CPU usage to the point that the fan rarely if ever starts, then you already have done something. 
 
Lastly, I do understand the drop-out analogy, since I tend to type very fast and I've almost never had a computer that was able to keep up with me 100% of the time, ether when typing on the Internet or on Microsoft Word. If typing, which I consider (albeit without proof) less involving than playing, say a 24/192 WAV file, is so difficult for a computer to manage in real-time, then it is possible to speculate that yes, even fairly good computers may need a program that forces priority to audio. 
 
I don't see how that goes against computer science, if it confirms what I basically experience in day-to-day computer usage. 
 
So if basic intuition and practical experience tends to support the audio-prioritization/noise-reduction concept, why not just jump to blind listener A/B tests? 

 

[watchnerd]

 
 
So if basic intuition and practical experience tends to support the audio-prioritization/noise-reduction concept, why not just jump to blind listener A/B tests? 

 
You certainly can.  But if you want to self-administer it, you'll need to record two files.

 

[WindowsX]

Alright. I found the culprit now. It's gain feature that caused it. Strange. It's software and bit-perfect so there should be no volume difference. I tested two identical files with null result but not in these tests.
 
After removing gain feature and build difference track again, all files have 0dB on both channel now but Corr Depth was reduced but still at over 100dB level.
 
before-master

parameters: -1.596sec, 0.000dB (L),  0.000dB (R)..Corr Depth: 130.6 dB (L), 136.2 dB (R)

 
before_again-master

parameters: -1.32sec, 0.000dB (L),  0.000dB (R)..Corr Depth: 125.2 dB (L), 117.5 dB (R)

 
after-master

parameters: -1.852sec, 0.000dB (L),  0.000dB (R)..Corr Depth: 137.4 dB (L), 140.7 dB (R)

 
after-before

parameters: -255.9msec, 0.000dB (L),  0.000dB (R)..Corr Depth: 113.9 dB (L), 111.2 dB (R)

 
I also tested bit comparator in foobar2000 with a few combinations and got this result.
 

  Differences found in compared tracks.
Comparing:
"C:\AMD\master.wav"
"C:\AMD\new\before@master.wav"
Compared 3787896 samples.
Differences found: 6149255 values, starting at 0:00.000000, peak: 0.0011902 at 0:00.196259, 2ch
Differences found in compared tracks.
Comparing:
"C:\AMD\master.wav"
"C:\AMD\new\before_again@master.wav"
Compared 3787896 samples.
Differences found: 6148185 values, starting at 0:00.000000, peak: 0.0010986 at 0:00.103243, 2ch
Differences found in compared tracks.
Comparing:
"C:\AMD\master.wav"
"C:\AMD\new\after@master.wav"
Compared 3787896 samples.
Differences found: 6144636 values, starting at 0:00.000000, peak: 0.0010986 at 0:00.103243, 2ch
Differences found in compared tracks.
Comparing:
"C:\AMD\new\before@master.wav"
"C:\AMD\new\after@master.wav"
Compared 3787896 samples.
Differences found: 6545785 values, starting at 0:00.175011, peak: 0.0010681 at 0:00.391837, 2ch
Differences found in compared tracks.
Comparing:
"C:\AMD\new\before_again@master.wav"
"C:\AMD\new\after@master.wav"
Compared 3787896 samples.
Differences found: 6544543 values, starting at 0:00.175011, peak: 0.0009155 at 0:00.261633, 2ch
Differences found in compared tracks.
Comparing:
"C:\AMD\new\before@master.wav"
"C:\AMD\new\before_again@master.wav"
Compared 3787896 samples.
Differences found: 6546764 values, starting at 0:00.175011, peak: 0.0010986 at 0:00.391837, 2ch

 
From these data, I shall conclude that bit-perfect playback/recording can't transport bit-perfect audio stream in such manner even with pure software environment, let alone dealing with real hardware. The reassuring part is Fidelizer doesn't affect audio stream enough to change leveling in DiffMaker test but this test doesn't prove anything about Fidelizer yet.
 
I think it's much easier to run a test and decide if you want to keep using it or move on but I'll try to investigate more to find evidence in future if I have some spare time to do.
 
Regards,
Windows X

 

[watchnerd]

  Alright. I found the culprit now. It's gain feature that caused it. Strange. It's software and bit-perfect so there should be no volume difference. I tested two identical files with null result but not in these tests.
 
After removing gain feature and build difference track again, all files have 0dB on both channel now but Corr Depth was reduced but still at over 100dB level.
 
before-master
 
before_again-master
 
after-master
 
after-before
 
I also tested bit comparator in foobar2000 with a few combinations and got this result.
 
 
From these data, I shall conclude that bit-perfect playback/recording can't transport bit-perfect audio stream in such manner even with pure software environment, let alone dealing with real hardware. The reassuring part is Fidelizer doesn't affect audio stream enough to change leveling in DiffMaker test but this test doesn't prove anything about Fidelizer yet.
 
I think it's much easier to run a test and decide if you want to keep using it or move on but I'll try to investigate more to find evidence in future if I have some spare time to do.
 
Regards,
Windows X

 
Ummm...you have a correlation depth of ~113-137 dB.
 
How much correlation depth are you expecting to indicate perfection, or close to it?

 

[WindowsX]

   
Ummm...you have a correlation depth of ~113-137 dB.
 
How much correlation depth are you expecting to indicate perfection, or close to it?

 
Ideally, I expect 300.0 dB for no error in digital data playback/recording in software domain. But I expect time alignment to affect correlation depth so I'm investigating further to find bit-perfect threshold.
 
Regards,
Windows X

 

[WindowsX]

Alright. I tested master file with added silence and got this.
 
master_moved-master

parameters: -500msec, 0.000dB (L),  0.000dB (R)..Corr Depth: 150.9 dB (L), 146.2 dB (R)

 
So it's about 14x-15x range for original file with time alignment. If recording can get at least to 140 dB level, we can consider the case with possbility of null result. However, it runs at and 11x-13x dB for digital recording so we can't get null result here.
 
What do you guys think?
 
Regards,
Windows X

 

[milosingh]

I am not sure if you're serious.
 
Even if you're talking of 90 db, it is inaudible. The level you're talking about isn't even manageable using the analogue output of reference level dacs.
 
Unless you can show that there is something that can be heard around 40 to 70 db or so, or less than 50 db or so, it is of no use.

 

[watchnerd]

   
Ideally, I expect 300.0 dB for no error in digital data playback/recording in software domain. But I expect time alignment to affect correlation depth so I'm investigating further to find bit-perfect threshold.
 
Regards,
Windows X

 
Where did you get the 300 dB number?
 
There is no system that does that. That's below the noise floor of 24 bit files, that's below the noise floor of even 32 bit audio files.  That's getting into the realm of random cosmic background radiation effects.

 

[Windows X]

I am not sure if you're serious.

Even if you're talking of 90 db, it is inaudible. The level you're talking about isn't even manageable using the analogue output of reference level dacs.

Unless you can show that there is something that can be heard around 40 to 70 db or so, or less than 50 db or so, it is of no use.

To get audible different with bit-perfect digital recording is like you want to see some broken stuff. It's supposed to be the same with aligned master file not having 30dB depth reduced.

So bit perfect playback/recording doesn't do perfect job with pure software environment.

Regards,
Windows X

 

[WindowsX]

Where did you get the 300 dB number?

There is no system that does that. That's below the noise floor of 24 bit files, that's below the noise floor of even 32 bit audio files.  That's getting into the realm of random cosmic background radiation effects.

300dB is from measuring two identical files as I posted in previous page here.

http://www.head-fi.org/t/795259/fidelizer-pro-real-or-snake-oil/210#post_12345412

For aligned original with added silence is 14x-15x. I expect bit-perfect to do perfect job at 14x at least for pure software environment. Now we get 11x-13x which make bits imperfect.

Regards,
Windows X

 

[bfreedma]

To get audible different with bit-perfect digital recording is like you want to see some broken stuff. It's supposed to be the same with aligned master file not having 30dB depth reduced.

So bit perfect playback/recording doesn't do perfect job with pure software environment.

Regards,
Windows X

 
I don't think you understand the results and their meaning.  I'm also not sure how any of this relates to audible improvements made by Fidelizer.

 

[limpidglitch]

  Alright. I tested master file with added silence and got this.
 
master_moved-master
 
So it's about 14x-15x range for original file with time alignment. If recording can get at least to 140 dB level, we can consider the case with possbility of null result. However, it runs at and 11x-13x dB for digital recording so we can't get null result here.
 
What do you guys think?
 
Regards,
Windows X

 
I suspect all you're seeing here are the effects of the algorithms rounding errors.
DiffMaker transforms the signal so alignment can be done in the frequency domain. Doing that followed by the inverse operation is lossless only if you have infinite precision, which you obviously don't.
 
If I'm thinking correctly, this should give the null limit in 32bit float: 20*lg(2^25)≈150dB

 

[WindowsX]

I don't think you understand the results and their meaning.  I'm also not sure how any of this relates to audible improvements made by Fidelizer.

As I said before, this test doesn't reflect Fidelizer performance but we can see something about bit-perfect at works.

I suspect all you're seeing here are the effects of the algorithms rounding errors.

DiffMaker transforms the signal so alignment can be done in the frequency domain. Doing that followed by the inverse operation is lossless only if you have infinite precision, which you obviously don't.

If I'm thinking correctly, this should give the null limit in 32bit float: 20*lg(2^25)≈150dB

I expected as much. I saw 14x range for aligned same data threshold but 11x-13x for bit-perfect playback/recording. There's some reduction loss in pure software environment.

Regards,
Windows X

 

[KeithEmo]

I can't resist the urge to comment here... but more on the discussion than on the product itself...
 
NOTE: I have read the claims for this product (and I understand them very well). However, since my current system is relatively immune to the problems it purports to fix, and so I wouldn't expect to experience an improvement with it on my system, I haven't actually tried it. Therefore, my statements about the product relate TOTALLY to whether the claims made for it "technically make sense".
 
The claim, as I understand it, is that, by reducing extraneous processes running in Windows, Fidelizer will allow at least some computers to put out "cleaner data" - which will result in an audible improvement. From coming to understand how the product is claimed to work, and a lot of background knowledge about how Windows processes audio data, and how DACs work, I have reached the following conclusions:
 
1) The actual timing of the audio data delivered by Windows IS in fact affected by processor load; therefore, it makes sense that, on SOME computers, under SOME conditions, reducing the number of extra processes running probably will result in more consistent clocking of the data delivered by Windows to the DAC. Any user can do this manually, by uninstalling programs that aren't necessary, and by shutting off extraneous processes; and a program that does this effectively and conveniently could be useful.
 
2) USB DACs with asynchronous USB inputs are relatively immune to timing variations on the data coming from the computer, so I wouldn't expect much of an improvement for them (although not all are totally immune). USB DACs with non-asynch USB inputs, especially older ones, may in fact be sensitive to the timing of data coming from the computer, so they MIGHT benefit from it.
 
3) Toslink and Coax inputs are NOT inherently immune to timing errors and jitter on the data coming from the computer, and computers are notoriously bad in this regard, so this may in fact help users who have a DAC connected to their computer using a Coax or Toslink connection.
 
4) Many DACs use an ASRC to remove jitter from incoming data. Even though an ASRC is not actually 100% effective at removing jitter, they are usually quite effective, and so do succeed in removing a significant percentage of any jitter that might be present. Therefore, I would expect a DAC that has any such jitter-removal mechanism to get little to no benefit.
 
Therefore, my conclusion is that, while I wouldn't expect Fidelizer to make a significant difference on many systems (including my current one), I have to say that the claims it makes do in fact make sense. By reducing extraneous processes running in Windows, it MAY reduce the number and magnitude of timing errors and jitter on the data coming from Windows, which in fact MAY produce an audible improvement with SOME DACs.
 
Since a free trial is available, I see no reason for anyone who thinks it MIGHT produce an audible improvement in their system not to try it. However, since I would only expect it to produce an improvement with certain systems, and certain DACs, and under certain conditions, I would surely advise doing some sort of double blind testing, and doing so with an open mind and thoroughly neutral expectations. (However, to be clear, the basic theory of reducing timing errors and jitter in the digital audio signal delivered by a Windows computer to the audio playback device is in fact valid.)
 
 

 

[Don Hills]

Keith, that's a good summary.
 
X, thank you for your testing efforts. Your Diffmaker results are especially interesting, I think they shed light on how Diffmaker may work. They imply that it first compares the files bit-for-bit and, if they are identical, says so. If they are not identical, it then goes into alignment and nulling to quantify the differences. If you were using physical (but perfect) DAC and ADC chained, you would expect the output file to be different due to their clocks not being exactly aligned. Running the files through Diffmaker should result in a difference approximating to the calculated accuracy of the bit depth used, and your results appear to support that.
 
So as I see it:
- If input and output files are identical, Diffmaker says the difference is zero.
- If the files are identical except for misalignment (say, one file is missing one sample at the beginning), Diffmaker aligns them and reports a difference equal to the precision of its internal math.
- If the files are different due to, for example, clock skew (samples cannot be directly time aligned), they have to be SRCed to generate the "aligned" samples for difference measuring. Diffmaker reports a difference equal to the resolution of the file bit depth.
 
I don't think I quite have it right yet. I'll have to do some experimenting with Diffmaker myself.