So there are always this new vs. old and what is better. I suspect that a lot of the old fashion audiophiles will scoff at the idea that anything digital will not be as good as the proven cdp. I personally thought that was the case too not too long ago, but having sometimes to think about it, I think architecturally a digital music server may have an advantage over the cdp. If you think about it, there is really nothing different between a cdp and a music server. Both are nearly identical in architecture. You need some digital music data, clock out the data, send it to the DAC to convert it to analog and ultimately to the amplifier. The only difference is how and where the data comes from. The cdp obviously gets its data from the disk, whereas the server gets its data from some type of memory source whether its a hard drive or flash memory of some sort. The rest is the same. Now as a designer, if you have a choice, which one would you prefer? Data form a spinning disk or the same data from a hard drive or flash mem.? It think it's probably pretty obvious. It's a lot easier to design if the data comes from a well control flash mem or hard drive due to easier power supply design, much higher speed (which present another advantage which will be discussed later), and physically it's better integrated.
.... more on the next post ...
.... more on the next post ...
One of the most difficult aspect of cdp design is the jitter control that every manufacture has to figure out some way to optimize. The final stage is the DAC which needs a clock to convert data from digital to analog. Most people have the misconception that since the music data is all digital so jitter is not an issue, but actually the DAC relies on this clock to synchronize the incoming data to clock out the data. But it's not simple as just a clock because this clock in most cases has to be "recovered" from the incoming data. If the incoming data stream has a lot of jitter, this recovered clock will have a lot of jitter too. The clock basically has to move with respect to the input digital data otherwise there will be either setup of hold time violations as the data is clocked into the DAC.
This jitter will ultimately be converted in someway into either timing distortion or voltage distortion on the DAC output which means the sound noise floor won't be as quiet, and the freq. response won't be as clean.
A lot of manufactures had various different way to minimize the jitter. Some claimed to use a retimer to "retime" the data to minimize the jitter. Some even went as far as minimize the vibration of the disk transport which supposedly minimize the data jitter. And some actually claimed that if the disk is painted with certain kind of color, it will lessen the error from lazer reading mechanism ....
But out of all these claims, there are only two methods that have been tried that I thought were any legitimate.
The first one is from Chord electronics. They made a DAC which had a really large memory buffer. The data from the transport does not clock directly to the DAC, but intermediately stored into the memory. A separate clock would then clock the data from the memory to the DAC. Since this clock is local to the DAC, and if there is no underflow of the memory, this type of implementation seems to work in term of minimizing the DAC clock jitter at least in theory because there is no longer a coupling mechanism between the DAC clock and the incoming data. The trick I guess you need to read the data from the disk much faster than you clock the data out of the memory to the DAC. Maybe because of this, Chord DAC offers a very large memory buffer to minimize memory underflow. Given most songs are about 5min long, the worse case is you may have to wait a few seconds between each song to wait for the buffer to fill up. But there still will be a lot of classical tracks that much longer so I guess the Chord DAC still need some type of forwarding mechanism in case of underflow.
The other way to minimize jitter comes from DCS which they called "reverse clocking". Basically the main clock is used to clock the DAC and local to the DAC. This clock is then distributed to the transport which is then used to control the disk mechanism. So with just one clock, everything is supposedly synchronized so there won't be any need for retiming. I think you still need to do some type of phase aligning, but this phase aligning probably won't be as bad as a full retiming.
By now, at least with respect to jitter, you can see how a musical server can lessen this jitter greatly because a the server doesn't have to deal with a lot of problem a cdp due to the freedom of where and how you get the data.
... more next post ...
This jitter will ultimately be converted in someway into either timing distortion or voltage distortion on the DAC output which means the sound noise floor won't be as quiet, and the freq. response won't be as clean.
A lot of manufactures had various different way to minimize the jitter. Some claimed to use a retimer to "retime" the data to minimize the jitter. Some even went as far as minimize the vibration of the disk transport which supposedly minimize the data jitter. And some actually claimed that if the disk is painted with certain kind of color, it will lessen the error from lazer reading mechanism ....
But out of all these claims, there are only two methods that have been tried that I thought were any legitimate.
The first one is from Chord electronics. They made a DAC which had a really large memory buffer. The data from the transport does not clock directly to the DAC, but intermediately stored into the memory. A separate clock would then clock the data from the memory to the DAC. Since this clock is local to the DAC, and if there is no underflow of the memory, this type of implementation seems to work in term of minimizing the DAC clock jitter at least in theory because there is no longer a coupling mechanism between the DAC clock and the incoming data. The trick I guess you need to read the data from the disk much faster than you clock the data out of the memory to the DAC. Maybe because of this, Chord DAC offers a very large memory buffer to minimize memory underflow. Given most songs are about 5min long, the worse case is you may have to wait a few seconds between each song to wait for the buffer to fill up. But there still will be a lot of classical tracks that much longer so I guess the Chord DAC still need some type of forwarding mechanism in case of underflow.
The other way to minimize jitter comes from DCS which they called "reverse clocking". Basically the main clock is used to clock the DAC and local to the DAC. This clock is then distributed to the transport which is then used to control the disk mechanism. So with just one clock, everything is supposedly synchronized so there won't be any need for retiming. I think you still need to do some type of phase aligning, but this phase aligning probably won't be as bad as a full retiming.
By now, at least with respect to jitter, you can see how a musical server can lessen this jitter greatly because a the server doesn't have to deal with a lot of problem a cdp due to the freedom of where and how you get the data.
... more next post ...
As you can probably guess by now, with a music server, a lot of this jitter can be minimized. Redbook cd native sampling rate is about ~44khz. Even with most DAC, the upsampling rate is 196K or a little higher but not much. Although the DAC system clock is usually a lot higher than the sampling rate, you can use a small amount of memory buffer and memory nowaday is pretty fast and cheap, you probably won't have any underflow issue. Even reading data from the hard drive, the hard drive bandwidth is fairly high, so underflow is probably not any issue either.
I've read the brochure of NAIM HDX music server that even when the unit is played from the cd disk, it seems that the data first ripped from the disk to the memory before playing. So maybe they are aware of this problem too.
Even when the data comes from a USB cable from an external server, usb cable can run fairly fast, up to Gbs of data, and as long as you can have an adequate amount of memory buffer, you should be OK.
So with a music server architecture, now you can de-couple the DAC clock from the data more easily vs. a cdp.
The other advantage I can see is for those audiophiles who are into high resolution format such as super audio. I mean the problem has always been distribution and compatibility. With a central music server, you can bypass these two. I don't thing there was any problem with recording or recording equipment. It's always a matter with getting high resolution format to the end user. But it will be easier if these can be stored somewhere, like iTune, things can be download like any other music formats.
You will probably need two DAC's, one for super audio format and one for regular redbook but that is an easy problem. Or both can be implemented in one DAC and there will be a separate path for each format. But as all things in high end, having dedicated DAC for each format is still the best.
Like any other audiophiles, before I was lamenting that everything is getting digitized and audio qualities will be suffered, but having sometimes to think about it, it seems more like you can actually have the cake and eat it too.
I've read the brochure of NAIM HDX music server that even when the unit is played from the cd disk, it seems that the data first ripped from the disk to the memory before playing. So maybe they are aware of this problem too.
Even when the data comes from a USB cable from an external server, usb cable can run fairly fast, up to Gbs of data, and as long as you can have an adequate amount of memory buffer, you should be OK.
So with a music server architecture, now you can de-couple the DAC clock from the data more easily vs. a cdp.
The other advantage I can see is for those audiophiles who are into high resolution format such as super audio. I mean the problem has always been distribution and compatibility. With a central music server, you can bypass these two. I don't thing there was any problem with recording or recording equipment. It's always a matter with getting high resolution format to the end user. But it will be easier if these can be stored somewhere, like iTune, things can be download like any other music formats.
You will probably need two DAC's, one for super audio format and one for regular redbook but that is an easy problem. Or both can be implemented in one DAC and there will be a separate path for each format. But as all things in high end, having dedicated DAC for each format is still the best.
Like any other audiophiles, before I was lamenting that everything is getting digitized and audio qualities will be suffered, but having sometimes to think about it, it seems more like you can actually have the cake and eat it too.
Last edited:
Hi,
One thing You forgot to mention imho is the fact that a CD player reads the data just once.
To prevent music from cuts due to readout failures the error correction had been implemented.
Reading from HDD or other memory must be free of failures.
A decent server makes use of caching data and typically the cache is much larger than the memory applied in CD players.
With 1.5GB as we use in our servers, roughly 2 complete CDs can be cached in wav format, whereas CD players cache only for a couple of seconds.
The small cache is perfectly sufficient if one plays one track after the other.
Due to the Memory beeing much faster -wether HDD or a solid state memory doesn't matter- the target time is much faster -and its required to be larger and faster, as the amount of data/number of tracks is immensely higher (talking of target times of <1sec for up to 1mio tracks).
The other points You mention are technical matters of the DACs, which may be implemented in both CD-Player as well as music servers.
Imho the most remarkable difference between CD and Music server is the amount of Data and the amount of functionality.
Both are issues of the control system. Its of prime importance how a music server is (remote) controlled. How is data managed, how are search functions implemented, etc, etc.
Unfortunately alot of systems on the market suck in this regard.
Those who own a decent music server for sure won't ever return to CD again.
Imho CD is a media short of the end of its lifespan ... its dead already ... just a few who haven't noticed yet 😛
jauu
Calvin
It not only seems so, but factually is so ..... well, at least when using a decent music server. 😉
One thing You forgot to mention imho is the fact that a CD player reads the data just once.
To prevent music from cuts due to readout failures the error correction had been implemented.
Reading from HDD or other memory must be free of failures.
A decent server makes use of caching data and typically the cache is much larger than the memory applied in CD players.
With 1.5GB as we use in our servers, roughly 2 complete CDs can be cached in wav format, whereas CD players cache only for a couple of seconds.
The small cache is perfectly sufficient if one plays one track after the other.
Due to the Memory beeing much faster -wether HDD or a solid state memory doesn't matter- the target time is much faster -and its required to be larger and faster, as the amount of data/number of tracks is immensely higher (talking of target times of <1sec for up to 1mio tracks).
The other points You mention are technical matters of the DACs, which may be implemented in both CD-Player as well as music servers.
Imho the most remarkable difference between CD and Music server is the amount of Data and the amount of functionality.
Both are issues of the control system. Its of prime importance how a music server is (remote) controlled. How is data managed, how are search functions implemented, etc, etc.
Unfortunately alot of systems on the market suck in this regard.
Those who own a decent music server for sure won't ever return to CD again.
Imho CD is a media short of the end of its lifespan ... its dead already ... just a few who haven't noticed yet 😛
jauu
Calvin
Buffering data is not new and has been done by some advanced CD players for quite some time. but in terms of Music sever vs CDP, just talk to the electronics engineers at DCs, Esoteric, Accuphase, Burmester etc and ask them why their very best transports are CD players and why they do not make music servers/streamers. The answer will be because they can still get better SQ from CD players.
The problem that music servers have had since people started looking for alternatives to their CD players was an immediate assumption of inferiority of CD players because they came before the average home PC. This attitude has severely hampered real developments in music servers. On this very forum there are people who believe to this day that standard PC is a perfect source for digital audio with all its SMPS, RFI/EMI etc thrown in.
It is true that decent music servers have surpassed so many CD players in performance but in terms of state of the art, there is still a way to go . The lack of industry standards and the reliance on USB are just a couple of impediments to server based devices being able to outperform the very best CD transports.
Hi,
We've had workshops and shootouts against the all of the 4 and I can assure You that sound quality was not the only parameter where they lost.
I'd rather assume that all 4 companies -who certainly belong to the top notch brands- realized that a control (App) that would be Sota and up to their level of quality thinking simply costed them too much.
See Burmester's server price nearly doubling and their App is still rather far off of what's possible.
jauu
Calvin
rotfl rotfl oh yeah, of course sound quality 😛
We've had workshops and shootouts against the all of the 4 and I can assure You that sound quality was not the only parameter where they lost.
I'd rather assume that all 4 companies -who certainly belong to the top notch brands- realized that a control (App) that would be Sota and up to their level of quality thinking simply costed them too much.
See Burmester's server price nearly doubling and their App is still rather far off of what's possible.
jauu
Calvin
I think we also should separate out what is fundamental architecturally and what is implementation dependence. I am not sure what you were really saying but all the noise, "SMPS, RFI?EMI" are all implementation issues that would be the same either for cdp or server. They both have to deal with those things. In term of architecture, I really don't see any fundamental advantage of a cdp over the server, and if anything, the server does lend itself better to making a better system. I mean a badly designed server is still a bad server just as a bad cdp ....
It may be true that the very best cdp's out there still outperform the best servers because I suspect that those very high end cdp are still no cost objects whereas some of the very best servers are still somewhat affordable so those servers are still being made to a price point. Overtime, with confidence that more end users, especially high-end, are adopting the new server format, I think you will be more expensive servers that will have better performance.
And for SACD lovers, I still think servers is the way to go. It will be much easy to obtain SACD format through downloading and probably cheaper too. Actually, even with redbook format, you can write an app that converts a regular redbook into SACD format and potentially can improve the sound and I wouldn't be surprised if some of the very high end servers are already doing that.
I still think there are quite a bit of development in the servers. It looks like both manufacturers and consumers are still sort of tip toeing into the field and once there starts to have a much wider acceptance of the format, I think we'll much even better performance servers on the market.
As you said, on the software side, there seems to be a lot more that can be done in the data processing in term of error correction, format upsampling, compression ...., and obviously there's nothing fundamentally that a cdp can't do these things, but with a full fledged servers, it will be easier.
As for the DAC, I still thing for high-end stuffs, there can be a lot of improvement. A lot of the off the shelf DAC still use serial input data, which does save a lot of pin count and cost, but the down side is you have to run the clock a lot faster which leads to more jitter and noise. If you can implement a DAC with a parallel data input, you can reduce the clock much less will ultimately reduce noise, but of course at the expense of higher pin count, but for higher end servers that shouldn't be a problem.
Last edited:
Hi,
there will be more development, yes, as new hardware components appear on market on a nearly daily basis.
I assume that in future maybe dedicated controller boards will emerge, that allow a certain reduction of costs, similar to those cheap linux boards one finds in the streaming clients.
But equipped with HDD memory and optical drives a server will always cost more than a client or a CDP.
As You mention correctly, there are not many fundamental differences between a CDP and a server.
The CDP is only restricted to one data format supplied by a optical drive.
Its hardware reduces to control- and readout electronics and a DAC
A music server allows to handle and play basically any format from any source, even analog when A/D converters are built in, and allows to export data to many kinds of memory devices.
Depending on built-in calculation power software based DSP functionality may be implemented (brute fir, speaker equing, room correction, etc.)
The same power allows for multirooming, hence the ability to supply multiple clients with different streams at the same.
etc. etc. etc.
All this and the huge amount of data and functionality requires advanced control software and I keep on to stress that this is the most important point differentiating between decent servers and those that ... well ... could do better.
The control software is where a huge amount of development resources go into.
And this is far beyond what most HiFi companies could develop on their own.
jauu
Calvin
there will be more development, yes, as new hardware components appear on market on a nearly daily basis.
I assume that in future maybe dedicated controller boards will emerge, that allow a certain reduction of costs, similar to those cheap linux boards one finds in the streaming clients.
But equipped with HDD memory and optical drives a server will always cost more than a client or a CDP.
As You mention correctly, there are not many fundamental differences between a CDP and a server.
The CDP is only restricted to one data format supplied by a optical drive.
Its hardware reduces to control- and readout electronics and a DAC
A music server allows to handle and play basically any format from any source, even analog when A/D converters are built in, and allows to export data to many kinds of memory devices.
Depending on built-in calculation power software based DSP functionality may be implemented (brute fir, speaker equing, room correction, etc.)
The same power allows for multirooming, hence the ability to supply multiple clients with different streams at the same.
etc. etc. etc.
All this and the huge amount of data and functionality requires advanced control software and I keep on to stress that this is the most important point differentiating between decent servers and those that ... well ... could do better.
The control software is where a huge amount of development resources go into.
And this is far beyond what most HiFi companies could develop on their own.
jauu
Calvin
I agree but from an engineering stand point the hard ceiling is determined by the hardware design but the sound can be optimized by the software development. That is not my personal opinion. I think most engineering organizations will come to that conclusion if they've gone through the development process.
Someone on the movie business said the one can make a bad movie out of a good script but one can never make a good movie out of a bad script. As a kid, I was an die hard Lakers fan and obvious Magic was the star of the show and credited with making all his players better whether that was true or not. Then came along Charles Barkley who I always enjoyed not only as a player but a personality with his always dry humor post game interview. He's a good player but his team wasn't as good as the Lakers and he sort of got pissed of sometimes when people criticized him for not helping the team as much as Magic. Charles one day finally said well Magic didn't make his team good. Magic already had good players to begin with and he just improved upon them, while I (Barkley) can't make a bad players into good players risking alienating his teammates.
Someone on the movie business said the one can make a bad movie out of a good script but one can never make a good movie out of a bad script. As a kid, I was an die hard Lakers fan and obvious Magic was the star of the show and credited with making all his players better whether that was true or not. Then came along Charles Barkley who I always enjoyed not only as a player but a personality with his always dry humor post game interview. He's a good player but his team wasn't as good as the Lakers and he sort of got pissed of sometimes when people criticized him for not helping the team as much as Magic. Charles one day finally said well Magic didn't make his team good. Magic already had good players to begin with and he just improved upon them, while I (Barkley) can't make a bad players into good players risking alienating his teammates.
Last edited:
It's very easy to say, "The best CD players sound better than the best servers.". However, it is somewhat harder to prove that. I would be interested in seeing a blind comparison between any major or SOTA CD against any of the better server systems. Much of what I see written about the superiority of one "thing" over another seems to totally disappear when the listener doesn't see which one he or she is listening to.
My experience is that the sound from my CDs on a decent player sounds no different from what I hear from my Linux server, played via MPD or on a Windows PC with any of several different software packages. For me, the convenience has won the day.
My experience is that the sound from my CDs on a decent player sounds no different from what I hear from my Linux server, played via MPD or on a Windows PC with any of several different software packages. For me, the convenience has won the day.
Hi,
yes, there's no reason to assume superiority of any of both technologies so far as CD standard 16Bit/44.1kHz wav is played.
A server has the edge when it comes to higher resolution formats, that a CDP can't play.
If a CDP features a DAC with additional inputs, allowing play back of HR material, the management of data is plain crap.
jauu
Calvin
yes, there's no reason to assume superiority of any of both technologies so far as CD standard 16Bit/44.1kHz wav is played.
A server has the edge when it comes to higher resolution formats, that a CDP can't play.
If a CDP features a DAC with additional inputs, allowing play back of HR material, the management of data is plain crap.
jauu
Calvin
Funny, no server advocate has addressed the backup issue.
It just takes one lightning stroke into a power line to terminate any server for good.
Has anybody heard of a mirrored terabyte server in home environment?
Hardly.
With CD and vinyl you have still got everything you had.
With a server with no backup plan and possibly discontinued download service...
It just takes one lightning stroke into a power line to terminate any server for good.
Has anybody heard of a mirrored terabyte server in home environment?
Hardly.
With CD and vinyl you have still got everything you had.
With a server with no backup plan and possibly discontinued download service...
Um, sorry to disappoint you on server backup.
My active music files live on a Solaris system that is also my mail server.
I have two WD NAS drives I use for backup. My music is backed up weekly to both systems. I have a whole-house surge suppressor, and have yet to loose any data, even with drive failures. . .
Plus, most of my music came from ripping my CD collectioin, which I still have. Much of the rest is on vinyl that I've ripped, and I still have that, too.
I'm not really worried about loosing my music archives.
3 and 4 terabyte NAS boxes are actually pretty inexpensive.
My active music files live on a Solaris system that is also my mail server.
I have two WD NAS drives I use for backup. My music is backed up weekly to both systems. I have a whole-house surge suppressor, and have yet to loose any data, even with drive failures. . .
Plus, most of my music came from ripping my CD collectioin, which I still have. Much of the rest is on vinyl that I've ripped, and I still have that, too.
I'm not really worried about loosing my music archives.
3 and 4 terabyte NAS boxes are actually pretty inexpensive.
Backups on NAS kept remotely (caddy at friends house so even in house burns down don't lose everything). Secondary backup from original CDs. So all good. Having a mirrored drive is not backup.
Hi Guys
Very timely for this discussion cause Im just moving into this.
Wouldn't an SD card player be a good bridge between the 2 media ?
Very timely for this discussion cause Im just moving into this.
Wouldn't an SD card player be a good bridge between the 2 media ?
As a long time advocate of pc audio a claim like this upsets me, but alas there is a lot of truth behind it.
Even the best implementations of server based audio using multiple stages of reclocking and galvanic isolation, independent clock domains and practically negligible jitter do sound distinctly different to a good CD player. Yes, the sound can be extremely transparent, but somehow lacks substance, punch, meat on the bones and is too ephemeral for some types of music. In the prat department there is also room for improvement.
Why is this so? Don't have a clue. Maybe CD players suffer less power line/radiation noise pollution? And if CD transports are overly sensitive to vibration tweaks and coloring of the cd edges, then PC audio is sensitive to EVERYTHING. USB cables, PC power supplies, PC hardware, BIOS settings, OS types and tweakings, player software.
PC audio is a tweakers paradise and this really cannot be a good thing.
- Status
- Not open for further replies.