Expensive Christmas...

Any NAS can be accessed for downloading directly - ripped or download,  its how you direct your PC/Mac to process the vendors files into your domain,  or if you wish to intergrate through Melco

Personally I prefer to download to PC & go into that to check metadata, art etc..  If (BIG IF) if it needs editing,  then I do that in PC where copy/paste & all the editing is easier & when that's done & I've run a function & audio test,  then I upload to NAS & nothing more needs to be done to it.

Graham Clarke posted:

nbpf posted:

Graham Clarke posted:

Think of the Melco more like a networking bridge or repeater.  Your streamer connects directly to the Melco (that's how it benefits from the low noise, reduced jitter etc).  Another port in the Melco connects it to your switch.  So when you want to listen to music on a NAS (not the Melco), it passes through the Melco and gains some of the benefits, but apparently not as much as music running direct from the Melco device.

This is a bit strange, isn't it? I would have expected that it is possible to setup the Melco to first retrieve the data from the NAS and then, once file transfer has completed, stream out to the connected streamer. Everything else amounts to handle data which is wholly available on the LAN as if it was an internet stream. This makes little sense to me. Am I missing something?

I suspect it amounts to complexity of implementation within the software, or simply existing software constraints.

When accessing music stored on the Melco storage (HDD/SSD) I assume that occurs via the UPnP API from the streamer.  I'm not sure if that API allows daisy chaining of devices (NAS -> Melco -> Streamer) - anyone know?

If not, then the easiest solution would be for the Melco to simply pass the UPnP commands to the target device rather than trying to buffer content from a NAS and then serve it up again.  Hence my comment of "bridge or repeater".

Like many such devices the Melco probably runs some form of Linux which means that they are using features provided by the OS and other RPMs that are available/installable.  Unless they want to write a lot of custom code themselves they have to stay within those constraints.

Also, would buffering in the way you suggest make further improvements to SQ?  Possibly.  I don't know.

I checked the Melco webpages a few months ago as the first threads on the devices appeared here in the forum. But I could not find any useful technical documentation. Thus, I do not know whether the Melcos are based on a stripped-down Linux distribution. But www.kogaudio.com/wp-content/uploads/HiFi_124_Melco_HR.pdf seems to suggest they are not. Who knows ... there was also a confidential patent agreement between Melco and Microsoft in spring 2015, if I remember correctly ...

I was not suggesting buffering but full (temporary) storage. Assuming that the data selected by the user are available on NAS but not on the local Melco drive, it should not be that difficult retrieving the data from the NAS and storing them on that local drive before starting playback. The data could be erased after playback has completed. This way there would be a (possibly significant) time delay before replay can start but certainly no difference in sound quality between NAS data and Melco data except, of course, if the sound quality happened to depend on the time stamp of the data! At the time point of replay, the NAS data would have been (completely and temporarily) stored on the local drive and no data transfer between NAS and Melco would need to take place.

I do not see what can be difficult in retrieving data from a NAS and my point is that, if the Melcos cannot be configured in such a way that NAS data are first-class citizen and get replayed with the same sound quality as locally stored data, then -- as bridge or repeater devices -- they do something quite wrong. Of course, they are probably excellent music servers and, if the local drives can be upgraded (2 TB SSD are not anymore so terribly expensive) there is not so much need for repeaters anymore.

Guys - just remember there is no concept of data jitter in the TCP transfers... noise isolation yes - we know cheap consumer network devices can be notorious for electrical noise, but jitter is nothing to do with this. A correctly working and top sounding UPnP TCP media transfer is fired in bursts of packets, pause, another burst, pause etc... there is no sample timing or even transport timing stability - therefore jitter is completely meaningless - the focus is to keep the TCP windowing  buffers full so the payload data can then be reassembled and passed upto the application layer - where it is then serialised and precision clocked - from this point  jitter matters again...

Simon

Graham Clarke posted:

nbpf posted:

Graham Clarke posted:

Think of the Melco more like a networking bridge or repeater.  Your streamer connects directly to the Melco (that's how it benefits from the low noise, reduced jitter etc).  Another port in the Melco connects it to your switch.  So when you want to listen to music on a NAS (not the Melco), it passes through the Melco and gains some of the benefits, but apparently not as much as music running direct from the Melco device.

This is a bit strange, isn't it? I would have expected that it is possible to setup the Melco to first retrieve the data from the NAS and then, once file transfer has completed, stream out to the connected streamer. Everything else amounts to handle data which is wholly available on the LAN as if it was an internet stream. This makes little sense to me. Am I missing something?

I suspect it amounts to complexity of implementation within the software, or simply existing software constraints.

When accessing music stored on the Melco storage (HDD/SSD) I assume that occurs via the UPnP API from the streamer.  I'm not sure if that API allows daisy chaining of devices (NAS -> Melco -> Streamer) - anyone know?

If not, then the easiest solution would be for the Melco to simply pass the UPnP commands to the target device rather than trying to buffer content from a NAS and then serve it up again.  Hence my comment of "bridge or repeater".

Like many such devices the Melco probably runs some form of Linux which means that they are using features provided by the OS and other RPMs that are available/installable.  Unless they want to write a lot of custom code themselves they have to stay within those constraints.

Also, would buffering in the way you suggest make further improvements to SQ?  Possibly.  I don't know.

Graham,

How are you getting on with the Melco. I'm loving it..most dangerous!!

Would there be any sonic improvements plugging an external hard drive direct into the Melco and playing direct from there rather than loading music onto the SSD drives (if your music collection is larger than the capacity of the Melco).

Darke Bear posted:

When I had a Demo of an early version of the Melco it was a no-brainer large upgrade, That was at my Dealer with NDS and 2x555PS source. It sounded like the musicians woke-up from a snooze and were interested in what they were playing - when I eventually decide to go for a streaming system I will have a Melco most likely.

I also spent nearly and hour discussing how it all works with the Designer at a show - he told me enough that I could almost build one. But essentially it is the electronic decoupling from noisy commercial 'good-enough' power supplies used in switches and routers and re-clocking to reduce jitter that then presents the NDS with a quiet HiFi-grade network and does not task it to work too hard to recover the signal from the data, so it ends-up performing better - and you easily hear it.

DB.

Makes sense but it's curious that Naim hasn't built a 'super' Uniti-serve, given its expertise in the field of power supplies etc.

I would not put it past them. They have been working on a mains block for years. Who knows what is trickling down (or presently jammed in) the pipe?

Harry posted:

Can the HDDs be user replaced? This is a big advantage of a NAS for me, the scaling and replacement of the discs. without data loss. If I need a new disk I don't want to have to send it back.

I've never got on with Twonky, although I suppose this is not a real issue because it is pre installed and configured in the device.  My understanding is that a Minimserver option is in development?

Not that I'm aware of, Harry.  Also the SSDs in the N1Z apparently have rewritten firmware to reduce the electrical noise during some operations (e.g. housekeeping activities that SSDs have to perform).

Dustysox posted:

Graham Clarke posted:

nbpf posted:

Graham Clarke posted:

Think of the Melco more like a networking bridge or repeater.  Your streamer connects directly to the Melco (that's how it benefits from the low noise, reduced jitter etc).  Another port in the Melco connects it to your switch.  So when you want to listen to music on a NAS (not the Melco), it passes through the Melco and gains some of the benefits, but apparently not as much as music running direct from the Melco device.

This is a bit strange, isn't it? I would have expected that it is possible to setup the Melco to first retrieve the data from the NAS and then, once file transfer has completed, stream out to the connected streamer. Everything else amounts to handle data which is wholly available on the LAN as if it was an internet stream. This makes little sense to me. Am I missing something?

I suspect it amounts to complexity of implementation within the software, or simply existing software constraints.

When accessing music stored on the Melco storage (HDD/SSD) I assume that occurs via the UPnP API from the streamer.  I'm not sure if that API allows daisy chaining of devices (NAS -> Melco -> Streamer) - anyone know?

If not, then the easiest solution would be for the Melco to simply pass the UPnP commands to the target device rather than trying to buffer content from a NAS and then serve it up again.  Hence my comment of "bridge or repeater".

Like many such devices the Melco probably runs some form of Linux which means that they are using features provided by the OS and other RPMs that are available/installable.  Unless they want to write a lot of custom code themselves they have to stay within those constraints.

Also, would buffering in the way you suggest make further improvements to SQ?  Possibly.  I don't know.

Graham,

How are you getting on with the Melco. I'm loving it..most dangerous!!

Would there be any sonic improvements plugging an external hard drive direct into the Melco and playing direct from there rather than loading music onto the SSD drives (if your music collection is larger than the capacity of the Melco).

Early days yet Dusty, it was installed a couple of hours ago and we listened to just 4 tracks.  Now it's copying 6,500 tracks and being left to warm up.

My plan is to run it for one week then introduce the second 555PS to see what difference that makes.  UHES also leant me a Chord STA Ethernet cable and a Melco alternative so that I can compare to my Audioquest Cinnamon.

Simon-in-Suffolk posted:

Guys - just remember there is no concept of data jitter in the TCP transfers... noise isolation yes - we know cheap consumer network devices can be notorious for electrical noise, but jitter is nothing to do with this. A correctly working and top sounding UPnP TCP media transfer is fired in bursts of packets, pause, another burst, pause etc... there is no sample timing or even transport timing stability - therefore jitter is completely meaningless - the focus is to keep the TCP windowing  buffers full so the payload data can then be reassembled and passed upto the application layer - where it is then serialised and precision clocked - from this point  jitter matters again...

... but serializing and clocking takes place in the streamer, right? Thus, the advantages of a Melco (or Melco-like devices) as an "audiophile" NAS (or as a repeater between a NAS and a streamer) could be explained in terms of diminished load for the streamer and better isolation.

I am not trying to argue for or against the Melcos, I just would like to understand what these devices have been designed to do.

In principle, I very much like the idea of dedicated servers like the Brystons, the Melcos, the Vortexboxes and, of course, the UnitiServe.

But I have the impression that most such devices are unnecessarily unflexible (e.g., w.r.t. SSD drive replacement, ssh access and data transfer, software upgrade, the possibility of installing different UPnP servers and stop unused services), and poorly documented.

MDS posted:

Darke Bear posted:

When I had a Demo of an early version of the Melco it was a no-brainer large upgrade, That was at my Dealer with NDS and 2x555PS source. It sounded like the musicians woke-up from a snooze and were interested in what they were playing - when I eventually decide to go for a streaming system I will have a Melco most likely.

I also spent nearly and hour discussing how it all works with the Designer at a show - he told me enough that I could almost build one. But essentially it is the electronic decoupling from noisy commercial 'good-enough' power supplies used in switches and routers and re-clocking to reduce jitter that then presents the NDS with a quiet HiFi-grade network and does not task it to work too hard to recover the signal from the data, so it ends-up performing better - and you easily hear it.

DB.

Makes sense but it's curious that Naim hasn't built a 'super' Uniti-serve, given its expertise in the field of power supplies etc.

Maybe that's why Alan Ainslie left to become general manager at Melco...

Thanks Graham. It sounds a bit non serviceable which does not appeal but if the musical enjoyment is beyond doubt the brain will always come up with the appropriate logic! One for me to watch with interest. 

Harry posted:

I would not put it past them. They have been working on a mains block for years. Who knows what is trickling down (or presently jammed in) the pipe?

Oooh! I'd take one of those. My old Russ Andrews block is beginning to look a bit out of place since all my Naim gear arrived. 

Mike

Graham Clarke posted:

Dustysox posted:

Graham Clarke posted:

nbpf posted:

Graham Clarke posted:

Think of the Melco more like a networking bridge or repeater.  Your streamer connects directly to the Melco (that's how it benefits from the low noise, reduced jitter etc).  Another port in the Melco connects it to your switch.  So when you want to listen to music on a NAS (not the Melco), it passes through the Melco and gains some of the benefits, but apparently not as much as music running direct from the Melco device.

This is a bit strange, isn't it? I would have expected that it is possible to setup the Melco to first retrieve the data from the NAS and then, once file transfer has completed, stream out to the connected streamer. Everything else amounts to handle data which is wholly available on the LAN as if it was an internet stream. This makes little sense to me. Am I missing something?

I suspect it amounts to complexity of implementation within the software, or simply existing software constraints.

When accessing music stored on the Melco storage (HDD/SSD) I assume that occurs via the UPnP API from the streamer.  I'm not sure if that API allows daisy chaining of devices (NAS -> Melco -> Streamer) - anyone know?

If not, then the easiest solution would be for the Melco to simply pass the UPnP commands to the target device rather than trying to buffer content from a NAS and then serve it up again.  Hence my comment of "bridge or repeater".

Like many such devices the Melco probably runs some form of Linux which means that they are using features provided by the OS and other RPMs that are available/installable.  Unless they want to write a lot of custom code themselves they have to stay within those constraints.

Also, would buffering in the way you suggest make further improvements to SQ?  Possibly.  I don't know.

Graham,

How are you getting on with the Melco. I'm loving it..most dangerous!!

Would there be any sonic improvements plugging an external hard drive direct into the Melco and playing direct from there rather than loading music onto the SSD drives (if your music collection is larger than the capacity of the Melco).

Early days yet Dusty, it was installed a couple of hours ago and we listened to just 4 tracks.  Now it's copying 6,500 tracks and being left to warm up.

My plan is to run it for one week then introduce the second 555PS to see what difference that makes.  UHES also leant me a Chord STA Ethernet cable and a Melco alternative so that I can compare to my Audioquest Cinnamon.

Ooo, now that is interesting Graham. Would love to read your thoughts on that journey (when does it end!!).

I am just copying some familiar tracks at the mo to the Melco. Looking forward to seeing what affect (if any) that has. 

All my close to 7000 albums are on the Melco and they sound great...., much better than before.

Hi Dustysox

re "would there be any benefits plugging an external hard drive into the Melco and  playing directly from there"...

in NZ/Aus region an external USB drive is the recommended configuration with a Unitiserve SSD.  All the Statement demos have used external powered USB drives their data source.  A quiet PSU for the external HDD is a key performance factor.  One system uses a modified Supercap to drive a LaCie P9230 drive.  I use a TP 12v 2a linear supply on my LaCie drive. Offloading the Ethernet traffic appears to reduce noise. I suspect another factor may also be 1500 byte Ethernet transfers vs 128k byte USB block reads reducing the processing workload.

Similar recommendations occur across a number of the Computer Audio sites.

Well worth trying, I think....

PS. the new "Super Sarum" Ethernet cable is reportedly a significant improvement on the previous STA

40 below posted:

Hi Dustysox

re "would there be any benefits plugging an external hard drive into the Melco and  playing directly from there"...

in NZ/Aus region an external USB drive is the recommended configuration with a Unitiserve SSD.  All the Statement demos have used external powered USB drives their data source.  A quiet PSU for the external HDD is a key performance factor.  One system uses a modified Supercap to drive a LaCie P9230 drive.  I use a TP 12v 2a linear supply on my LaCie drive. Offloading the Ethernet traffic appears to reduce noise. I suspect another factor may also be 1500 byte Ethernet transfers vs 128k byte USB block reads reducing the processing workload.

Similar recommendations occur across a number of the Computer Audio sites.

Well worth trying, I think....

It seems that, in one way or another, we are back to a dedicated music server, local data and direct connection to a DAC or streamer. This is good, I think. In this context, what are the advantages / disadvantages of S/PDIF, TCP/IP and I2S connections?

Bert Schurink posted:

blownaway posted:

One thing I'm unclear on Burt is can the Melco work with a nas drive in the sense can you easily move music/data around from one to the other? I need more storage than 4TB.  Can you just plug in your nas directly into the Melco?  You mention a nas that will transcode to wav so it sounds like you still have use for a nas.  I just bought a nas drive (synology 716+) and two 6TB drives and it would be cool to use the two together.

I will try this one as good as I can with my limited knowledge:

1. You could expand the storage of the Melco by sticking in the Melco bigger harddisks (so replace the standard 2 * 2 TB ones with bigger), experience on noise etc are standing out - not heard about this.

2. You could expand the managed storage by connecting other storage up to 16TB additional via USB connection of the Melco - Melco would manage it together with it's own storage as one.

3. Elsewhere available storage on the network can be used through Melco passthrough. In which case you still use the quality of the Melco, whatever the capacity you need.

Thanks for making the effort to field my questions.  I'm hopeful the Melco can work together with a nas and files can be easily moved between both.  I'm fine with the idea of putting the music I listen to most on the Melco and store the rest on my nas.  Since I like so much music I can easily see I would want to rotate my Melco go-to music with my collection that I haven't heard in while for the sake of variety.  Being able to transfer music via USB from the Melco to the nas and from the nas to the Melco would be key for me.  I'm not sure how this can all work, but if Melco is in fact working with minimserver that would help since you need minimserver for gapless & DSD playback on the Synology nas (so I'm told).  

 To clarify, the Unitiserve with USB HDD on a supercap, and super Sarum, is being used on an NDS and Statement.......

blownaway posted:

Bert Schurink posted:

blownaway posted:

One thing I'm unclear on Burt is can the Melco work with a nas drive in the sense can you easily move music/data around from one to the other? I need more storage than 4TB.  Can you just plug in your nas directly into the Melco?  You mention a nas that will transcode to wav so it sounds like you still have use for a nas.  I just bought a nas drive (synology 716+) and two 6TB drives and it would be cool to use the two together.

I will try this one as good as I can with my limited knowledge:

1. You could expand the storage of the Melco by sticking in the Melco bigger harddisks (so replace the standard 2 * 2 TB ones with bigger), experience on noise etc are standing out - not heard about this.

2. You could expand the managed storage by connecting other storage up to 16TB additional via USB connection of the Melco - Melco would manage it together with it's own storage as one.

3. Elsewhere available storage on the network can be used through Melco passthrough. In which case you still use the quality of the Melco, whatever the capacity you need.

Thanks for making the effort to field my questions.  I'm hopeful the Melco can work together with a nas and files can be easily moved between both.  I'm fine with the idea of putting the music I listen to most on the Melco and store the rest on my nas.  Since I like so much music I can easily see I would want to rotate my Melco go-to music with my collection that I haven't heard in while for the sake of variety.  Being able to transfer music via USB from the Melco to the nas and from the nas to the Melco would be key for me.  I'm not sure how this can all work, but if Melco is in fact working with minimserver that would help since you need minimserver for gapless & DSD playback on the Synology nas (so I'm told).  

 

The USB transfer of music onto the Melco is the recommended way of transferring music, so it should suit your needs. With close to 4tb you should have a rather sizable option for storing special music onto the Melco.

blownaway posted:

...  Being able to transfer music via USB from the Melco to the nas and from the nas to the Melco would be key for me. ...

Since the Melco can (or even must) be connected to a LAN, I would expect one to be able to copy data back and forth from the Melco to any other device supports file transfer via TCP/IP. You do not want to fiddle around with USB drives when you have a fast Ethernet connection and you can do the job by just pressing a button, do you?

40 below posted:

 To clarify, the Unitiserve with USB HDD on a supercap, and super Sarum, is being used on an NDS and Statement.......

Right, but what can we actually deduce from this fact? Does it suggest that a US with attached USB drive powered by a linear PSU is the recommended setup for serving musical contents to a Naim streamer? Why a PSU on the drive and not on the US? How can we bring together this fact with the many experiences reported in this forum from experienced users who compared the US as a UPnP server to a NAS? I am confused.   

So, 24 hours in with the Melco N1Z (the SSD version), oh boy, this is a tricky one...

Here's what the "tower of power" currently looks like:

Now, before anyone says "that's too high!", we did check with Naim and given that we have concrete floors downstairs they thought this would be alright.  I wouldn't want to try it on a suspended wooden floor though!

We added a second 555PS and the Melco which was connected to the mains via a Powerline.  The 555 was plugged into the dedicated spur and the Melco into the standard ring main due to the fact that it has a switched mode power supply.

We did consider locating the Melco next to the NAS drive (opposite end of the room, under the TV) but that would have prevented us from trying a Chord STA Ethernet cable.

At present the second 555PS isn't connected to the NDS, it's just powered on, warming up.  The Melco is using the STA Ethernet cable and the cable from the switch to the Melco is an Audioquest Cinnamon.  The Melco, 555 and STA cable have all been run in for some time before appearing at our house.

So does it sound any different?  Yes!  However it's not all positive...

The soundstage is certainly slightly bigger than it was, but we're not talking a huge change here.  Emotionally it sounds slightly more involving than before, too.  It's quite hard to put a finger on the differences though, as they are subtle and I feel that rather than having added something positive (detail, weight etc) what it has actually done is taken away something unwanted.  Maybe that's the effect of reducing electrical noise throughout the circuits?  This much is all good news and if there was nothing further to report I may already be sold on the idea.

But there's a "gotcha".  One of the consistent improvements I've had through many changes this year (552 to S1, Super Lumina IC, SL speaker cable, SL DIN-XLR and then SL DIN 4-4) is in the treble area.  With each change there has been additional delicacy, space, airiness and ease of reproduction and detail, most obviously noticed with cymbals.  With the Melco there seems to be a slight dampening of cymbals, they've lost some of the gains that have been made through my upgrade-itis this year which I find troublesome.  Troublesome enough to make me wonder whether I could live with it.  I did try switching between NDS connected to Melco and NDS connected directly to switch and could hear it clearly, although it was apparent simply from memory of well known tracks without an A/B test.

So I'll give it a couple more days to see if that changes at all then I'll add in the second 555PS.  I was also leant a relatively cheap (compared to STA) Melco Ethernet cable so I'll experiment with that too.

Try plugging the Melco into the HiFi Mains, rather than into a different circuit and see if the HF blur goes away. I find that different mains circuits can end-up subtending a large RF loop and it gets into the system and can cause what you describe.

I may be wrong - but easy to try.

DB.

very impressive "tower of power" Graham...

enjoy

ken