Who said anything about one box solutions? None of the servers/file player I would recommend have on board DACs.
And MOST of the RF/EMI being emitted from computers is from the garbage power supplies, display, etc.
Merlot DAC and Syrah Music Server
- Thread starter Bruce B
- Start date
Who said anything about one box solutions? None of the servers/file player I would recommend have on board DACs.
And MOST of the RF/EMI being emitted from computers is from the garbage power supplies, display, etc.
Can I convert a .flac file ripped from CD to a DSD256 file and store it using HQplayer? Are there other software programs doing the same job?
Sorry, I misinterpreted you
The computer will never leave the listening room, it'll be there in different disguises, be it streamers, NAS or traditional computers.
You must do it on the fly with HQplayer. And it's CPU intensive. I've tried other offline conversation software, but they simply don't have the algorithms as good as Jussi at HQPLAYER does. However I had Jussi offline convert 3 redbook tracks for me to DSD 128. I copied them to SD card to play in my Mirus DAC, and they sounded stunning. So I wish he would make offline conversion software. This way powerhouse computers won't be required. But file sizes of DSD 256 are huge, so lots of storage required.
There is no doubt that purpose built digital audio file players are computers.
But they are PUROSE built by AUDIO engineers, not computer engineers. The are optimized to do one thing only.
My dish washer, cell phone, and even my car are computers at this point.
Even going back 10 years, CD players were computers with optical transports.
The bottom line is any computer, which goes on a desk top or on a lap, that sends email, browses the web, and hosts full applications, will
never be SOTA for audio, even with all the so called optimizations, aftermarket software, etc.
Agree on your last sentence, disagree about audio engineers being most suited building computers for audio. Computers should be designed & built by computer SME's based on requirements, in this case audio engineers.
I think we have seen the enough of the results of computer engineers designing audio products. It ain't pretty.
it might be interesting to compare redbook or even dsd64 files upconverted to dsd256 by HQplayer with those same files up converted to dsd256 by Channel Classics or other dsd centric recording labels. might these pro's outdo the freeware from Jussi?
I have a bunch of those upconverted dsd64 to Quad files. but none redbook to Quad.
You're missing the requirement part of my post, let's leave it at that ...
/Enjoy weekend
Lars
No worries, btw, the gear you list is quite interesting. How do you like the Audio GD DAC? I've wanted to try one.
Well, let's examine one of these embedded systems and figure out if that is the case. I believe you are a fan of Bryston BDP-2, yes? If so, I searched and could not find a high-resolution picture of its inside. But there was one at reasonable size that I could analyze and annotate. Here it is:
As shown, the board on the left is the power supply and the board on the right is the computer. Below the power supply board we see a rather large toroidal transformer leading one to think this devices uses a linear power supply. Indeed we see a rectifier and a pair of regulators/transistors on the right. But smack in the middle is a Mean Well (chinese company) 5 volt switchmode power supply! Its input is mains at 120 volts so it will be whaling all out, triggering worries people have about such devices.
From the low resolution I can't quite tell whether it is there just to power the front panel or the main CPU board. But whatever it is, it is generating noise.
The output of the power supply board is that gray cable carrying power to the CPU motherboard on the right. Note the path that is taking. It goes right over that little board that produces AES/EBU and S/PDIF digital output from the machine!!! That cable is unshielded as power cables usually are so not only could it be carrying noise from the power supply, it can also pick up noise from the computer side and radiate that out onto the digital audio output.
This is pretty poor design hygiene for an audio equipment. It is what a computer designer would do that doesn't know audio. The fix would have been dead simple: a slightly longer cable travelling in the front of the CPU board.
Another miss is where it goes on the CPU board. Notice that is almost touching the aluminum silver heatsink for the CPU! I have indicated that with a second arrow. That heat will degrade that cable over time. Is it a big deal? No. But these are the things that separate great designs from working designs.
Back to power supply, we see a coil on the right on the main CPU board. That tells me that there is another switchmode power supply on the CPU motherboard generating all the other voltages that board/CPU require. I can't be quite sure without higher resolution image or access to the board but there is high likelihood this is the case. If so, then there is no notion of a "linear power supply" here. You have two switchmode supplies creating the noise that they do which gets telegraphed to that power cable and run over the digital audio output.
The main "boot drive" for Linux is a compact flash. This is a common approach in embedded systems which assumes that the drive only gets used to boot and for infrequent access by the system. It is a rather poor choice in my opinion here. This is an audio server and that storage is used to cache/store all the activities of the system. That CF file will get far more use here than it would be in a typical embedded system. That causes two issues: slower access/response from the system and eventual demise of that Flash memory due to limited write cycles.
When we build computers we use SSDs which are designed for high-performance and much higher endurance. CF cards may not apply although you could use them just the same if you really wanted to.
At high level, there is no magic here. There is a computer and power supply, running an operating system. Its hardware design is "OK" but nothing remotely like a high-end piece of audio electronics. There should be no assumption that by mere design in this manner, it can provide superior digital audio out of its digital ports.
Well, let's examine one of these embedded systems and figure out if that is the case. I believe you are a fan of Bryston BDP-2, yes? If so, I searched and could not find a high-resolution picture of its inside. But there was one at reasonable size that I could analyze and annotate. Here it is:
As shown, the board on the left is the power supply and the board on the right is the computer. Below the power supply board we see a rather large toroidal transformer leading one to think this devices uses a linear power supply. Indeed we see a rectifier and a pair of regulators/transistors on the right. But smack in the middle is a Mean Well (chinese company) 5 volt switchmode power supply! Its input is mains at 120 volts so it will be whaling all out, triggering worries people have about such devices.
From the low resolution I can't quite tell whether it is there just to power the front panel or the main CPU board. But whatever it is, it is generating noise.
The output of the power supply board is that gray cable carrying power to the CPU motherboard on the right. Note the path that is taking. It goes right over that little board that produces AES/EBU and S/PDIF digital output from the machine!!! That cable is unshielded as power cables usually are so not only could it be carrying noise from the power supply, it can also pick up noise from the computer side and radiate that out onto the digital audio output.
This is pretty poor design hygiene for an audio equipment. It is what a computer designer would do that doesn't know audio. The fix would have been dead simple: a slightly longer cable travelling in the front of the CPU board.
Another miss is where it goes on the CPU board. Notice that is almost touching the aluminum silver heatsink for the CPU! I have indicated that with a second arrow. That heat will degrade that cable over time. Is it a big deal? No. But these are the things that separate great designs from working designs.
Back to power supply, we see a coil on the right on the main CPU board. That tells me that there is another switchmode power supply on the CPU motherboard generating all the other voltages that board/CPU require. I can't be quite sure without higher resolution image or access to the board but there is high likelihood this is the case. If so, then there is no notion of a "linear power supply" here. You have two switchmode supplies creating the noise that they do which gets telegraphed to that power cable and run over the digital audio output.
The main "boot drive" for Linux is a compact flash. This is a common approach in embedded systems which assumes that the drive only gets used to boot and for infrequent access by the system. It is a rather poor choice in my opinion here. This is an audio server and that storage is used to cache/store all the activities of the system. That CF file will get far more use here than it would be in a typical embedded system. That causes two issues: slower access/response from the system and eventual demise of that Flash memory due to limited write cycles.
When we build computers we use SSDs which are designed for high-performance and much higher endurance. CF cards may not apply although you could use them just the same if you really wanted to.
At high level, there is no magic here. There is a computer and power supply, running an operating system. Its hardware design is "OK" but nothing remotely like a high-end piece of audio electronics. There should be no assumption that by mere design in this manner, it can provide superior digital audio out of its digital ports.
here we go again. fasten your chin straps.
what's the over/under on the post count?
here we go again. fasten your chin straps.
I'm out.
here we go again. fasten your chin straps.
So am I ...
FWIW a friend of mine and I some years ago (2011 by memory) converted 3 natively recorded DSD64 files to PCM 16/44, 24/44, 24/88, and 24/176 and played them randomly back to each other blind.
We used Weiss Saracen for the conversion and paid particular care wrt dithering etc.
Neither of us could reliably distinguish between the DSD file and the higher bit rate PCM conversions. ie 24/88 and above. 16/44 could be reliably distinguished from 24/88 and above and unreliably from 24/44.
The playback system was fairly modest by the standards here, but at the time fairly good: a MacBook Pro running A+ & firewire > Mytek 192 DSD > Australian made active monitors (SGR CX3B), but we felt it was revealing enough for our purposes.
I have not done it the other way - converted a PCM file to DSD 64 or 128, but may do so in the future and cf a native DSD file of the same piece.
FWIW2 - servers are just computers, with a design goal in mind of clean power to the mobo, USB or spdif/AES out and either a minimum of processes and overhead (low drawer linux based units) or a minimum number of processes but with high overhead (high draw windows based units). No magic there IMHO, having built many servers over the years. I have heard numerous commercial offerings - some good, some great and some fairly disappointing, at least to my ears and with the auditioning equipment. There can be no question that the hardware choice influences sound outcome via USB (the specific recipe of hardware is the reason for the sound quality achieved with the Antipodes server, which runs atm the open source Vortexbox) , and perhaps spdif/AES, but IME far less so with firewire and ethernet protocols.
There is no question with USB servers that local storage on SSD's with and OS on SSD (or high read/write SD card) have yielded the best SQ for me to date. That said there is nothing wrong with the sound I have from my MBA running A+ USB to my dac. Albeit no doubt it could be improved by a decent reclocker and isolator eg an external SOtM tx USB Hubln (external).
While ubiquitous, I am far from sure data transfer via USB is necessarily the best protocol. Ethernet and FW (and to a lessor extent thunderbolt) appear to offer advantages to USB which seem apparent in listening tests I have done over the years. But, and it is a but, I rather think it all depends on the implementation of the protocol rather than the protocol per se.
We used Weiss Saracen for the conversion and paid particular care wrt dithering etc.
Neither of us could reliably distinguish between the DSD file and the higher bit rate PCM conversions. ie 24/88 and above. 16/44 could be reliably distinguished from 24/88 and above and unreliably from 24/44.
The playback system was fairly modest by the standards here, but at the time fairly good: a MacBook Pro running A+ & firewire > Mytek 192 DSD > Australian made active monitors (SGR CX3B), but we felt it was revealing enough for our purposes.
I have not done it the other way - converted a PCM file to DSD 64 or 128, but may do so in the future and cf a native DSD file of the same piece.
FWIW2 - servers are just computers, with a design goal in mind of clean power to the mobo, USB or spdif/AES out and either a minimum of processes and overhead (low drawer linux based units) or a minimum number of processes but with high overhead (high draw windows based units). No magic there IMHO, having built many servers over the years. I have heard numerous commercial offerings - some good, some great and some fairly disappointing, at least to my ears and with the auditioning equipment. There can be no question that the hardware choice influences sound outcome via USB (the specific recipe of hardware is the reason for the sound quality achieved with the Antipodes server, which runs atm the open source Vortexbox) , and perhaps spdif/AES, but IME far less so with firewire and ethernet protocols.
There is no question with USB servers that local storage on SSD's with and OS on SSD (or high read/write SD card) have yielded the best SQ for me to date. That said there is nothing wrong with the sound I have from my MBA running A+ USB to my dac. Albeit no doubt it could be improved by a decent reclocker and isolator eg an external SOtM tx USB Hubln (external).
While ubiquitous, I am far from sure data transfer via USB is necessarily the best protocol. Ethernet and FW (and to a lessor extent thunderbolt) appear to offer advantages to USB which seem apparent in listening tests I have done over the years. But, and it is a but, I rather think it all depends on the implementation of the protocol rather than the protocol per se.
My son is having my Audio-Gd Ref 5 (4*PCM1704UK R2R chips) now in his system, I'd say it's a medium performance DAC. The designer has not been able extract the possibilities of the PCM1704 DAC chip, most likely a blueprint of the standard BB implementation. I've upgraded mine from adaptive USB to asynch.
That mirrors my experience as well with Audio Gd product (eg the Reference 7) - they make very good mid fi products but are not what I regard as higher tier product. Good but not great is how I would categorise it. But even their entry level kit offers amazing value for money, however, and you get alot of sound for £, and alot of pounds for your $$ (just about everything Audio Gd makes is huge and heavy). I don't think Kingwa makes a bad product.
Similar threads
