Re: MQN
Posted: Fri Oct 04, 2013 10:11 pm
Yeah thats it Nigel.
Now to look at flac and later hires
Fran
Now to look at flac and later hires
Fran
It's 2.59 is the latest - just in case anyone gets confused.Fran wrote:Yeah thats it Nigel.
Now to look at flac and later hires
Fran
fixed itjkeny wrote:It's 2.59 is the latest - just in case anyone gets confused.Fran wrote:Yeah thats it Nigel.
Now to look at flac and later hires
Fran
As Pearse has said, I'm not sure how much better hi-res can be compared to what's being pulled off the 16/44 files currently?
But then there have been a number of times along this path where I & others have said - "I don't know if the sound can get much better"
I'm sure Flac will be working soon if not already!
It is a valid point Gerry but it is all about the music. Installing this is not rocket science and it doesn't take more than 5 mins. Once you start playing music hours just slip by. It is just rendering any music thrown at to a very organic level.Gerry D wrote:The thing about MQN is ...
I have to say that I dig the whole computer audio is "better" thing.
Sounds better. Ya da ya da ya da.
But I have to point out that to me it seems to be all about the sound.
Is it contributing to the experience of enjoying the music?
Is Hi Fi about the sound of music or the sound of noise within the music?
Does the artist want you to hear the song or what the engineer did?
Just saying'
Happy Friday.
hifi's all engineering is it not?Gerry D wrote:The thing about MQN is ...
I have to say that I dig the whole computer audio is "better" thing.
Sounds better. Ya da ya da ya da.
But I have to point out that to me it seems to be all about the sound.
Is it contributing to the experience of enjoying the music?
Is Hi Fi about the sound of music or the sound of noise within the music?
Does the artist want you to hear the song or what the engineer did?
Just saying'
Happy Friday.
did my stupid testnige2000 wrote:fixed itjkeny wrote:It's 2.59 is the latest - just in case anyone gets confused.Fran wrote:Yeah thats it Nigel.
Now to look at flac and later hires
Fran
As Pearse has said, I'm not sure how much better hi-res can be compared to what's being pulled off the 16/44 files currently?
But then there have been a number of times along this path where I & others have said - "I don't know if the sound can get much better"
I'm sure Flac will be working soon if not already!
hi res is no better than 16 44 at the minute it might even be worse, think hi res needs work
ill convert a track or two to see what happens
The arrogance is palpable. He has no clue what MQN is about & judges the code based on what is dated & more concerned with how the code might read to other programmers. The only possible valid issue he raises is the Waitforobject statement & he states his reasons. I'm sure SGBK has an answer but it really is approaching it from exactly the wrong angle i.e how can reading the code determine how it will sound.I'm a programmer, and have written audio stuff for 20 years or so.
If that code is really in the player, it's not doing anything clever,and it's written in a completely duff style by someone who doesn't know what they are doing, it's as simple as that.
The 1024 and 4096 are hard coded, and these numbers are basically telling you a sample buffer size (1024 samples) and a hard coded assumption of the sample width (2 bytes) and channels (2).
goto statements? Those went out of fashion in 1975.
There is a mix of variable naming convention - sound_buffer is old C style, although is still trendy in modern boost circles. pData is hungarian notation, and that was popular with BCPL, and microsoft in the 1980s.
WaitForSingleObject basically is a thread locking operator, waiting on a condition to be met. This means it introduces a context switch and a non-deterministic delay before the code wakes up again.
So, assuming people are looking for a carefully crafted tight and efficient audio playback engine, you are looking in the wrong place. If you are wanting to find a bit of code that demonstrates that modern audio drivers, and OSes are so clever that they can produce good results in spite of the quality of the audio software passing them buffers to play, you are looking in the right place.
It's the old argument that effect is equivalent to size. "Is that all you've got" style of attempted put-downI 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?