Flac vs Wav audio quality

That's probably more accurate Huge 

For SQ wav every time for me.

Wat, thanks for the explanation... Now I know stuffing is nothing to do with padding and is not much to do with turkeys either. 

PONO.hres for me. 

SJB

Paul,

You would say that.

Hope you get to blast the dust off your 800s grills tomorrow night.

Yes, agreed. 

I was just referring to the way it is described in dBpoweramp.  The FLAC encoder settings are "Lossless Uncompressed", "Lossless Level 0" to "Lossless Level 8".

gales, because that's what I believe, I would never use flac 

Unless there was no alternative , biggest disappointment this year pono, one trick pony,sounds ok on kans but really lo-fi via a system Imho, great marketing job though And if the message gets through about best file types then that's an accomplishment.

Good post, well said.

+1 on WAVE my entire collection of ripped music, CDs through the Unitiserve and purchased 24bit is all WAVE for the same reason.

Can anyone explain why Naim players struggle to play FLAC files flawlessly, when other makes of player (notably the Scottish brand) are able to play FLAC and WAV files equally well?

I should add that I am perfectly happy playing FLAC files on my Naim/Hugo player.

NaIm players should not have an problems playng flac, if you have issues contact your retailer or naim support, flac offers several-advantages  over wav especially how meta data/album art is handled it's just the SQ I have issyes with.

I have both WAV and FLAC conversions of the same files (ripped and converted by the HDX) which I cannot tell apart - perhaps the WAV is very slightly more rounded...perhaps.

G

Who says Naim don't play .flac ?    The only reports I read on the forum is when trans-coding .flac to .wav,  & thats a media server problem, not Naim,   & equally applies to scottish boxes as well..  

And if .flac is so good SQ,  why not play it straight .flac - .flac ???

Happy New Year to All  - from all us satisfied .wav'ites 

As said, FLAC can be transcoded on the fly to WAV, and as far as Naim is concerned it's regular PCM. And just to be sure last year a set a network sniffer to compare the first 1000 bytes or so of a WAV track and FLAC transcoded to WAV track.

And guess what?

The PCM in both traces was identical.

Now there are audible differences to me between streamer Servers with differing TCP transport parameters - but that is a different matter and I reported my observations couple years back on the forum regarding this. But the TCP crosstalk is related to the FLAC decode, Jitter removal crosstalk some of us can hear.

And for those who are still interested crosstalk is the term used to describe the interaction of one process on an other that is not directly related, and exists in just about all practical electronic circuits and systems.

So in short there are more variables than just file types for a given performance.

Simon

Simon,

When you looked at the packet traces did you notice any difference in the timing of packet delivery between them or were they identical?

Graham, I can't remember looking specifically at the timing, but the packet sizes were all the same and by the time they appear above the transport level they are all sequential. however randomly interspersed at layer two and at layer three you will see other frames and packets respectively - which is what you expect on a network. Therefore network packet timing with TCP has no or minimal (crosstalk) impact on the PCM audio carried.

If streaming audio used low latency UDP to carry the media, then timing would be essential for a given audio quality, which is why on VoIP systems we use quality of service parameters to ensure this across the network. But on home audio we sacrifice low latency for the reliable transmission of the audio using TCP.

Simon

When I ran a similar network trace the packet timing was close to identical as well. This is what left me happy to transcode to wav on the fly.

Two words: SUBFRAME_VERBATIM

From FLAC v1.2.1 onward, when decoding an uncompressed FLAC file, the frame information is presented but the PCM samples are extracted exactly as stored; no decoding or mathematical processing is required to extract the raw audio data from the file itself (aside from the frame overhead, which actually may be a good thing from a file integrity perspective). PCM frames are stored with zero padding to byte boundaries.

dBpoweramp's Music Converter enables this by setting the encoding parameters to eliminate any predictive encoding, which greatly reduces the processor overhead at both the encoding as well as the decoding stages.

If you really feel the need to encode compressed (lossless) FLAC, compression level 5 provides the next best option IMHO in terms of processing overhead:

• 6th-order Linear Predictive Coding
• 4K (4096 sample) block size
  
• Choice between storage of mid-side (L+R, L-R) encoded or stereo LR pair, optimized per sample block
• Rice encoding residual partition order: minimum 0, max 2^4 = 16

Ultimately, the overhead for decoding uncompressed FLAC is trivial, IMHO; for compressed FLAC, not so trivial (requires acceleration of fixed-point arithmetic).

Thanks WAT,

That was indeed my point. I have both Linn and Naim players, and cannot distinguish between FLAC 

 and WAV on either of them.  Virtually no one on th Linn Forums has suggested that WAV files sound better, and Linn themselves make no recommendation in favour of WAV.

From the posts on this forum, it would appear that many people are unhappy with the SQ of FLAC files, hence my earlier comment about Naim devices seemingly not being able to play FLAC files adequately.  Not a view I share from my personal experience. 

Why just Naim?

Interesting, thanks Simon.

...and pono is what proves FLAC is rubbish and not worth using?  My word.

That's their game Gale!

No I am not being objectionable just for the sake of it, I am not being objectionable at all.  Believe me I am really a nice guy.

The problem I have is with your posts.

I alwayst thought kans had very high resolution. When I had them I used a Linn deck and 72/250, and they sounded great.

Ogg Vorbis comment field names do certainly exist, and they can possess more than one value (i.e., appear more than once in a single header). They are also a de facto standard, rather than an ISO one, but I don't think that has affected their overall uptake IMHO.

If someone asked me for a best practice in 2015 regarding music storage for PCM digital audio, it would most definitely be to use FLAC Lossless Uncompressed with both Vorbis comments as well as ID3v2 tags embedded into the file headers.

In order to implement FLAC Uncompressed storage, the FLAC encoding library must support all FLAC encoding flags, as the numerical compression defaults (0-8) are insufficient to enable uncompressed storage (i.e., SUBFRAME_VERBATIM with no linear prediction, e.g., max-order = 0).

I cannot speak for Naim on this as regards support for FLAC Uncompressed on the HDX / NS0x / UnitiServe products....