why expensive streamers

@nigeltheflash either you didn't read my first post in this thread or your read it and didn't believe it.  After all, I'm just a rando on the internet.   

The difference you, and others in this thread are missing, is that 99% of all data trasfer in the world is done for business and is indeed bit perfect.  Business, govt, and individuals need their files to be perfect.  You'd hate it if you bank dropped a zero when it downloaded your account data.  

Streaming can't use the error checking protocols that achieve bitperfect file transfer. Thus, dropped bits and the streamer's attempts to deal with it. Otherwise, there would be no market for high end streamers, silver digitlal cables, or anything high-end digital audio.  We could use all the same equipment that you use at work to achieve bitperfect file transfer inclding generic cables in plastic wrappers.

I've spoken to many IT professionals who don't know the dirrerence because they spend their entire career in business where bitperfect is an non-negotiable requirement.  

So I'm not interested in arguing and this is the second time I've explained the difference in this thread.  So I'm done (unless someone shows up who really understands streaming and can add to my understanding.)   I did some googling before I responded here, knowing people will be more likely to believe it if they can google it,  and google doesn't get any answers.  Google explains bitperfect well but discusses streaming in general terms.  

I do acknowledge that I could be wrong.  I'm no a streaming expert.  I'm a physicist who had to dig really deeply to understand this and of course my sources could have been wrong.  but I'm usually pretty good at sorting the wheat from the chaff.

Hope you system sounds great,

Jerry

“Streaming can’t use the error checking protocols that achieve bitperfect file transfer. Thus, dropped bits and the streamer’s attempts to deal with it. Otherwise, there would be no market for high end streamers, silver digitlal cables, or anything high-end digital audio.”

Jerry, apologies, I do recall your first related post but didn’t realise you were the same author. For a self-professed non-expert on streaming, they’re quite some assertions!

Perhaps you should forget the network tech googling thing and find somewhere where a streamer manufacturer says something about why they can’t use the same error correction techniques/technologies as other ethernet-capable devices. I don’t recall having read anything from Antipodes or Innuos or dCS or similar where they talk about how they’re much cleverer at working out how to fill in the dropped bit “gaps” than their competitors. I suspect you won’t find anything as it’s not a problem they’ll recognise but, hey, what do I know, I’m just another internet rando like you!

Until I see anything from a streamer manufacturer/designer which corroborates your suggested explanation of the differences in sound quality amongst streamers, I’m going to stick with my own assertions that ethernet data transfer IS ethernet data transfer full stop (US period) and that streamers differentiate based on noise and clocking (possibly amongst other factors).

If file transfer is perfect and done until it's right, reassembling the former exactly into the later, and when someone comes up with a teleporter based on this "exacting" tech, who will be the first to volunteer to go into the descrambler chamber knowing they'll come out "bit perfect" in the reassembler chamber just ten feet away?

Any volunteers?

No,I didn't think so. Like that fly in the movie, The Fly, noise is the culprit that gets into the mix, messing with the reassembling. It's what Antipodes cleaned up long ago, as best they could, by writing reams of code to combat it. Competitors could build the hardware side good enough to look as good as what Antipodes did but they just didn't sound as good (from what I remember from reviews in the early days). Antipodes is just one example.

Some listeners just didn't want to spend that extra to get it and that's around the time things got really heated in regards to what's good enough, that meeting the protocols was all that's needed. 

But as has been succinctly pointed out, that's all that's needed for bank transfers, general data, guidance systems, properly sized fonts, etc. Music is so complicated and fragile that simple noise can corrupt the intended results. I think it's wrong to relegate music to the same terms as the aforementioned, for it has deeper connections to us that general data just can't match.

There are levels of  gradations that show this. We can be deeply moved by a photo of a beautiful event or something as simple as some old calligraphy recreated exactingly from some subject we're familiar with. That definitely lies between a bank transfer from our Social Security account and the music we listen to. It's still nowhere near the level of seizing and moving us like music does, and we can tell when we're being deceived when it's on that deep a level of appreciation.

They've got it pretty well sorted with CDPs nowadays. People talk of flavors, see through ability, tone, timber, pacing, dark and light, etc. when comparing them. With streaming, it's a different kettle of fish, if anyone bothered to notice. What they talk about is emotion, soul, and what seems to be lacking in a more corporeal manner. 

I've always found that interesting. 

All the best,
Nonoise

carlsbad2

... Streaming can't use the error checking protocols that achieve bitperfect file transfer. Thus, dropped bits and the streamer's attempts to deal with it ...

That is not true. Services such as Qobuz and Tidal use TCP/IP, which is a bit perfect protocol. Data arrive in packets and faulty packets are resent.

so, to be potentially off topic, from a software point of view, streaming is a method. It has nothing to do with data loss, error handling, the quality of the data, etc. The content (5 seconds of a cat video, pdf file or song) is converted into bytes and sent from one endpoint to another. The client endpoint will receive it and convert it back to "content". In between there is "networking stuff" that I know little about and won’t google it (so that e.g. I still don’t say stuff that would embarrass my offspring who spent 4 years in College to understand the "networking stuff".)

If you want to play 5 frames of the cat video, 5 seconds of a song, you will need to receive the data that comes in a form of a stream. It has the beginning and end, x amount of bytes. The programmer writing the software that handles the data assumes it is 100% the same data  the server sent.

What we also call streaming is the concept that we don’t need to receive the 6th seconds of a song to play the first 5. We just assume that we will have it in time, before the 5th seconds of the song has played. We can add business rules to our playing procedures such as we won’t play the song unless the entire song has completed streaming (in which case, it’s not really streaming but downloading.)

I feel these concepts are easily confused - as shown in this thread. I would go on about lossless and lossy formats and compressions and how Spotify changed business rules to get around receiving all the data that was sent and "just move on and play something" and never wait for the lost pockets - if I had know more than I can google. But I don’t, music streaming is a different animal than streaming data for maps and location data that I work on.

Still, this is a very educational thread despite our different understanding/ misunderstandings of various issues around streaming...