Fidelizer Pro - Real or Snake Oil?
Status
Not open for further replies.
Jan 18, 2016 at 5:34 PM Thread Starter Post #1 of 683

watchnerd

Headphoneus Supremus
Joined
Jul 12, 2008
Posts
2,093
Likes
775
I don't use Windows for audio (or really at all these days), doing all my audio exclusively on Mac or Linux.
 
This Windows software seems to be making the rounds with a big debate about whether it's useful and has a real impact, or just inconsequential:
 
http://www.fidelizer-audio.com/
 
Jan 18, 2016 at 5:47 PM Post #2 of 683
  I don't use Windows for audio (or really at all these days), doing all my audio exclusively on Mac or Linux.
 
This Windows software seems to be making the rounds with a big debate about whether it's useful and has a real impact, or just inconsequential:
 
http://www.fidelizer-audio.com/

 
Does windows let you capture the PCM stream? If so it would seem trivial to capture the samples going to the DAC and compare them to the originals.
 
Jan 19, 2016 at 8:31 AM Post #4 of 683
Some opinions from the experts about archimago's test

http://www.audioasylum.com/cgi/vt.mpl?f=pcaudio&m=150062

Let us know if you have any question related to Fidelizer products.

Regards,
Windows X
 
Jan 19, 2016 at 9:26 AM Post #5 of 683
Archimago's home tests are the equivalent of home run ABX tests - not fit for purpose - not even hobbyist fun because of the pretense of it being an actual serious piece of scientific investigation
 
Jan 19, 2016 at 9:56 AM Post #6 of 683
  I don't use Windows for audio (or really at all these days), doing all my audio exclusively on Mac or Linux.
 
This Windows software seems to be making the rounds with a big debate about whether it's useful and has a real impact, or just inconsequential:
 
http://www.fidelizer-audio.com/

 
For it to actually have an impact, you would have to assume that a modern Windows PC can't successfully process audio while potentially executing other tasks in the background.  That hasn't been the case for many years.
 
I suppose you could simply manually turn off and/or change priority the Windows Services and Processes that Fidelizer does via a script, but the chance of any audible change/improvement is essentially zero unless your Windows system has existent significant performance issues unrelated specifically to audio.  Those who espouse the type of change Fidelizer makes to Windows will also frequently recommend running Windows Server OS instead of a desktop OS because in theory, you have more control over what processes and services the OS is running.  Again, we are so far past the threshold of potential CPU saturation on modern hardware that this is a solution in search of a problem.
 
If you really wanted to ensure audio playback wasn't compromised via contention with other processes, you could set the Process Priority of elements involved in playback to "Realtime" or "High" via task manager, but unless your system is already running at heavy CPU loading, it won't make any difference.
 
Jan 19, 2016 at 10:20 AM Post #7 of 683
Some opinions from the experts about archimago's test

http://www.audioasylum.com/cgi/vt.mpl?f=pcaudio&m=150062

Let us know if you have any question related to Fidelizer products.

Regards,
Windows X

 
I just see a lot of arguing on that thread.
 
Jan 19, 2016 at 10:22 AM Post #8 of 683
   
For it to actually have an impact, you would have to assume that a modern Windows PC can't successfully process audio while potentially executing other tasks in the background.  That hasn't been the case for many years.
 
I suppose you could simply manually turn off and/or change priority the Windows Services and Processes that Fidelizer does via a script, but the chance of any audible change/improvement is essentially zero unless your Windows system has existent significant performance issues unrelated specifically to audio.  Those who espouse the type of change Fidelizer makes to Windows will also frequently recommend running Windows Server OS instead of a desktop OS because in theory, you have more control over what processes and services the OS is running.  Again, we are so far past the threshold of potential CPU saturation on modern hardware that this is a solution in search of a problem.
 
If you really wanted to ensure audio playback wasn't compromised via contention with other processes, you could set the Process Priority of elements involved in playback to "Realtime" or "High" via task manager, but unless your system is already running at heavy CPU loading, it won't make any difference.

 
What's the alleged symptom?
 
Jan 19, 2016 at 10:29 AM Post #9 of 683
   
I just see a lot of arguing on that thread.

 
I'm just providing more source for you to read. There's also another link but it violates the rule to link to that website so please search for Fidelizer snake oil and you should find it.
 
As a maker, I don't intend to sell products that don't really work out. If you can't see anyone ever complaining about Fidelizer Pro, there should be some good reasons to support this cause. :)
 
Regards,
Windows X
 
Jan 19, 2016 at 10:30 AM Post #10 of 683
 
I don't use Windows for audio (or really at all these days), doing all my audio exclusively on Mac or Linux.

This Windows software seems to be making the rounds with a big debate about whether it's useful and has a real impact, or just inconsequential:

http://www.fidelizer-audio.com/


For it to actually have an impact, you would have to assume that a modern Windows PC can't successfully process audio while potentially executing other tasks in the background.  That hasn't been the case for many years.

I suppose you could simply manually turn off and/or change priority the Windows Services and Processes that Fidelizer does via a script, but the chance of any audible change/improvement is essentially zero unless your Windows system has existent significant performance issues unrelated specifically to audio.  Those who espouse the type of change Fidelizer makes to Windows will also frequently recommend running Windows Server OS instead of a desktop OS because in theory, you have more control over what processes and services the OS is running.  Again, we are so far past the threshold of potential CPU saturation on modern hardware that this is a solution in search of a problem.

If you really wanted to ensure audio playback wasn't compromised via contention with other processes, you could set the Process Priority of elements involved in playback to "Realtime" or "High" via task manager, but unless your system is already running at heavy CPU loading, it won't make any difference.

Or it could be a change in the spectrum of the noise transmitted on any cable connection to the computer including USB cable
 
Jan 19, 2016 at 11:14 AM Post #11 of 683
   
What's the alleged symptom?

 
Not really specified.  The web site talks a lot about "Sound Quality Improvement" but seems to carefully avoid any specific issues other than the need to prioritize Windows functions related to audio playback.  Notionally, the theory being espoused is that "other functions" being performed by a Windows PC may be compromising audio playback by over saturating a subsystem (CPU, Disk, Memory) but in reality, this is a non issue unless you're also using the system in question for high demand applications.  It's trivially easy to look at the utilization of a Windows system via the Resource Manager and to determine that none of the elements of audio playback are stressing a normally operating system (and see the overall workload).  And even then, we're ignoring the buffering that occurs which makes impacting audio playback even less likely to be an issue.
 
Or it could be a change in the spectrum of the noise transmitted on any cable connection to the computer including USB cable

 
How would stopping or optimizing Windows services and processes have that result?  If that's the claim, then the Fidelizer team needs to validate it via objective data.  Seems highly unlikely at best in the digital domain.  In many decades of working with Windows and multiple other OS's, I'm unfamiliar with any tuning that would result in a changed set of data.
 
Bottom line - this is a solution in search of a problem.
 
Jan 19, 2016 at 11:19 AM Post #12 of 683
Or it could be a change in the spectrum of the noise transmitted on any cable connection to the computer including USB cable


How would stopping or optimizing Windows services and processes have that result?  If that's the claim, then the Fidelizer team needs to validate it via objective data.  Seems highly unlikely at best in the digital domain.  In many decades of working with Windows and multiple other OS's, I'm unfamiliar with any tuning that would result in a changed set of data.

Bottom line - this is a solution in search of a problem.

Ah, yes, the old chestnut - if the bits haven't changed then the sound hasn't changed - I thought the enlightenment had reached these dusty hollows of head-fi, I was obviously wrong - please continue.
 
Jan 19, 2016 at 11:26 AM Post #13 of 683
Ah, yes, the old chestnut - if the bits haven't changed then the sound hasn't changed - I thought the enlightenment had reached these dusty hollows of head-fi, I was obviously wrong - please continue.

 
Your claim, your burden of proof.  What other data within the Windows PC processing cycle of music reproduction is there other than the bits?
 
What you're basically suggesting is that all digital data is unreliable. It's not a concern in any other realm of data processing, but somehow it is in processing audio data?  Is there something you suggest datacenters that process mission critical data should be doing to avoid catastrophe?  Sorry for the hyperbole, but your reply was insulting.
 
Jan 19, 2016 at 11:34 AM Post #14 of 683
Ah, yes, the old chestnut - if the bits haven't changed then the sound hasn't changed - I thought the enlightenment had reached these dusty hollows of head-fi, I was obviously wrong - please continue.


Your claim, your burden of proof.  What other data within the Windows PC processing cycle of music reproduction is there other than the bits?

What you're basically suggesting is that all digital data is unreliable. It's not a concern in any other realm of data processing, but somehow it is in processing audio data?  Is there something you suggest datacenters that process mission critical data should be doing to avoid catastrophe?  Sorry for the hyperbole, but your reply was insulting.

No, I'm not saying that the data is changed - that is just your blinkered view or your debating tactic, I don't know which because you are using such a hackneyed line of argument?

Anyway, the world of computer based audio has moved well beyond that luddite view of "bits are bits" & it's not a debate I'm interested in revisiting. Maybe you can use a galvanic isolator on your USB DAC connection to your computer & report ?

please continue
 
Jan 19, 2016 at 12:07 PM Post #15 of 683
No, I'm not saying that the data is changed - that is just your blinkered view or your debating tactic, I don't know which because you are using such a hackneyed line of argument?

Anyway, the world of computer based audio has moved well beyond that luddite view of "bits are bits" & it's not a debate I'm interested in revisiting. Maybe you can use a galvanic isolator on your USB DAC connection to your computer & report ?

please continue

 
 
Care to provide a concrete example of your claims - something that indicates Fidelizer has the capability of improving audio reproduction.  What, specifically, other than bits is involved in the Windows digital audio processing cycle.  We aren't discussing DACs, or the connection to the DAC, but simply taking the data from it's storage medium and processing it within the PC in preparation for output.  Moving the goalposts by introducing galvanic isolation has zero impact on the discussion of Fidelizer, what it does (or doesn't) do, and whether it addresses any real world problems.
 
It would also be appreciated if you could discuss this without the continued insults.  I see a lot of hand waving, but no substance.
 
Status
Not open for further replies.

Users who are viewing this thread

Back
Top