It's called experimental results - It's the first stage in most investigations.
Have you listened to MQN or do you need to know the theory of operation before you would deem it worth listening to?
Another playback software to argue over
- Thread starter jkeny
- Start date
Have you listened to MQN or do you need to know the theory of operation before you would deem it worth listening to?
No, it's called "observations". "experimental results" require controlled experiments.
I have tried to discuss the theory of operation, and I "know" it to the extent that the author has explained it.
I would have listened to it if I had a suitable environment fullfilling all the particular requirements of that software.
In my personal opinion, putting a lot of effort in one small piece of the computing environment while ignoring the rest of it is not the best approach.
Do you hear differences in the sound quality of different player (not DAC) software depending on what compiler and what compiler options you use? What programming language sounds best to you?
Insofar as the author has a generally defined approach to his experiments, I conclude that they are more than you are trying to make out by your usual attempts at disparaging what you don't understand.
By your posts here you have no interest in knowing so I take your claim of "trying" as a pure sham. Yes you have an opinion & you are not bothered nor have the interest to try the software. So what? I'll grant you that you may represent a majority.
Using the same equipment, I hear a substantial difference between this player, MQN & Jplay & Foobar - in descending order of SQ. What is behind these differences - that's the big question & MQN brings a lot of data to this question by putting on the table the software changes & resultant SQ change for all to hear (for those that are interested, that is). I consider this an important venture as it is no longer an arguable point of contention - we now know how the particular version of the player is built & can judge it's SQ. The next step is obviously to try & make sense of these data points.
If you're not interested then why post? Why not do what Phelonious has done?
It's best to withhold making assumptions until you have amassed enough data, don't you think?
Do we see a familiar pattern here. How about addressing factual concerns instead of attacking people by making childish insinuations about their motivations and interests?
I assume you have verified the code to see that the various, different-sounding versions are actually bit perfect?
Ah, so you agree in the principle but don't apply it (except where you think it suits?)
In this case I have amassed enough data points in our engagements.
In that case, let me spell them out. The main one is about the focus on a small, trivial part of the code (basically writing the bytes that constitute the audio data into a memory buffer that then gets handed to the Windows WASAPI layers), while ignoring all the other code and processing in the audio data path of the OS. Another concern is the development metodology - software development by trial and error usually only works for trivial pieces of code implementing well-understood and easily verifiable tasks, and usually require very solid regression test methods. In this case, the only verification mechanism seems to be subjective listening that doesn't really allow for quantifying the correlation between changes in code and actual changes in sound quality.
By the way, does MQN take over the whole computer/OS, or are there other processes running at the same time as MQN (leading to unpredictable performance)?
Nothing factual here - just your opinion about what you consider is important in computer audio processing. Your claims about the importance of the various processes involved in computer audio processing is simplistic & not based on any empirical evidence that I know of. If you have any such evidence please present it to change this from just your opinion into something more factually based
I see nothing wrong with his guided methodology with some trial & error when the end product of the software is the sound. It can be immediately validated (let's not get into blind tests, please). The correlation between code changes & sound is the area under investigation. As I said already both assumptions & correlations require the accumulation of many examples before beginning to address this. The desire to rush into assumption/theory/correlation is a commonly repeated mistake & something you seem to want to repeat.
No, it doesn't take over the whole CPU or OS - it is solely resident on a single core of dual or quad core CPU.
All your theories & premises are muted by listening to MQN, if you bothered to do so. Then you would have a more balanced view of what actually works & what are incorrect premises. Until you do this you are just repeating the usual pseudo-technical guesses/premises about what is important in the SQ of computer audio processing
They are factual questions, in the sense that they could be answered with simple, factual answers.
I guess you didn't understand the facts in my question. I suggest you take a look at the documentation for the Windows audio system and the WASAPI interface, as well as any basic textbook on operating systems. How much more evidence do you need that there are a lot of steps in the path of the audio data through the somputer and the OS, and that MQN only focuses on a minuscule part of that?
Just because you believe in the absolute perfection of the human psycho-acoustic system doesn't mean it necessarily is. But yes, that is another discussion.
So it has exclusive access to a CPU core, but not to memory or I/O. Wouldn't memory and I/O contention affect sound quality more than the optimization of a copy loop?
They are based on false premises which then can't be redressed by actual facts - go figure!
You have no notion or evidence for what are the important elements that determine SQ in this pathway!! I had hoped you might realise this.
Says who? I really don't think you understand what empirical testing is all about.
You could always try...
I had hoped you might realize, from what I explained, that the optimized loop in MQN is about 1/1000th of the lines of code involved in processing the audio data. What makes you think that 0.1% is the one that makes a difference?
Empirical testing is an essential element of the scientific method, as in "to be termed scientific, a method of inquiry must be based on empirical and measurable evidence subject to specific principles of reasoning".
Yes, I was just going to say; who here from this entire audio forum has listened to MQN? ...Any other member yet?
* Clive did not report much (post #19 and #24). ...Not much at all.
* Clive did not report much (post #19 and #24). ...Not much at all.
 | Steve Williams Site Founder | Site Owner | Administrator |  | Ron Resnick Site Co-Owner | Administrator |  | Julian (The Fixer) Website Build | Marketing Managersing |