Also Simon’s other point was about a different encoding of wav sounding different in some streamers. Again that would mean the rips would be different at the bit level not identical. So the first step to uncover whats going on is to answer my first question. Are the rips identical at the bit level or not?
1 Like
You should lookup how AccurateRip actually work. Their definition of accurate etc. And how easy disk-errors can come out as correct-results. In my personal opinion there are big holes in it.
And the reason it exist is because instead of adding the required functions to the drive-firmware (which should have been the natural starting point) everyone is trying to work around using a function-set for showing multimedia-presentations.
Look at the open-source CDPARANOIA-library for ripping and see how something that should have been very simple ends up.
I never opened the D100 to see what was inside and I may remember this wrong, but I think I read Melco did it the right way which probably explains, at least to a degree, the price tag of their product.
If you have two identical files they should sound the same on identical hardware. But the complete file must be identical, not just the audio bits.
2 Likes
OK well I’m out of my depth here, but that wasn’t my understanding from Simon’s post. Anyway I’ll leave it to Simon to comment further if he feels inclined to.
But really, it all misses the point, as in my post at 231. I hear differences, as do many others. Technical explanations as to why this can’t happen seem rather redundant in the face of this.
Sure. I believe you. I would love to understand what you can hear and what’s causing it but really am limited in time for a week or two.
I do think this whole debate is rather academic now anyway. The differences are going to be on the margins and not of the same scale of a utpoik upgrade or comparing the old linn casing design ds streamers to the new kdsm. Now thats serious differences!
Also i think I only listen to my own rips about 1 in 20 times versus streaming (either via roon or direct to the linn from qobuz). And then factor in vinyl, its got to be a 1% problem for me and I suspect many others.
Enjoy the day 
I have to pick my dad up from the airport returning from the us. Such things are way more important than music hifi 
2 Likes
Whilst explanations as to why you cannot hear a difference when you can maybe pointless, discussions around trying to understand What is happening that results in people hearing a difference is quite another matter! And if the digital music data are indeed identical, which can be verified, then it cannot be that that is causing the difference, so it must be something else coming to play as some of the contributors here have suggested.
1 Like
A quick scan of the roon forums say that the PCM is stripped out of the file container in the server and that is sent via RAAT as uncompressed PCM regardless of the file container it is stored in e.g. WAV, FLAC etc. At that stage there is no metadata passing only a PCM stream.
The device manufacturer (in my case Linn) are responsible for creating an app/software on their streamer that interacts with Roon. The way these things usually go is that they will negotiate a request for a subset of the metadata from the roon server upfront before the PCM starts streaming and they will write the code super defensively to handle all kinds of out of the ordinary circumstances - which linn would test. That would likely also include the playlist. I can pass/view the playlist on from roon seamlessly to the linn app - that app can only be getting the playlist from the streamer.
Linn would not want their DS sounding worse just because someone loads in 1300px album art, which I think roon either replaces or trims to 1000px anyway.
1 Like
It’s like in the dCS world, and adding a master clock.
Some people don’t hear anything when you add one, and others do.
Our brains all work differently, and some are more in tune to timing, others not so.
I guess how we are wired also goes along way into this debate as well.
But as been said, you can only try for yourself and see.
1 Like
The rips are identical assuming no read errors causing ticks, skips or dropouts.
There are different ways wav files can be constructed to hold the recovered (ripped) sample data from the CD, but the rip data is identical irrespective of the wav file format.
5 Likes
The difficulty is that it necessarily involves the discussion of extremely complex technical issues that are I’m sure beyond the full grasp of most here. And of the few people qualified to discuss them I suspect that they have had to be presented in a much simplified form in order to enable some sort of understanding from the majority here.
There’s nothing wrong with a group of lay people discussing it and it can be fun. But don’t expect any sort of worthwhile outcome. Just enjoy the ride.
1 Like
I think you’re over-estimating the complexity, and whilst you may or may not be right about the majority of people’s ability to grasp, it only needs a few for the discussion to be meaningful, while if there is a reasonable hypothesis as to possible cause of the phenomenon it only takes one willing person with the necessary tools to di at least some preliminary testing, though if they don’t gave the Melco ripper they would be reliant upon someone else providing.
Sorry totally correct, I misspoke in a hurry I meant the encoded wav files that are sent to streamer if there is no transcoding would be slightly different and presumably there could be secondary effect in the streamer as before.
I am struggling to see how a rip can be more accurate than accurate and therefore sound better. It’s just accurate or it’s not.
And I can’t see how a bit perfect stream can be better than another bit perfect stream unless there is a bug.
So any observable difference in replay must be secondary when compared to an alternative chain used for testing either
A) the alternative option is generating a secondary effect in the streamer and the d100 rip is not e.g. one is an optimal file wav or pcm, the other is a suboptimal wav or flac generating an effect
B) the alternative setups are on something like a pc or a less isolated device than a melco that has not be well isolated from the hifi eg diff room, a couple of network switches away.
C) some dsp is in play
?
1 Like
I think it is likely that the metadata from the file never even gets directly into the streamer. Only indirectly via the media server and / or its control device
Think of two processes. One is a steam server sending chopped up audio file (flag, wav etc in case of upnp, pcm for room RAAT) in a bit stream and one an interaction over a playlist (complete with a minimal set of data like artist, album, title, image, track progress, and the endpoint to stream the track data) and control actions between streamer, media server(s) and endpoint(s).
Edit. That’s how I would design it in my head heading up the m6 (carefully 
). Coffee break.
And it you think about it this makes sense - roon uses the file meta data to totally recuate the key fields and stores it in its database. You can amend that data and it doesn’t change the file. Ditto with upnp.
1 Like
This forum has very many amateur engineers, scientists and psychologists that come out of the woodwork to take part in discussions like this. That’s OK - this isn’t a professional forum it’s just for enthusiasts. But we need to recognise the limitations of the value of what amateurs say with respect to technical considerations.
I’m a retired biomedical scientist so I don’t have a professional knowledge of the stuff discussed here. However, as a scientist I can usually spot non-scientists in technical discussions easily because they tend to make the same sort of mistakes. These include leaps of logic, unjustified assumptions, mistakenly thinking that details are insignificant when they are in fact vitally important, and so on. Apart from more obvious things like they sometimes obviously actually just have no idea at all what they are talking about. People who have no professional scientific training are very prone to this sort of thing.
I don’t mean to be rude or direspectful and it’s not a shortcoming in itself. The shortcoming is in not recognising one’s own limitations and behaving as though one were an expert when that is simply not the caae. There are people around here who do that and make their various totally unfounded pronouncements as though they were established undisputable facts. It’s just daft. But that’s what frequently happens when you get a bunch of amateurs trying to put the world to rights. Suddenly everyone’s an expert.
As for preliminary testing, I’m not sure what you mean. I can see how it is possible to fairly easily establish that two or more rips are bit-identical. Beyond that, and unless one has the technical know-how, access to the required analytical equipment and the knowledge to interpret the results correctly then it’s just a matter of subjective listening. I will say the Melco ripper sounds better than a £30 drive. Someone else will say it doesn’t. End of story.
Anyone have a mirror handy? 
Sorry if you feel under pressure PJL. Thats unfair of us and me. There are a few of us who just get interested in how things work.
Anyway no more from me on differences unless it’s just more questions or discussion on how things actually work, which fascinates 
If it helps, ripping cds is less like a recording mentality and more like recovering photos from a slightly dodgy sd or cf card to expose my other (and bigger hobby!)
I do hope you are really enjoying your retirement and musical equipment! And especially the music! After a lifetime in the tech and consulting industry, I am also approaching retirement in next few months or year or 2.
2 Likes
No worries . i don’t feel under pressure - just my take on things. Very good to have resident experts here. I hope you enjoy your retirement when it arrives!
If it does! About to take 6 month loa for photography. Then go back. Can work 60% as option for a few years or stop. Love the work but love the hobbies too! Listening to a Klimax kdsm doesn’t help the choice! Anyway we’ll see - got trips to Norway, Scotland, Northumberland planned for photography from mid September to Christmas.
3 Likes
Having had the time to read the specs now for upnp, yes the metadata typically comes from a content directory service from the server. Which can be requested by the renderer (ds) or control device (tablet). The spec leaves it open to get it direct from the file but that is unlikely in our implementations.
So see it as two basic processes. An asynchronous bitstream (the protocol of which is negotiated and setup upfont in the spec) process to get audio data from one of many server endpoints to the renderer. That should be audio data only. And a set of control services to allow the control device to manage the renderer. Pause, play, add to playlist etc. the renderer owns its own internal playlist. In linn’s implementation that must be published in a pub-sub style service to allow my roon control point and linn app control point to see whats happening in real time. There are other processes for content mgt, discovery etc - updatIng the database in the server.
So net net, i think it would be a major implementation failure for metadata to have any impact on the quality of the audio stream (except with our old friend the secondary effect on the streamer cpu).
And implementing a bit perfect stream seems fairly straightforward in this architecture, if almost left fully open for the server and renderer to arrange.
1 Like
And Roons implementation is much more prescriptive and centralised with everything including database files and streaming services going through one standardised RAAT bitstream process rendered into pcm. Same applies. Metadata is split as a separate set of services from audio data stream. So again only risk is secondary impacts on the cpu of handling the track and playlist metadata. That is under control of the implementation between renderer manufacturer and roon. Action could be taken to protect the renderer from excessive metadata.
1 Like
A few very simple examples: 1) someone with the relevant software tools could examine a Melco and A.N.Other ripper file beyond whether the music data are identical, and modify the non-music data of one to imitate the other, to then see if a difference is still heard. 2) From a different angle someone could compare the audio waveform of the two audibly different but music-bit-identical files to see what the differences are. 3) A very simple one: I’ve heard people say the D100 rip sounds better than A.N.Other played on a Melco. Does it also sound better on other servers or pkayers? (I don’t recall anyone saying they’ve tried)
1 Like