And again, that's a difference due to choice of 'player', not intrinsic to the files.
Not sure why you are belaboring this?
-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
David Chesky on Streaming Convenience vs Sound Quality
- Thread starter markstein
- Start date
And again, that's a difference due to choice of 'player', not intrinsic to the files.
Not sure why you are belaboring this?
You own it, and you have the choice of which mastering to own.
Otherwise, if it's the exact same master data, streamed vs owned in any manner, the only way for it to sound
different is some sort of sighted listening bias.
This is an Internet message board and it’s seems helpful to imagine and do thought experiments on reasonable possibilities independent of the actual probabilities of such possibilities.
There is a concept of “correlation vs. causation” but also the concept of “right for the wrong reasons.”
Robin L
Master Contributor
Dumb streaming question - I've got Tidal. I'm using a Topping E30 DAC. Tidal streams a lot of content at greater than Redbook standard. Everything via the E30 comes out as 16/44.1. Is there any way to get the Hi-Rez playback? More to the point; is there any reason to make the attempt?
According to the specs on the E30 it does hires, not sure why everything shows redbook.
The only reason I stream certain hires albums is I like the master not because I could hear any difference between 16/44.1 or 24/192 or any in between.
E30
The only reason I stream certain hires albums is I like the master not because I could hear any difference between 16/44.1 or 24/192 or any in between.
E30
- USB Sample Rate:
- DSD: DSD 64-512 (native)
- PCM: 44.1-768kHz, 16-32bit
- Coaxial & Optical Sample Rate:
- PCM: 44.1-192kHz
- DOP: DOP 64-256
Last edited:
Robin L
Master Contributor
Figured out the problem - fixed. Thanks.
IMO the word "streaming" is a general term which stands for various technologies.
RTP streams used e.g. for internet radio are clock masters, paced by the server clock. But the receiver/renderer, once it starts playback, must keep delivering samples on time to the audio device, which is another clock master. Independent clocks never run at the same pace. The renderer can delay playback start, to allow caching some amount of data. This creates latency which may not be acceptable. Nevertheless, if the incoming stream clock is slower than the playback clock, any amount of cached samples will be eventually consumed and buffer underflow will occur. To avoid that, the renderer should asynchronously resample between the two clock domains, using some more or less or almost zero damaging algorithms, depending on implementation. In this case one could tell streaming is not bitperfect.
Unlike e.g. network filesystem (smb, cifs) or DLNA protocol or Squeezebox protocols or fast HTTP downloads which either carry no clock (such as downloading as fast as available bandwidth), or they give control to/allow feedback from the renderer, letting the server know when to send more data down the transmission rate. Then there is only one master clock in the chain (again the soundcard clock) and no stream adjustments are needed.
But I very much doubt this IMO important technical difference was considered behind the claim that downloads sound better than streaming ...
RTP streams used e.g. for internet radio are clock masters, paced by the server clock. But the receiver/renderer, once it starts playback, must keep delivering samples on time to the audio device, which is another clock master. Independent clocks never run at the same pace. The renderer can delay playback start, to allow caching some amount of data. This creates latency which may not be acceptable. Nevertheless, if the incoming stream clock is slower than the playback clock, any amount of cached samples will be eventually consumed and buffer underflow will occur. To avoid that, the renderer should asynchronously resample between the two clock domains, using some more or less or almost zero damaging algorithms, depending on implementation. In this case one could tell streaming is not bitperfect.
Unlike e.g. network filesystem (smb, cifs) or DLNA protocol or Squeezebox protocols or fast HTTP downloads which either carry no clock (such as downloading as fast as available bandwidth), or they give control to/allow feedback from the renderer, letting the server know when to send more data down the transmission rate. Then there is only one master clock in the chain (again the soundcard clock) and no stream adjustments are needed.
But I very much doubt this IMO important technical difference was considered behind the claim that downloads sound better than streaming ...
Last edited:
It is very disappointing that a lot of people on this site, some with no more than a little knowledge find it convenient to assail and assassinate the character of someone they don’t even know because he has a different opinion about something. It seems that the more illustrious the character they aim their daggers towards, the more their appetite for blood grows. Shame on you. Clearly, the man was just expressing his opinion and not reporting a scientific experiment. I personally disagree with him but certainly, that doesn’t make him a charlatan who is trying to sell speakers on behalf of his son. Shame on you again.
Robin L
Master Contributor
But the man did a null test, and it turned out there was no difference between a stream and the download in the null test. That should have ended it right there. And, as the man sells downloads, it appears he has a financial interest in this. He probably shouldn't have brought up the subject in the first place. It might be just a "different opinion", but he disproved that opinion himself.
There is simply no reason and no explanation of how two bit-identical datastreams going through the very same DAC could have any difference whatsoever, let alone an audible one. Of course the explanation of why it seems different for some people is overly obvious.
This is a site that focusses on the science and engineering of audio. It is not about opinions, it is about facts.
I agree with you, that should have ended it right there, except that the temptation to stab his character was too great. It’s my belief that his little experiment was flawed but that doesn’t give me the right to assign motives to his opinion. He is not the first scientist to err in something.
Clearly he was expressing his opinion like all of us. He didn’t bring any facts finding to this site for analysis. I still don’t see how that gives you the right to assassinate his character. I fail to see the science nor engineering in that, just the same pettiness common on most internet sites. Carry on.
100%
Until the motives of an individual who is selling audio gear or in this case software are brought into the discussion.
When Chesky donned the cloak of science by referencing a null test, he opened himself to charges of pseudoscience in his claims.
Oh, boo hoo hoo he got called on it on a forum called Audio Science Review. Who would have dreamed?
Littletycoon
Member
You are naive, just expressing an opinion is not as innocent as you portray it, especially from a person with a track record. It then should be seen as a deliberate attempt to influence opinions. Nothing wrong with scrutinizing possible motives.
- Joined
- Jun 24, 2024
- Messages
- 688
- Likes
- 961
I might have been amenable to a call to be less harsh, if the man hadn't performed testing that decidedly disproved his theory and then immediately ignored that to make some incredibly implausible and evidence-free claims that just so happen to lend support to his son's business interests. The very most benefit-of-the-doubt I can give to him is to call that highly motivated reasoning.
I think all streaming services use TCP these days, not RTP/RTCP (real time protocol) over UDP. For music apps, it is absolutely not necessary to remotely keep ultimate clocking accuracy between source and destination devices. The destination device is perfectly capable to keep its own local reference, so timing info is kinda wasted.
That’s all common decency asks for. I am not sure how this lent support to his son’s business. I thought his son was selling speakers. His conclusion doesn’t seem to involve speakers to me.
Similar threads
