CD Ripper/Music Server Recommendations

Streaming Audio
121

This thread has remained very civil considering the material under discussion. Let’s hope it remains so and maybe we can all benefit in some way.

I’m all for open-minded logical discussion and I agree that even though most of us have no expertise in this area we can still learn from the different perspectives of others. I know I have anyway and I’m grateful for that.

The problems usually start when a few people start insisting that they ‘just know’ that a particular observed phenomenon cannot happen. Therefore those who experience it are suffering from some sort of psychological malady etc. etc.

This goes beyond disagreement, which in itself is absolutely fine and something I have no problems with at all. It is attacking the integrity of those people and insulting their intelligence. I admit I find that extremely ignorant and annoying. Someone telling me that they don’t hear what I do is one thing and absolutely fine. Someone telling me that I’m mistaken in what I hear, I’m suffering from ‘expectation bias’ or whatever I find irritating. Not per se, but rather because the people claiming things like expectation bias seem to fail to realise that they will be equally vulnerable, so their reasoning actually makes no sense at all.

Enough said.

3 Likes
122

Agree with your comments re civility etc.

I am quite looking forward to what @badger1 says in his more detailed post that I assume will follow fairly soon. As I said before my understanding is that assuming there is a bit perfect file as source then it is the slight technical variances (hardware, software and their combined operation) of the replay chain that give rise to the differences in what we hear.

That said I am happy to be further educated and obviously change/adapt my understanding as required.

2 Likes
123

I don’t recall ever reading such a suggestion in this forum.

However, what can make discussions difficult is when someone refuses to recognise the reality that bias or other psychological influences are real phenomena to which any of us might be subject without knowing, so for any reasoned discussion of an abnormal/novel observed occurrence (e.g. difference in sound) some form of verification of the occurrence is appropriate. That absolutely is not, and indeed is fundamentally different from, saying or suggesting that the observer is mistaken or wrong: Even if the observation is the result of, or modified by, some psychological influence, it is no less real for the observer, and can legitimately be the basis of said person’s choices and enjoyment. Unfortunately some people don’t like even a hint that their hearing is not a perfect objective measure and can’t accept even the possibility that they could be subject to any psychological influence whatsoever, and get aggressive when the subject is raised.

Anyway, this is a matter for a thread on the subject, and not helpful to thd OP in this yhread.

3 Likes
124

Software engineering (continued) as promised. I hope this helps everyone. If not feel free to ignore it.

So, software engineering is a process of matching desired outcomes to expected outcomes and then to actual outcomes. As I mentioned earlier, in order to do that software engineers live in a world of logic, trust and problem determination. The logic is that they breakdown the desired outcome into manageable chunks and then code the expected results (we call them acceptance criteria which are basically expected behaviours) as a series of highly logical instructions that have very predictable behaviour- eg. assignments of variables , if then statements based on conditions etc.

To do this software engineers have to trust that other components in the system do their job. So for example, if I code something in the python language, I have to explicitly trust that the python kernel and libraries behave exactly as they are expected to behave. That in turn requires that the c language libraries it uses behave predictably and that the operating system file management code works too. Which in turn requires us to believe that the c compiler correctly creates machine code that works with a particular processor. And so on and so on. Crucially this spills over into code created in the infrastructure world. And then the physical operation of hardware devices and networks.

Software engineers test that the code they write meets the acceptance criteria or behaviour. And then they start working out whats gone wrong based on the evidence they can see and crucially the balance of probabilities. So their testing process can miss things, especially outside the domain of their experience. Sometimes it needs user input to find things. Mostly they find defects with their own tests. Whatever, they act based on probabilities.

So if the code doesn’t do what they expect, they will investigate their own code first. And 99% of the time fix it there. Then they will begin to suspect other components based on balance of probabilities. How feasible is it that component x is not working as expected? They will try to reproduce a potential defect or unexpected behaviour in the suspect component and confront the team that develops or maintains that component. And so on…

I explain all this because it means that somethings in a system have a reasonably high probability of being a problem - in my case, especially my own code!!! :rofl:

Other components can have a rapidly diminishing probability of being a problem based on how frequently it is used and sometimes based on how long and how well the team builds and tests that component. That probability approaches but never reaches zero for some things that are so well tested and used by 1000s of systems. But its never really zero as defects due to poor processes or design decisions can always emerge. The recent crowdstrike outage proves that. Windows allows the kernel to be updated by software in certain conditions. Hey presto that went wrong with an untested software upgrade.

I say all this because you mention a result you heard and attribute it to ‘identical accurate rips being the same but sounding different’. You were probably asked to compare that the files were in actual fact identical as the first step in problem determination. If you didn’t do this, the problem determination process ends there. And a software engineer will walk away and find something better to do.

This is because a software engineer implicitly trusts the lower level code such that when two files are identical at the bit level they will behave in an identical way in a closed system of logic. If they didn’t believe this, their world would come crashing down as in fact would every computer system in the world. It would be armageddon mixed with apocalypse now and we would be all bashing stones together to light fires! :rofl:

So lets examine the ripping process again. The music was captured and converted into a digital file using the pcm format at 16bit 44khz. The software engineers who built the software to do this relied on software libraries that handle pcm files with predictable behaviours and therefore it was trusted. They also relied on and trusted the operating system libraries that copied the file from one hard drive to another. And crucially the libraries to read it back into memory. So far so good.

Then it goes wrong. The digital file is encoded onto a file storage medium called a cd that is nothing like as reliable as the low level file system code they trust when they read the file from a hard drive.

The process of recovering that data from the cd is not a trusted process. Its is inherently unreliable. So when the cd is ripped, it is quite unpredictable if the data is actually ripped accurately. By accurately I mean if you were to compare the pcm file you have created to the original pcm file used, it would be an identical match. There are factors that improve the chances of the rip being accurate and being an identical match to the original pcm file. A better optical drive or transport is one. Error detection code at the optical drive level and software that uses those features to check if the sectors might be bad and trigger actions to re read multiple times and take the most commonly recovered results etc. So different rips at different times and with different methods have the potential to be different and sound different.

But because we do not have access to the original pcm file we can’t actually compare the file to the original pcm file. So we have no way of validating the file and calling it an accurate rip. If the file is ripped by two different processes and drives and produces different files at the bit level it is definitely the case that one of the two (or both!) are inaccurate. But which is it? There is no way of knowing.

Ok enter accurate rip. This is a software engineering challenge. How do I without having access to the original pcm file, validate that it is correct and a match? Their solution was simple and brilliant. You crowdsource the results from multiple rips of a cd by different people and store it in a database. If 2 people with different optical drives and physically different cds rip the same version of a cd and it has the exact same checksums, the probability that they are both accurate rips just went up dramatically. If the results from 3 users in different parts of the world agree it goes up even higher. And so on. At say 20 identical files we have to be as close to being certain as it is possible to be in system engineering terms that we have a rip that is identical to the original pcm file. Unless there is a bug in the ripping software itself of course.

That is why I called it the gold standard software ripping solution. It means that if 100 people have ripped the remastered version of Dire Straits ‘Brother in Arms’ and they agree on the checksums we can be close to being certain that the file is identical to the original pcm file used to create the cd. That degree of probability is what I and some others who have used this software have been calling an accurate rip.

The byproduct of this simple and genius engineering solution is that the quality of the optical drive no longer matters much. If it gets a rip that matches what 100 different people got when they ripped the cd, my trust has gone from low to very very high. There are other great reasons as Dunc rightly mentions to get a good optical cd transport if you intend to continue to play the cds into a DAC. In my case the cds are gathering dust in the loft.

So my question is simple. Does the software bundled in the various ripping solutions you have been using, utilise the above accurate rip software engineering solution or something similar to handle the inherent unreliability of cds? I don’t know the answer to that question I am afraid. But I begin to suspect at least like me the earlier ones you used did not, especially if you are hearing differences between the rips.

So I hope that helps you and others when it comes to ripping. A rip becomes an ‘accurate rip’ when the result produced is matched to the result produced by lots of people. It is the best proxy we have to trust it matches the original pcm file.

It’s why I think some of us tried to say earlier this ripping game is actually really really really simple and really really cheap. You can get an accurate rip with a cheap optical drive, your existing pc and a few quid spend on a bit of software owned by dbpoweramp.

If the ripping solutions you have been using don’t use this technique to validate the result matches the original pcm, what makes a software engineer trust that the rip is actually a match to the original pcm file? Maybe they have a comparable genius software engineering solution? I don’t know. It’s a question you’ll have to ask them.

Anyway enough from me. For ripping, my recommendation is always going to be the accurate rip software mentioned above. It’s what I did years ago. I have moved on well beyond this and currently use Roon to seamlessly integrate my old cd collection, my recordings of vinyl done over the years and the qobuz streaming. And I love vinyl. I keep an open mind and always listen first but the software engineer in me puts me immediately into problem determination mode :rofl::rofl::rofl: If the result is not as expected what is the probable cause? I will tend to not go deeper into tracks that have low probability until the evidence becomes incontrovertible :grinning:

Above all keep enjoying your music and the hifi journey. :slightly_smiling_face:

PS todays demo was educational as they usually are. To my ears, the upgrade in sound quality from the old Klimax casing and layout designed in I think about 2008 and this one is truly remarkable. I for one will be getting a home demo into my 5 series amps asap.

8 Likes
125

Hi @badger1, many thanks for the words. If I’ve understood it correctly my understanding of the ripping bit is pretty much the same as you describe. I’ve used the “accurate rip” approach with dbpoweramp for many years. The words should help the OP with the ripping part of their question.
Are you, or maybe some other knowledgeable forumites, going to be brave and delve a little into the replay part as this is where I believe the OP will gain a lot of info/help in their search for a good music server. For me this is the hard bit for manufacturers to implement well.

Glad the demo went well, maybe a little change to your system after a home demo?

2 Likes
126

Thanks Orac. I will do my best tomorrow or Saturday and no doubt others will chip in!

Edit. I fear so (and so does my bank balance ) that an upgrade might be on the cards! We’ll see. As always I will decide based on my ears and general understanding of what might make things even better.

2 Likes
127

Ive been reading professional reviews of cd rippers/music servers over the last couple of weeks to short list what to demo and have now discounted Aurender, which leaves Innuos and Melco.
Reading the reviews of the Zen and Zenith it became apparant to me that the reviews never mention the capability to directly download bought music from websites like Bandcamp and HDTracks etc, which I would expect should be a must have option going forward with digital music, where-as the reviews of the Melco N50-S38 advised that this can be done and is a very good function.
I asked Innuos Customer Support about this and their engineer advised that its not a feature that they support but can be done via a file transfer App that supports SMB.
Im amazed that a leading company in music servers dont have this functionality fully supported and part of their Sense App, this seems to be a major omission to me.
Looks like the Melco is now the front runner for a demo for me now, with their native support for internet music downloads.
Would be interested to hear from Innuos users on their experience with downloading directly from the internet with file transfer Apps to understand if this is not a deal breaker.

128

I found an interesting post from @nbpf , in a thread on Core vs D100 :

„ The D100 rips sound definitely better than the Core rips but only if the D100 is mounted on a plarform whose vertical axis is nearly perpendicular to the axis of rotation of the earth. Melco warrants audiophile-grade perfect bit alignments of the bit sequences corresponding to the outer tracks of a CD only under these conditions. Melco are aware of the fact that that many D100 owners are not operating their devices at equatorial regions and that realizing audiophile-grade conditions at mid and high latitudes may be inpractical. They are working on a cost-effective solution of this problem. In the meanwhile, a simple workaround is to make two rips of the same album, one with the D100 in its standard position and one with the rotation axis of the D100 at 90 degrees from its standard position. A bitwise comparison between the rip obtained in the standard configuration and the rip obtained in the orthogonal configuration needs to be done via controlled A/B listening test to overcome the obvious limitations of MD5, SHA-1, SHA-256, and SHA-512 checksum comparisons. The orthogonal-ripping comparison procedure yields best rips that are bit identical to the rips obtained with the Core. But, thanks to superior, audiophile-grade bit alignment and to entanglement effects, the D100 rips sound less congested, more open and more fluid than the Core rips.”

1 Like
129

I don’t actually use this function of my N50-S38. If buying music from Qobuz I download to my Macbook and then transfer to the Melco using a USB stick. I hardly ever buy downloads though as I much prefer to rip CD’s on the D100. I’ve only downloaded a few high res albums and a few albums that were very rare and therefore very expensive in CD format.

If I was buying a lot of downoads then my method would become a bit of a faff I think so in that case this functionality would be important. If you do intend to buy a lot of downloads as opposed to buying the CD’s to rip then I think you’re right to be concerned here.

And to open yet another can of worms some people claim that music ripped from CD’s using the D100 ripper sounds slightly superior to the equivalent downloads. I’ve never done a direct comparison but given that the D100 makes slightly better sounding rips when using a Plixir power supply as opposed to the supplied SMPS and that it makes better sounding rips than a cheap drive I’ve no reason to doubt it.

NB. Those who believe that all bit-perfect rips sound identical can safely disregard the last paragraph. Any differences heard will only be imaginary.

1 Like
130

I of course can’t speak for anyone else but I imagine that the vast majority accept the reality of psychological influences.

What can make discusions difficult is the inappropriate and illogical way in which some people reference them as explanations for observations of widely experienced phenomena which although they have a scientific explanation in physical reality are not understood and therefore rejected buy those people.

They can’t personally understand how mains cable X can sound better than cable Y, this having been experienced and accepted by many people. They therefore resort to a psychological explanation instead of recognising and possibly addressing shortcomings in their scientific knowledge or understanding which would in fact explain the difference. That is not appropriate, logical or in any way helpful to anybody.

131

I assume you know this was intended to be humourous :thinking::slightly_smiling_face:

1 Like
132

I guessed that it may have been written on April 1.

133

I’m still a bit confused by all of this. If you have a rip made with dbpoweramp, and then one of the same CD made with a Melco ripper, and then you put them both on a Melco player, I don’t get how they might sound different. Similarly, if you put the dbpoweramp rip and the Melco rip on a NAS.

With Ethernet leads I understand that it’s the analogue components and rejection of noise (that’s just a summary) is what makes them sound different, ie other stuff is getting into the mix.

But with ripping, if we assume that both copies are bit perfect and checked with Accurate Rip, what else is getting into the mix that makes them sound different? Whatever it is must somehow be getting into the copy and being embedded, as people are saying that the different rips sound different when played on the same player - or at least I think that’s what they are saying!

134

My eyes hurt. What was the question?

1 Like
135

I went looking for a Melco Dealer today; none in Western Australia, spoke to prominant HiFi Dealers in Sydney x2 and Melbourne x1 and although they are Melco Dealers they only really deal in their Network Switches etc and none of them stock their Music Servers, had any experience wifh them or any real knowledge of them, but they could all sell me one.
With no chance of a demo and no real dealer support if I need user advise and help, its not looking too good to seriously consider a Melco from todays experience.

PS The Innuos Customer Service Engineer suggested I submit a "feature request’ to their online system for direct internet music downloading capability to be added to their products, so Ive just done the submission.
Will be interesting to see where that goes.

136

That’s what I’m saying yes. My assumption is that the differences are embedded into the different rips. I could be wrong about that of course.

I could talk about this or that as explanations but I’m not comfortable here and there are those who are far better qualified to explain it than I am.

I agree that in some ways it is counter-intuitive. But then aren’t so many things in hi-fi like this? I’m satisfisfied enough for my own purposes that the phenomenon is a real physical (as opposed to a psychological) phenomenon. Hence my purchase of the D100 and Plixir power supply for it (actually I was using the Plixir on my previous Melco N100 before the upgrade).

I’m not saying that perfectly decent rips can’t be had using a standard IT type drive. I guess it depends on your system and how fussy you are. I’m a bit of a perfectionist so I forked out for the D100, at vastly increased expense. It’s also very nice and convenient to use though and looks good on my rack!

1 Like
137

If the rips have the same “accurate rip” data base check and if you want another independent check the same SHAH checksum then the 1s and 0s are identical in both rips. If you then discern a difference when playing back then the differences (my understanding) come from the replay channel. Note a rip stored on a usb stick and a rip stored on a hard drive may have the same “accurate rip”/SHAH checksum but when played back through a single machine with access to both rips it may produce differences in playback due to the slightly different replay channel. One is read from a usb stick and the other a hard drive, subtly different replay channels. I’ll not delve into DAC architecture, timing, software, noise rejection or a multitude of other hardware/software/firmware factors that impact the replay chain. Seem to recall @Simon-in-Suffolk and others put up some good info on this, but may be wrong in my recollection. Some individuals can hear these differences others not.

As ever happy to be told I’m wrong in my understanding. Maybe someone with better explanation skills can put it more eloquently, and correct any misunderstandings I may have put across.

1 Like
138

That is it essentially. Same checksum means files are identical and will sound exactly the same if played via the same system. What won’t be identical is the background noise in the room, the humidity and exact temperature, any electronic noise generated by the environment and of course the emotional and metabolic status of the listener.

139

That’s what I’m interested in. Take a dBpoweramp rip and a Melco / Core / Innuos rip of the same album and put them all on the same server, and replay through the same system. People say they sound different. I’m not saying they don’t, but what is getting into the rip that makes them sound different? I’m no techie, and am open minded on all of this, I’m just intrigued. Could it be the way metadata and album art are embedded in the tracks, or stored alongside them that it making the difference?

140

If the files are different due to metadata or other factors then they may well sound differently. Indeed it might be that files could have tags added to trigger differences in how they are read by certain streamers.

1 Like