Streamed music file compared to the same file from local storage

[Shivam]

After a recent long discussion in another thread, I was given an idea to compare file formats using streamed audio and same file played locally.

I used a wav file (sourced from 2L) that I first sent to a friend of mine in a distant country. He then setup a server to stream that file as a loop again and again.
I switched my Internet connection to a higher speed one in the meantime.

Two days back when we were ready, he started the server and I connected to it using foobar on a windows laptop (accessing the Internet on wifi). I tried listening to the streaming file and the one I had stored on my computer, I felt the one stored on computer clearer. Later it seemed that the file on computer storage was playing at a higher volume. So after changing a few settings, I got the volume level same. Result was then similar to my untrained ears.

Tried comparing both the files on a program called 'sonar' and again everything seemed same.

If a file can be streamed from another part of the globe using Internet which runs though wires, air and underwater too and then through telephone cables in my city at the end with multiple joints (and noise in the cable which makes my landline almost impractical to use as a phone) and then over a wifi to reach my laptop and still end up being same as the one stored in my laptop, then I am surely going to stick to cheapest digital cables that work.

The only thing that matters in streaming is good Internet connection and cache to make the playback without any pauses ! Maybe. I should try this experiment again on a high end (revealing) system but the effort required is enough to make a person mad.

Disclaimer - This was an experiment conducted to satisfy my whim and does not endorse or argue any ideas or thoughts of any forum members.

(Someone had said that Musical Fidelity M1 Clic provides better quality over LAN than wifi in an audiophile magazine review, but I am going to stick to wifi for the convenience and ability to control using ipad.)

 

[Shivam]

The files were compared on sonar after storing them locally so that part of my experiment is not exactly comparing streaming with playing locally stored file. It did however show no drop in quality.

 

[ranjeetrain]

Nice experiment!

The experiment can also be carried by setting up a local streaming server. Results would be same, so long as the media player is accessing the stream using the public ip (internet address) rather than LAN IP (local private address).

Whether there would be a difference or not, depends on many factors, such as:

(1) Whether the streaming server compresses the stream
(2) Whether the internet connection caused packets to be dropped

An even more objective result can be had by just saving the streamed file locally and comparing the file with the original using any software such as AudioDiff. Results would be much more objective and independent of the resolution of the playback system.

 

[Santy]

Thank you for trying it out, Shivam.
The results are not surprising to me.
Can you tell us how exactly you connected the system.
Were you using USB out of laptop with a DAC?

 

[Shivam]

Even I had expected the same results. I had to do it so as to be in a position to say - ' been there, done that'.

 

[ajopaul]

Yes, although on local network I had expected to experience drop in quality when accessing (not streaming) the file over NFS compared to playing from USB. But I could hardly make out the difference.

Also if there is no rencoding of file during streaming essentially you should not observe any difference on a good connection.

 

[reignofchaos]

If a file can be streamed from another part of the globe using Internet which runs though wires, air and underwater too and then through telephone cables in my city at the end with multiple joints (and noise in the cable which makes my landline almost impractical to use as a phone) and then over a wifi to reach my laptop and still end up being same as the one stored in my laptop, then I am surely going to stick to cheapest digital cables that work.

Your conclusion about spdif digital cables is completely invalid from the above experiment. For transmission of the file from wherever, you used TCP/IP over a network link. TCP has error correction schemes built into the protocol. So if a packet is lost in transit, the host from where the packet is being streamed re-transmits the packet. Also there is no concept of timing for packet based transfers. Its simply blocks of data that is sent and received.

SPDIF over coaxial cable has absolutely no concept of error correction. Its just s simple bitstream using differential manchester coding. This is unlike packet based transfer mechanisms used in networking where the packets may arrive out of order and maybe reassembled at the receiver in the correct order.

The timing information in the SPDIF protocol is embedded into the signal itself. Also the receiver has no control over the source clock. So if the source clock drifts, there's no way for the receiver to correct itself. Reclocking at the receiver is just an approximation. This is the reason ultra high end dacs have a separate master clock to which both the dac and the source are slaved. Also the signal can potentially be affected by RF interference.

The above does not hold for USB though - this has error correction and hence any usb cable works.

 

[Shivam]

Thank you for trying it out, Shivam.
The results are not surprising to me.
Can you tell us how exactly you connected the system.
Were you using USB out of laptop with a DAC?

USB out from laptop to M1 Clic's DAC.

 

[Thad E Ginathom]

I am surely going to stick to cheapest digital cables that work.

Network cables...

And whilst the cheapest of the cheap probably will work, there will be a failure rate, which is going to be much more annoying at home than when you have a box full of them on the shelf. Buy decent, branded cables. You should be able to take it for granted, for instance, that something like Belden is built to spec, and is properly terminated. Still, you'll hardly notice the price compare to audiophool snake oil cables, which are sold on absolute lies. Of this I am absolutely convinced, and others here are better qualified to explain why.

The same thing goes for USB Cables, although I don't have the same level of practical. dogmatic, no-two-ways-about-it conviction. I believe that anything that will work for an external HDD will work for a DAC: it is my considered opinion, and I would not buy anything other that, again, branded decent cables (and I've used much worse!). I notice that reignofchaos says that "any USB cable works," and I'm certainly not going to argue with that.

He also says,

Your conclusion about spdif digital cables is completely invalid from the above experiment.

Yes, it is. The whole SPDIF thing is built around and for audio. Albeit digital, it is an audio data protocol, and I have some sympathy with a person who might say, "that's music passing along that cable," even if it is in the form of bits. But still... no need to grease the data with snake oil. Just buy decent, branded cable, with decent, properly fixed connectors, at a reasonable price.

 

[KiranPS]

There was a great article where they explained how a square digital wave becomes more like a sawtooth wave when it flows thru bad copper cables with high capacitance. Since in digital for the bit to be considered a 1 it should be at a pirticular voltage, in a high frequency signal because of the delay in the rise time , the next bit will come even before the previous bit has time to reach the desired voltage to be recogonized as 1, this will lead to data loss. Like Thad said , you just need good branded cables. The same applies for HDMI cables also, some bad cables will transmit 720p video but will croak on 1080p video since the bits are too close and not being recogonised properly.

If you use http or other tcp/ip based protocols, it has corruption and packet loss detection with retransmission so you will get the exact copy of what is there on the server.

Some sites use UDP protocol for streaming, this is like uni direction transmission, with no retransmission on loss , this is used for real time streaming of live events etc, here there will be quality loss in case of packet loss . Some internet radio sites will also do adaptive re-encoding of the stream to a lower bandwidth based on the client , here also there will be loss of quality. Even in tcp/ip , apple realtime streaming uses file blocks , so the client requests the next block after downloading the first one, in case the client download is slow , by the time the client requests for the next block, the server would have generated more blocks than what the client can download , so will choose to skip a few blocks.

 

[ranjeetrain]

^^ 100% correct.

Even in TCP based protocols theoritically there is a possibility of loss. Practically it will happen or not depends on the actual condition. In TCP if the connection is not stable or if the connection speed is almost same as the required data rate, there will be broken packaets causing jitter. For a TCP based transmission to work perfectly the connection speed has to be at least 2 times the data rate plus a stable connection.

 

[Thad E Ginathom]

Sure. IIRC, neither TCP nor the underlying physical layers make any guarantees as to when the data will arrive. There is a basic essential requirement that the network be fast enough and free enough to ensure that, in practice, this does not matter.

People are installing gigabyte networks to connect two or three devices!