NDX support for 24/192 via UPnP?

Hook

1) stream FLAC

2) stream FLAC transcoded to WAV

3) convert FLAC to WAV, save file and stream native WAV

I have done some listening comparisons here, and am continuing using HiDef files.

I am using NDX into nDAC/555ps. The results with just the NDX/555ps were more pronounced.

1) Streaming to FLAC results in a slightly fuzzier sound, sibilance becomes more pronounced and 'depth' reduced. ie there is less dynamic air to the sound - hard to describe but effectively less realistic.

2) Improvement, HiDef sounds very good transcoded. 16bit / 44.1kHz not bad, but there is still slighlt compression of the air and ever so slight increase fuzziness. I am aware this could be down to uPNP server and the NACK flow control at the TCP level, ie getting the NDX network port adapter and TCP stack working harder.

3) Here I can hear no difference at all ie between original ripped WAV, and rip to FLAC then convert to WAV and stream as WAV. This sounds awesome and HiDef takes a step forward.

I am intrigued by the findings of 2) and will get wireshark out and have a look when I remember how to get port spanning opened up on my switch.

Also i decompiled the WAV converted from the  FLAC with the original WAV used in 3) and the PCM is identical, there are some subtle changes in the ID3 data, and on examination, it was the description of the source and encoding history was different - ie a simple ascii text difference.

Simon

A couple of weeks ago, my dealer asked me whether or not I could hear a difference between native WAV, and FLAC transcoded on-the-fly to WAV.   I told him I would do this test, but was doubtful there could be a difference, as I could not understand how it could possibly be.   I never did, and now I feel a little bit guilty over doubting what he told me he heard!

Ok, so we all agree that the end result of using a file converter to decompress FLAC to WAV is a perfect, repeatable process.   I can take the same FLAC file as input, and run it through any number of audio converter programs, and get the same WAV file as output, over and over and over....right?

So the only explanation for what you are hearing is that there is a difference between the (perfect, repeatable) file conversion process and the on-the-fly transcoding process.  The only difference I can think of between the two is.....time.   It does not matter how long it takes for file conversion to take place.   It is done when it is done.   Transcoding, however, is bound by time.   I imagine that a UPnP server like Asset is allocating buffer space, and then making a best effort to keep that buffer filled with enough, but not too much, data.   No underflows or overflows, all in an attempt to support a smooth stream of uncompressed WAV file transmission.

So Simon, is your experiment repeatable?   Do you hear the same differences each time you perform this test?   Could it all be down to a bug in Asset's transcoding process?  Have you tried anything other than Asset?

I wonder if this doesn't mean that Mr. Spoon needs to create a "memory play" option for on-the-fly transcoding... it is, after all, pretty easy to hear the difference in Pure Music between regular playback and memory-based playback...

Oh well Simon, thanks a freaking lot for getting my head spinning so early on a Saturday morning! 

Am looking very much forward to reading what Wireshark tells you.   Would be nice if there was a way to turn on an Asset debug trace at the same time, and somehow match the two up.   I wonder if Mr. Spoon would be interesting in supporting your analysis.....

I will definitely give this a try today, and check back here later for updates.   Good luck pal!

Hook

PS - I really hope you figure out what is happening and why.   The thought of re-ripping 2000+ CD's makes me nauseous.   But now that I think about it, if transcoding-on-the-fly was such a perfect answer, then why would Naim have been so stubbornly set on ripping to WAV?   I think I am going to go read the UnitiServe manual....just in case.  I imagine we'll be hearing from Mr. Dever at some point on this one...

.. spoon is busy putting upnp streamers in the cloud .. so he just might have other things on his plate ..  googling "cloud upnp" will tell you more

Hi Hook

I think you would find it interesting to have a look at what JPlay does in hibernation mode.

You can read something about it here.

In music, timing is everything. And in digital music reproduction doubly so: while producing bit-perfect output is easy, producing it at exact time required by digital formats (e.g. 32 bits every 22 microseconds for CD) is not. Why? Because while your PC may be really fast, it’s also doing hundreds if not thousands other things at the same time it plays music. With so many things going on, do you trust it will always ‘hit the beat’ at just the right time? Programming optimizations in jplay are designed to minimize both software & hardware interruptions in order to make it ‘easier’ for PC to ‘keep the rhythm’.

They have developed from this viewpoint a remarkably good audioplayer, esp. their hibernation mode (which temporarily turns off loads of unnecessary Windows threads) noticably improves SQ.

This is not exactly the same situation as iwth UPnP servers because this player feeds its output to a Windows sound device, but it gives you a sense that bit-perfect only is not enough and that their are other aspects in replay and playback chain that can still be improved to enhance SQ.

-

aleg

Hi Hook,

I'm extremely sceptic about this, too. But I will give it a go once back home, as it's not always logic...

Transcoding process isn't (or at least shouldn't be, when done properly) different from conversion process onto a disk. On-the-fly transcoding just converts the format onto a network. (And if the conversion program is faulty/buggy, then the same converted data piped into a WAV file on disk should be corrupt also). When converted/transcoded properly, there should be no difference how the resulting WAV file is received by NDX/renderer as it buffers the _file_ before turning it into audio signal. It's not like it's suddenly receiving error prone SPDIF.

Cheers,

M