MQN testing/experimentation thread

[jesuscheung]

to be honest. if not impossible, it is very difficult to measure using software method. just think about it- measurement will always interfere with the observation. in the other word, measurement will alter the audio output. assume error of audio output exists, i guess you can fake a audio driver, MQn will pipe/stream data into the fake 'audio driver', which has a database to record data at every nanosecond. from there and interpret the recorded results any way you like it... very difficult to code.

to measure true audio of MQn, think you need a hardware setup.

You are right JC - but there are better ways to go about this. Use a second computer to capture the output from the audio PC, running one player (or one version of MQn), then repeat using another version of MQn. Measure the differences between the two captures.

The trick is figuring out what to measure and how!

you cannot just send data from MQn straight from one computer to another computer. audio stream must go through WASAPI channel. it is part of the measurement. you need to code a fake 'audio driver' to recieve the data as though it is a real DAC. once the fake DAC receives the data, save it.

the thing is that, think about it, the more accurate you measure, the bigger the interfere of the original audio. the measurement software will be worse than a having firewall, which has the same function(intercept every network packet). in the other word, the measurement will compete for OS resources/CPU cycle/memory with MQn. you will end up measuring bad audio!

perhaps you need a 2 XEON cpu board.

[jrling]

Well if JC is right, then we need to find an interested party who, unlike me, is fortunate enough to own or have ready access to appropriate hardware to do the measurements. And the time and inclination too of course.

So far no volunteers have stepped forward.

[jesuscheung]

Well if JC is right, then we need to find an interested party who, unlike me, is fortunate enough to own or have ready access to appropriate hardware to do the measurements. And the time and inclination too of course.

So far no volunteers have stepped forward.

what does your hardware measurements say about 2.71 vs 2.71 v2 vs 2.71 raw? hehe

[LowOrbit]

to be honest. if not impossible, it is very difficult to measure using software method. just think about it- measurement will always interfere with the observation. in the other word, measurement will alter the audio output. assume error of audio output exists, i guess you can fake a audio driver, MQn will pipe/stream data into the fake 'audio driver', which has a database to record data at every nanosecond. from there and interpret the recorded results any way you like it... very difficult to code.

to measure true audio of MQn, think you need a hardware setup.

You are right JC - but there are better ways to go about this. Use a second computer to capture the output from the audio PC, running one player (or one version of MQn), then repeat using another version of MQn. Measure the differences between the two captures.

The trick is figuring out what to measure and how!

you cannot just send data from MQn straight from one computer to another computer. audio stream must go through WASAPI channel. it is part of the measurement. you need to code a fake 'audio driver' to recieve the data as though it is a real DAC. once the fake DAC receives the data, save it.

the thing is that, think about it, the more accurate you measure, the bigger the interfere of the original audio. the measurement software will be worse than a having firewall, which has the same function(intercept every network packet). in the other word, the measurement will compete for OS resources/CPU cycle/memory with MQn. you will end up measuring bad audio!

perhaps you need a 2 XEON cpu board.

Why?

Simply send the data out of the computer and feed it to a dac, capture the output of the dac. As long as you use the same signal chain for both files, you are good to go.

It's not a waveform until it goes through the dac.

If you want to examine the digital domain you need a whole host of software mods (and then, as you say, you are interfering in what you are trying to measure, screwing with your results) or some very fancy test equipment. Personally I am interested in what is different in the analogue signal that emerges from the dac from one player to another (same computer, same cables, same dac, only player is different).

[jrling]

Low Orbit - Good to hear some positive thinking

Do you have any software in mind that would be suitable to measure the analogue output from the DAC, or would it be hardware analysers?

Jonathan

[LowOrbit]

Low Orbit - Good to hear some positive thinking

Do you have any software in mind that would be suitable to measure the analogue output from the DAC, or would it be hardware analysers?

Jonathan

Ah - that's where it might get tricky! The simple approach - as per an earlier mail of mine - is simply record the output into a second computer and capture/analyse the audio. Reaper or any other DAW will capture at whatever your hardware interface (soundcard) is capable of. Then you need a methodology for analysis. Indications are that the differences are subtle. We'd expect that. So we need to think about how best to do the analysis. My own expectation is if we find a way of looking hard enough we'll find timing and maybe spectral differences at a low level, from files from one player versus another.

I think a good pro audio adc would be required - Presonus, Lynx, RME - that sort of jobbie, and a high sample rate.

If we still find no difference, we have to conclude we're all hearing things (as it were).

This doesn't tell us why MQn sounds different than Foobar (for instance) but it might point at where to look. And it will at least confirm that we aren't all suffering some form of expectation bias.

[jkeny]

The approach that I like the look of which I may have mentioned before has a particularly interesting approach to measuring timing without the need for very expensive hardware. A test is documetnted here - the IQTest http://www.audiomisc.co.uk/Linux/Sound3 ... hange.html and the test software & procedure linked from that article.

The approach is interesting & may be extrapolated to other area. It uses a stereo signal - one channel is a sine wave & the other is a cosine wave. Therefore each sample point between L & R channel has a known phase (timing) relationship which can easily be calculated to very low levels of timing i.e nanoseconds.

There are 2 programs that are provided - one to generate the stereo signal above & another one that analyses the output signal.

The procedure is to use a recorder to record the analogue output signal from a DAC through which you have played the generated stereo file using your software player. Then analyse the file with the analysis software which graphs the timing.

The software was originally written for Linux or RTOS & the source is linked to for recompiling on Windows (just needs a couple of changes to pathnames).

I have tried this test but it requires a better recorder than I have - I borrowed a Zoom recorder. It also probably needs 24/96 or 24/192 recording & a very linear & sensitive AD to ensure minimal effects on the results of the recording.

Anybody, who wants to follow this path - send me a PM & I can provide the recompiles files but you need to read up on & understand the test - I can't train you up on it

[LowOrbit]

John

Good find. It would have been useful it he'd managed to test more than one interface and/or dac,to see if you could isolate the problem to the computer or the interface or the combination of interface/dac.

I have a 24bit 96k soundcard (M-Audio 24/96) but it isn't really pro quality In particular I would not class its internal clock reference as clean enough for this task.

This approach does simplify the analysis as you are dealing with a simple, deterministic waveform. Probably better to get a convincing result than my proposed method above, though I still think that would give us an insight into what we think we are hearing.

If I foresee having the time, I'll drop you a mail, cadge a copy of that compile. I can only do it with confidence on Windows as my Linux skills are poor and I have yet to get any distro to play nicely with the Audiphile card.

Mark

[jkeny]

John

Good find. It would have been useful it he'd managed to test more than one interface and/or dac,to see if you could isolate the problem to the computer or the interface or the combination of interface/dac.

Ah, yes he has done it on another DAC - the Arcam rDac http://www.audiomisc.co.uk/Linux/Sound4/rdac.html

This one doesn't show the big difference that the first test does & gives you an idea of what differences there might be. How to analyse these graphs is another issue. But the first test was comparing the USB native input (adaptive) of the DAC Magic Vs using the DAC Magic with Halide Bridge USB-SPDIF converter (asynchronous). The big jump in timing at regular intervals in the graphs is better explained as the adaptive mode USB readjusting it's timing & not the conclusion that Jim LeSurf comes to i.e that it is the internal processing in the computer affecting the timing.

But showing repeatable differences in timing between different playback software or versions of MQN would be interesting. Analysis of the graphs would have to follow.

I have a 24bit 96k soundcard (M-Audio 24/96) but it isn't really pro quality In particular I would not class its internal clock reference as clean enough for this task.

This approach does simplify the analysis as you are dealing with a simple, deterministic waveform. Probably better to get a convincing result than my proposed method above, though I still think that would give us an insight into what we think we are hearing.

If I foresee having the time, I'll drop you a mail, cadge a copy of that compile. I can only do it with confidence on Windows as my Linux skills are poor and I have yet to get any distro to play nicely with the Audiphile card.

Mark

Sure, Mark, it would be good for some others to try this out - I don't have much time these days.
But, a word of warning, it needs a bit of dedication & work to get on top of this test & analyse the results. It's not as straightforward as I might have suggested above.

[jrling]

If we still find no difference, we have to conclude we're all hearing things (as it were).

This doesn't tell us why MQn sounds different than Foobar (for instance) but it might point at where to look. And it will at least confirm that we aren't all suffering some form of expectation bias.

We aren't!
I can tell you that I did a reverse placebo test twice with Gordon. He sent me 'the latest & greatest' version. He told me that it was a material improvement on the previous version. "Let me know if you agree."

So I was pre-conditioned to think it was going to be better. I immediately could tell the later version was 'flawed' and told him so. Soon came back the reply - "Oh yes I forgot to take out some code that shouldn't be there."

There are definitely real and material differences between most versions. Some large, some small, but they are there and repeatable.

We just need to find out why.

Jonathan

PS jkeny - if you use a recorder in the measurement process, surely that is introducing an unknown and potentially unreliable step in the measurement chain?