Surely it's only digits?

I've been biting my tongue and not responding here as I have talked a little about this in other posts ...

.... but I still don't get it ...

Simon is trying to educate us on technical issues and all seems logical and (perhaps) relevant but I still always come back to other data flows in computing ...

.... if I am loading a program or data from the internet or a NAS or any other remote storage the bits arrive with no errors or if they do, are reconstituted with the use of the relevant transport protocols. If they were not then programs couldn't work correctly since even a single bit error would make them "wrong". This works irrespective of the source storage media and/or communication technologies being used - different hardware/software does affect the speed of response of this access but not the "quality" (since all bits must be correct). What Simon is talking about here and in other threads is the effect that the transport pipeline has on the analogue signal that is carrying the digital signal and, I concur, may affect the time it takes to receive the correct bits - but I maintain the bits will still be there and be identical to the original bits stored on the source.

Everything behind the DAC (Nas, cabling, network) is all digital.

So the only difference with a DAC and "normal" computing data is that it is a real-time processor and requires its data packets to be available "in time" for its processing ...

... if data wasn't arriving in time I would expect jumps in the sound or are the gaps so small that the DAC ignores them and it is this that is causing any perceived SQ differences?

I just cannot believe that sending audio digital data from different storage devices using different network technologies can change the SQ - this is like saying that a computer program works differently depending on where you load it from!

still confused and still cynical,

Allan

Allan Milne posted:

 

.... but I still don't get it ...

 

 

Somewhere between "bits are bits" and 'everything can change the sound,' most of us are awash in a sea where every mirage (or is it really an island???) on the horizon looks to SOMEONE ELSE like Paradise.

Strange prejudice from some people against naming the Melco here - it is simply another solution, and if used with a Naim player like NDS doesn't even challenge anything Naim - an n area which perhaps more understandably sometimes triggers adverse reaction from people to whom Naim is sacrosanct. What Melco does challenge is various NAS and network solutions: and if it is, or even just may be, a way to get better sound quality, especially out of a Naim product, surely it absolutely should be discussed in this forum!  (It can also be used as a renderer, direct into a DAC via USB, but I dont think NDS has a USB digital input so presumably not the case here, nor an option to compare.)

Given the many discussions trying to solve people's network and NAS problems, and the variaility of networks in setup and componentry, and the variability of potentially interfering electrical/RF sources that may be in the vicinity, it is hardly surprising that something which isolates the music streaming from the network could be beneficial, as I have pointed out in other threads extolling the virtues of a self-contained music store and renderer (which in fact Melco can be if its USB output is used into a DAC). I understand the Melco has good isolation on its ethernet connections to external network to avoid importing RF contamination, so claims to not be degraded through connection to internet etc. Meanwhile the Melco can serve music files across a network to other devices just like a NAS should that be desired, so for music use would appear to have no disadvantages compared to a standard NAS.

For clarification I am not a Melco user, though if I was at the decision point I would certainly again go for the non-network-streaming approach, and would seriously consider Melco as the self-contained store/renderer in place of Mac Mini/Audirvana, not least because it apparently has good RF isolation of its USB output unlike MM, so avoids the need for a separate isolator if used with DAC that lacks good isolation on its input, though into a DAC with excellent isolation these two solutions sounded very similar, albeit on a very brief test.

Allan Milne posted:

 

I've been biting my tongue and not responding here as I have talked a little about this in other posts ...

 

.... but I still don't get it ...

 

Simon is trying to educate us on technical issues and all seems logical and (perhaps) relevant but I still always come back to other data flows in computing ...

.... if I am loading a program or data from the internet or a NAS or any other remote storage the bits arrive with no errors or if they do, are reconstituted with the use of the relevant transport protocols. If they were not then programs couldn't work correctly since even a single bit error would make them "wrong". This works irrespective of the source storage media and/or communication technologies being used - different hardware/software does affect the speed of response of this access but not the "quality" (since all bits must be correct). What Simon is talking about here and in other threads is the effect that the transport pipeline has on the analogue signal that is carrying the digital signal and, I concur, may affect the time it takes to receive the correct bits - but I maintain the bits will still be there and be identical to the original bits stored on the source.

 

Everything behind the DAC (Nas, cabling, network) is all digital.

 

So the only difference with a DAC and "normal" computing data is that it is a real-time processor and requires its data packets to be available "in time" for its processing ...

... if data wasn't arriving in time I would expect jumps in the sound or are the gaps so small that the DAC ignores them and it is this that is causing any perceived SQ differences?

 

I just cannot believe that sending audio digital data from different storage devices using different network technologies can change the SQ - this is like saying that a computer program works differently depending on where you load it from!

 

still confused and still cynical,

Allan

 

Aside from the timing factors described by Simon, RF interference is well recognised as degrading sound quality in DACs, and without very careful screening and/or filtering to ensure the streamed data is pure it can be an issue: in simplistic terms, any piece of wire can effectively act as an aerial, picking up RF interference, while every piece of computer equipment, including a NAS, is a potential local generator of RF which can contaminate its own output. A network adds a layer of risk of RF pickup and potentially increased level of RF to have to remove, compared to avoiding a network.

Another thought occurs to me,, though I cite this as purely conjecture not a fact it is not an area in which I have enough knowledge and others will correct if it is irrelevant or simply wrong:  if inbuilt streaming software sends data from its own dedicated store, then the only data on the connection between it and the renderer  is the music being streamed and associated control data, whereas if that is streamed across a network which may have other data also on the cable, the renderer has an additional task of separating out the wanted from unwanted data, which if nothing else is an additional load on the processor, with the potenial to delay data delivery. I accept that given  processor speeds this may be totally irrelevant, but the simpler self-contained system avoids it completely.

Bart posted:

Allan Milne posted:

 

.... but I still don't get it ...

 

 

Somewhere between "bits are bits" and 'everything can change the sound,' most of us are awash in a sea where every mirage (or is it really an island???) on the horizon looks to SOMEONE ELSE like Paradise.

I've just decided not to concern myself about this. I don't see any point in saying 'I'm cynical' because all you have to do is listen. We compared a UnitiServe playing an album with the same album played on a Synology nas, and the nas sounded better. Both were playing FLAC transcoded to WAV. We have also compared standard cat 6 cables and AudioQuest Cinnamon boutique cables and the AudioQuest sounds better. I've really got no idea why, but I do know that the bits are bits argument just doesn't hold true in reality. 

Allan Milne posted:

 

I've been biting my tongue and not responding here as I have talked a little about this in other posts ...

 

.... but I still don't get it ...

 

Simon is trying to educate us on technical issues and all seems logical and (perhaps) relevant but I still always come back to other data flows in computing ...

.... if I am loading a program or data from the internet or a NAS or any other remote storage the bits arrive with no errors or if they do, are reconstituted with the use of the relevant transport protocols. If they were not then programs couldn't work correctly since even a single bit error would make them "wrong". This works irrespective of the source storage media and/or communication technologies being used - different hardware/software does affect the speed of response of this access but not the "quality" (since all bits must be correct). What Simon is talking about here and in other threads is the effect that the transport pipeline has on the analogue signal that is carrying the digital signal and, I concur, may affect the time it takes to receive the correct bits - but I maintain the bits will still be there and be identical to the original bits stored on the source.

 

Everything behind the DAC (Nas, cabling, network) is all digital.

 

So the only difference with a DAC and "normal" computing data is that it is a real-time processor and requires its data packets to be available "in time" for its processing ...

... if data wasn't arriving in time I would expect jumps in the sound or are the gaps so small that the DAC ignores them and it is this that is causing any perceived SQ differences?

 

I just cannot believe that sending audio digital data from different storage devices using different network technologies can change the SQ - this is like saying that a computer program works differently depending on where you load it from!

 

still confused and still cynical,

Allan

 

Allan.

Perhaps having such an in depth knowledge of computer technologies is preventing you to seeing a wider picture.

 I know nothing about computing, apart from being able to throw plug and play components into a PC case and getting it to work. I do however know a little about instrumentation and control, it appears to me, Simon’s description of “server frame jitter” is simply a transducer.

 The presence of jitter is an indication of the presence of a force/influence of something else, the amount of jitter is an indication of the amount of this force/influence.

 Perhaps the jitter itself doesn’t affect sound quality, but whatever is causing the jitter does.

Hmm, direct influence vs transduction; that's a very interesting way of looking at it.

I'll have to think about that.

Innocent bystander, I'm not going to quote your post here, because it can be read above. I hold no candle for or against either Naim or Melco, but like you, I believe that we have to keep our minds open. But much more important is to keep our ears open. 

Right now, I am hearing CD rips from my Uniterve, via the Melco into NDS, which are clearly better to my ears than I have ever heard them before. Can't tell you why, nor do I have the time to try to figure it out. I also know that they sound even better when played from the Melco's own drives, but that presents difficulties to do with .wav files and metadata, which I don't want to discuss here.

All I wanted to do in this thread was to share my good news. That seems to be more difficult than you might expect!

I just don't get the argument 'bits are bits' .. It makes no engineering sense to me in the world of electronics, data comms and computer engineering I professionally inhabit .. and it seems implausible to me why domestic hifi should somehow be different. . Bits are represented usually by voltages in our systems, and unless static they are usually streams of bits, therefore the value of a bit is determined by voltage and a point in time. Electronic systems encode and decode these streams so as to process them. The systems that do this have other functions imbedded within them like other clocks to create new data streams or drive DACs. Functions within a system typically interact or intermodulation with each other. Therefore for example if a clock at the end of a system drives a DAC, all the other functions in that system will potentially interact and modulate that clock... Thetefore a system processes input stream of bits with time  T and an output DAC of sample time t in the same system, will be related such that the system output timing will be determined by t.FN(T) where FN is the system intermodulation or system feedback function .... Notice the actual bits don't feature in this.. just their timings.

In real systems and data streams bits are definitely not neccessarily just bits... 

Simon, that's because you have a significant degree of hardware focus in your work.  As a software engineer, one just doesn't need to consider the underlying physical implementation of the data, it just 'works' behind the scenes.

As a result, unless you're taking about firmware (or very exceptionally in device drivers) the only things that needs to be considered when designing software (or programming) are the data and code, not the underlying physical layers.  It's an approximation to the truth that works when dealing with systems that are only in the software domain, and simplifies the thought processes necessary when working exclusively in that information domain.

Ah Jay..,.s lads, lighten up!!

Simon - you seem to be talking about low-level comms signals,.

That is why we have a protocol stack and layers of transport protocols, so that, at a software level for example, we deal with the bits and can disregard the low-level electronic voltage  and carrier details.

This may be the answer I have been looking for in all my questions - is the digital and DAC front-end using low-level comms rather than proven digital protocol stacks for its input ports? If so then I can see why RF interference, signal noise etc cqan affect and effect the SQ.

... which then begs the question as to why digital processing using these protocols is not used in the audio components; 

... and perhaps explains why Ethernet connection might be better than a direct cable from a US to a dac - Ethernet has its protocol to be applied to preserve digital integrity.

I see no digital reason why '1101' on some source media should not arrive as '1101' to the DAC in a timely fashion; I notice no-one has explained to my previous question as to why this happens with computer data but not audio data

perhaps the low-level comms is the answer, but if so why is this not explained to consumers by the component manufacturers?

a less cynical Allanm 

Allan, the '1101' does arrive as '1101' however along with that are small ELECTRICAL (rather than data) variations in the wires that carry the data, variations both in voltage and timing.  These variations are smaller than the size of the bits, so the data themselves are preserved.  As the wires that carry the date MUST be connected to the DAC (even if via opto isolators), then some part of these variations gets to the digital side of the DAC, and from the digital side of the DAC some of that variation gets to the analogue side of the DAC.

Ok guys, you win. ZZzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz!

G'dnight David.  

David O'Higgins posted:

Innocent bystander, I'm not going to quote your post here, because it can be read above. I hold no candle for or against either Naim or Melco, but like you, I believe that we have to keep our minds open. But much more important is to keep our ears open. 

Right now, I am hearing CD rips from my Uniterve, via the Melco into NDS, which are clearly better to my ears than I have ever heard them before. Can't tell you why, nor do I have the time to try to figure it out. I also know that they sound even better when played from the Melco's own drives, but that presents difficulties to do with .wav files and metadata, which I don't want to discuss here.

All I wanted to do in this thread was to share my good news. That seems to be more difficult than you might expect!

 

Interestingly I haven't heard adverse comments anyone who has tried the Melco, though some praise it more than others - which may depend on what they are coming from, or listening through. For me, I can't justify the cost having invested in Mac Mini/Audirvana only a couple of years ago, and compared to my specific MM setup any Melco differences are not major enough to notice in a short session. OThers say Melco is better than MM/Aud, but none that I have seen used the exact same setup as me, and there are suggestions that the MM itself can vary from example to example. But when one day my MM dies, as it probably will, whetherbthat be next year or a decade's time, I will certainly consider Melco (or whatever it mightbhave evolved to).

One significant advantage of Melco over MM/Audiv or conventional NAS solutions is that it is available for home demo - I even have tacit agreement for that to be done by mail given my remote location. Some people say it is expensive compared to a NAS - but the same poeple sometimes spend, or advocate others spending, considerably more on upgrading a power supply: which has greater benefit can only be judged by hearing, while the experience of others is the fuel for that. 

Given that I have a DAC I like very much, and expect to change soon for one even better, my own interest in Melco would be as a renderer as well as a music store, which is a little different from using it with an NDS - but the result may be the same.

Thanks for the benefit of your experience.

Huge posted:

Simon, that's because you have a significant degree of hardware focus in your work.  As a software engineer, one just doesn't need to consider the underlying physical implementation of the data, it just 'works' behind the scenes.

As a result, unless you're taking about firmware (or very exceptionally in device drivers) the only things that needs to be considered when designing software (or programming) are the data and code, not the underlying physical layers.  It's an approximation to the truth that works when dealing with systems that are only in the software domain, and simplifies the thought processes necessary when working exclusively in that information domain.

Huge, I agree with you to a point, but there is more to software engineering than merely high level languages, being a computer engineer I have designed and and developed high and lower level software commercially as well as integrated and engineered hardware ... High level programming (what the media genereally calls 'coding')  and physical implementation are two different things but do coalesce at the machine code level or low level programming level. A high level language, is usually abstracted and machine independent (which I think is what you are referring to).. where as machine code is typically entirely machine and hardware dependent.

with physical devices and their interactions we are real, not abstract, so the programmer in many scenarios needs to consider implementation cause and effect as well as data representation at the I/O interfaces.... and of course Naim are entirely here at the moment with their firmware development on their streamers....

Simon, even at the machine code level one is rarely troubled by the physical implementation, even the numeric instruction set codes (i.e. below the assembler level) are still an abstraction of the internal operation of the CPU.  One can still assume that a fetch from a memory location will return the exact data at that location and they will be correct and stable after a defined number of clock cycles (albeit dependant on cache hits if a cache is fitted, but then the instruction won't return until the data are successfully read).

In general programming at any level one doesn't usually need to take into account any voltage level outside 1s and 0s or any timing outside of single clock cycles - the only time when this does need to be considered is at the interface between digital and analogue domains.  This is even more critical when considering a real time analogue domain (as we are with audio).

It's only a very small proportion of programmers (a few percent) who have any practical experience interfacing between the digital and analogue domains.

Huge posted:

It's only a very small proportion of programmers (a few percent) who have any practical experience interfacing between the digital and analogue domains.

I get the context of your statement here (audio: DAC / ADC) , but I must add that the biggest area where digital and analogue meets each other is in the User Interface - or User Experience.

This implies that any programmer, either assembler (do they still exist?) - java - html5 - whatever language need to consider the impact of digital to the analogue domain since I am the interpretor of the analogue domain.

Only digits….. For me it is not just “only”. I am impressed of the technical knowledge shown. I have read what a few of you stated and tried to understand. So far not everything understood but improving. Really impressed!

Streaming and storing music. For me a few things are equal important. SQ, easy to install and easy to use and a good build quality.

1 year ago I started my project. A huge upgrade. I went from 72/140 to NDS/552/300. Loudspeakers still to replace. I decided very fast to stay with Naim as I have used Naim electronics for more than 20 years without problems. Like the sound also.

What took time to decide was how and where to store my CDs. I search over internet, forums and reviews. What I did not want was a something complicated. A network seemed complicated. For most of you it is not complicated. For quite some time I felt that the best option was to buy a new laptop just for storing.

During my search I found something called Melco. Reviews were very positive. Seemed to be easy to operate. Contacted Melco direct for further information. I got even more info than I asked for. Very positive first contact. (Got also very fast and professional responses from Steven at Naim)

Since 2 week I got the N1Z and all other Naims I bought installed. A piece of cake to get the Melco to work. Ethernet cable from the switch to the Melco and a further (high quality) Ethernet cable from the Melco into the NDS. Switched on the power and it streamed directly. With the Buffalo CD ripper I load my CDs. It takes 6 min per CD to rip in WAV and “it” pick up the covers from the internet by itself. Perfect for an old CFO as myself.

SQ? I have no experience from similar products but for me the Melco sounds great. I still have my old CD2 connected but for sure it will retire. The CD2 cannot compete with the SQ from the Melco/NDS combination. Not saying that the Melco is the best in the world but I like it very much.

Conclusion. I am happy and I am pleased that David feels the same.

Ardbeg10y posted:

Huge posted:

It's only a very small proportion of programmers (a few percent) who have any practical experience interfacing between the digital and analogue domains.

I get the context of your statement here (audio: DAC / ADC) , but I must add that the biggest area where digital and analogue meets each other is in the User Interface - or User Experience.

This implies that any programmer, either assembler (do they still exist?) - java - html5 - whatever language need to consider the impact of digital to the analogue domain since I am the interpretor of the analogue domain.

The only circumstance where you need to consider the analogue element specifically (rather than considering a human's analogue interpretation of data existing in a digital domain) is the the HID hardware itself (and just possibly the lowest level drivers).

For instance taking a display: The physical intensity of a pixel is controlled by a video DAC.  The programmer doesn't need to know the voltage (or current) output by the DAC, they only need to trust that the right intensity will be displayed by the hardware corresponding to the digital data provided by the application.  (The designer of the display hardware on the other hand has to ensure other stuff, such as that interference from the mains supply doesn't cause the display to flicker - that's analogue, but the programmer doesn't have to care, they only deal with the digital data.)

Taking a keyboard, even the human considers that to be digital - do you have a concept of a half pressed key on a computer keyboard, or pressing in-between two keys?  (And the keys are even pressed with your digits! )

Huge posted:

Allan, the '1101' does arrive as '1101' however along with that are small ELECTRICAL (rather than data) variations in the wires that carry the data, variations both in voltage and timing.  These variations are smaller than the size of the bits, so the data themselves are preserved.  As the wires that carry the date MUST be connected to the DAC (even if via opto isolators), then some part of these variations gets to the digital side of the DAC, and from the digital side of the DAC some of that variation gets to the analogue side of the DAC.

Bit by bit this starts to make sense. Thank you.

in audirvana there are two integer playback modes, mode 1, and mode 2. both arrive at the dac bit perfect. the developer claims these modes will sound different as there is a difference in the way each are streamed to the dac. mode 1 more transparent with better soundstaging, mode 2, warmer. i did a quick blind test and picked out mode 2 four out of five times. does this mean i could hear a difference? my own view is i need to pick it out 10 out of 10 times. to cancel any noise effect the laptop was running on batteries into galvanic isolated dac. here's a challenge for anyone, if you can do this same blind test (get someone else to change the mode) and pick out the right mode 10 out of 10 times then i will disagree with those that claim bits are just bits.

You don't need 10 out of 10 from any one individual, you just need statistical significance across a number of people.

the challenge is ten attempts and get all ten right. quick and simple. the odds of getting all ten right by luck is minute unless you can actually hear a difference.