Flac vs Wav audio quality

I am in the process of converting my HDX library to switch to my new NDS

 

I have seen various discussions about wether people can (and indeed should) be able to detect a difference in quality between flac and wav files.

 

Well I am absolutely certain I can tell. I don't consider myself the most analytical listener, and I'm not always the best as describing it but the difference for me is marked-and my wife agreed.

 

Flac is a bit drier, a little sweeter perhaps and I think details better resolved. Wav seems fuller, richer and perhaps a bit more dynamic. Flac maybe a bit 'cleaner' sounding?

 

Curiously I'm not sure which I prefer. Flac certainly not a deal breaker and some tracks really suited the presentation. I'm going to wait until I have attached the NDS to decide-and I retained a wav library as back up too (so have also directly compared tracks as well).

 

Interesting

 

Bruce

 

Original Post

Bruce, are you comparing the two formats as played back directly from the HDX, or is one version sitting on a NAS ?

 

When I compared the two played back from a UnitiServe HDD, I found that WAV revealed subtle timing cues that were buried in the FLAC version. That said, I like the sound of FLAC files, which seem a bit softer, more rounded, but the WAVs seem more dynamic. Opposite to your findings.

 

The differences are subtle though, and I could live with FLACs, if disk space were a limiting factor.

 

Jan

I decided to rip using FLAC from the start, though not with an HDX or similar.  I did many comparisons between the two formats, but I would say that any difference is insignificant with my system.  There were several occasions where I thought I could hear a benefit from WAV over FLAC, but in the end I concluded it was my imagination.  Mainly because it seemed which ever format I listened to second was the one I preferred, purely because I'd notice some detail, significant note or level of warmth that I had not noticed with the first listen.  However, I found that to be true regardless of the order.

 

What I don't follow though, and I'm not very familiar with the HDX, but why does it need converting?  If the files played via the HDX were good, why do they need to be changed?

Jan.

 

I guess some of the files are stored in the HDX and some on the NAS played through the HDX. About 50% is NAS stored now as my HDX filled up years ago. I had not really thought to see if the site of the stored files made any difference. I played a lot of music old and new last night and it all seemed consistent so I suspect it was a mixture.

 

I'm converting them as I am selling the HDX and have bought an NDS. Several people have advised converting the files. Main reason is to have more data tagging etc. Although my NAS UPNP server did seem to identify track ordering correctly on the wav files I am aware not all server software does this well with WAV files so it seemed sensible at this point to 'future proof' my library for future NAS/server software changes. I'm also aware it takes up a lot less space as FLAC vs WAV, and I have a lot of music.

 

Bruce

Originally Posted by Bruce Woodhouse:

I'm also aware it takes up a lot less space as FLAC vs WAV, and I have a lot of music.

 

What compression level of FLAC?

 

I recently converted everything from wav to flac and fixed/added all the missing metadata. Even on my UnitiQute i can hear a difference. Flac is quieter and more smooth, just as you have reported. I still have some wav albums in parallel with their newer flac cousins. All data comes from the same device and no 'conversion' takes place on the fly. I've not yet heard the results through my more resolving SU as it's too cold in the listening room atm.

My dbpoweramp program defaults to compression level 5. I'm no expert but this is about 'average' compression, files are now taking up about 40% of their previous size (obviously the metadata for each track has 'grown'!) At the moment I'm enjoying the flac more as I can turn up the Qutes and get them 'cooking', wav seemed loud and a little coarse, but the coarseness may be due to the lower level gain being used in the amp rather than the files themselves.

I have been experimenting with this all week. I find whilst there is a difference it is very small. I have come to the conclusion that Flac uncompressed gives the best trade off between tagging and sound quality.

 

My very favourite albums are stored in wav. I only use a unitiqute2 so not very far up the Naim tree. my collection is medium ish in size and it still took a reasonably fast computer and network 24 hours to convert from flac level 5 to flac uncompressed. This was using dbpoweramp.

 

The interesting thing is I hear a difference between this and asset serving up transcoded to wav material. Going to leave as is for a while to see if its all in my head or not.

 

I have experimented with some high def (24bit 96khz and 176khz) files from Qobuz which allows you to download multiple copies of purchased albums. I have run direct comparisons between the WAV and FLAC files offered by Qobuz; WAV is usally better BUT if I convert the FLAC downloads to Lossless FLAC using dBpoweramp then run these then I FLAC is better (and of course allows good tagging info using MP3tag).  The size of the files are the same in lossless FLAC and WAV by the way whereas FLAC as downloaded from Qobuz is usually about 65% smaller. (My system is NDX, DAC, 555PS, NAC 252, NAP 300 and Ovator S400 speakers. I use a Tranquil PC running Windows Home Server and Asset to serve the files to the NDX over a gigabit LAN run by a Draytek Vigor 2930n modem/router.)

Bonner, there is no difference to the audio contained  in lossless files by definition, which includes any inherent quality. However the process of unpacking the data from the files creates side effects that appear to interact with circuitry associated with audio replay. Therefore choose the format or steps that sounds most pleasing in your replay chain/replay equipment.

The beauty of lossless files is that if and when your system changes in the future you can re choose your formats or steps to suit your new equipment with no loss of information or any contained quality.

Simon

Picked up the free B&W Peter Gabriel 96/24 FLAC yesterday

 

I experimented with it to recheck my file format preferences (again) 

.flac as downloaded

.flac with no compression

.flac transcoded to .wav

.wav (all my albums are .wav)

.wav gets my vote again -- a touch more detail overall & a hint of more body in the bass

For those interested I now have my NDS. I think the flac files sound a fraction cleaner than the more juicy wav files back-to-back but the differences are far more subtle than they were with the HDX as the server. The NDS seems to do pretty amazing things with even a rubbish mp3 so I'm very happy with my flac library. My UPnP server does not have the option of flac to wav 'on the fly' conversion during playback.

 

I'll just get on with re-discovering my music with the new system again!

 

Bruce

 

 

Originally Posted by Harry:

Months from now you'll still be hearing the NDS serving up unexpected little delights on music you thought you already knew intimately. Nothing but fun awaits.

I have already been incredibly surprised by all sorts of nuances in favourite tracks I've played hundreds of times before. Not just dry detail but a lovely integrated whole. It also has some of the natural unforced musicality I recall from my old CDS3, and a bit of grit too when needed. I'm hugely impressed.

 

Bruce

What Bill said.  FLAC is designed to be very easy to decode, portable players can do it with ease.  That's why it takes far, far longer to encode in FLAC than decode.

 

One other thing mentioned, that CPU's must have more work to do decoding FLAC than WAV.  Well the WAV files are larger so the CPU is decoding for longer...

 

"On my PC, using Sysinternals Process Explorer (the benchmark tool for CPU usage analysis), playing a WAV file in Foobar required a scant 0.327 seconds of total CPU time from a single core of my multicore processor. This works out to about 0.2% CPU usage. Playing the exact same file in FLAC format, required 0.312 seconds of total CPU time—also about 0.2% CPU usage. These numbers are essentially the same, and the FLAC number is even slightly lower. Why? It’s likely because the CPU has to read half as much data with FLAC compared to WAV. But these numbers are so small, they really don’t matter. Other background tasks in the operating system consume far more CPU than FLAC decoding. So this alone should put the myth to rest."

Originally Posted by Big Bill:

WAV is rubbish for tagging data. 

I must remember that,  it seems I might be deluding myself over my many .wav albums that have ripped with the tag data.

Maybe you can tell me what .flac does that .wav cannot.  

 

Originally Posted by Mike-B:
Originally Posted by Big Bill:

WAV is rubbish for tagging data. 

I must remember that,  it seems I might be deluding myself over my many .wav albums that have ripped with the tag data.

Maybe you can tell me what .flac does that .wav cannot.  

 

WAV rips get locked metadata at source it appears. I can't change any metadata from my own ripped WAVs, although all purchased ones I don't feel any need to add more. My entire library is WAV but I am tempted to create a second FLAC library to help me with the metadata on my ripped DVD-As and BR discs, although DVD-AE uses a metadata library and allows changes before ripping.

Having said that all the UnitiServe CD rips are all fine for the metadata I require and are WAV. Hmmm...

Originally Posted by Mike-B:
Originally Posted by Big Bill:

WAV is rubbish for tagging data. 

I must remember that,  it seems I might be deluding myself over my many .wav albums that have ripped with the tag data.

Maybe you can tell me what .flac does that .wav cannot.  

 

FLAC uses the same system as mp3, WAV does not.  WAV files can be produced that do not allow many changes to tags and in fact...

In fact don't bother to read this please read Dan43's post above he has put it much better.

Originally Posted by Jota:

What Bill said.  FLAC is designed to be very easy to decode, portable players can do it with ease.  That's why it takes far, far longer to encode in FLAC than decode.

 

One other thing mentioned, that CPU's must have more work to do decoding FLAC than WAV.  Well the WAV files are larger so the CPU is decoding for longer...

 

"On my PC, using Sysinternals Process Explorer (the benchmark tool for CPU usage analysis), playing a WAV file in Foobar required a scant 0.327 seconds of total CPU time from a single core of my multicore processor. This works out to about 0.2% CPU usage. Playing the exact same file in FLAC format, required 0.312 seconds of total CPU time—also about 0.2% CPU usage. These numbers are essentially the same, and the FLAC number is even slightly lower. Why? It’s likely because the CPU has to read half as much data with FLAC compared to WAV. But these numbers are so small, they really don’t matter. Other background tasks in the operating system consume far more CPU than FLAC decoding. So this alone should put the myth to rest."

Jota that is very interesting.  The argument is that:

(a) WAV and FLAC send 'bit-perfect' streams to your player, whether wired ofWiFi - don't believe anyone who says different.

(b) FLAC requires more processing on your streamer so can cause the beast to heat up more than a WAV file, this will increase the noise floor.  There can be NO other way for WAV to sound better than FLAC.

 

But your observations seem to blow this out of the water - interesting.

 

You are quite right about the design of FLAC.  The goal was to produce a lossless compression system that required minimal processing to decode but was 'expensive' to encode.  Because you only encode once.

Originally Posted by Big Bill:
FLAC uses the same system as mp3, WAV does not.  WAV files can be produced that do not allow many changes to tags and in fact...

In fact don't bother to read this please read Dan43's post above he has put it much better.

OK,  I'm obliged Dan & Bill.  Seems I got it right when I ripped the 500+ that are OK as I see no reason to want to change what the rip has locked in.  

I do have 3 albums that do/did have issues,  x1 I fixed using dBpoweramp editing, it was a bit of a pain as its not listed on any of the tagging databases. I will dig out the other CD's & try ripping into .flac & see if that fixes the problems.

I use MinimServer which allows you to configure the decision tree, so to make that work I need to be able to edit the tag data.  But even if I didn't need to, I find that all the labels use a slightly different tagging scheme and the overriding principal of music tagging is CONSISTENCY!

 

Originally Posted by Big Bill:
Originally Posted by Jota:

What Bill said.  FLAC is designed to be very easy to decode, portable players can do it with ease.  That's why it takes far, far longer to encode in FLAC than decode.

 

One other thing mentioned, that CPU's must have more work to do decoding FLAC than WAV.  Well the WAV files are larger so the CPU is decoding for longer...

 

"On my PC, using Sysinternals Process Explorer (the benchmark tool for CPU usage analysis), playing a WAV file in Foobar required a scant 0.327 seconds of total CPU time from a single core of my multicore processor. This works out to about 0.2% CPU usage. Playing the exact same file in FLAC format, required 0.312 seconds of total CPU time—also about 0.2% CPU usage. These numbers are essentially the same, and the FLAC number is even slightly lower. Why? It’s likely because the CPU has to read half as much data with FLAC compared to WAV. But these numbers are so small, they really don’t matter. Other background tasks in the operating system consume far more CPU than FLAC decoding. So this alone should put the myth to rest."

Jota that is very interesting.  The argument is that:

(a) WAV and FLAC send 'bit-perfect' streams to your player, whether wired ofWiFi - don't believe anyone who says different.

(b) FLAC requires more processing on your streamer so can cause the beast to heat up more than a WAV file, this will increase the noise floor.  There can be NO other way for WAV to sound better than FLAC.

 

But your observations seem to blow this out of the water - interesting.

 

You are quite right about the design of FLAC.  The goal was to produce a lossless compression system that required minimal processing to decode but was 'expensive' to encode.  Because you only encode once.

I can't hear any audible effect from processor loads when playing via optical SPDIF from my Mini. I can be ripping and compressing DVD video (huge processor load) while playing audio tracks with iTunes. They never skip a beat sound the same (to me) as when the Mini is doing little else. Modern computers can do audio with incredible ease, as Jota notes. They don't break a sweat.

Technically FLAC holds metadata as 'Vorbis Comments' rather than the ID3 format of MP3, but the overall effect is the same.

 

However, in order to hold metadata, WAV files have to use proprietary formats.  Because ID3, Vorbis Comments or any other metadata formats aren't actually included in the MS WAVE specification, their use in WAV files is still proprietary.  So, since there is no standard for metadata for WAV files, it's unpredictable as to whether any particular software or device will support any particular scheme.  In fact it would be perfectly acceptable for a WAV file renderer or editor to report that a WAV file with tags isn't a valid WAV file.

 

Yes, I also know that most WAV file renderers (in fact possibly all real ones) actually ignore correctly formatted RIFF based extensions to the WAV format, but they are extensions.

 

 

You can add non-standard tags to WAV and they may or may not work.

Your choice.

Just don't blame the software or hardware if they don't work.

Huge, I think you and I have discussed this before exchanging links etc, but WAV does include meta data as part of it official specification (IBM/MS) - but not the simplified subset used for the latest MS consumer audio libraries. They are the List Info comments. It is the ID3 comments that were informally added. Agree List Info is very comprehensive and is more suited to commercial  use and not limited to consumer audio files and so its mapping to ID3 tag type info is open to some interpretation for some values. 

Of course a compliant WAV file reader may chose to ignore chunk IDs it doesn't recognise... That is a beauty of WAV in as far as it supports future developments and backwards compatibility.

 

Some popular WAVE meta data tag types used.

http://wavmetadata.blogspot.co.uk

 

Simon

 

Hi Simon,

 

Since this is an aspect of system programming, the answer is a little bit long as there are several parts to it.

 

 

I have looked this up and I am certain that I understand the position.  I have reviewed the detailed format definitions for both WAVE and RIFF (including the provided C++ sample code and header files).

 

Identification of metadata blocks is contained within the generic definition of RIFF, but not in the specific limited list of FOURCC identifiers for the WAVE subset.

 

Most (if not all) WAVE file renderers (including the Microsoft ones) are actually RIFF parsers, but ones that only interpret the WAVE subset data blocks (they ignore other RIFF data blocks with FOURCC identifiers that are not in the WAVE subset).

 

 

So using the underlying RIFF

As Big Bill says, in practice, Ogg Vorbis comments can be included.

In practice, so can ID3 (two different types).

In practice, so can any other Metadata anyone cares to define within an RIFF metadata block.

 

But these are relying on the underlying RIFF structure: as far as the WAVE format is concerned they are undefined & unknown RIFF blocks, as the FOURCC identifiers for them aren't specifically defined within the WAVE specification.

 

 

In other words within RIFF datasets you can choose to use whatever metadata format you want, provided it's contained in an appropriate block.  However, whether any specific reader can understand the format you choose is an entirely different question.  It doesn't have to read any metadata blocks.

 

The WAVE format doesn't help with this as it doesn't even define a FOURCC code for metadata (that's only defined at the RIFF outer layer and WAVE doesn't include the entire RIFF set of data block formats).

 

 

There is no practical reason why you should not include metadata within WAVE files; it simply may or may not work.

 

There is no onus on anyone writing a WAVE reader to read any metadata block at all.  There isn't even a definition of what format to use, should they even try to read it.  If it fails to read it or reads it wrongly, that's your hard luck, it's not a fault in the reader (unless the manufacturer specifically says it will read a particular form of RIFF metadata).

Hi Huge, indeed RIFF chunk IDs can be ignored..  But interestingly with OGG files which to my eyes are chunked sequenced packaged pages as opposed to linear chunked data as typically used in WAV there is no standardised (from my notes as of 2007) for incoporating metadata. Thefore with an OGG format the suggested recommendation is to use Vorbis Comment type value pairs within the codec chunk itself such as in Vorbis or FLAC. Therefore implementing Vorbis Comments in RIFF feels possible but would require some bespoke implementation coding, just as it has been for ID3.

 

Also the Vorbis Comments is a living list of expanding type value pairs.. Therefore even with Vorbis Comments it may be possible to come across types you can't parse, and so you need to handle that just as with RIFF, but this time it is within your codec parser as opposed to your file parser.

So I guess I am saying there are pit falls everywhere for the unwary 

 

Simon

 

 

I too tried the FLAC vs. WAV test some months back and couldn't distinguish between them.  I'm not trying to discredit others findings, just trying to add another viewpoint.

 

Both files were played through the same source chain (NAS / switch / NDS) to eliminate other differences.

 

While both are a lossless format, FLAC does offer different levels of compression and I wonder whether this is what people are hearing?  All my material is ripped to lossless uncompressed via dBpoweramp.

 

For those who can hear a difference, had you all ripped to lossless uncompressed?  If yes, just call me cloth eared

Originally Posted by Graham Clarke:

I too tried the FLAC vs. WAV test some months back and couldn't distinguish between them.  I'm not trying to discredit others findings, just trying to add another viewpoint.

 

Both files were played through the same source chain (NAS / switch / NDS) to eliminate other differences.

 

While both are a lossless format, FLAC does offer different levels of compression and I wonder whether this is what people are hearing?  All my material is ripped to lossless uncompressed via dBpoweramp.

 

For those who can hear a difference, had you all ripped to lossless uncompressed?  If yes, just call me cloth eared

All lossless uncompressed, however with NAS/HDX vs NAS/NDS as I said the differences much less obvious. Absolutely no mistaking through the HDX but with the NDS it is slight. I've stopped comparing now and just got on with enjoying stuff.

 

Cheers

 

Bruce

Originally Posted by Graham Clarke:

For those who can hear a difference, had you all ripped to lossless uncompressed?  If yes, just call me cloth eared

Erm Graham all uncompressed must surely be lossless.

 

The thing is that if you change anything in your file structures then you make life difficult for someone, so basically you get stuck with it.

 

Both mp3 and FLAC used the earlier Ogg Vorbis tag system, which is a very simple system and was proven.  A good decision in my book.

 

It is surprisingly easy to read off tag data from FLAC (or mp3) and I have been working on developing a system for reading my FLAC files and storing them in an SQL database.  That means you can make changes to the database and then 'implant' them back into your FLAC files.  The tage data is stored at the beginning of the file and is described here --> https://xiph.org/flac/documentation.html

 

Get yourself a copy of notepad++ and look at individual FLAC files with it.  That will show you what is happening.

Likes (0)
×
×
×
×