AudioCircle

Industry Circles => Bryston Limited => Topic started by: Music Matters on 3 Feb 2012, 03:53 pm

Title: FLAC Lossless Uncompressed versus WAV
Post by: Music Matters on 3 Feb 2012, 03:53 pm
I am relatively new to the BDP-1, so this is what I have done so far:

Bought new version of dbpoweramp and ripped my CDs to FLAC Lossless Uncompressed
Using SSD external drive
Using mpod on my iphone as control interface

So as I have read more, some questions have come to mind and I am hoping for some feedback:

1) Thoughts on audio quality between FLAC Lossless Uncompressed and WAV?

2) File size between the two formats is slightly larger with FLAC versus WAV. Anyone know why?

3) "Loss of metadata" and "WAV lack of metadata support" is what consistently appears in print that would seem to give the nod to using FLAC encoding. With dbpoweramp used to rip, and if I ripped to WAV, at what point or how is there "loss of metadata"?

4) With the BDP-1, is there any practical advantage to FLAC versus WAV using the various control interfaces: mpod, mpad, gnome, mini, max as far as how album art, song titles, etc. will display? I have only used mpod at this point.

Thanks very much for any replies. I am still learning!!
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 3 Feb 2012, 09:53 pm
1) Thoughts on audio quality between FLAC Lossless Uncompressed and WAV?
The end goal with both formats will be to provide a bit-perfect PCM stream that matches the CD.   It all comes down to how bug free the codecs are to encode and decode the intermediate file format.   Since WAV and AIFF are both older formats and they are bound to have less bugs than Flac:lossless.  Tag support is clearly a major advantage with flac and AIFF over WAV and FLAC takes this a step forward with it's checksum utility on the actual PCM data.   If AIFF, WAV or FLAC sound differently then there's most likely a bug in the software but could be user error, configureation, etc.  The sound cards only support PCM data, which at that point the data should match the CD.
Quote
2) File size between the two formats is slightly larger with FLAC versus WAV. Anyone know why?
FLAC supports file tagging, which will make the files slightly larger.
Quote
3) "Loss of metadata" and "WAV lack of metadata support" is what consistently appears in print that would seem to give the nod to using FLAC encoding. With dbpoweramp used to rip, and if I ripped to WAV, at what point or how is there "loss of metadata"?
Technically there's no loss of metadata because it never existed on the CD to begin with.  All ripping software looks up the "metadata" from a database to populate the artist, title, song names, etc.
Quote
4) With the BDP-1, is there any practical advantage to FLAC versus WAV using the various control interfaces: mpod, mpad, gnome, mini, max as far as how album art, song titles, etc. will display? I have only used mpod at this point.
The answer will vary by MPD client as some clients don't even look at tags in the file which provides no advantage for FLAC or AIFF tagging ability.    If you use the fat32 file system, there will be some special characters omitted or converted to an underscore "_"  and some situations that will covert short names to all lower case.   i.e. U2 will appear as u2 and Keb' Mo' will appear as Keb_ Mo_.    So if you use WAV (or other tagless file) clients that can read tags will revert back to the directory structure.   So AIFF or FLAC:Lossless would be the better choice IMO.   

I do like the idea of Flac's ability to checksum the data, but I have enough devices where FLAC isn't supported it's not my preference for 16/44.1 files.   For hi-rez files, flac seems to be the best option for now at least. 

Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: Music Matters on 5 Feb 2012, 10:20 pm
Thanks, skunark, for your reply. Doing critical listening, my ears and my wife's ears both come to the conclusion that WAV sounds more "right" than FLAC lossless uncompressed. We have done several listening sessions and each time have come to the same conclusion. Differences are subtle, but I would describe being able to hear into the music a bit more and bass a bit more punchy with WAV. Not a head over heels difference, but to our ears we'd give the nod to WAV. Perhaps using dbpoweramp the metadata issue is not something we need to worry about with either format, as you say dbpoweramp goes out to fetch metadata anyway.

I am assuming that cover art should display exactly the same regardless whether I rip to FLAC or WAV since there is always a cover art file for each album using dbpoweramp. Would that be your understanding, as well? I am also assuming album titles, artist names, and song titles will display the same regardless of which format is used?

Given your experience, is there any downside you see to ripping CDs as WAV?
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: Crimson on 5 Feb 2012, 11:42 pm
WAV is not portable with respect to its metadata. FLAC saves the metadata as part of its file, whereas WAV does not (it's stored separately). This can be a problem when switching playback programs, or changing machines (a major PITA).

Have you tried AIFF? It's a straight PCM file, like WAV, but can also store metadata as part of the file.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: Music Matters on 6 Feb 2012, 02:09 am
Crimson, thank you. I am not familiar with AIFF. As far as sonics, will it be identical to WAV? How does it differ from FLAC lossless uncompressed?

What I am also struggling with understanding is your statement "WAV is not portable with respect to its metadata". I am learning this stuff, and so far with the BDP-1 I am using my iPhone with MPoD to control - just very basic. I am planning to get an iPad and then use MPaD. What practical differences will I experience with album art, song titles, artist names, etc. as far as AIFF versus WAV? Is this the metadata you are referring to that is not portable? Thanks for enlightening my understanding.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 6 Feb 2012, 08:02 am
AIFF and WAV are both uncompressed PCM containers.

WAV doesn't have a standard way to store the metadata so each application stores the data differently and that metadata doesn't normally transfer.     

Apple Lossless(ALAC) another popular format, is more like FLAC where it can compress the lossless stream to save disk space.    Really the only advantage one has over any other for 16/44.1 files is usability.    I don't recommend ALAC with the BDP because certain files I've had issues with and since migrated to AIFF for CDs I've ripped.   

Using NIN The Slip downloads I don't hear a difference between the 24/96 FLAC and WAV files nor with the AIFF (converted from the WAV file).   I do feel the bass is sharper when compared to the CD or even the 16/44.1 AIFF file that I ripped.   With the BDP I find that all files sound better than other players and have pretty much stopped with that for now.    For kicks I have mixed both high res and cd lossless files of varying formats on the BDP and have yet to reliably pick them.  It's easier to spot hirez vs cd lossless but I'm still not perfect spotting them, but that is causal listening not a critical comparison. 
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: zolta on 7 Feb 2012, 01:34 am
i have seen this topic on many forms, and I am always surprised that someone would hear the difference between the two file types.  especially in this case where the flac file is not being compressed.  If a cd is ripped with the same hardware and software and then using the same hardware and software to convert the file to a wav file and then to flac, such as how EAC does this task, there should not be a difference in sound quality as it is all one's and zero's.  I have never been able to tell the difference between slightly compressed flac and wav.  There was a time when i was keeping both, so my portable could play the flac as they were smaller in file size, when i up[graded my DAC i did comparisons and could not hear the difference, and got rid of the wav files, to save space.  I would be curious to know if the the wav file sounds as good or better than the cd, which is my case.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: dlach on 16 Feb 2012, 04:11 am
With their March, 2012 issue, The Absolute Sound magazine concluded a 4-part project to evaluate and quantify every sonic variable in computer audio.  This includes comparing sonic differences between FLAC and WAV files, different ripping s/w, playback s/w, etc.  The authors, Dr. Charles Zeilig and Jay Clawson, offer specific recommendations that may surprise most of the folks on this thread.  For example, they claim that CD's ripped to WAV do in fact sound better than the same CD ripped to FLAC.

I'm going to try some of their recommendations and decide for myself.  The March, 2012 issue should be available on newsstands now.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 16 Feb 2012, 07:34 am
With their March, 2012 issue, The Absolute Sound magazine concluded a 4-part project to evaluate and quantify every sonic variable in computer audio.  This includes comparing sonic differences between FLAC and WAV files, different ripping s/w, playback s/w, etc.  The authors, Dr. Charles Zeilig and Jay Clawson, offer specific recommendations that may surprise most of the folks on this thread.  For example, they claim that CD's ripped to WAV do in fact sound better than the same CD ripped to FLAC.

I'm going to try some of their recommendations and decide for myself.  The March, 2012 issue should be available on newsstands now.

Just means the FLAC codec isn't as mature as the WAV then.   They all have the end-goal of producing a bit-perfect PCM stream.   It's real simple to check to see if the conversion is bit-perfect and also real simple to test the jitter at the output, for a given system.  If they don't provide this then their findings is just more hearsay, chances are they won't provide this detail since it's not even financially beneficial for them.   I will have to go to the newsstand though and read that article.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: NMG on 16 Feb 2012, 10:17 pm
If you go on Audio Asylum - Digital and Computer Audio, several engineers who would know say that the articles are full hooey. I have never been able to hear any difference between a CD ripped with DBPA into FLAC or Apple Lossless.

Neal
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: saisunil on 16 Feb 2012, 11:18 pm
There is so much to do with Transport as well ... PC vs. Mac OS to drivers to hardware to optimization

and who knows what ...
and then resolution of DACs and Players ...
and then some people are able to and care for the subtle differences more than others ...

There is so much more to computer audio than we / I currently know ... there is so much to explore ... if some people hear those differences - great - perhaps we can try or not care about it ...

Does not mean those who do hear the difference are lying or have a screw missing upstairs ...

Heck there are people who believe bits in and bits out are the same - whether they come from ipod or from high end transport ...
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 17 Feb 2012, 12:03 am
There very well could be differences, but a better comparison would be PCM vs DSD.  PCM is contained in the  WAV, AIFF, FLAC, ALAC and other files, different codecs, drivers and hardware can and probably do have bugs.   

So get a known good bit-perfect PCM stream and compare that to a known-good bit-perfect DSD stream.  That would be an interesting debate.     

Even checking the quality of various codecs for a given file type would also be interesting.  A good example is the nero AAC codec, vs Apples vs the less mature opensource AAC codecs.   Of course, folks wouldn't provide quality or performance benchmarks which is the key information and is much like you see with video codecs for TV and blu-ray reviews,
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: Music Matters on 10 Mar 2012, 12:44 am
Since I started this thread, I thought I'd report back. I abandoned all of my FLAC Uncompressed files and reripped using dbpoweramp to WAV and AIFF. I archived the WAV files and loaded the AIFF on the SSD external drive tethered to the BDP-1. I agree with the conclusion reached in the recent series of Absolute Sound articles comparing WAV to FLAC - that WAV exceeds the audio quality of uncompressed FLAC by a margin of 10% or so. It is particularly noticible in the lower end - overall pace of the music is improved with WAV or AIFF and the soundstage similarly improved by a margin. So I thank skunark (above) for the suggestion to use AIFF and for anyone starting out, I strongly recommend AIFF or WAV. I chose AIFF because of its better metadata support capability. Unless there is a compelling reason for you to chose FLAC, I wouldn't go that route. Have fun!!
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 10 Mar 2012, 07:41 am
Interesting findings. 

I know the BDP will work harder with FLAC and ALAC files since it has to uncompress them before shipping the lossless PCM data to the sound card.  You can watch the processor utilization and server load and see how much extra effort it takes.  That extra effort consumes more watts which is translated to heat, it's a pretty minute difference but maybe that plays a part.  In the end FLAC, ALAC, WAV and AIFF should be bit-perfect when sending the PCM stream to the sound card, so more likely there's a bug with the FLAC codec and probably something to revisit if there's any significant firmware updates with the BDP.   I haven't tried Flac:uncompressed but I believe it is a recent feature that might require a codec update for the BDP to take full advantage of the tweaked format.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: rbbert on 10 Mar 2012, 02:22 pm
With their March, 2012 issue, The Absolute Sound magazine concluded a 4-part project to evaluate and quantify every sonic variable in computer audio.  This includes comparing sonic differences between FLAC and WAV files, different ripping s/w, playback s/w, etc.  The authors, Dr. Charles Zeilig and Jay Clawson, offer specific recommendations that may surprise most of the folks on this thread.  For example, they claim that CD's ripped to WAV do in fact sound better than the same CD ripped to FLAC.

I'm going to try some of their recommendations and decide for myself.  The March, 2012 issue should be available on newsstands now.

As has been fairly well chronicled in many places on the Internet, including at least two other AC threads, the biggest problem with these recommendations is that the WAV > FLAC > WAV conversion process itself causes sonic degradation, an easily disprovable hypothesis.  So while real-time FLAC decoding and playback may (or may not, depending on hardware and software) be associated with altered sound quality, the magazine's articles in no way establish that.  Although I don't have a BDP-1, I 'd be a little surprised if a dedicated music player like it has audible problems decoding FLAC, but I don't really know about that.  If it does, a firmware update should improve or even fix it.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: groovybassist on 10 Mar 2012, 03:16 pm
I had previously ripped my CDs to FLAC and decided to do an experiment a couple of weeks ago - I ripped one well recorded cd to WAV, keeping the FLAC files. I then sorted the tracks, so that they alternated FLAC, WAV for each tune. While a casual listener wouldn't care about the difference, critical listeners definitely will. The most obvious thing was the soundstage collapsing to 1/2 size on the FLAC files. The WAV files had a much greater feeling of being at the performance. Subtle cues likes snares on a drum and differences between cymbals were much more obvious on WAV. I didn't want to reach this conclusion, as it meant I needed to re-rip all my stuff, but I'm in the process of switching everything to WAV.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: rbbert on 10 Mar 2012, 08:03 pm
Rather than re-ripping, did you try just decoding your FLAC to WAV?  I haven't tried ripping directly to FLAC, but I have ripped to WAV, then compressed to FLAC for storage.  Uncompressing the FLAC back to WAV then results in a WAV file identical to the original WAV both sonically and by data checksum.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: Phil on 10 Mar 2012, 09:28 pm
interesting results.  have to give this comparison a try with the BDP-1.  Did a comparison with AIFF, WAV and FLAC when I was using a Touch and preferred them in that order, but the BDP-1 could be different. 

FLAC has been sounding very good on the BDP-1...

Phil

Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: calinet6 on 10 Mar 2012, 09:30 pm
Hi. Computer scientist and algorithms expert (and audiophile) here to chime in. Interesting discussion so far, but I thought I'd respond to a few points. To preface this, let me say I am all for improving audio and the way we listen to it, and I find differences in DACs and transports and digital processing solutions to be a very worthwhile pursuit and I'm endlessly fascinated by those kinds of optimizations. However, FLAC vs. WAV is not one of them.

Quote
Just means the FLAC codec isn't as mature as the WAV then. They all have the end-goal of producing a bit-perfect PCM stream.

They don't just have the end-goal of producing a bit-perfect PCM stream, they both do produce a bit-perfect PCM stream. There is no problem with the FLAC lossless codec or its implementation. I know, I've tested it, and I've verified the algorithm and the underlying code. The digital stream coming from a FLAC file isn't just supposed to be identical to the WAV, it is identical, and provably so.

Quote
WAV exceeds the audio quality of uncompressed FLAC by a margin of 10% or so.

This is scientifically impossible. Were there a failure in the FLAC decoder or in the FLAC codec, the bitstream going into the DAC would differ. It does not, ever, 0% of the time, once again, provably beyond a shadow of a doubt.

Quote
... several engineers who would know say that the articles are full hooey.

This is 100% correct. The articles are describing a difference which is physically impossible and can only be the result of false perception or conflicting variables in the testing process.

Quote
While a casual listener wouldn't care about the difference, critical listeners definitely will. The most obvious thing was the soundstage collapsing to 1/2 size on the FLAC files.

This, too, is physically impossible. The digital stream output by your DAP is going to be 100% exactly the same from a FLAC or a WAV file, regardless of the decoding process or the format. They are the same bits, and bits are either on or off—there is no in-between. It's not possible. The only limiting factor in the digital processing is the transport and the DAC, which both come after the PCM stream is generated, and the PCM stream generated by the WAV and FLAC files from an identical source are mathematically provable to be identical. In short: if you hear a difference, you are making it up.

I realize this may be difficult to understand when we're used to describing such small and subtle differences, many of which I fully support, but this is one case where having a little knowledge of algorithms, mathematics, and provability comes in handy. This basically means that in the realm of computers and digital processing, there are certain things you can't argue against, things which are mathematical facts. And the provability of identical bitstreams is something we understand so very well that we can say that this is a mathematical fact, no ifs ands or buts about it.

Please let me know if anyone has any questions about this, I'd be happy to help you understand further. In the meantime, please feel free to encode all of your WAVs or CDs in FLAC format, and as long as you have players which support it, rest assured that your bit-perfect audio will remain at 100% of its original quality.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 11 Mar 2012, 09:56 am
They don't just have the end-goal of producing a bit-perfect PCM stream, they both do produce a bit-perfect PCM stream. There is no problem with the FLAC lossless codec or its implementation. I know, I've tested it, and I've verified the algorithm and the underlying code. The digital stream coming from a FLAC file isn't just supposed to be identical to the WAV, it is identical, and provably so.
Experienced EE here :)

Is there such a thing as bug free software?  I'm rather shocked anyone would consider flac or any codec bug free.   I assume your findings with flac is limited to a small subset of tests, but please do post your results, would be interesting to see.  I assume you are not aware about Flac's changelog (http://flac.sourceforge.net/changelog.html) and their bug tracker that can disprove your outcome.  There's several bugs there and that's not even the complete stack, so who knows what other bugs exist upstream or downstream of the codec!   Every codec is bound to have bugs even if the algorithms, mathematics and provability are sound...  Even how the software is compiled can introduce bugs which is why you see a big push for integer only compiles for these codecs.

I have experience issues with ALAC files on the BDP-1 that doesn't exist with other players.  These issues include hangs partway through a track and sometimes would pops/glitches between tracks and all reproducible.  Clearly some issue with ALAC and the BDP.  You can google about the quality of various AAC codecs and the issues there, but that is lossy format and will never be bit-perfect so might be a little uninteresting.   

A broader set of regressions with various hardware and software combinations will indicate there are bugs....

Quote
Quote
WAV exceeds the audio quality of uncompressed FLAC by a margin of 10% or so.
This is scientifically impossible. Were there a failure in the FLAC decoder or in the FLAC codec, the bitstream going into the DAC would differ. It does not, ever, 0% of the time, once again, provably beyond a shadow of a doubt.
Sure in academia where everything is ideal, you can formally prove they are equivalent, but in the real-world, there's a few more twists and turns.  I agree WAV, AIFF, ALAC and FLAC should be bit-perfect, but a difference might indicate issues, and yes it very well could be PEBKAC, but could otherwise indicate an actual issue for a given scenario.  My first hand issues with the ALAC files on the BDP does make me question all formats and all devices now.  I even greatly questioned FLAC for a spell since I had ALAC and FLAC intermixed.  I don't think any less of ALAC, and don't even have an issue using it on other devices, I just won't use it with the BDP until firmware is updated that has an upgraded codec.    Even Squeezebox users have reported issues around various codecs and how everything gets converted to FLAC before streaming.   

There are a few manufactures that will provide a test file or test cd that is used in conjuction with the DAC to test the quality of the transport.  (I believe you can do this with an HDCD if your DAC indicates it)  That's pretty nifty test, it's not a complete test by any means, but useful nonetheless. Out of the several thousand ALAC files I had, very few caused the hang or the glitches between tracks, we are probably talking less than .2% of a hard failure-rate that would easily fail any bit-perfect test for a transport.  Instead of debugging this further with ALAC, I just opted to switch to an uncompressed and more mature format.  Using the notion that all lossless formats are bit-perfect, assuming no bugs, I did switch to AIFF since it supports tagging.   

Now why would one feel that one lossless format is X% better than another, vs my experience where there was a huge failure in playback?    I think the squeezebox users probably could shed some light on this too.   And the OP is comparing flac:uncompressed to wav and aiff, so that's even yet a closer file format.   Perhaps it has to do with features like volume normalization with the playback (BDP is suppose to have that off with MPD) that is only enabled for one codec?  Perhaps there is a higher CPU load with one format over another burning more watts that could be raising the noise level.... tons of little possibilities...   I would agree that it's highly unlike there is an actual difference between the uncompress lossless formats, but I also don't mind scratching my head pondering why it could be different. 
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: JfTM on 11 Mar 2012, 01:11 pm
@skunark

Excellent post :thumb:
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: rompolompo on 11 Mar 2012, 02:19 pm
I agree with the conclusion reached in the recent series of Absolute Sound articles comparing WAV to FLAC - that WAV exceeds the audio quality of uncompressed FLAC by a margin of 10% or so.

Allow me to interject...

As FLAC is a compressed data set that represents the actual bit for bit of the original WAV, there are no differences in the files content wise. The issues I have seen are coming from poorly implemented applications that perform badly when readings FLAC files as they need to extract chunks of audio data while in memory. Since that process is done in real time, the better memory management the better the computer will execute its memory I/O.

The problem is that most audiophiles are not computer savvy and seeing the ways they conduct tests is laughable from any computer geek's eyes. On a properly setup PC, I can tell no different between lossless formats where else in a crappy PC with old codecs you can hear a difference. The beauty of the Bryston unit is that it takes away the requirements to properly set up a pc.

FLAC is here to stay. It is open, free and available;e on any platform. The meta data capabilities are a bonus.

Ran

P.S. Don't believe everything you read on the "Absolute Sound"...
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: rbbert on 11 Mar 2012, 03:08 pm
I agree with the conclusion reached in the recent series of Absolute Sound articles comparing WAV to FLAC - that WAV exceeds the audio quality of uncompressed FLAC by a margin of 10% or so.

Actually, the authors were careful to point out that the difference in their tests was not "10%", but rather 10 points on their visual-analog scale, not the same thing.   Regardless, though, in this area as in several others they are full of hooey.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: groovybassist on 11 Mar 2012, 04:50 pm
I chose to re-rip to WAV vs converting from FLAC to WAV to avoid a second conversion process. May or may not have made any difference, bUt that's what I chose.

In terms of sound quality, I'm only reporting what I heard and what I believe any skilled listener would hear, not why I heard it. The playback chain I used was identical in both cases. I have no idea whether the change in sound quality is due to the files themselves, processing, CPU, memory playback, etc., but it's nonetheless there. From my standpoint, it doesn't matter why one sounds better vs. the other, simply that it does and there's no reason I shouldn't take full advantage of the best sound my system can provide.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: calinet6 on 11 Mar 2012, 05:16 pm
skunark, agreed on all points. There's always a possibility that there's user error or another contributing factor, but given the difference between WAV and FLAC using the same source, it's generally going to be equivalent.

Also regarding bugs in the encoding itself, possible but very, very unlikely. If they ever did come up, it would be like you mentioned: blips or audible drop outs, not quality differences. As long as the music still sounds like music, then it's nearly 100% probable that it's exactly the same as the original. Also, FLAC employs a set of testing procedures called "unit testing," which ensure that all of its internal algorithms work correctly, so it's less likely that encoding bugs make it into the released version of the software. That is not to say that all decoders are equal, but again, as long as you can hear the music and don't notice blips or pauses, it's exceedingly likely the quality is exactly equivalent.

Thanks for the great and well-measured reply.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: rbbert on 11 Mar 2012, 06:08 pm
The Tape Project tapes (that are in print) are $300 per album, and some other companies that offer similar products are $500 per album.  For OOP the cost is usually higher but dependent on market variables.  I chose $7500 for a tape deck because that's about the cheapest you can find one, but to get one that would equal a $10k SACD player you would probably have to pay at least $10k.  But it's certainly your money to do with what you want, I'm just pointing out that the economics wouldn't work out for most audiophiles.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: srb on 11 Mar 2012, 06:19 pm
The Tape Project tapes (that are in print) are $300 per album, and some other companies that offer similar products are $500 per album.  For OOP the cost is usually higher but dependent on market variables.  I chose $7500 for a tape deck because that's about the cheapest you can find one, but to get one that would equal a $10k SACD player you would probably have to pay at least $10k.  But it's certainly your money to do with what you want, I'm just pointing out that the economics wouldn't work out for most audiophiles.

I think you're in the wrong topic?
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: WGH on 11 Mar 2012, 11:09 pm
I chose to re-rip to WAV vs converting from FLAC to WAV to avoid a second conversion process. May or may not have made any difference, bUt that's what I chose.


I'm going in the opposite direction and converting all my WAV files to FLAC. I think my playback solution (below) bypasses the FLAC vs. WAV controversy. I don't use a BDP-1 so this may be a little off topic regarding the Bryston player but it would be an interesting direction for the next version.

I don't know if the BDP-1 converts FLAC files on the fly like foobar2000 or stores the converted files for playback.The Stereophile review says:

"When a file is selected for play, the BDP-1 first copies the file from the external drive to an internal buffer, thus avoiding the usual jitter problems when data are streamed directly from a USB port. The BDP-1's soundcard outputs the stream via the player's S/PDIF and AES/EBU ports to feed an external D/A processor."

My solution is to use Mike Galusha's FlacWavLoader. The FWL converts FLAC files to WAV and stores them in memory for playback. The FWL can play a mix of files in a playlist so I have listened to songs that were converted from FLAC and then the the WAV version back to back and can detect no differences. FLAC downloads no longer have to be converted for best sound quality, disk space is conserved, and I have tags.

Further reading:
Thread: http://www.audiocircle.com/index.php?topic=100921.0 (http://www.audiocircle.com/index.php?topic=100921.0)
Website: http://www.mikegalusha.com/ (http://www.mikegalusha.com/)

Wayne

Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: groovybassist on 12 Mar 2012, 12:05 am
I'm not even sure what Mike's program does, but I use a Mac to stream these files and I believe Mike's program works on Windows only.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: WGH on 12 Mar 2012, 12:52 am
Yes, unfortunately Mike's program is Windows only. It is amazing for free software, FlacWavLoader turns my fanless low powered computer/music player into a memory player. I store music files on a main computer that is networked to the music player which is similar to but not as refined as the BDP-1. FWL is installed on the music player and can also access an internal hard drive, external USB drive, thumb drive, or a wireless connection to a server, pretty much anywhere music files are stored. It is pretty basic, no searching or playlist functions; it kind of works like vinyl - pick an album or songs from an album, convert and play using the software player of your choice (foobar, Windows Media Player Classic, maybe even iTunes)

Mac users would have to go to the dark side and install Windows7 using Parallels.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: Music Matters on 12 Mar 2012, 02:18 pm
Once again, since I started this thread, I will chime in. First of all, I am most appreciative of all of the information that has been offered, from the technical to the more subjective. I would like to clarify one mis-statement that I made about the Absolute Sound article (actually in the March 2012 response to a letter to editor) on the issue of FLAC vs. WAV. The threads herein are correct - the article said uncompressed FLAC bettered the parent WAV file sonically by 10 "points", not "percent" as I incorrectly stated.

Regardless, my point was that in my system and all other things being equal in the comparison, I found incremental sonic differences to WAV over uncompressed FLAC. I do not know from a technical standpoint why that is the case and quite frankly had been hoping that my ears were not correct since I had originally ripped all of my CDs to FLAC uncompressed. But there is a difference in overall sound quality that gives WAV or AIFF a slight edge in my system and anyone with a good set of ears listening to my gear in my room would likely have come to the same conclusion. Again, this is not an issue of a stunning difference. They are a bit subtle, particularly in the area of bass response, timbre, and soundstage. But the differences are there. Unknown why from a technical standpoint. Thanks again for all of the comments and information offered by all of you who continue to contribute to this topic!!
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: Music Matters on 12 Mar 2012, 02:33 pm
In my post above, the correct Absolute Sound issue is April 2012, under the letter titled "The Flack Over FLAC".
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: tonyptony on 12 Mar 2012, 03:02 pm
Many of us who've used Squeezboxes felt early on there was a small difference in sound quality between FLAC and WAV. After a bit of experimentation it seemed that sending the FLAC data to the SB and allowing it to do the FLAC->WAV conversion internally had something to do with the slight degredation in sound quality. As the SB server software is pretty well designed, it allows for the option of doing the FLAC->WAV conversion on the server side as an alternative. In my case (and in others') the server side conversion does make for a slightly better sound.

What I'm struggling with in particular in the AS articles is the conclusion that FLACs coverted back into WAVs did not sound as good as the original WAV rip. It's been shown by more than a few people that you could WAV->FLAC->WAV->FLAC->WAV all day long and the checksum and bit-for-bit exactness of the final WAV will match the original. I've done it myself (cycling through about 10 conversions) and I can't say the final WAV sounds any different than the original (yes the data checked out bit identical). Either I'm missing something or this conclusion in the AS article is questionable at best. I suppose it's possible if one used different versions of the FLAC encoder/decoder along the way, but even in that case I would think you'd eventually get a bit mismatch.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: rbbert on 12 Mar 2012, 06:03 pm
You can't get a bit mismatch in WAV>FLAC>WAV without an error message because checking checksums is part of the FLAC protocol.

There are many questionable conclusions in the TAS articles; in most thinking audiophiles' minds the only firm conclusion is that there may be audible differences between different hardware/software combinations.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 12 Mar 2012, 07:06 pm
You can't get a bit mismatch in WAV>FLAC>WAV without an error message because checking checksums is part of the FLAC protocol.
You are assuming that the convertor is generating a checksum for the WAV file at every step and comparing it to an online database?     

I think we are a bit hung up on the flac codec.    I think it's safe to say the conversion between WAV, FLAC, AIFF, or ALAC can be done correctly, sure bugs can exist here, but low probability.  The checksums help, but if the encode is bad to begin with then how useful is it?    Solutions like EAC are highly recommended, but still dependent on the drive used to perform the rip, makes you ponder why all rips are not equal..   

The difference in sound quality can be attributed to other variables, and more likely these other variables...   For example, how well do the application and sound card driver interact for a given codec.   With features like volume normalization, oversampling, upsampling, etc, there's enough options during playback that will alter the bit-stream.  It's very unlikely that the BDP is doing any of that, you can review the settings to find that it's not intentionally tweaking the PCM stream, but that doesn't mean there aren't other factors. 

It would be hard to agree with anyone that makes the bold statement that one lossless codec is simply better than all others with a big period..   It's also hard to agree with anyone that a given codec sounds better on a given transport, but to me, this is a little more acceptable based on the number of options we are faced with digital playback.

I would be curious to know what tests Bryson has performed with the BDP with the various file formats.  James if you are reading this, is this something you can share?

Btw, what is exactly is "10 points"?  Guess I should go read that article to understand their scale.     

Jim
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: brother love on 12 Mar 2012, 07:54 pm
Since I am in the infant stages of ripping 300 CD's or so, I am reading this thread w/ great interest .... and confusion.  :lol:

Oh, & for those interested, this topic was discussed in The Discless Circle last year by fellow AC members:

http://www.audiocircle.com/index.php?topic=92852.0

Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 12 Mar 2012, 08:05 pm
Since I am in the infant stages of ripping 300 CD's or so, I am reading this thread w/ great interest .... and confusion.  :lol:

Oh, & for those interested, this topic was discussed in The Discless Circle last year by fellow AC members:

http://www.audiocircle.com/index.php?topic=92852.0

I think it's safe to say this is directed towards the BDP, but yeah, this topic has been discussed numerous times generically and with other devices.   
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: rbbert on 12 Mar 2012, 10:17 pm
You are assuming that the convertor is generating a checksum for the WAV file at every step and comparing it to an online database?     

I'd have to go back to the FLAC page and review the exact protocol, but IIRC the WAV>FLAC encoding generates a checksum of the original WAV file and includes in the FLAC file.  When the subsequent FLAC>WAV conversion occurs, a checksum for the new WAV file is generated and compared to the checksum (included in the FLAC file) for the original WAV file; if they don't match, an error message is generated.  I don't know if this occurs with on-the-fly FLAC>WAV conversion, but there have been users who report that the digital output in this case still matches that of the original WAV file.  In my mind, that doesn't guarantee that there wouldn't be timing errors with the on-the-fly converted file (similar to what occurs without an asynchronous USB connection), but I really haven't investigated that possibility.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: adprom on 13 Mar 2012, 12:45 am
Experienced EE here :)

Does this mean you actually have a qualification, or you just happened to have done some technical work? For what its worth, I have a Bach Eng (mixture of electronic and software).

Quote
Is there such a thing as bug free software?  I'm rather shocked anyone would consider flac or any codec bug free.   I assume your findings with flac is limited to a small subset of tests, but please do post your results, would be interesting to see.  I assume you are not aware about Flac's changelog (http://flac.sourceforge.net/changelog.html) and their bug tracker that can disprove your outcome.  There's several bugs there and that's not even the complete stack, so who knows what other bugs exist upstream or downstream of the codec!   Every codec is bound to have bugs even if the algorithms, mathematics and provability are sound...  Even how the software is compiled can introduce bugs which is why you see a big push for integer only compiles for these codecs.

You attempt to confuse the real issue here. The flac codec, as has been shown across many many tests, produces a bit perfect ouptut. As many have tested, the bitstream output from the sound card is perfect to the original source. If there was a bug, then it would need to affect the actual ouput. Of course, what you are referring to on the bugtracker are things which are metadata related, or cause the software to fail completely. i.e. a buffer overflow is listed in that changelog. What you have failed to mention, is that none of the changes are affecting the integrity of the core encoding and decoding which has been shown to have excellent integrity.

No different to using a zip file on a computer.

The real test is, what you get in, is what you get out which holds true with flac. In fact, the encoder even tests it. It is in fact how I found out I had a faulty memory stick in my desktop - because the encoder was producing erroneous outputs and was telling me that it was!

So you have used a strawman argument to misrepresent the bug argument which doesn't hold.

Quote
I have experience issues with ALAC files on the BDP-1 that doesn't exist with other players.  These issues include hangs partway through a track and sometimes would pops/glitches between tracks and all reproducible.  Clearly some issue with ALAC and the BDP.  You can google about the quality of various AAC codecs and the issues there, but that is lossy format and will never be bit-perfect so might be a little uninteresting. 

So you've referred to a lossy codec.  Completed unrelated to the topic here and has no bearing whatsoever. As for the clicks between tracks, or hanging - then you are referring to potential glitches in the BDP-1 implementation - and nothing which happens to change the ouput - but are an outright fail. In particular, the pops between tracks has to do with an implementation of gapfree playback which has nothing to do with the codec. The codec is likely working 100% perfectly, but there is an unrelated glitch causing an issue. Not to mention, the way the codecs work - they aren't issues which question the integrity of the output of the codec here. You are confusing general usability and device bugs with the integrity of a codec. Different issues.

Quote
A broader set of regressions with various hardware and software combinations will indicate there are bugs....

What on earth are you talking about? What are these regressions? Does the zip format, for data file compression exhibit this behaviour?

Quote
Sure in academia where everything is ideal, you can formally prove they are equivalent, but in the real-world, there's a few more twists and turns. ..... Even Squeezebox users have reported issues around various codecs and how everything gets converted to FLAC before streaming. 

Actually no.... Plenty of people have verified the flac codec (amongst others) actually does what it says for the basic encoding and decoding functionality. Unless you have a hardware fault, it will work. Thanks to the error checking in the format - it will actually let you know if there is any loss of integrity! Don't try to confuse this with an academic argument to confuse the issue. This has practically been tested and verified.

A zip file doesn't just randomly not work when you decompress it. These things are not as complex as you are making out.

Quote
I just opted to switch to an uncompressed and more mature format.  Using the notion that all lossless formats are bit-perfect, assuming no bugs

Mature? You use the word as if software grows like a child - it does not - it is a discrete process... By nature of the way software is designed, especially something extremely mathematical such as the encoding and decoding, it can be mathematically proven that the core algorithm is bug free. Sure,might be some bugs to do with tagging etc, but that does not affect the core decoding and encoding functionality. If the lossless formats aren't bit perfect - they are found out very quickly.

Flac is no different to a zip file - using your theory, every so often a zip file should just randomly fail - because there is a bug. I have never had a zip file compression, or decompression fail (unless the archive is corrupt through other means).

Quote
Now why would one feel that one lossless format is X% better than another, vs my experience where there was a huge failure in playback?    I think the squeezebox users probably could shed some light on this too.

Because they want to. There are some squeezebox users who do some ludicrous stuff swearing by better quality. Most of it is people 'tweaking' for the sake of it and wanting to hear something better because they did something. A purely psychoacoustic effect.

Quote
I would agree that it's highly unlike there is an actual difference between the uncompress lossless formats, but I also don't mind scratching my head pondering why it could be different.

The truth is often far more boring than people like - and in cases such as the above, psychoacoustics is often the boring answer. The other, less boring answer is that the particular user has a hardware fault.

You are assuming that the convertor is generating a checksum for the WAV file at every step and comparing it to an online database?     

I think we are a bit hung up on the flac codec.    I think it's safe to say the conversion between WAV, FLAC, AIFF, or ALAC can be done correctly, sure bugs can exist here, but low probability.  The checksums help, but if the encode is bad to begin with then how useful is it?    Solutions like EAC are highly recommended, but still dependent on the drive used to perform the rip, makes you ponder why all rips are not equal.. 

As per my zip file comment, if the bugs you suggest above existed, they would have been found out a long time ago. Anything which affects the core functionality. Now you are confusing the issue by comparing different ripping drives. Well that is a real, but different issue. All rips are not equal, but for any given rip - the flac output and wav output are.

Quote
The difference in sound quality can be attributed to other variables, and more likely these other variables...   For example, how well do the application and sound card driver interact for a given codec.   With features like volume normalization, oversampling, upsampling, etc, there's enough options during playback that will alter the bit-stream.  It's very unlikely that the BDP is doing any of that, you can review the settings to find that it's not intentionally tweaking the PCM stream, but that doesn't mean there aren't other factors. 

A sound card doesn't even know what a flac or wav file is (usually). All it gets is a PCM stream. The application will simply use the codec for whatever container, decode it - get the output and send it to the sound card. So the application actually handles the file format. The output from the application to the sound card (or to the driver in most cases) will be identical. To suggest there is a difference is to suggest that the data must inherently be different somehow. At this stage of the process, it won't even affect jitter as the sound card, or output will buffer the stream anyway.

I haven't really covered jitter much. However, the main influence on jitter will be the hardware used in the output stage, or sound card. The data from the software decoding is buffered before it is output making the codec used irrelevant. I also saw the mention that cpu usage may effect noise etc... In hardware devices such as the BDP-1, there is usually a chip doing hardware decoding of the codecs before outputting it. Either way, if it is done in software, it hardly requires any processing power anyway. I'd be surprised if you can even measure any theoretical power increase.

Of course, it defeats the fun when we let good electrical and software engineering get in the way of the need for people to 'feel an improvement'.

How about asking for firm scientific evidence that there is a difference? I have certainly never seen any... Has anyone ever done an ABX test, and managed to verify the difference? I've seen this same argument on many forums - and the standard responses promoting differences always have a scattergun approach (essentially a FUD arguemnt) of loosely related computer analogies (i.e. software bugs, software regression, power usage, software/hardware integration or combinations) to justify the idea that there might be a possibility even though no objective evidence supports the concept.

In fact many of the arguments presented are entirely illogical as they would make computing as we know it impossible. We could never be certain of any behaviour with software. Yet somehow when it comes to audio, software and electronics somehow take on a far less predictable state and all these differences become possible.

Many of the lossless arguments are defeated simply by looking at how a rudimentary zip file works.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: adprom on 13 Mar 2012, 12:51 am
Just found a decent resource with some tests: http://thewelltemperedcomputer.com/KB/WAV-FLAC.htm

There is a quote at the end referring to people choosing wav 82% of the time - but nothing to back it up or testing methodology.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: rbbert on 13 Mar 2012, 03:02 am
ALAC is a lossless codec
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: adprom on 13 Mar 2012, 03:46 am
ALAC is a lossless codec

I realise that - I was referring to the comment about issues with lossy codecs. ALAC is just another format like zip, ra, tar etc
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 13 Mar 2012, 09:44 am
Does this mean you actually have a qualification, or you just happened to have done some technical work? For what its worth, I have a Bach Eng (mixture of electronic and software).
I've been doing digital design most of my life.

Quote
You attempt to confuse the real issue here. The flac codec, as has been shown across many many tests, produces a bit perfect ouptut. As many have tested, the bitstream output from the sound card is perfect to the original source. If there was a bug, then it would need to affect the actual ouput. Of course, what you are referring to on the bugtracker are things which are metadata related, or cause the software to fail completely. i.e. a buffer overflow is listed in that changelog. What you have failed to mention, is that none of the changes are affecting the integrity of the core encoding and decoding which has been shown to have excellent integrity.

No different to using a zip file on a computer.

The real test is, what you get in, is what you get out which holds true with flac. In fact, the encoder even tests it. It is in fact how I found out I had a faulty memory stick in my desktop - because the encoder was producing erroneous outputs and was telling me that it was!

So you have used a strawman argument to misrepresent the bug argument which doesn't hold.
Look at the "sync" bugs, those are more interesting.     Yes all the lossless codes have excellent integrity, that's why they can be called lossless, but that doesn't mean they are immune to issues.   I'm not stating one codec is better than the other, nor am I stating compressed vs uncompressed is better, but do note the increased load on the BDP.  CPU is mostly at idle with AIFF and WAV, but it utilized with ALAC and FLAC.  For most systems, it's probably not a big deal, but something that is optimized like the BDP, perhaps it plays a larger role. You also need to look at the entire software and hardware stack.   As the application calls the codec to convert the file to PCM for playback could be called differently with the application that encodes the CD and performs it's checks.    The encoder could use the provided executable under the hood while the media player could just link the library to offer a more memory efficient approach.  Perhaps we could even discuss all those switches and options...    As for zip, tar, bzip2, etc, there's bugs in those as well, rare, but they are there.   

Because one transport is shown to be bit-perfect with WAV files, that doesn't make all other transports that use WAV bit-perfect.  About all it states is that other transports could also be bit perfect with the wav codec.    Just like if FLAC sounds the best on one transport, doesn't mean it will sound better on another transport, it just means that the possibility is there.

We shouldn't be hung up on the codec though, they all have have damn good odds of being bit perfect.  Just are they bit perfect for a given transport. Again, one should look at the entire solution for the transport.       
Quote
Quote
You can google about the quality of various AAC codecs and the issues there, but that is lossy format and will never be bit-perfect so might be a little uninteresting.
So you've referred to a lossy codec.  Completed unrelated to the topic here and has no bearing whatsoever. As for the clicks between tracks, or hanging - then you are referring to potential glitches in the BDP-1 implementation - and nothing which happens to change the ouput - but are an outright fail. In particular, the pops between tracks has to do with an implementation of gapfree playback which has nothing to do with the codec. The codec is likely working 100% perfectly, but there is an unrelated glitch causing an issue. Not to mention, the way the codecs work - they aren't issues which question the integrity of the output of the codec here. You are confusing general usability and device bugs with the integrity of a codec. Different issues.
I will just restate this
" You can google about the quality of various AAC codecs and the issues there, but that is lossy format and will never be bit-perfect so might be a little uninteresting. "

As, I stated with calinet6, lets not try to talk past each other.   Just want to make it clear that i'm not questioning the integrity of any of the lossless codecs. 

The issues with AAC (yes the lossy codec and shouldn't be confused with ALAC) is an interesting google.  There's three main codecs, Apples, Nero and the open source version, guess which on you don't want to use...  The parallels here could be the same, perhaps ALAC, which has been recently open sourced, might have the same issues, many codecs were designed by reverse engineering, not from a standard.    Are there multiple versions of the FLAC codec? I don' believe so but guessing they would at different levels.   AIFF and WAV have various implementations, but it's rather hard to screw up the data if all you are doing is building a container. 

The glitches and hangups could entirely be how MPD interacts with the codec and the sound card driver if there is a failure.  Glitching has been common in several file and disc transports the PCM stream is muted between tracks or at the end of a playlist.  I've only noticed this with ALAC files on the BDP and not any other device.  Where do you think the issue is at?   If the MPD manages all codecs the same, then you would assume the ALAC codec is buggy, but might be how MPD controls the codec?         As for the hang, initially I assumed it was the metadata but since the hangups were in the middle and identical spot on the song, it's most likely an issue with the interaction of the codec and application.    I did convert that ALAC file to AIFF and had no issues, so doubtful it was the file.  I had several cause these issues, but once i could a resolution, I moved on.


Quote
What on earth are you talking about? What are these regressions? Does the zip format, for data file compression exhibit this behavior?
Sorry, I probably should have stated "regressions tests".  When you design that ASIC (aka those tiny black chips), regressions become your life.   Whether it's an encryption, adders, multipliers or other algorithms that has been tested with formal verification, or the serial busses that we've all come to love, they all go through months if not years of testing.  You don't get many chances to re-fabricate an asic, mistakes can cost around a million.   At least the software folks I've worked with, they also perform the same testing for their applications and device drivers.   If you have access to linux/osx/cygwin, feel free to download gzip's source code and type "make" and then "make check", they too perform regressions tests.  Most codecs will offer the same.    In my field you understand that the bug rates are always higher with newer designs and older designers get the boot when they don't make performance or power numbers, it's a fun balancing act.

Quote
Actually no.... Plenty of people have verified the flac codec (amongst others) actually does what it says for the basic encoding and decoding functionality. Unless you have a hardware fault, it will work. Thanks to the error checking in the format - it will actually let you know if there is any loss of integrity! Don't try to confuse this with an academic argument to confuse the issue. This has practically been tested and verified.
Again, the point i've been trying to make is that it's not just about the codec, its' the entire software and hardware stack both upstream and downstream of the codec.   

Quote
A zip file doesn't just randomly not work when you decompress it. These things are not as complex as you are making out.
Try using different OSes.. I've had a few gzip files not decompress and had to find go find the original OS and gzip version to decompress.  It's not as simple as some make it out to be...  Also consider resource limitations you have to watch out for when compressing and decompressing a file and those are outside of known good algorithms.   BTW the issue was between a Solaris and Linux machines...  annoying but easy enough to work around.

Quote
Mature? You use the word as if software grows like a child - it does not - it is a discrete process... By nature of the way software is designed, especially something extremely mathematical such as the encoding and decoding, it can be mathematically proven that the core algorithm is bug free. Sure,might be some bugs to do with tagging etc, but that does not affect the core decoding and encoding functionality. If the lossless formats aren't bit perfect - they are found out very quickly.
I think most IT, SW and HW folks will agree that software and hardware matures.   Consider the alpha and beta releases of software.  The version number for MPD would even make me believe it's still in beta or that they are being rebellious by not releasing a 1.0 product.   Rolling out a new product or OS build to your customers can be a handful when dealing with those initial bugs.     Consider the age for zip and gzip compared to flac and alac, zip and gzip both are more mature than flac and alas, but they still get updates and still have some pretty basic bugs.  i.e. 1020 characters in a filename can crash gzip..  Not sure you can have a filename that long on windows, so zip is probably in the clear for several more years.   

What features do most codecs and media players now have that can alter the sound?    Just because the codec has been mathematically proved to correctly encode/decode doesn't mean there aren't other forces at play.    (i feel very repetitive at this point....)

Quote
Flac is no different to a zip file - using your theory, every so often a zip file should just randomly fail - because there is a bug. I have never had a zip file compression, or decompression fail (unless the archive is corrupt through other means).
NSEU, great thing to google.   This is why workstations and servers use ECC memory and checksum data, you can get a neutron induced single event upset (random bit-flip) every few hours on a plane.   It's really not that black and white.. Of course we are talking about music codecs where the data is stored in memory for milliseconds, and clearly not a concern. 
Quote
Because they want to. There are some squeezebox users who do some ludicrous stuff swearing by better quality. Most of it is people 'tweaking' for the sake of it and wanting to hear something better because they did something. A purely psychoacoustic effect.

The truth is often far more boring than people like - and in cases such as the above, psychoacoustics is often the boring answer. The other, less boring answer is that the particular user has a hardware fault.
I agree PEBKAC and snake oil is rampant in this industry.    I'm always baffled why folks purchase expensive power cable (RLC), force their mac minis to boot in pure 64-bit mode (impacts cache?) , spend thousands of dollars for a .025 ohm resister that they mount in series with their speaker cables (again RLC).  At first glance I've ignored the claims.      I don't see how a pricey power cable could change the sound if plugged in to the wall, but perhaps there's something there with a power conditioner that has ample storage caps?    Why pure 64-bit vs mixed mode with OSX, this really baffles me, benchmark has proven that you can get bit-perfect output from the optical outputs on mac...   I do understand why the .025 ohm resister can impact the sound on speakers, just like using a longer cable. 

Quote
As per my zip file comment, if the bugs you suggest above existed, they would have been found out a long time ago. Anything which affects the core functionality. Now you are confusing the issue by comparing different ripping drives. Well that is a real, but different issue. All rips are not equal, but for any given rip - the flac output and wav output are.
With my previous response, i've stated that you have to look at the entire software and hardware stack...

Quote
A sound card doesn't even know what a flac or wav file is (usually). All it gets is a PCM stream. The application will simply use the codec for whatever container, decode it - get the output and send it to the sound card. So the application actually handles the file format. The output from the application to the sound card (or to the driver in most cases) will be identical. To suggest there is a difference is to suggest that the data must inherently be different somehow. At this stage of the process, it won't even affect jitter as the sound card, or output will buffer the stream anyway.
Yes, i've stated this in my first post of this thread and as well as others in defense of all these lossless codecs should be bit perfect.
Quote
I haven't really covered jitter much. However, the main influence on jitter will be the hardware used in the output stage, or sound card. The data from the software decoding is buffered before it is output making the codec used irrelevant. I also saw the mention that cpu usage may effect noise etc... In hardware devices such as the BDP-1, there is usually a chip doing hardware decoding of the codecs before outputting it. Either way, if it is done in software, it hardly requires any processing power anyway. I'd be surprised if you can even measure any theoretical power increase.
Very few computers and sound cards have codecs to the decoding these are all libraries that you can install.  For some formats, you can select between various codecs.  Most will support PCM, DSD and a few now AAC and default audio formats for H.264 (which might just be WAV, DSD and AAC).  From a shell (cygwin for windows folks) log on to the BDP (ssh root@bryton-bdp-1.local, password is bryston) and type top, you can monitor both load and cpu utilization.  Play a WAV, AIFF and FLAC, you can see the utilization vary, it even varies per song and with hi-res.   WAV seems to be the most efficient followed by AIFF.    You can actually measure power consumption on most newer systems today, not sure about AMD ALIX motherboards though.  I can check to see if the hardware is there, but it's normally a simple function of utilization.   You can watch most desktop cores jump from 35 watts idle to 130 watts at 100% cpu utilization.   The power supply will work harder and also heat up... It's not unlike claims that amps sound better when left on 24x7.  We probably could discuss the switching regulators on the ALIX board, I assume the custom linear power supply provides 12Volts to the motherboard, then it's up to the motherboard to provide the various other voltages required.

Quote
Of course, it defeats the fun when we let good electrical and software engineering get in the way of the need for people to 'feel an improvement'.
Some enjoy the talks some don't.   I've stayed clear from the hired debate on the other threads. How we hear sounds is a little more up for debate than how reliable a transport is.

Quote
How about asking for firm scientific evidence that there is a difference? I have certainly never seen any... Has anyone ever done an ABX test, and managed to verify the difference? I've seen this same argument on many forums - and the standard responses promoting differences always have a scattergun approach (essentially a FUD arguemnt) of loosely related computer analogies (i.e. software bugs, software regression, power usage, software/hardware integration or combinations) to justify the idea that there might be a possibility even though no objective evidence supports the concept.
With the correct test gear this is rather simple to verify.  ABX tests have aren't a good way to test gear, but that's what the OP did.  My only goal was to provide the OP possibilities on why he and his wife were hearing differences.  BTW, there's nothing stopping reviewers from crafting a benchmark for various codecs and perform a bit-perfect test on transports.  Several reviewers do this for the video codecs.

Quote
In fact many of the arguments presented are entirely illogical as they would make computing as we know it impossible. We could never be certain of any behaviour with software. Yet somehow when it comes to audio, software and electronics somehow take on a far less predictable state and all these differences become possible.

Many of the lossless arguments are defeated simply by looking at how a rudimentary zip file works.
Yeah, and we all know zip files don't have bugs either and if your entire counterarguement is to model a zip file... again, look at the complete environment.    Various filesystems, 32-bit vs 64-bit OSes, network drives etc all increases the complexity of compression utilities even though the algorithm is fine. 


These last few posts i believe i stated two key things:
1) all the lossless codecs should be bit perfect....
2) there are other factors that could make one file format sound better than the other.  Fault could be with the listener but there could also be other factors at play.   

Nothing FUD about that.. 

Jim
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: adprom on 13 Mar 2012, 11:27 am
I've been doing digital design most of my life.

So you aren't actually an engineer then?

Quote
Look at the "sync" bugs, those are more interesting.

Seen them - they aren't really anything that will affect sound quality. They are specific errors which will result in the codec returning an error. It does not indicate anything wrong with the integrity of the stream that would represent a change in quality at all.

Quote
but do note the increased load on the BDP.  CPU is mostly at idle with AIFF and WAV, but it utilized with ALAC and FLAC.  For most systems, it's probably not a big deal, but something that is optimized like the BDP, perhaps it plays a larger role.

Not if it is designed well and the digital outputs are properly buffered. Through basic buffering, any theoretical increase in jitter would be eliminated.

Quote
You also need to look at the entire software and hardware stack.   As the application calls the codec to convert the file to PCM for playback could be called differently with the application that encodes the CD and performs it's checks.    The encoder could use the provided executable under the hood while the media player could just link the library to offer a more memory efficient approach.  Perhaps we could even discuss all those switches and options...    As for zip, tar, bzip2, etc, there's bugs in those as well, rare, but they are there.

Rather than dispute you, how about you specifically highlight a bug or issue which has caused a change is playback quality? I am still seeing a scatterygun approach with "may do this" or "may do that". Lets talk about what actually happens in the circuit. Who cares what application calls the codec (in reality simply sends signalling code to the decoding chip to tell it which codec to use - maybe even through a mux if the codecs are on different chips). Either way, provided the codec is working perfectly, and producing the same bit perfect output from either, any decent buffering will eliminate any influences on jitter due to those specific chips.

If the output isn't bit perfect... then the device is broken. If it is bitperfect, then it is being buffered anyway.

Quote
Because one transport is shown to be bit-perfect with WAV files, that doesn't make all other transports that use WAV bit-perfect.  About all it states is that other transports could also be bit perfect with the wav codec.    Just like if FLAC sounds the best on one transport, doesn't mean it will sound better on another transport, it just means that the possibility is there.

If the transport isn't producing a bit perfect play back with WAV or FLAC, then it is broken or faulty. It is not working to specification. So providing it is a transport that works, yes it will be bit perfect. No different than being able to produce the same bitperfect playback across multiple PCs and multiple soundcards... There is nothing special in these media players as far as the processing goes.

Quote
We shouldn't be hung up on the codec though, they all have have damn good odds of being bit perfect.  Just are they bit perfect for a given transport.

Well yes... unless the transport is broken. A 4th year electrical engineering student should be able to get a bit perfect stream from a chip (I'm not saying a media player is an engineering student project - but the principles of how individual chips work are well understood).

Quote
I will just restate this
" You can google about the quality of various AAC codecs and the issues there, but that is lossy format and will never be bit-perfect so might be a little uninteresting. "

Why state it though, it has nothing to do with what we are talking about?

Quote
As, I stated with calinet6, lets not try to talk past each other.   Just want to make it clear that i'm not questioning the integrity of any of the lossless codecs. 


Well you are - you are questioning the integrity of the flac/wav playback from multiple transports which use those codecs. provided those codecs are working as advertised, they will produce a perfect output. From there, random bits shouldn't just be flipping to another value to make it non-bitperfect.

Quote
The glitches and hangups could entirely be how MPD interacts with the codec and the sound card driver if there is a failure.  Glitching has been common in several file and disc transports the PCM stream is muted between tracks or at the end of a playlist.  I've only noticed this with ALAC files on the BDP and not any other device.  Where do you think the issue is at?   If the MPD manages all codecs the same, then you would assume the ALAC codec is buggy, but might be how MPD controls the codec?         As for the hang, initially I assumed it was the metadata but since the hangups were in the middle and identical spot on the song, it's most likely an issue with the interaction of the codec and application.    I did convert that ALAC file to AIFF and had no issues, so doubtful it was the file.  I had several cause these issues, but once i could a resolution, I moved on.

You are making a lot of assumptions here which just happen to support your "quasi" view of how a media player works. The reality isn't that complex. Glitches and pops between tracks - often a syncing issue with the digital stream in the player independent of the codec. Quite a few devices have issues with that - and as I said, a closely related issue is gap free playback. In terms of a particular codec - at the start and end - it depends how it buffers the rest of the data. I don't have this information so it is impossible to say. It does not follow though, to assume the codec must be buggy.

Sorry, I probably should have stated "regressions tests".  When you design that ASIC (aka those tiny black chips), regressions become your life.   Whether it's an encryption, adders, multipliers or other algorithms that has been tested with formal verification, or the serial busses that we've all come to love, they all go through months if not years of testing

..... 

Try using different OSes.. I've had a few gzip files not decompress and had to find go find the original OS and gzip version to decompress.  It's not as simple as some make it out to be...  Also consider resource limitations you have to watch out for when compressing and decompressing a file and those are outside of known good algorithms.   BTW the issue was between a Solaris and Linux machines...  annoying but easy enough to work around.[/quote]

Ok, you have stated a few different things here - pretty much entirely unrelated to the issue at hand. Regardless of GZIP - we know that flac, AAC and WAV decompress perfectly fine on a range of systems. The codec used is the same. In fact, from memory the BDP just runs a highly customised flavour of linux. This isn't a hugely customised set of chips with unusual code being used bringing out unusual flaws.

Either way - you can easily test whether the transport is outputting a bit perfect signal. Simply record the digital stream, and compare it against the known file.... Either way, there is error checking involved so if there is an error - it won't simply be let through undetected.

I think most IT, SW and HW folks will agree that software and hardware matures..... Rolling out a new product or OS build to your customers can be a handful when dealing with those initial bugs.     Consider the age for zip and gzip compared to flac and alac, zip and gzip both are more mature than flac and alas, but they still get updates and still have some pretty basic bugs.  i.e. 1020 characters in a filename can crash gzip..  Not sure you can have a filename that long on windows, so zip is probably in the clear for several more years.  [/quote]

The core functionality is pretty stable though. Stuff like long length filenames etc, are loosely related issues that don't affect the core functionality. Your method of mentioning 'maturing' or software development is far more reasoned than the unexplained response you originally gave. Either way, it still doesn't have anything to do with codecs sounding different and how that would be the case if they are doing what they are designed to do, and verify as having done that.


Quote
With my previous response, i've stated that you have to look at the entire software and hardware stack...

Yet you don't actually explain in detail how it will make a difference to the sound if the codec is actually doing its job as advertised. Yes it is a stack, but you can pull out each component and see if it is doing its job. In fact, you can test the whole lot and see if the bitstream output matches the file! Even people with squeezeboxes have done this, rather cheap devices, and verified across multiple codecs that there is in fact no difference in the output. This has been verified multiple times.
 
Quote
From a shell (cygwin for windows folks) log on to the BDP (ssh root@bryton-bdp-1.local, password is bryston) and type top, you can monitor both load and cpu utilization.  Play a WAV, AIFF and FLAC, you can see the utilization vary, it even varies per song and with hi-res

I'm well aware how to do a remote ssh login. Either way, the fact that there is a change in utilisation, doesn't explain any difference. Whether the cpu is at 0% or 100% shouldn't affect the integrity and the output from the codec is buffered anyway.

You have stated an awful lot of technical stuff which shows you have a bit of technical competence, but for the most part has absolutely no bearing as to whether 2 codecs sound any different. It is basically a heap of loosely related theories, and issues described out of context in relation to the topic here. In fact, a majority of it isn't directly relevant at all and you have said a lot of what may happen - but you haven't actually tested to see if there is a difference.

Got a spectral output from the digital output? Got affirmative results from a properly run ABX test to show auditory differences which aren't induced psychologically?


Quote
These last few posts i believe i stated two key things:
1) all the lossless codecs should be bit perfect....
2) there are other factors that could make one file format sound better than the other.  Fault could be with the listener but there could also be other factors at play.   

#1 is correct, #2 is not. #2 has not been shown at all. You refer to these "other factors" without being able to describe how they actually change the sound at all, unless the software is actually faulty and not producing a bit perfect output. If it is not producing a bit perfect output, then the device is faulty. As I also said - the format differences have been compared on other devices and verified as producing the exact same output. I doubt the bryston is any difference. In fact, the boring but rational response would be that the listener is the variable here.

By definition, bringing up tech theories out of context, and by not being able to show how they directly cause the changes in this case, with absolutely no data is FUD.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 13 Mar 2012, 10:32 pm
Is 'bach eng' an associates in electronics or a general engineering degree?   
I figured with an associates in electronics one might actually have had circuits class with an introduction to digital design (http://en.wikipedia.org/wiki/Digital_design).   As I stated before I am an EE (http://en.wikipedia.org/wiki/Electrical_engineering), which implies the degree. 

Quote
Not if it is designed well and the digital outputs are properly buffered. Through basic buffering, any theoretical increase in jitter would be eliminated.
If the gain changes on the buffer, slew rates change, which will impact jitter.  Additional buffering does theoretically increase jitter, not eliminate it as you staed, there's huge amounts of research on this topic and is huge engineering challenge for ICs.   Also, the design needs to handle real-word tolerances that can be influenced by many factors.   Probably a distinction that the actually designer of the buffer would understand vs someone selecting between various circuits or vendor solutions.

Even if you loosely called a asynchronous fifo a buffer, you still won't eliminate jitter by the output driver (buffer) or the clock oscillators... and that assuming there are no issues recovering the clock from the input stream. 
Quote
Lets talk about what actually happens in the circuit. Who cares what application calls the codec (in reality simply sends signalling code to the decoding chip to tell it which codec to use - maybe even through a mux if the codecs are on different chips). Either way, provided the codec is working perfectly, and producing the same bit perfect output from either, any decent buffering will eliminate any influences on jitter due to those specific chips.
The BDP doesn't have a hardware codec for FLAC, nor does MPD and ALSA hasn't been configured to support hardware codecs. Just review the mpd source code, there's clearly calls to the APIs, review the ALSA configuration file, or review the capabilities of the sound card (esi juli@).  You can even see a compile time option in the source (http://git.musicpd.org/cgit/master/mpd.git/tree/src/decoder/flac_decoder_plugin.c) to select between different versions of the sw flac API for one example.   Feel free to identify any such flac codec chips in the BDP.  It's not on the ALIX (http://pcengines.ch/alix1d.htm) motherboard, ESI Juli@ (http://www.esi-audio.com/products/julia/) sound card or even with MPD's interaction (http://git.musicpd.org/cgit/master/mpd.git/tree/src/output/alsa_output_plugin.c) with ALSA driver nor with ALSA's configuration. 

There are hardware codecs that do exist in the wild, but mostly have been AAC and H.264 (if not combined) and typically have custom drivers for very controlled devices.

...
Quote
If the output isn't bit perfect... then the device is broken. If it is bitperfect, then it is being buffered anyway.

If the transport isn't producing a bit perfect play back with WAV or FLAC, then it is broken or faulty. It is not working to specification. So providing it is a transport that works, yes it will be bit perfect. No different than being able to produce the same bitperfect playback across multiple PCs and multiple soundcards... There is nothing special in these media players as far as the processing goes.
Reports about Squeezebox and other streamers come to mind here.   Even the older USB DACs have had issues with this.   Nothing there would state that the codec is bad, just the implementation needs improvement. 
Quote
Well yes... unless the transport is broken. A 4th year electrical engineering student should be able to get a bit perfect stream from a chip (I'm not saying a media player is an engineering student project - but the principles of how individual chips work are well understood).
An Electrical Engineer would be designing the chip implementing the algorithm with a new angle on efficiency, not building a media player from various chips like an Electronics Engineer would probably do.  Otherwise I would be questioning both the school and the engineer during the interview.

Quote
I'm well aware how to do a remote ssh login. Either way, the fact that there is a change in utilization, doesn't explain any difference. Whether the cpu is at 0% or 100% shouldn't affect the integrity and the output from the codec is buffered anyway.
Please bear with me here, assuming WAV and FLAC have been shown to be bit-perfect on a given setup that has galvanic isolation, are you making the claim that the power or power supply won't impact the jitter at the buffers?  Pretty bold statement if that is your claim. 

Think about the clock oscillators as well and how the power planes react on a PCB board when power consumption changes, digital circuits can tolerate those changes, but the analog paths can't.    The analog signals (aes ebu or bnc) carrying this source-synchronous digital information (which most folk call digital signals) have rise and fall times that will vary based on the power of the drivers adding to the jitter already incurred by the clock oscillators.  The DAC now has to deal with this jitter along with adding it's own.   Even the synchronizing DACs like the BDA are not immune jitter, but guessing you know about that.

Quote
You have stated an awful lot of technical stuff which shows you have a bit of technical competence, but for the most part has absolutely no bearing as to whether 2 codecs sound any different. It is basically a heap of loosely related theories, and issues described out of context in relation to the topic here. In fact, a majority of it isn't directly relevant at all and you have said a lot of what may happen - but you haven't actually tested to see if there is a difference.
I've stated them as possibilities, nothing more.  I've even stated that I can't reliably pick various files formats or even reliably select hi-rez.    And you have yet all you have come up with it's like a zip file, assume bugs don't exist, thought ALAC was lossy, incorrectly assumed there are muxing hardware codec chips on the BDP, buffering eliminates jitter and bordering on personal attacks.

Quote
Got a spectral output from the digital output? Got affirmative results from a properly run ABX test to show auditory differences which aren't induced psychologically?
and you?   
OP and the random folks claiming that WAV sounds better than FLAC.  I'm with you, I don't hear it and at the 1s and 0s level, don't even expect it, but that's also not conclusive evidence that they are full of shit.   Luckily the MPD is configured to be bit-perfect, folks that enable volume control and normalization, or even DSP effects like room correction have started down the path of integer only playback and whole new level of complexity.

Also ABX tests are not reliable, just the volume is enough to sway the outcome.  They might shed some light, but nothing conclusive, besides I would rather see the results from an actual test.  If your dac has the HDCD indicator, that's a pretty simple test try with the various file formats, probably not conclusive though.

Quote
#1 is correct, #2 is not. #2 has not been shown at all. You refer to these "other factors" without being able to describe how they actually change the sound at all, unless the software is actually faulty and not producing a bit perfect output. If it is not producing a bit perfect output, then the device is faulty. As I also said - the format differences have been compared on other devices and verified as producing the exact same output. I doubt the bryston is any difference. In fact, the boring but rational response would be that the listener is the variable here.
At least you agreed with the "should' part and vs it being fact. :)

I would agree that listener is the primary variable here, I would even agree that the output should be bit-perfect independent of the lossless codec utilized, and i would probably go as far as saying all devices providing a bit-perfect output have same potential to sound the same.   However, I would disagree it's that black and white as you make it out to be.   

The beauty of the BDP is how simple it is... linear power supply, extremely low-power computer, class-a output stage, all focused on reducing noise that could interfere with the downstream gear.  Even schematics to look over, access to view the linux environment, it's a pretty open and transparent setup to be honest.   There's a very limited amount of things to blame especially compared to a computer with a USB DACs.   The BDP also has it's faults (alac for me), but they are all very minor and easily worked around.   

Quote
By definition, bringing up tech theories out of context, and by not being able to show how they directly cause the changes in this case, with absolutely no data is FUD.
Well by your definition, you are fighting FUD with FUD then...   Zip files.. lol

Again, i've never made the claim one format is better than any other, just noted a few possibilities why one might notice a difference for a given system even using bit-perfect lossless files.   There are probably hundreds if not thousands of reasons why a user might hear a difference between codecs on the hardware and software fronts without even discussing the analog front, which apparently you are blind to even consider the possibility. 

Jim
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: adprom on 14 Mar 2012, 02:51 am
My engineering degree is in Australia. I'm not quite what an associates in electronics is as there is no such thing here. Logic synthesis from your link was covered in our coursework as was circuity design etc. Bach eng was short for bachelor of engineering... Electrical and electronics design is covered.

You seem to be referring to a buffer amplifier, not a data buffer.

Your point about the lack of hardware decoder is taken, but also largely irrelevant. The cpu is rather specific - i.e. it isn't an i7 in there pulling 40w of power. Simply decoding a flac file is not a power intensive task, and wouldn't increase power usage to a level where any theoretically increased noise would affect the jitter. The suggestion of that is throwing ideas out there - not making a valid claim. You could also say that the wav file means the device has to read extra data from the source and use extra power... That is the margin of difference we are looking at here. Not intensive tasks at all.

Hell the squeezebox didn't even record an increase in jitter when using the extra power required by wifi! - http://www.stereophile.com/content/logitech-squeezebox-touch-network-music-player-measurements - To suggest flac vs wav would be responsible is a stretch

I never said power supply won't affect the jitter at the buffers. But the increase in cpu seen, won't have any effect on the induced noise from the power supply based on any theoretical increase.

Quote
I've stated them as possibilities, nothing more.

Which is the entire problem - there are theories out there to justify what people think they hear. Nothing about what is actually happening, or the less convenient (depending on how you look at it) truth that people want to hear a difference. It becomes religious at this point. It is like your theory on bugs - it just doesn't follow. A bug on functionality but not related to the core decoding functionality is the classical strawman argument. lets grab all the theory about computer code bugs, and try and loosely adapt them to this situation to provide an explanation. Based on that sort of logic, people shouldn't store their money in a bank, because there is always the potential that some bug won't complete transactions properly - and there must be a bug somewhere in the core because it is software! It is all unverified claims, to justify yet another unverified claim.

Lets prove that a difference between the actual formats exist before debating what might actually cause it... Of course, it shouldn't be that hard to prove. As an engineer yourself, you should be open to an objective testing criteria. Surely something like an ABX test should show up any difference consistently? Barring that and the issues with ABX tests (that they can only prove a difference, not a lack of) - then surely a spectral analysis of the digital output should. That said, they are also not full of shit. If a perceivable difference actually exists, they will show it.

It is not up to me to provide this evidence as I am not the one making fairly extraordinary claims. I'm not the one using loosely related concepts which have little relevance to the topic to apply them. Flac files for all intents and purposes use a form of compression analogous to data file compression - so it is a perfectly valid comparison. Not FUD.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 14 Mar 2012, 07:09 pm
You believe a data buffer is going to eliminate jitter?   Where is this jitter eliminating buffer you dream of?   At most it will help deal with underflow in the scenario you seem to be talking about.   Yes there are clearly fifos acting as data buffers and synchronizing fifos found at all the pcie devices (sound card, usb device, etc), but there's not jitter with the data (it's not even a pcm stream yet).  If you done STA, one should know how a clock tree is built, how everything is timed all within the chip, how to handle different clock domains, but this is when you have a dedicated clock moving data around. 

For audio, Jitter is introduced once the signal becomes source-synchronous (i.e. the data is the clock), which is about the time the sound card starts to drive the signal out.   

...

Read the entire paragraph a change was noted other than jitter....  Interesting note on how it up-sampled one format unexpectedly, and the power supply noise (look the graphs around 60hz)...  Also the BDP is a much more tuned product with a much better noise floor and jitter specs than the squeezebox touch, which would make the BDP more sensitive assuming one can hear a difference between the two players.    If the squeezebox touch is anything like the Apple TV (gen 1 or 2), there's a significant improvement when compared to the BDP.    The stereophile review of the BDP does indicate it's bit-perfect accuracy, but flac wasn't in the test list, would have been nice if it was tested. 

You still paint it as black and white, even the review with the squeezebox touch indicated an unexpected issue. 


Jim
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: adprom on 15 Mar 2012, 02:39 am
With the squeezebox, I am not sure a jump in noise at 60Hz is exactly unexpected given the switch mode power supply. This is exactly why some use a different, higher end power supply on the unit. It certainly has no implication that different processing implies different noise levels - simply that the power supply used induces noise. The spectral bump is also noted as being negligible. I don't think anyone would say that a slight increase at 60Hz is unexpected (or 50Hz here in Aus). Upsampled one format unexpectedly? From memory, there is setting which allows you to specify what happens with 32Khz sampling rates. On mine, with a 32KHz signal, the DAC lights up with 32Khz. I am pretty sure you can actually customise what happens. Either way it will simply be a software switch. The real point was that by using higher power, higher cpu use and using wifi on the SB touch as compared to LAN or USB had NO effect on the jitter) - it is hard to think that something like changing a file format would somehow affect it. That is the real question, not whether a power supply by default would induce some noise. Of course that is expected to some level - especially with a cheap PSU.

As for whether it is bit perfect - the suggestion that it isn't (provided there is no post processing, and volume is locked at 100%) is ludicrous given it has been tested and verified multiple times - it really is just clutching at straws with a significant creative license.

As for using a data buffer. Data from a wav or flac file doesn't have a clock in itself - it simply indicates what the clock is. From there, by rebuffering the data, and realigning it to the clock used, you can decrease any jitter, induced in the codec output, or direct hardware. You essentially store the data in a fifo buffer and it is reclocked anyway. Provided the buffer is working correctly, and the jitter isn't so high that samples are incorrectly being stored - then the buffer decouples the data from the original ouput. This is essentially what a reclocking dac does anyway to minimise or eliminate the original jitter (of course it can still induce its own before the data gets to the DAC circuit).

It isn't as convoluted as you are trying to make out. You are trying to use 'fringe physics' to explain a phenomenon that doesn't actually exist. Just like you attempted with the 'catch-all' software bugs argument.

Once again, care to show any evidence at all of the pseudo-science that you are suggesting is possible? Got any outputs showing an incorrect data stream for flac vs wav, or increased noise on the power rails due to a different format being used? Until you produce some evidence, you essentially have a religious argument.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: BrysTony on 15 Mar 2012, 04:00 am
Yawn...
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 15 Mar 2012, 04:28 am
"What harmonics of the low-frequency squarewave can be seen above the noise floor lie at the residual level, though the central tone is widened at the base due to random low-frequency jitter."

I read that sentence as a change with the wireless stream...vs usb.. perhaps it was a general statement.

", with the exception of 32kHz-sampled material, which appeared to be upsampled to 96kHz."
The unexpected up sampling... yet you disregard that since now it's customizable...since we are trusting the measurements I can assume the reviewer would know if it was customizable then.    Not sure what else to say on that.  I agree it's unlikely the BDP has a configuration issue with FLAC, but it's not unlikely, sadly the stereophile review didn't test to confirm with flac.  It would have been much easier to have the OP to review that article.  Perhaps there are other reviews out that does indeed test the bit accuracy of flac with the BDP. 

Off topic, but you don't seem to understand the definition of source-syncronous and how it fits into the picture with jitter.    In a very simplified view, cachelines of the file will be moved to system memory (or direct to the cache), unpacked and then sent to the sound card, all of this is based on the system clock, jitter hasn't been introduced here.   The sound card will pop the data from the fifo and at a rate required by the PCM stream, this is where jitter starts for the PCM stream and this is where the data becomes source-syncronous.   All dacs will use this PCM data stream to regenerate the clock (pll), dacs can either use this regenerated clock or resynchronize with higher precision clock as what you are attempting to describe, (not a function in the BDP btw).  Jitter is never eliminated with either solution, but it's greatly reduced with dacs that re-clock the stream using a crystal that is more precise.  So for a dac that doesn't reclock, the BDP will have more influence on the overall jitter, for a dac that does reclock, it all really boils down to how precise the crystal used.  If this reclocking is done outside the dac, hopefully it's converted to i2s so that jitter isn't compounded.

As for evidence, it's not that hard, you can continue to read the stereophile reviews between the squeezebox touch and the bdp and note how the noise floor is different.  Both are sharing the same SW based codecs, and with your zipped file analogy both will be equal.     But before I provide more so-called fud, first i've never said that the power supply would prevent a bit-perfect stream.   Clearly a change of the voltage or even noise could impact the rise and fall times of the aes ebu output, you should understand that.   So the squeezebox can maintain it's jitter whether wireless is on or off, but there was that comment in the review.. perhaps that was meant in the general since.   Ignoring your zip analogy, which one do you think will sound better?   

Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 15 Mar 2012, 04:28 am
Yawn...
I totally agree...
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: AgentOrange on 15 Mar 2012, 04:30 am
"Yawn..."  is a good reply and says a lot.
This has been and will be argued with similar formats forever.  It is good fun and I like to read it all.

At the end of the day it takes really good equipment and an experienced "listener" to find a slight difference in the real world.

It is all a good party tool.  Get in some friends and some booze and do blind tests.

Have some fun with it.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: adprom on 15 Mar 2012, 05:36 am
I read that sentence as a change with the wireless stream...vs usb.. perhaps it was a general statement.

I can't see what it is being compared to. The only specific comment about wireless vs usb was "Finally, the Squeezebox Touch's jitter performance remained unchanged, whether it was playing the 16-bit diagnostic Miller-Dunn tone via WiFi or stored on a USB-connected drive".

Quote
The unexpected up sampling... yet you disregard that since now it's customizable...since we are trusting the measurements I can assume the reviewer would know if it was customizable then.

I don't disregard it. If it is a bug, then it falls in the category of functionality bugs or where the device isn't doing what it said it would. It isn't just possibility if random behaviour of the bitstream changing which is what you have tried to argue due to 'bugs'. That isn't a case of a bug causing small changes in sound quality at a given rate. Outputting at the wrong sampling rate is a different class of problems to what we are talking about. The assumption is that the basics are actually right to begin with - i.e. outputting at the same sampling rate as the source.

Quote
The sound card will pop the data from the fifo and at a rate required by the PCM stream, this is where jitter starts for the PCM stream and this is where the data becomes source-syncronous.   All dacs will use this PCM data stream to regenerate the clock (pll), dacs can either use this regenerated clock or resynchronize with higher precision clock as what you are attempting to describe, (not a function in the BDP btw).

Which doesn't explain how the different decompression techniques (or decompressing vs uncompressed) could induce further jitter.

Quote
As for evidence, it's not that hard, you can continue to read the stereophile reviews between the squeezebox touch and the bdp and note how the noise floor is different.  Both are sharing the same SW based codecs, and with your zipped file analogy both will be equal.

I never said the noise floor for different devices will be the same. In fact the power supplies are different, and as such will produce a different noise signature. What I have argued is that the processing and file format used is highly unlikely to affect that noise signature. No one is saying that 2 devices with different PSUs will produce the same noise floor.

Quote
But before I provide more so-called fud, first i've never said that the power supply would prevent a bit-perfect stream.   Clearly a change of the voltage or even noise could impact the rise and fall times of the aes ebu output, you should understand that.

I don't think anyone disagrees that the power supply has an effect upon those things. However you have tried to argue that the file format used and associated difference in processing would affect the power supply enough to change the noise floor - theoretically affecting jitter.

Quote
So the squeezebox can maintain it's jitter whether wireless is on or off, but there was that comment in the review.. perhaps that was meant in the general since.   Ignoring your zip analogy, which one do you think will sound better?

I've tried it both with wireless and without. It sounds no different.

Either way, you have provided absolutely no empirical evidence supporting your theory in practice. I haven't seen any measurements which show different jitter measurements on the same device (all things being equal) when playing back flac vs wav (or measurements showing one codec is more buggy and leads to less bitperfectness than the other).
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: srb on 15 Mar 2012, 06:07 am
I've tried it both with wireless and without. It sounds no different.
 
Either way, you have provided absolutely no empirical evidence supporting your theory in practice. I haven't seen any measurements which show different jitter measurements on the same device (all things being equal) when playing back flac vs wav (or measurements showing one codec is more buggy and leads to less bitperfectness than the other).

For every person who says "I've tried it both with wireless and without.  It sounds no different", there is another person who has said "I've tried it both with wireless and without and there is a substantial difference".  The same with WAV vs AIFF vs FLAC.
 
In that respect, your completely subjective evaluation is no more or less valid than theirs.
 
If you argue that there is no measurable data difference you will be presented with the argument that there are other electrical and acoustic phenomena at play that either have yet to be discovered or properly measured.  From the time I've spent on audio forums, I find that many audiophiles feel that science just gets in the way of their ears, heart and brain.
 
Steve
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: adprom on 15 Mar 2012, 06:39 am
If you argue that there is no measurable data difference you will be presented with the argument that there are other electrical and acoustic phenomena at play that either have yet to be discovered or properly measured.  From the time I've spent on audio forums, I find that many audiophiles feel that science just gets in the way of their ears, heart and brain.

Yet the people who design the equipment rely on the measurable differences. Thus making it a religious belief rather than scientific argument when people rely on "we can't measure stuff" etc. You cannot prove the lack of something, only that something is different. I haven't been able to do that, and I haven't seen any scientific data saying otherwise. The onus is on the entity saying there is a difference to show that there is.

The problem is that the science often disproves or gets in the way of how the listeners feel when the differences they hear are essentially the placebo effect. I've even seen people trying to argue that the type of NAS they use affected the sound - i.e. data packets. Surely if those differences exist, and can't be measured electrically - then the audible differences would be able to be verified via an ABX test?

Those who are religious justify their beliefs in much the same way audiophiles try to justify immeasurable differences - hence the comparison. The difference is that religion in itself is based upon the concept of belief, whereas audio is based upon science - so applying religious arguments to it really doesn't hold.
Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: skunark on 15 Mar 2012, 07:18 am
Yet the people who design the equipment rely on the measurable differences. Thus making it a religious belief rather than scientific argument when people rely on "we can't measure stuff" etc. You cannot prove the lack of something, only that something is different. I haven't been able to do that, and I haven't seen any scientific data saying otherwise. The onus is on the entity saying there is a difference to show that there is.
There are many examples of failures by some of the best engineering companies around all because they failed to measure something.  The transition to 90nm is a great example, asics went from asynchronous resets to synchronous resets and had to use tools to model cross-talk, which is boiled down to someone noticing an issue figured out a new way to model it and measure it and then design to prevent it.     As you know folks do design both the product (and the test equipment) based on models of the of measurable behaviors , they can even test that the models match the implemented design, but they can only model, measure and test what they are aware of...  there's always room for improvement. 

Title: Re: FLAC Lossless Uncompressed versus WAV
Post by: SHV on 20 Mar 2012, 03:21 am
"I find that many audiophiles feel that science just gets in the way of their ears, heart and brain."
********
The can't be "evaluated by science" is also common meme with "alternative" medicine.  A similar belief system applied to "audio" is relatively harmless, the other situation can be fatal.

Steve