MQN testing/experimentation thread

[jkeny]

sorry guys. i don't understand the point of measurement.... if a complete and sound measurement exists, then every DAC on earth would have been ranked mathematically.

the fun of hifi is listening. why reason it with measurements? coz our ears aren't reliable? if so, why bother with hifi...

sorry to spoil the fun. i guess there is a point. programming compiler have well-defined test cases. yet player compiled by newer compiler seems to produce better SQ. yet, compiler's test cases weren't goal for better SQ, but for better performance and stability.

also, when you start to measure 'cache misses', i feel that you are intercepting, hence damages SQ, hence the measurement is not the true MQn audio output. it is like a firewall intercepting every packet going in and out of your computer.

Yes, it's of real value to those who want to develop better sounding systems.
It's also of value to try & take the guess work out of developing better playback software.
As we have seen, not all new versions of MQN have sounded better than previous versions.
It would be much more efficient to progress if we could determine what measurable aspects of the processing correlate to what audible aspects of the sound. What determines the bass, treble, soundstage, etc.
It also might lead to new & interesting approaches to audio playback as well as being of inherent interest to some of us, anyway.

I agree that the ears are the determining factor but there still is some disagreement about what the best player is so it's not always clear cut.

I agree also that measuring cache misses will possibly interfere with the processor load & skew results. It's not so much that SQ will be affected as we can listen to SQ without the cache testing program being active.

[jrling]

Surely there is a reason - to inform the developer why changes he makes to the code do result in a different sound. That way he can develop with knowledge of where he is going? As it is, SBGK is by his own admission, develops by trial and error and does not really know why the code changes he makes affects the sound the way it does. Very inefficient.

We are just spoilt by the dedication, determination and talent of SBGK with his trial and error approach being successful some of the time.

It has to be said that you particularly do find issue with most versions that SBGK produces. That's not a criticism but it does illustrate how inefficient it is to develop 'in the dark' by trial & error.

Having said that, no one on this thread has yet come up with any proposal for how to measure the output. I fear that it is either too difficult or requires too sophisticated equipment for anyone to be able to do so.

I would love to be proved wrong.

[jesuscheung]

Surely there is a reason - to inform the developer why changes he makes to the code do result in a different sound. That way he can develop with knowledge of where he is going? As it is, SBGK is by his own admission, develops by trial and error and does not really know why the code changes he makes affects the sound the way it does. Very inefficient.

We are just spoilt by the dedication, determination and talent of SBGK with his trial and error approach being successful some of the time.

It has to be said that you particularly do find issue with most versions that SBGK produces. That's not a criticism but it does illustrate how inefficient it is to develop 'in the dark' by trial & error.

Having said that, no one on this thread has yet come up with any proposal for how to measure the output. I fear that it is either too difficult or requires too sophisticated equipment for anyone to be able to do so.

I would love to be proved wrong.

i guess you need to buy hifi based on charts and maths. joking.

quote
"develops by trial and error and does not really know why the code changes he makes affects the sound the way it does. Very inefficient."

totally disagree. MQn SQ improves faster than any other player on earth. HQplayer uses measurements to maintain SQ. i think its SQ is about the same as a year ago.

[jesuscheung]

Having said that, no one on this thread has yet come up with any proposal for how to measure the output. I fear that it is either too difficult or requires too sophisticated equipment for anyone to be able to do so.

I would love to be proved wrong.

according to Albert Einstein:

"It would be possible to describe everything scientifically, but it would make no
sense; it would be without meaning, as if you described a Beethoven symphony as
a variation of wave pressure."

yes. measurements should be possible. just don't exist yet. because where can you buy such a product?

[jkeny]

Yes, but it's not one Vs the other - measurements Vs listening - it's the two in conjunction aiding one another & speeding progress - that's the whole point of any possible measurements

[jrling]

Would this software measurement package be suitable for our purpose?

http://audio.rightmark.org/downloads/RM ... 0Guide.pdf

It does have the advantage of having a freely distributed version which has the majority of the facilities of the paid-for version.

[LowOrbit]

Would this software measurement package be suitable for our purpose?

http://audio.rightmark.org/downloads/RM ... 0Guide.pdf

It does have the advantage of having a freely distributed version which has the majority of the facilities of the paid-for version.

Read through the documentation - doesn't look like what we need. It feeds audio out from within itself, measures the difference returned from the output of the device under test (soundcard etc). And you can't change the default config without buying the Pro version.

[jrling]

Noted. Close but no cigar.

Any other suggestions that might work? The thread seems to have stalled.

[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.

[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!