Meridian Unplugged - Powered by MrTechGuy.co.uk Forums Discussion Meridian - Systems SB Touch

hecd
As regards whether the ID40 receives the FLAC File or not, have a look at Carl's post below

Is there any reason why we both would be misleading people here.........or why Meridian would be misleading us??
The posts from the Dealers are there too if you take the time to find them. I know what they say, but you don't seem willing to accept that

I can but direct you to your own statements earlier today that show that you are:
There is NO jitter in an an ethernet transfer - what could be simpler than that, and what could be a more obvious misunderstanding of the way these rthings work than your statement?

Again:
No it doesn't - why on earth should it? Ethernet transfer is asynchronous and jitter free. Zero can't be better than zero. Jitter is a meaningless concept for ethernet traffic.

This is just building unwarranted speculation on top of unwarranted speculation. Why on earth would receiving decoded data in asynchronous ethernet packets at the input lead to more jitter at the output. It makes no sense at all.

As I pointed out, it's moot. It doesn't matter where Sooloos does its FLAC decoding. The advantage of ID40 over SPDIF, such as it is, is to do with jitter-free asynchronous transfer rather than jittery SPDIF (the communication mode), and nothing to do with whether it's FLAC or uncompressed data (the file type of the transfer).

Yes that is what you say......

In a relatively recent past you also said

which after you actually compared your 808.3 spinning a disc to an SB SPDIF into an 808.3 became the following observations

Keeping an open mind about the possible things that can affect music replay can be a good thing..........others have found a difference using Server Side Decoding...........tell them they are hearing things

Just to chuck 'me tuppence worth in here, I've also been told by my dealer that FLAC files, not PCM, are sent over the network and decoded by the ID40.

Cheers

George

Good to see the carrier pigeons venturing out in all that snow


...just trying to lighten things up a bit.

@rawlander,
Is your original question answered in the meantime?

That's my boss and he is absolutely one of the most Brilliant, most generous people I have ever met.
You can put my picture if you like, but I'd appreciate his be taken down.

I thought this was a forum for music and movie lovers (and of course M-gear lovers) and that we were free to ask our - even stupid - questions.
So George, if you're getting tired of explaining again and again to us, the hoi polloi, keep in mind that you don't have to reply. And if you do don't be our judge and don't use the capitals and "periods", but just enlight us. It really isn't necessary or the place to be(come) unfriendly.

In the world of bits and bytes consensus appears far away. On the audio side that has never been different. In my system I could name at least three things that make a difference in sound. The phase of the Touch (what a difference by the way). The Meridian lead that is not burned in yet (it's new) an the former never used input for the Touch (does that have to burn in, I guess so).
For this item it's my last reply (and by the way, thanks Ronnie).

The posts from the Dealers are there too if you take the time to find them. I know what they say, but you don't seem willing to accept that [/quote]

And FLAC has nothing to do with the jitter part. It's all the same if it was WAV or FLAC. It's jitter free either way. If Carl thinks FLAC is responsible then he is wrong too. But that quote does not really imply it one way or the other. But could be read it that way. And if Carl meant FLAC is even partially responsible it's incorrect.

The key phrase in that quote, which is correct, is "enabling it to buffer". It could buffer WAV just as well and have the same jitter performance. And this is not quite the same as a FIFO buffer in processors that have no control over buffer overrun or underrun.

Surely it all comes down to network protocol used? If tcp is used then data received will either be intact (on time or late) or fail/timeout. If udp is used, then data will either be intact (on time) or be dropped (if late/out of sequence or delivery failure). Tcp handshaking maintains data integrity in preference to temporal integrity, udp is the reverse. Obviously in an ideal world, the network will be 100% reliable with a constant low latency so one will not be more correct than the other but this is not always the case with differing network technologies and workloads.

I don't know what protocol Sooloos uses, but iirc the squeeze protocol uses a mix of tcp and udp for streaming depending on audio format (pcm = tcp, MP3 = udp, FLAC = ?) or at least it did when I last used it.

Obviously if udp is used, no amount of buffering is going to fix dropped packets unless a higher level protocol handles this which kind of makes the benefits of udp redundant.

Buffer underflow with tcp is much more likely than with udp.

George,

There is nothing wrong in what I said; I described what the ID40 does, its operation as conveyed to me from two Meridian dealers. Please don't extrapolate and spin this it to something that I did not say ie. �FLAC reduces jitter�.

For clarification; the point of my post was to illustrate that the ID40 avoids the introduction of jitter by avoiding SPDIF; and by virtue of its design decoding FLAC (or �decoding� WAV if you like or any other asynchronous lossless format) within the processor enables it to output audio data �natively� and jitter free directly on to the 861�s (808.3s) internal bus.

I did not state or even imply that FLAC itself was responsible for this.

I hope you now understand what I said and did not say on this topic.


Regards,
Carl