My music server is basically a Windows PC that I assembled from component parts using a small form-factor case, medium price motherboard, i7 CPU, 8 GB of RAM and and SSD for programs. I use a NAS for storing and streaming my ripped music files to the server and my PS Audio DirectStream DAC. I later added a JPlay USB output card designed specifically for music that made a significant improvement in sound quality. Otherwise the computer is dedicated for music and only necessary programs required for music playback have been installed on the server. I believe this combination has been effective for music playback, and all things considered, has been a relatively low cost approach for a dedicated server. However, my system is several years old, and includes cooling fans which possibly introduce potential impact to sound quality. I believe the best music servers tend to be fanless. I have compared my server to a MAC mini that I configured specifically for music hoping it would sound better. I found the MAC mini to be inferior to my current server and this was before I added the JPlay USB output card to my server. I have also done comparisons to several laptops with the same result - laptops always seem to be deficient for music playback even when compared to the desktop PC (not dedicated to music) that a friend uses in his system. In every case, comparisons were done using the same music files and playback programs configured identically on each computer.
I intend to compare the Roon Nucleus along with a few other dedicated music servers to find a better sever for use in my system. It is entirely possible that the simplicity of these newer servers may change my rankings of playback programs, but until that is done, my preference for jRiver is based on my current music server. I can appreciate how each of us can have different rankings for these playback programs given the variability in music servers and DAC combinations. This is an arena that is not fully explored compared to other components in our music systems. Optimization of digital output is still not fully understood generally within the industry. For example, PS Audio continues to refine the sound of their DirectStream DAC via firmware updates, which is a feature that is unique among DAC manufacturers. I have heard several iterations of their firmware updates and continue to be amazed at the improvements these updates have wrought in my system. Ultimately, we have to trust our own ears when selecting the hardware/software that sounds best in our own systems.
For what it’s worth, I routinely attend the Rocky Mountain Audiofest (RMAF) held annually in Denver (I am also a member of the Colorado Audio Society which provides volunteer support for the RMAF). The RMAF is one of the best place to hear the latest equipment available in the high-end audio industry with about 400 rooms displaying nearly everything imaginable in high-end audio. Although it is difficult to configure systems for optimal playback in the confines of a hotel setting, it is nevertheless possible to evaluate overall sound quality. Still, I rarely find a music system at the show that compares favorably with my home system in the sound qualities that I find critical, including instrument/vocalist focus, ambience, transient decay, stage width and depth, general resolution across the spectrum, high frequency transient response, rhythm and pace, and overall musicality. This includes systems that cost upwards of $500k. I have discovered that some of the least expensive systems at the show sometimes make a greater impression.
The disks in my NAS cost £700. Not zero; seven hundred pounds.
You can can use reductive stats to try and make a point but it quickly becomes absurd. You can do the same things with RAM, GPUs, CPUs. At the end of the day, you’re doing man-maths: justifying expensive up-front purchases that in theory have low whole life costs, but often don’t because they’re upgraded before the end of their useful life in many cases.
Paul, AIFF was indeed created by Apple. Check the Wikipedia page. I was working for Apple back when it was created (though I had nothing to do with it). And if you want to be precise about it, Apple engineers based AIFF on a file format that Electric Arts had developed for their video games of the day (Amiga, Apple ][/Mac, and PC). ProTools came much much later.
Yes, I agree. I was in a high end audio store Morton Grove, IL (that narrow it down), and made a comment to their new sales guy that I though my home system sounded better than what I was listening to and his comment was kind of snobby stating how possibly could a system costing a third as much sound better. Well there are a lot of reasons that could be including many that are not really valid such as I like what I’m used to. But the answer surprised me. Instead of engaging me in a logical conversation exploring why I felt that way it was a in-my-face, “you must be wrong.” kind of answer. Not a very good sales man of high end audio equipment in my book.
ALAC = A[F]LAC; there is no big difference but they do use slightly different compression algorithms so require separate decompression algorithms. If one takes longer than another, the software that does the decompression has a design flaw and/or the hardware is woefully underpowered. Sorry, no other real explanation:
A design flaw or a buggy implementation can indeed have been the reason. It most probably did not have to do with the decompression workload. Skipping tracks did not cause significant differences but jump forward within the track did. Anyway my point was more about selecting the audio format based on the preferred software in use or the one that comes with the hw system as long as they are lossless. Lossless data compression should normally not be a problem with actual microprocessors.
I did not mean decompression load, I meant only supporting one standard fully with the assumption that the other didn’t matter, which is more of failure in the planning of the design than a bug per se, as a bug is an implementation flaw; but it could be either.
A bit late to this discussion, but I’m surprised that no one mentioned the metadata and verification pluses for FLAC vs ALAC. I was an ALAC/iTunes user for years for all releases while using FLACs for all the live recordings. I recently moved to Roon, and very slowly (no rush) have been making the effort to migrate the most important ALACs releases to FLAC solely for better metadata management and, most importantly, the ability to have embedded verification with FLAC fingerprints.
Both formats support metadata, but tools to manipulate FLAC metadata are much more prevalent and easier to use than those for ALAC. Finding a CLI tool to extract artwork from a FLAC is much easier than trying to find/do the equiv for ALACs. Extracting artwork from an ALAC that contains multiple images with ffmpeg is an exercise in computer science, whereas metaflac handles it relatively easily.
But for me, the most important difference is FLACs support for embedded md5 checksums, readily avail tools to create and verify those fingerprints, and FLACs support for changing the metadata without affecting the checksum/fingerprint. It’s the killer difference for me – it allows me to hack away at all things related to metadata and cover art while knowing that I’m not corrupting the media…something you can’t do with ALACs. I recently had Roon tell me that one of my oldest ALACs was corrupt (worth the cost of Roon alone to know this) and it took forever to go back far enough in backups to find a version before it was corrupted. It would have been so much easier to just check md5sums in FLACs rather than loading every version in iTunes/Roon to track down a good one.
Those two differences are worth the move from ALAC to FLAC for me. I’ve already written various tools to manage the live FLACs so it was an easy (and joyous) addition to add in the ALAC releases. Very happy to be all FLAC moving forward.
Luckily I decided 15 years ago when I started ripping my CD‘s to use the FLAC format for all the reasons mentioned. I never had to go back and re-rip anything. I would still take that route today.
FLAC is okay but AIFF or WAV still better since those are uncompressed lossless. Ever wonder why pro recording and mastering studios never use anything but AIFF or WAV?
They use uncompressed audio since they can seek directly to any audio frame, which is important in that environment. This is not an issue for regular playback.
People tend to think so however a real-time uncompress needs to be done with playing a compressed audio file. Even though all the bitrate is there and a compressed file is still technically lossless, there is some bit of quality loss experienced in that real-time uncompress. I know in my system I can have an ALAC and a AIFF of the exact same track and the AIFF sounds noticeably better.
Not point in arguing a religious war… Suffice it to say, I don’t subscribe to the religion.
But as previously stated in this thread, any perceived issue of decompression when using Roon is a moot point, since the Core decompresses and then sends it as raw PCM to the endpoint for playback. The endpoint is not doing any decompression.
Roon prebuffers ~5 seconds of audio to the endpoint. The decompression has zero impact. The decompression engine is stalling waiting on the endpoint, as it can decompress thousands of times faster than the endpoint can play it back at normal playback speed. You don’t even need a modern CPU for that.
