A Morning With Graham
Posted by: Mr Underhill on 17 April 2010
Thank you to Graham Russell who kindly hosted me this morning ...which was an interesting three hours for me!
Graham has a top line Naim system, and one that sounds excellent; topped with a dual PSU CD555. I won't mention all the supports and cabling Graham uses, suffice it to say that his HiLines are far from the most expensive interconnects he uses!
Working in the IT industry with a background in programming and hardware configuration Graham's home network is well thought through and gives him the functionality to stream both Audio and DVDs.
Graham has built the full CMP2 front end, including Julia soundcard, this streams WAV files from his remote NAS, via MPD.
To add to this hardware behemoth I added ......a DELL laptop, HiFace and a stereovox digital cable!
Rather than run through each front end I'll start by stating that within Graham's system the order of playback quality was, IMO:
CD555 (2psu) > CD555 (1psu) > Graham's CMP2 front end (WAV) > [Grahams CMP2 (flac) = My Laptop (flac)]
None of these front ends disgraced themselves, and I could happily live with any of them; but back to back this order was clear to my ears.
What really surprised me was the difference between flac files and WAV files within Graham's system.
Flac files sounded less dynamic, the bass was softer and the top end was not as extended. This was the difference I noted between listening to my laptop and the CMP2. So I decided to play a few of my HiRes files!
HiRes Stumbles!
We picked an album that Graham has ripped from CD, and compared that with HiRes on my laptop. The CD rip won.
We therefore moved the HiRes rip onto the CMP2. The CD rip won.
The HiRes rip was expanded to WAV. The HiRes and CD rips were of equal quality!!
Now the HiRes rip was taken from my DVDA using DVD-A Explorer, and it may be that that in some way compromised the sound quality. At least it confirms I am not bonkers when I have posted my reservations about just pronouncing HiRes better than CD as a default win.
Flac -vs- WAV
There is NO doubt that within Graham's system WAV was clearly better. Returning home I uncompressed some files and did the same comparison within my system. Now I KNOW I had done this and heard no difference, but I just had to redo this ....and? No difference. I even got my younger daughter down and subjected her to Annie Lenox, and askd her which she preffered ...' they're the same.'
All I can say is that if you are running Naim amplification I would strongly recommend doing the test.
Music
Graham has a wide ranging taste and played me a number of female vocalists whose CDs will be bought for my collection.
Final Thoughts
Do I think I could walk into a room and pick that I was listening to the 555 rather than my Laptop or the CMP2? I'm not sure. Back to back I could pick them. If I new the music well I think I might be able to. For me that makes the computer front ends BRILLIANT value for money. Graham has the priviledge of choosing whether he wants the best of quality, or to be able to sit back and browse his music collection.
The CMP2 turns in a fine performance, and with more services running than my laptop - including networking; good news as I will now experiment with opening up the networking on the laptop to stream Spotify through the HiFace into the nDAC.
I'm redecorating the back room of my house for my summer hols, and I will be redoing my structural wiring (Cat5 > Cat6). Graham has given me some good ideas about also ripping my DVD collection and streaming that in addition to my audio; and I will definitely setting up MPD once HiFace make the Linux driver available; I dropped them an email last week - not even a tentative delivery date I'm afraid.
A very profitable and enjoyable morning for me,
Thank you Graham.
M.
Posted on: 20 April 2010 by Aleg
quote:
Originally posted by pcstockton:
Excuse my ignorance but what is "MPD"?
...
Thanks,
Patrick
Patrick
MPD is a "Music Player Daemon" a music player that runs on a Linux machine as a daemon, so without a user interface, a kind of background process.
It is controled by an mpd-client (many are available) run from a network attached computer (can by PC, Linux, Mac, iPod, iPhone, etc...). The client gives the control commands over the network to the daemon which then plays, stops, pauses, skips music. All kinds of audio codecs can be played and the output is send to attached audio card.
It is quite good sonically and has the advantage you can run it on a headless machine and control it over iPod, it has
gapless playback (yes this one has because it is
not UpNP), it is very stable and is free, being maintained as OpenSource.
Architecture:
Regards
-
aleg
Posted on: 20 April 2010 by Graham Russell
Spot on Aleg
I use GMPC to control it from Windows machines.
It took a bit of fiddling in the MPD config file to get music out the digital out port of the Juli@ card. Now sorted it sounds much better than any of the Windows players I have tried, including CMP/cPLAY.
Graham
Posted on: 21 April 2010 by pcstockton
Whoa. This all goes WAY over my head. Thanks for the explanation though.
I saw that diagram when looking for information. Unfortunately I cannot understand it.
But it may be a moot point, as I dont run Linux.
Its crazy that an OS could affect the audio in such an extreme fashion. I would have only expected very subtle differences.
Cheers.
I will try to find a Linux buddy and give it a shot.
-patrick
Posted on: 21 April 2010 by likesmusic
How can it be any good if it makes WAV sound differnt to FLAC even through a Naim DAC which buffers and re-clocks the data?
Posted on: 21 April 2010 by Aleg
quote:
Originally posted by Graham Russell:
Spot on Aleg
I use GMPC to control it from Windows machines.
It took a bit of fiddling in the MPD config file to get music out the digital out port of the Juli@ card. Now sorted it sounds much better than any of the Windows players I have tried, including CMP/cPLAY.
Graham
Graham
I run it on a Popcorn mediaplayer at the moment and control it with mPod on my iPod Touch from my lazy chair or from Minion plugin for Firefox when at work.
I think it is a great setup and I love the mPod as a controler.
Waiting for something like this from Naim, something like a very lean and slimmed down HDX (wink wink,nudge nudge).
-
aleg
Posted on: 21 April 2010 by Mr Underhill
quote:
Originally posted by pcstockton:
Funny.....
What do I think is going on? I would guess it is a combination of placebo along with a dose of self-fulfilling prophecy.
-patrick
No Patrick,
What I heard on Graham's system was obvious & repeatable; And I would guarantee I could pick it blind.
If it was p[placebo I should have heard it on my system ...I didn't.
M
Posted on: 21 April 2010 by Mr Underhill
quote:
Originally posted by pcstockton:
quote:
To add to this hardware behemoth I added ......a DELL laptop, HiFace and a stereovox digital cable!
You added a dell laptop to his existing CMP2/MDP Linux computer?
What does this mean?
thx,
patrick
I took my DELL Laptop + HiFace with me, and we compared it to Graham's front end, within the context of his system.
M
Posted on: 21 April 2010 by pcstockton
quote:
Originally posted by Mr Underhill:
No Patrick,
What I heard on Graham's system was obvious & repeatable; And I would guarantee I could pick it blind.
If it was p[placebo I should have heard it on my system ...I didn't.
M
Oh I have no doubt you heard it.
I was trying to come up with an empirical hypothesis as to why. I of course am probably wrong, but just trying to answer Joe's question directed to me. It is my best guess educated guess as to why there is a difference.
Placebo effect is not ruled out by virtue of two independent experiences that say there is a difference. Often sugar pills are only surpassed by the actual drug by as little as 8%. In those cases there were hundreds of people experiencing the same effect.
-patrick
Posted on: 21 April 2010 by sq225917
If you heard any difference between wav and flac then it is an artefact from the hardware and software used in your set-up. Perhaps there's a mismanagement of resources in the Linux subsystem that means it can't properly allocate resource and ends up affecting the output.
It would be good to view the spdif on an osciloscope to see exactly what the effect is.
But there is no difference in the presented bits between wav and flac, so it has to be down to hardware/software you use.
I've heard many comparisons or WAV, FLAC and other lossless codecs and never has there been any detectable difference in the set-ups used.
I'm sure you do hear what you think you hear so it must be down to the equipment.
Should have bought a MAC! ;-)
Posted on: 21 April 2010 by Mr Underhill
Patrick,
I agree that the placebo effect can be very strong, I was saying that having heard a big difference in Graham's system I heard NON in mine. If I was convincing myself that it makes a difference why am I not being consistent with myself? I also have run the test on the flac - vs - wav, using both my daughters separately as referees, on my system and non of us heard any differnces - of course it could be that Graham is influencing me, BUT the effect was obvious: clearer / cleaner / more extended top end and greater dynamics - not subtle.
Further, both Graham's and my front ends sounded the same with flac files, but we heard the performance lift with WAV via Grahams CMP specified hardware using MPD; unfortunately I had to leave before testing WAV files through the laptop/HiFace into Graham's setup. This is something that I am now regretting as I have just tested playing files from USB into the nDAC - and it sounds better than the Laptop/nDAC, and is of course WAV files.
I did do a comparison of CMP2 software vs foobar using flac files, and again heard no difference on my hardware - that is no difference between foobar - which I believe is decompressing on the fly(?) and the cPlay in memory player.
Lots of empirical observations.
M
Posted on: 21 April 2010 by Graham Russell
quote:
Originally posted by sq225917:
If you heard any difference between wav and flac then it is an artefact from the hardware and software used in your set-up. Perhaps there's a mismanagement of resources in the Linux subsystem that means it can't properly allocate resource and ends up affecting the output.
It would be good to view the spdif on an osciloscope to see exactly what the effect is.
But there is no difference in the presented bits between wav and flac, so it has to be down to hardware/software you use.
I've heard many comparisons or WAV, FLAC and other lossless codecs and never has there been any detectable difference in the set-ups used.
I'm sure you do hear what you think you hear so it must be down to the equipment.
Should have bought a MAC! ;-)
I can demonstrate this on Windows, Linux and Sonos so it's pretty platform independant.
Posted on: 21 April 2010 by pcstockton
Graham, and Mr Underhill,
I would like to hear your take on why there is a SQ difference assuming that after the media player that processes the data everything is identical (bit perfect).
I am being absolutely serious. There is no wrong answer.
What do you think is going on?
Apparently the SQ delta exists, but is only perceivable with Graham's exact kit.
So two questions, if you dont mind.
1) What is your best guess about why and how there is a difference?
2) Why is it only perceivable on Grahams kit, and not Mr. Underhill's nor mine?
Is it possible that Graham would hear it on any kit (his threshold allows a smaller window of perceivable difference). Is it maybe possible that Mr. Underhill only heard it on Graham's kit because he "knew" he would?
I am not trying to undermine anyone's experience. I am simply trying to wrap my mind around this.
If there is something beyond bit perfection that is negatively affecting SQ with the FLACs, there must be someway to "see" it no? What could it be? Jitter? Electromagnetism? RF? etc....
I know bit perfection is not the be all end all, but once the file is decoded (and if proven to be bit perfect) how do the signals differ and how does that affect SQ?
All very serious questions.
-Thanks
patrick
Posted on: 21 April 2010 by Graham Russell
I really don't have super human hearing.
As I've said before I think it's down to the real-time decompression that is required to stream Flac. This must put additional overhead on the replay pipeline.
Mathematically Flac can always be converted to Wav with no losses. Absolutely no dispute about this. But doing it in real-time while trying to play the file does affect the sound.
Why my system? Perhaps it's a combination of the particular Naim boxes and the Audiovector speakers. It is very revealing. Dunno, just a guess.
Posted on: 22 April 2010 by David Dever
Might be worth indicating the compression level used with the FLAC files under test, as this will most certainly affect the decoding of the files as they are spooled out into memory.
What I find interesting is that this same effect seems to be corroborated by a variety of people's experiences with Logitech hardware, for example-again, here lies the strength of using uncompressed WAV with a decent player / server.
Posted on: 22 April 2010 by likesmusic
quote:
Originally posted by David Dever:
What I find interesting is that this same effect seems to be corroborated by a variety of people's experiences with Logitech hardware, for example-again, here lies the strength of using uncompressed WAV with a decent player / server.
Logitech Squeezecenter converts WAV to FLAC before streaming (unless you override the default settings) so I'd be careful about what conclusions you draw unless you know how Squeezecenter has been configured.
Posted on: 22 April 2010 by Graham Russell
quote:
Originally posted by David Dever:
Might be worth indicating the compression level used with the FLAC files under test, as this will most certainly affect the decoding of the files as they are spooled out into memory.
What I find interesting is that this same effect seems to be corroborated by a variety of people's experiences with Logitech hardware, for example-again, here lies the strength of using uncompressed WAV with a decent player / server.
The Flacs we used were compress level 0 which is least compression and maximum file size.
When Sonos was my main streaming source I compared Flac level 5 with Flac level 0 and heard a difference too. I've not redone this test with my Linux/MPD source and the Naim DAC. Life is just too short..... Which is why I stick with Wav and be done with it now.
Posted on: 22 April 2010 by pcstockton
You guys are making the incorrect assumption that FLAC-0 is easier to decode than FLAC-5 which is easier than FLAC-8 etc....
FLAC5 has been proven to present the smallest load to the processor.
The only part you have intuited correctly is that each file is smaller than the next as you increase levels. This has little to no bearing on the amount of "effort" needed to decode it.
What does "additional overhead on the replay pipeline" mean?
Does anyone know what could be added to the resultant WAV file after decoding that creates degradation of sound?
If they sound identical if converted to WAV not in real time (which doesnt make sense with the computer), how much time is needed between the decoding and playback to have the files identical again.
Are you saying that if I put a 5 minute buffer on a 4 minute song, I will get identical SQ between FLAC and WAV?
If not, what amount of time erases this degradation, that no one experiences with a previously converted file. Everyone says that WAV converted from FLACs sound identical. But doing it just prior to playback is perceivable. Clearly there is some strange time limit to this effect.
Curiously yours.
Patrick
Posted on: 22 April 2010 by {OdS}
Let's not forget that despite being fast, computers do not work in real time. Real time in computers requires very specific hardware and software and none of which we use daily can operate in real time. I wouldn't be surprised if there was an actual difference between Wave files and Flac files. I guess everyone of you can read a book, right? Now, try doing a lecture to some people sitting in front of you. If you've never read that book, you will have hesitations and make mistakes, although the book is written in your mother tongue, which you are perfectyl able to read. What I mean is this: you'll have a more fluent reading if you know the book by heart, thus allowing you not to actuylly read the book, although the text is strictly the same.
Ok, just trying to draw a picture, but I guess you see my point...?
Posted on: 22 April 2010 by js
quote:
Originally posted by pcstockton:
You guys are making the incorrect assumption that FLAC-0 is easier to decode than FLAC-5 which is easier than FLAC-8 etc....
FLAC5 has been proven to present the smallest load to the processor.
The only part you have intuited correctly is that each file is smaller than the next as you increase levels. This has little to no bearing on the amount of "effort" needed to decode it.
What does "additional overhead on the replay pipeline" mean?
Does anyone know what could be added to the resultant WAV file after decoding that creates degradation of sound?
If they sound identical if converted to WAV not in real time (which doesnt make sense with the computer), how much time is needed between the decoding and playback to have the files identical again.
Are you saying that if I put a 5 minute buffer on a 4 minute song, I will get identical SQ between FLAC and WAV?
If not, what amount of time erases this degradation, that no one experiences with a previously converted file. Everyone says that WAV converted from FLACs sound identical. But doing it just prior to playback is perceivable. Clearly there is some strange time limit to this effect.
Curiously yours.
Patrick
I believe it's shown to provide least decode time but '0' to use least resources in general. The extra speed of 5 could have to do parallel decoding and it being the optimal speed size profile for FLAC but I really don't know. Time is of little importance in this app. It may be easier to manage a rotating buffer from non variable compression of '0' or some other such minor aspect that also has effect here.
I tend to agree with likesmusic that these decoders should be better but I've found the same results as the OP and others on every platform tried. Haven't tried the latest HDX firmware yet as I've been in Mexico.
Need a browner smiley.
Posted on: 22 April 2010 by pcstockton
I am not disagreeing there is a difference for some of you. I do however find it completely bizarro that you are.
Forget FLAC compression for a moment.
FLAC converted back to WAV is identical to the original WAV. But there is some minimal time "t" between decoding the FLAC back to WAV and playback that can degrade sound.
This is very strange.
Doesn't anyone else find this odd?
If the PC decodes the FLAC just before sending the WAV to the soundcard, sound is degraded.
But if i do lengthen the time t to a an hour before, resulting in the EXACT same WAV file, they sound the same.
I cannot wrap my mind around how a WAV can sound different given the length of time between the conversion.
If the decoding process happening with a minimal t degrades the computer's performance to such a degree that despite bit perfection, something is added or removed from the signal that affect SQ well before the soundcard touches it, how do you avoid the slippery slope of looking at everything in the chain.
How does the motherboard, hard drive, mains supply of the PC etc, not affect SQ on par with shortest possible t?
I get flat earth and everything, but it can be clearly and empirically shown how PSUs, Hilines, Powerlines and Fraims work. But this WAV vs FLAC is just strange to me.
I can accept that WAVs sound better and convert my entire library just to be safe. But I will then have to assume everything else in the supply chain is suspect as well.
thanks for helping me understand this,
Patrick
PS - every single person outside of this Forum that I have discussed this with cannot find any reason why a minimal "t" could/would affect SQ.
Even if the PC was so badly spec'd that it took enormous resources to decode the FLAC, or even errored when doing so, it would either not play the FLACs or do so with buffering entailing drop-outs. Not SQ difference.
At least this is what the engineers, computer dorks, and DA experts are telling me (outside of this forum).
When I tell them the difference actually exists for some listeners they all simply shrug their shoulders. When pressed for an explanation they can only come up with 2 answers. WAVs play louder and therefor sound "better". Or people are imagining a difference.
Posted on: 22 April 2010 by Graham Russell
When playing a Flac the file is being decoded in real-time while streaming across the network or off disk. The file is not decoded then played. Clearly there is something going on with the decoding while streaming.
We're not going to get to the bottom of this, and frankly I'm not bothered. I've settled on Wav as my playback format and that works great for me. Storage capacity is not an issue.
Posted on: 22 April 2010 by pcstockton
Wouldnt the file be decoded before or after streaming? How could it be done while streaming?
What does "real time" mean in this context. I realize we are talking about micro-seconds here, but technically isn't the decoding happening before it goes into some kind of RAM buffer? From a human perspective this is happening at the same time, but technically it is not.
This is why I bring up the issue of time.
Why wouldn't the negative effects of the decoding exist in every WAV file regardless of how and when?
I simply do not understand how these two sound different
1) a FLAC converted to WAV in Foobar then the resultant WAV played back in Foobar.
2) a FLAC being converted by the Foobar, then sent as fast as possible to the soundcard.
I realize you dont care and cannot be bothered Graham, so I am continuing this discussion with any others involved in the thread. But thanks for your help, impressions, and write up.
Take care,
Patrick
Posted on: 22 April 2010 by fatcat
quote:
Originally posted by pcstockton:
1) a FLAC converted to WAV in Foobar then the resultant WAV played back in Foobar.
In this scenario Foobar writes the wav file to the hard drive without errors. Error correction ensures this. Computers are very good at accurately reading and writing data to and from hard drives
quote:
Originally posted by pcstockton:
2) a FLAC being converted by the Foobar, then sent as fast as possible to the soundcard.
In this scenario because the Foobar is ONLY transferring the data to a sound card, error correction is not as robust. It doesn’t really matter if the data is corrupt.
With regards to “t”. It may simply be a consequence not a cause.
Posted on: 22 April 2010 by pcstockton
Fatcat,
Thx for the thoughts.
I am not trying to be argumentative, just thorough.
Wouldn't errors be present either way? Are you saying that the decoding in converting and playback are handled differently?
thx,
patrick
Posted on: 22 April 2010 by David Dever
quote:
Forget FLAC compression for a moment.
FLAC converted back to WAV is identical to the original WAV. But there is some minimal time "t" between decoding the FLAC back to WAV and playback that can degrade sound.
This is very strange.
Doesn't anyone else find this odd?
If the PC decodes the FLAC just before sending the WAV to the soundcard, sound is degraded.
But if i do lengthen the time t to a an hour before, resulting in the EXACT same WAV file, they sound the same.
I cannot wrap my mind around how a WAV can sound different given the length of time between the conversion.
You're assuming uniform increments of time, variations in which are more significant with shorter buffer tails than longer ones.
