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).
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 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.
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.
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?
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.
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).
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.
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.
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.
