WAV vs. FLAC transcoded to WAV - Network Trace
Posted by: DaveBk on 18 October 2012
One of the perennial debates often encountered here is whether WAV sounds better than FLAC on Naim streamers. The general consensus seems to be that any perceived differences are explained by the extra processing required to decode FLAC, and the resulting increase in digital noise which could be picked up by sensitive analogue components nearby.
A more contentious subset of this debate is whether FLAC transcoded on the fly to WAV on the uPnP server sounds different...?
Personally I can't tell them apart, but I was interested in whether there was any difference in the network traffic in these two scenarios so decided to do a little test.
I use a Shuttle bare bone PC, with an i5 processor and 4Gb RAM running Windows 7 and Asset as the Server. This is connected via a Netgear GS116 switch to my NDS all using CAT6 cables. They are about 15m apart with 3 solid brick walls in between. The music files are on a QNAP 459 Pro NAS next to the server.
I picked relatively short 2 minute track, Intro off the XX album, and converted this from FLAC to WAV using dBpoweramp music converter. I put this and the original FLAC file into a new directory and edited the metadata to change the artist field to 'Test Material' so I could distinguish them from the original album. I forced a rescan on Asset, then checked I could see the new tracks on nStream. All as expected so far.
For the network capture I used WireShark running on the server and captured all the packets flowing between the server and the NDS while the 2 tracks were played.
For the sake of simplicity I ignored all the uPnP discovery, and the content look-up between nServe and the Server and only considered the actual delivery of the music stream. It starts with an HTTP Get from the NDS, specifying the uPnP URL of the required music file. For the FLAC file transcoded to WAV the URL format is a path with forced.wav at the end, for the native WAV the path ends with a unique file ID, also of type .wav. The URL path is not the path to the file on the NAS, it is a uPnP 'shorthand' using alphanumeric tokens to represent the required file.
The response from the server is an HTTP 206, followed by the required file which is streamed back to the NDS. I looked closely at the WAV headers and they are different, but closer inspection showed that this was due to the meta data tags being included in the direct WAV, but not on the transcoded WAV. The data chunk looks identical - exactly the same length, and at various offsets containing exactly the same bytes. I have not done an exhaustive comparison yet, but a close 'eyeball' inspection over 30 mins could not see any difference.
Looking at the network exchange it is almost identical as well -
On the initial handshake the Max Segment Size is set to 1460 ( no jumbo frames ). The initial receive window from the NDS is 8192, which reduces to 6732 after 3 segments have been exchanged then remains constant. It's just textbook TCP, 1460 length segments, getting ACKed, final one has the FIN bit set. I can see absolutely no material differences, other than the presumably redundant transfer of a bunch of metadata at the end of the 'real' WAV which I guess the NDS just discards.
So, no further forward in working out why some people hear a difference....