[Joe Bloggs]

So when I use VSTHost to record and process my microphone input in real time to improve my Skype call quality in real time, I'm not doing real time audio? I can probably get the latency down lower than any method you're using! Heck I play movies and games with sound processed by VSTHost too, do you think I can live without realtime audio in those circumstances?

That's totally different topic. There's nothing wrong in adding VST into audio chain for playback/recording. It'll change from just 'audio stream' to 'audio stream + dsp in vst host' before streaming. But recording audio from vst host software is different. Your method was synchronization within device. All you got was aligned data with the same clock synchronization within the same device. You might as well just copy/paste that file instead of doing playback/recording simulation.

There's no record of anyone successfully doing bit-perfect recording with -300dB across the device no matter how they configured it. You can try playing audio with foobar from machine A using audio interface with digital output and perform recording from machine B using audio interface with digital input. In this scenario, I'll allow you to use VST or whatever you want if you can make bit-perfect -300dB recording using different machines and host controllers.

Regards,
Keetakawee

No record? I wasn't aware that you represented the sum total of human knowledge.

Continuous misrepresentation of VSTHost aside, why don't you ask the pros how to do it?
https://www.gearslutz.com/board/so-much-gear-so-little-time/471239-getting-bit-perfect-recording.html

Plenty of people there who managed bit perfect recordings. No Fidelizers or VSTHosts were harmed or used during the process.

Not that using VSTHost jives AT ALL with your characterization of it.

All my VST plugin did was RECORD the audio coming out of the digital line input I'd connected to the digital line output. At NO POINT does it see anything remotely resembling the original audio file in origin. You can paint and misrepresent and FUD until you're blue in the face, but that's what it did.

It's blindingly obvious that you're only continuing with this farce only because to not do so would affect your Fidelizer sales.

 

[WindowsX]

No record? I wasn't aware that you represented the sum total of human knowledge.

Continuous misrepresentation of VSTHost aside, why don't you ask the pros how to do it?
https://www.gearslutz.com/board/so-much-gear-so-little-time/471239-getting-bit-perfect-recording.html

Plenty of people there who managed bit perfect recordings. No Fidelizers or VSTHosts were harmed or used during the process.

Not that using VSTHost jives AT ALL with your characterization of it.

All my VST plugin did was RECORD the audio coming out of the digital line input I'd connected to the digital line output. At NO POINT does it see anything remotely resembling the original audio file in origin. You can paint and misrepresent and FUD until you're blue in the face, but that's what it did.

It's blindingly obvious that you're only continuing with this farce only because to not do so would affect your Fidelizer sales.

 
b- Using ASIO driver and S/PDIF synchro: Success

2- Recording a professional S/PDIF (aka AES/EBU) PCM signal played from the Audiophile 192 itself

The S/PDIF output has the possibility to send AES/EBU data (switch on the driver side). I directly connected its S/PDIF output to its S/PDIF input, and played using foobar and ASIO playback driver. Unfortunately ASIO driver can't be used for both playback and recording, so I could not test ASIO recording with this configuration.

a- Using WDM driver and internal synchro: Success
 

1. No problem. Jitter can't happen as the same clock is used for both playback and recording. This test validates that the Audiophile 192's S/PDIF input accepts AES/EBU data correctly.

 
All success cases are done with synchronization. I already told you before it's not valid. I hope you know the reason why using clock synchronization is rejected om this case. Try to do bit-perfect recording across the device with two audio interfaces and see if you can still do it.
 
Regards,
Keetakawee

 

[Joe Bloggs]

Again, you talk as if using a hardware digital interconnect can ever be less valid than using VB-Audio cable only.

The only reason you appear to have a leg to stand on is because you screwed up the recording.

You speak as if clock synchronization cannot be used in normal playback.

You speak as if no synchronization is going on when you are just looping through a virtual audio cable all within the computer CPU and memory, unlike us who are routing physically out of the computer, to a separate audio output device, an audio capture device, and back into the computer. And again you have the guts to call our recording less authentic than yours?

 

[WindowsX]

Again, you talk as if using a hardware digital interconnect can ever be less valid than using VB-Audio cable only.

The only reason you appear to have a leg to stand on is because you screwed up the recording.

You speak as if clock synchronization cannot be used in normal playback.

You speak as if no synchronization is going on when you are just looping through a virtual audio cable all within the computer CPU and memory, unlike us who are routing physically out of the computer, to a separate audio output device, an audio capture device, and back into the computer. And again you have the guts to call our recording less authentic than yours?

 
If this is about getting bit-perfect recording topic, you're exactly right in every way you speak of. But this thread is about finding digital difference in bit-perfect playback. Recording with synced clock to spdif or internal sync with internal loop has no meaning here. Doing bit-perfect recording that way is possible but you can't actually record anything that way. If anything, you're throwing invalid test to wreck another test.
 
In virtual audio cable, there's different bit-perfect host devices in my methodology. Foobar for playback through WASAPI and Audacity for recording through WASAPI. Each has its own latency and stream and capture packets in fixed internal. Its implementation is close to real world situations. Valid methods should simulate the situation that reflects real world environment.
 
Regards,
Keetakawee

 

[Joe Bloggs]

In case you thought otherwise, my playback device was also outside of VSTHost (Audacity rather than foobar in my case).

What do you mean I can't record anything that way? *** I can plug a mic instead of the loopback digital into my audio interface and I could have recorded myself talking in real time!

And like I said my recording device (the VST plugin) is even further removed from the played back audio file than your so-called loopback recording.

Just, stop embarrassing yourself would you?

 

[Joe Bloggs]

In any case, I've found that my results with VSTHost can just as easily be duplicated with foobar2000 playing into Audacity through VB HiFi cable pretty much exactly as you're doing. The only caveats are that the input audio should not quite reach full digital level (because there's an infernal bit of coding in Windows that insists on mapping the full scale digital signal to 0.131dB less than full scale on the recording end) and Audacity's project settings should be set to produce 24bit tracks by default while dither should be turned off in the quality settings (a. because that's the maximum bit depth HiFi-cable actually records to, b. to avoid dithering causing spurious deviations from a nullable signal.

I can now simply manually align the imported and recorded tracks, invert one of the two, and "mix and render" gives me pure digital silence.

 

[WindowsX]

In any case, I've found that my results with VSTHost can just as easily be duplicated with foobar2000 playing into Audacity through VB HiFi cable pretty much exactly as you're doing. The only caveats are that the input audio should not quite reach full digital level (because there's an infernal bit of coding in Windows that insists on mapping the full scale digital signal to 0.131dB less than full scale on the recording end) and Audacity's project settings should be set to produce 24bit tracks by default while dither should be turned off in the quality settings (a. because that's the maximum bit depth HiFi-cable actually records to, b. to avoid dithering causing spurious deviations from a nullable signal.

I can now simply manually align the imported and recorded tracks, invert one of the two, and "mix and render" gives me pure digital silence.



Your turn, or should I say checkmate?

 
That's what I'm waiting for. That looks interesting. Did you trimmed down volume of input file or find tracks without maxed volume level? How about Diffmaker's test result with that approach? Is it still -300 dB? I'm going to try with capped volume level soon and check things out from my side too.
 
Regards,
Keetakawee

 

[Joe Bloggs]

Hello Keetakawee,

Am I allowed to trim the recorded and input wave files (i.e. the original music file, gained down by 6dB, which I played back for recording) to the same segment? When I do that, yes, the corr. depth is 300dB as expected.

 

[WindowsX]

Hello Keetakawee,

Am I allowed to trim the recorded and input wave files (i.e. the original music file, gained down by 6dB, which I played back for recording) to the same segment? When I do that, yes, the corr. depth is 300dB as expected.

 
I think only truncating silence should be allowed. You shouldn't manipulate actual data if you want to preserve the validity of results.
 
Regards,
Keetakawee

 

[Joe Bloggs]

If I trim about 50s of source audio for recording, and leave the silences before and after as-is in the recorded track, I get "only" about -283dB in DiffMaker. But I'd confirmed via manual alignment and nulling that one could simply align the tracks by whole samples and the nulling results would all be -Inifinity samples (i.e. digital zeroes). This would then seem to be more a flaw of DiffMaker than a flaw of the recording.

 

[WindowsX]

If I trim about 50s of source audio for recording, and leave the silences before and after as-is in the recorded track, I get "only" about -283dB in DiffMaker. But I'd confirmed via manual alignment and nulling that one could simply align the tracks by whole samples and the nulling results would all be -Inifinity samples (i.e. digital zeroes). This would then seem to be more a flaw of DiffMaker than a flaw of the recording.

 
That's interesting. Because adding only silence to master file never give me over -200dB, I wonder if it's something to do with using actual music file. Can you try this file?
 
http://www.lindberg.no/hires/test/2L-056_03_stereo_96kHz.flac
 
Regards,
Keetakawee

 

[Joe Bloggs]

Sorry, spent too much time banging my head against making bit perfect recordings today (and going to sleep now) and I think I'm going to spend more of tomorrow's free time enjoying music if possible. Am happy to help you with replicating my results if you run into any problems though. I must give you more credit than I thought you deserved for intellectual honesty, for being interested in replicating these results. Maybe one day you can make a patch for windows that would remove this digital levels mapping bug (the -0.1dB difference) from digital loopback recordings. That sounds like something you might be able to pull off and would be a truly ingenious piece of coding I can get behind

 

[WindowsX]

I hope they'll find solutions to do bit-perfect recording in Linux as good as yours or get audio fixed in next kernel update soon.

Regards,
Keetakawee