I only told you to listen to people has different ideas instead of shooting down everyone who disagree with you. There's no insult here. If anyone, it's you or your confidence in your field of work.

Click to expand...

biggerhead said:

   
 
No you called him an ignorant idiot... then you deleted it and said you didn't.  That's not really a smooth marketing strategy.

Click to expand...

windowsx said:

   
I only told you to listen to people has different ideas instead of shooting down everyone who disagree with you. There's no insult here. If anyone, it's you or your confidence in your field of work.
 
You did manage enterprise server but not computer audio server. Don't mix the job please. They need completely different optimizations.
 
Regards,
Windows X

Click to expand...

windowsx said:

   
I only told you to listen to people has different ideas instead of shooting down everyone who disagree with you. There's no insult here. If anyone, it's you or your confidence in your field of work.
 
You did manage enterprise server but not computer audio server. Don't mix the job please. They need completely different optimizations.
 
I did my part to show significant improvement with correlation depth in pure software environment. This measurement data is used in gearslutz and a lot pro pros accept this kind of measurements. Since I can show significant improvement in pure digital domain, there's nothing more to prove within analog. I'm writing software to optimize Windows platform not the DAC itself.
 
Regards,
Windows X

Click to expand...

biggerhead said:

   
 
No you called him an ignorant idiot... then you deleted it and said you didn't.  That's not really a smooth marketing strategy.

Click to expand...

windowsx said:

   
I shortly changed it back few minutes later after realizing I went to far with my emotions. I'd have changed it back sooner if my battery didn't run out. His quoted text is from the updated data so I thought I made it in time.
 
Regards,
Windows X

Click to expand...

bfreedma said:

   
Windows process management is not specific to audio.  The general concepts remain consistent.
 
I'm not shooting down everyone who disagrees with me, I'm explaining how the technology being discussed actually works.  The problem is, you immediately latch on to any alternate explanation that you believe supports your position without knowing the accuracy of those statement.  And again, we are talking about very rare scenarios unlikely to happen on the vast majority of systems reproducing digital audio.  It certainly doesn't support your product claims of universal improvement driven by Fidelizer.
 
Good luck WindowsX - Until you produce some actual data supporting your claims, I'm out of this absurd discussion you're using to distract from your claims of universal improvement on all systems.

Click to expand...

bfreedma said:

   
 
 
 
 
Caught in another lie.  If you're being intellectually dishonest here, why would anyone believe your claims about Fidelizer?
 
Hopefully, everyone takes note of that.
 
Again, good luck and get back to us when you have actual validation.

Click to expand...

windowsx said:

   
Because your explanation don't reflect on how real thing works. For example, enterprise server requires low priority task to be more responsive with 100% system responsiveness but multimedia requires I/O operations which is registered as higher priority task to be responsive so it should be 10-20% system responsiveness. That alone affect audio performance and a most Fidelizer Pro users can perceive it from different Machine Configuration options.
 
My claims for product is improving audio performance. By increasing audio  thread priority, clock rate, and kernel timer resolution, it did increase correlation depth from 12x-13x to 13x-14x which is significant enough to show improvements. Do you understand the importannce of correlation depth and how it can measure quality of digital signal? There's a lot of better ways to make snake oil products instead of selling 2-digit software that barely have customers.
 
Regards,
Windows X

Click to expand...

bfreedma said:

   
Your knowledge of how Windows tuning is implemented is sadly lacking - you can't simply generalize it into the simple statement as you did.  It seems like you just make up the "rules" as you go to suit your purpose. The subjective feedback from your users doesn't in any way support your claims.
 
And despite your assertion, you insulted me then claimed you didn't.  Editing after the fact to deny it after being called out is intellectually dishonest.

Click to expand...

biggerhead said:

  What you do hope is that the audio itself is a very tiny load compared to everything else going on, and that your process scheduler is kind enough to give it the microsecond or so it needs before its buffer runs empty.  A bit of googling on windows scheduling reveals that windows workstations allow foreground processes to hold on to a CPU for 6 quanta, which seems to equate to somewhere in the ballpark of 90ms!  That's 90ms before anything else other than maybe an interrupt can do anything.  Multiple cores sounds good, but if one process on the same core as the audio does that, and you have a 50ms buffer, then it seems like a problem to me.

Click to expand...

joe bloggs said:

As I pointed out before, your problem with DiffMaker is in the very fact that your loopback process is not bit-perfect, not that your computer is introducing random errors into the result that can be mitigated with Fidelizer.

There are several possibilities for this happening, but the two main factors are:

1. The bits being played out are being mapped to a smaller range of bits on the recording side. This could be due to a desire to prevent clipping, or a simple programming error.
2. The bits are being dithered. This often happens due to assumptions about the nature of the recording made by the software that cannot be overriden.

As I point out, others have gotten a bit-perfect recording
https://www.gearslutz.com/board/so-much-gear-so-little-time/471239-getting-bit-perfect-recording.html

And now so have I.
https://www.dropbox.com/s/cxllwudpsqb64p2/input.wav?dl=0
https://www.dropbox.com/s/7lsijcomhzgaxnn/output.wav?dl=0

input.wav was played through foobar in WASAPI mode at 24-bit to a S/PDIF output on my computer and recorded at the corresponding S/PDIF input using VSTHost and the MRecorder VST plugin at 24-bits as output.wav
https://www.meldaproduction.com/plugins/product.php?id=MRecorder

You may check for yourself that input.wav and output.wav only differ in the amount of silence before and after the test signals.

Aligning the starts of the tracks and inverting one then adding to the other yields digital silence:


Cropping the silence before and after the tracks and running through DiffMaker yields -300dB correlation depth, which is the same result you get by feeding it the same file for reference and comparison:

https://www.dropbox.com/s/7c3noeub0vl8qji/input-crop.wav?dl=0
https://www.dropbox.com/s/1xbrjyb0nkcsd8z/output-crop.wav?dl=0

At no point was Fidelizer running on my computer, nor did I attempt to lessen the load on my computer in any way.

Moral of the story: if you aren't getting a bit-perfect recording, you fix it by fixing your recording chain.

Click to expand...

windowsx said:

Finally, someone really posts about DiffMaker in details. Let's see.....

1. The bits being played out are being mapped to a smaller range of bits on the recording side. This could be due to a desire to prevent clipping, or a simple programming error.
: Bits are played from foobar's bit-perfect playback (Kernel Streaming/WASAPI) to Audacity's WASAPI recording through virtual cable emulated sound card. There's no way it's not bit-perfect.

Click to expand...

2. The bits are being dithered. This often happens due to assumptions about the nature of the recording made by the software that cannot be overriden.
: I made sure the sample rate and bit-depth of sample file, foobar and Audacity has the same configuration without dithering/resample.

Click to expand...

Your MRecorder is interesting but it looks like extracting pure audio stream from DSP chain to external file. I haven't tried the actual software myself yet so correct me if I'm wrong. If you desire to do real bit-perfect recording, you need to do real recording from real mapped audio device. Hit the Record button in Audacity or something like that. Please confirm me if you use real record button in Audacity to record audio stream from virtual sound card to complete bit-perfect playback/recording route. Otherwise, it could be just extracting audio stream in DSP chain before actually play/record.

Regards,
Windows X

Click to expand...

joe bloggs said:

I tried using Audacity to record using WASAPI. Only loopback devices appear (no real recording devices). In all cases I get a drop in digital signal level on the order of 0.0xdB, as mentioned in the gearslutz thread and consistent with the point I make here.
The dithering could be occuring within VB-cable. I never managed to get Virtual Audio Cable to produce an unmodified stream from input to output without volume changes (which also implies dithering). Not that I care about bit-perfect at all in actual music listening.
As I said, I used actual S/PDIF output and input ports. Like this:

The VST plugin was running in VSTHost which was entirely separate from foobar playing the input file, and foobar was set to play to the digital output while VSTHost was tapping the digital input on the other end of the *real* digital cable (unlike your test which used VB-Audio software cable). I did have to hit record on MRecorder just like you would in Audacity.

Click to expand...

cjl said:

  If you have a buffer underrun like this, I'd expect a pop, click, or gap in playback though, not a subtle improvement in soundstage or dynamics or something.

Click to expand...