[rbbert]

ALAC is a lossless codec

[adprom]

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

[skunark]

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.

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.       

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.

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.

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.   

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.

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

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. 

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. 

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

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.

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.

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.

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.

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

[adprom]

I've been doing digital design most of my life.

So you aren't actually an engineer then?

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.

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.

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.

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.

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

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?

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.

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.

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.
 

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?

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.

[skunark]

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.   As I stated before I am an EE, which implies the degree. 

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. 

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 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 motherboard, ESI Juli@ sound card or even with MPD's interaction 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.

...

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. 

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.

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.

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.

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.

#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.   

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

[adprom]

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.

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.

[skunark]

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

[adprom]

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.

[BrysTony]

Yawn...

[skunark]

"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?   

[skunark]

Yawn...

I totally agree...

[AgentOrange]

"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.

[adprom]

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".

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.

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.

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.

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.

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

[srb]

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

[adprom]

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.

[skunark]

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. 

[SHV]

"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