No, it’s pretty clear from Steve’s words that there is indeed an upper 4GB limit for WAV.
WAV uses unsigned 32-bit integers (as opposed to the signed 32-bit values used in AIFF) and hence gets twice the storage of AIFF - but still hits the buffers at 4GB.
The clue is in the word ‘streaming’. A stream from a UPnP server to a Naim streamer has no ‘file size’.
Or do you think a radio stream of 24/96 will stop when 4GB has been sent?
The WAV maximum file size has nothing to do with Naim. This is purely about storage.
FLAC requires decompression in order to play the PCM inside it. Some people prefer WAV and have Asset, Minin etc transcode to WAV. Some prefer the let the Naim streamer do the transcode but doing so will generate electrical noise in the stream. Either way all the Naim streamer plays is PCM.
No, I don’t think this is correct. Let me explain.
This thread started because an AIFF file - which we’ve established has a theoretical limit of 2 GB on account of internal block sizes - could not be played by the ND5 XS streamer. The file itself stored fine! It also played fine - on my Mac - and dBPowerAmp was happy to generate it (albeit incorrectly).
However, whilst the file stored and played well on the Mac, as soon as it hit the streamer there was a “Cant Play” error. That’s because - as Steve has explained - the streamer analyses the file structure and recognises that the internal block size(s) are out-of-spec. Clearly, on a Mac, the system is happy to interpret signed integers as unsigned integers.
Now, back to WAV: again, this has a similar internal structure to an AIFF file. That means that it uses fixed size 32-bit integers. These define the size of internal blocks, which relate to the content being played. Going beyond the maximum size of an (unsigned) 32-bit integer will overflow the field (and so the file can’t be played).
The important thing to realise is that both AIFF and WAV use a structured file format, including headers to define the contents of the file. It’s not as if you’re just getting a stream of music coming across; you’re getting a formal structure first, and then the bytes follow. Break the formal structure and the streamer can’t (or won’t) play the rest.
Hi,
I think this one comes down to do you really need to capture one performance as one single giant stream outside of recording/production work. Nowadays I would suggest no. Primarily:
On file formats naturally Naim don’t design these but we do ensure we have faithful implementations of them. If a given file format is limited to 2GB or 4GB by design then it’s really a case of don’t try and go beyond those limits as it won’t work properly. On the newer products we do support WAV’s with 64bit headers (RF64), but that just opens up another can of worms of UPnP servers support them as well.
Regarding internet radio and FLAC - as the FLAC is inside an OGG and has no ‘size’ and is non seekable then it can generate a stream beyond 4GB. I’ve got one test device that has been streaming from Naim Radio FLAC and has pulled over 30GB in one constant stream from it.
Best regards
Steve Harris
Software Director
Naim Audio Ltd.
Good points, Steve (and interesting to hear that the W64 format is supported on new streamers)!
The problem again is that some companies (e.g., Channel Classics) aren’t splitting large movements into separate tracks because of bad experiences with other vendors’ DACs; and with their new DXD option (24-bit 386 kHz) it’s highly likely that the 4 GB WAV buffer will be broken.
Back to your first posting: I think all this emphasises the need for a clear set of FAQs regarding advantages/disadvantages (and limitations) of the various file formats available to the hapless customer 
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.