To Compress or Not?

[Tony Lauck]

There are Unicorns around since 2002. They are no longer rare. Benchmark DAC1 started the mainstream movement to asynchronous DACs and we haven't look back since then.

 

The problem in the past was that the clock signal came from the master and couple that with the Inherent jitter issues with spdif, toslink and USB and HDMI and you have universal problems.

 

You need to read up on asynchronous designs - you can couple them with pretty much everything and you can ignore the jitter from the source....

 

The problem with the asynchronous resamplers is that they are not transparent. They may eliminate measurable jitter through the use of a very narrow bandwidth digital PLL, but they all degrade the signal in various ways, making them unsuitable for high quality usage to many people's ears. The Benchmark 1 was the prototypical example of a product that "measures well but sounds bad". (At least this is what I gather from reviews and discussion forums.) One more knock on the Benchmark 1. It resamples everything to 110 Khz. This means that it downsamples the 176.4 and 192 kHz sample rates.

 

Asynchronous DACs using ASRCs are not to be confused with asynchronous USB protocols. The latter concerns I/O protocols on USB and has nothing to do with sample timing. In a well designed DAC that uses asynchronous USB the DAC master clock controls the arrival rate of the digital data. There is no need for ASRC processing when operating in this mode. (There is also no need for ASRC processing when using AES/EBU or even SPDIF, if a suitable mechanism is provided to slave the computer clock to the DAC's master clock.)

[tranz]

☝I could not put it more eloquently than Tony did. Btw, I have owned/listened to seizure and migraine inducing synchronous DACs to, highly customized version of the Benchmark ( as otb it sounded painful), to >10K discrete ladders. They all benefit from USB gadgets and upstream tweaking. Have a peak at some of the work from John Swenson or Berkeley Audio or IFI or Schitt or ....to help with upstream noise.

[Shadorne]

The problem with the asynchronous resamplers is that they are not transparent. They may eliminate measurable jitter through the use of a very narrow bandwidth digital PLL, but they all degrade the signal in various ways, making them unsuitable for high quality usage to many people's ears. The Benchmark 1 was the prototypical example of a product that "measures well but sounds bad". (At least this is what I gather from reviews and discussion forums.) One more knock on the Benchmark 1. It resamples everything to 110 Khz. This means that it downsamples the 176.4 and 192 kHz sample rates.

 

Asynchronous DACs using ASRCs are not to be confused with asynchronous USB protocols. The latter concerns I/O protocols on USB and has nothing to do with sample timing. In a well designed DAC that uses asynchronous USB the DAC master clock controls the arrival rate of the digital data. There is no need for ASRC processing when operating in this mode. (There is also no need for ASRC processing when using AES/EBU or even SPDIF, if a suitable mechanism is provided to slave the computer clock to the DAC's master clock.)

 

Tony,

 

There is no discussion then from me. You have your ears or the ears of those you trust. If you don't believe in measurements from instrumentation that is orders of magnitude more sensitive and reliable than human ears then that is your perogative.

 

I will only add that you are totally confused about technologies. PLL is what the Benchmark DAC replaced. The old PLL technology worked well in some cases and some setups but was never totally reliable as it still fundamentally depends on master and slave - it was never certain that interface jitter was being completely eliminated with old PLL systems. The asynchronous approach simply eliminates master slave control in a very elegant way. As for sample rates well above 44.1 KHz again this is another of those ears vs instrumentation discussions that will never be resolved as long as there is no agreement on how to measure response reliably. (Human ears are simply not a reliable metric so all discussions are pointless and fruitless - people like what they like - some like wine & some like beer - so there is no right or wrong except everyone enjoys what they enjoy)

[audiventory]

Dennis was being sarcastic there, as he has stated many times before that although he can hear differences in equipment based upon cables, formats, or other "audiophile" beliefs, he firmly believes all the differences he hears are imaginary and there is no benefit anyone anywhere can realize with hi-res formats.

 

There is a lot of real research to do on the subject, but there is not a lot of time or money being invested into it. Dennis often has a lot of good things to say, but he has sensitivities in this subject area that often result in rather sarcastic postings like that one.

 

-Paul

 

Hi Paul,

 

Yes. Many time, efforts and money. Somehere sample rate DBT.

 

And there we can follow how and why need consider deep details. For approaching to enough correct results.

 

Best regards,

Yuri

[esldude]

Dennis was being sarcastic there, as he has stated many times before that although he can hear differences in equipment based upon cables, formats, or other "audiophile" beliefs, he firmly believes all the differences he hears are imaginary and there is no benefit anyone anywhere can realize with hi-res formats.

 

There is a lot of real research to do on the subject, but there is not a lot of time or money being invested into it. Dennis often has a lot of good things to say, but he has sensitivities in this subject area that often result in rather sarcastic postings like that one.

 

-Paul

 

Well, the subject was actually compression and hearing AIFF sound different than WAV. So writing buggy code (rather than simply testing the two formats) struck me as about as reasonable as a high res conversion of both followed by a known colored format like vinyl and then doing the 'definitive' comparison.

[Paul R]

Well, the subject was actually compression and hearing AIFF sound different than WAV. So writing buggy code (rather than simply testing the two formats) struck me as about as reasonable as a high res conversion of both followed by a known colored format like vinyl and then doing the 'definitive' comparison.

 

Who said anything at all about buggy code, speaking of going off subject.

 

The assertion was more along the lines of "any audible differences in file formats has to be caused by the playback chain, and is not inherent in the formats." That hardly deals with "buggy code."

 

Whatever reason [some] people are able to hear differences in audio formats, it certainly isn't "buggy code." The code in most engines reliably produces the "right" answer every single time.

[jabbr]

Well, the subject was actually compression and hearing AIFF sound different than WAV. So writing buggy code (rather than simply testing the two formats) struck me as about as reasonable as a high res conversion of both followed by a known colored format like vinyl and then doing the 'definitive' comparison.

 

Agreed. There are so many other vastly more important variables than different container formats for uncompressed audio data, that even if there were some conceivable and reasonable reason that this made a difference, it would still be a waste of time for me to consider.

 

Buggy software does not "count" because that has nothing to do with any real difference between AIFF and WAV. That would be an "artifact" of a testing procedure.

[Tony Lauck]

Tony,

 

There is no discussion then from me. You have your ears or the ears of those you trust. If you don't believe in measurements from instrumentation that is orders of magnitude more sensitive and reliable than human ears then that is your perogative.

 

I will only add that you are totally confused about technologies. PLL is what the Benchmark DAC replaced. The old PLL technology worked well in some cases and some setups but was never totally reliable as it still fundamentally depends on master and slave - it was never certain that interface jitter was being completely eliminated with old PLL systems. The asynchronous approach simply eliminates master slave control in a very elegant way. As for sample rates well above 44.1 KHz again this is another of those ears vs instrumentation discussions that will never be resolved as long as there is no agreement on how to measure response reliably. (Human ears are simply not a reliable metric so all discussions are pointless and fruitless - people like what they like - some like wine & some like beer - so there is no right or wrong except everyone enjoys what they enjoy)

 

As to wine and beer, they are both nice, but neither is a substitute for music

 

 

My writing might not have been clear, but I am not confused about how ASRC works. I have studied various designs, looked at the SABRE chip ASRC patent, etc... And I am quite familiar with the protocols involved with USB flow control, which is a separate issue. These systems are very complicated and it gets very difficult to keep track of all the various clocks involved and the implications of their behavior. Having worked in the networking area at the systems level, I am well aware of how all these things work and what the problems are with the various approaches involving in making systems work well that have multiple clocks.

 

As to those measurements. The standard audio mesurements are historically geared to distortions in analog components and have evolved very slowly when it comes to the more complex non-linear distortion created by various mixed signal devices, such as DACs and ADCs. Most of the measurements used to evaluate DACs are frequency domain plots, but it is possible to perform other types of measurements as well. It is possible to perform very subtle system identification where the desired signal is far, far below the noise. It may be that there are audio designers doing this at the present moment, but if I were in the business I would keep my techniques proprietary, because the ability to measure a distortion give a designer a huge speed advantage when iterating designs over one who has to perform slow and unreliable subjective listening tests. Measurements are an extremely valuable tool for a designer to use, but are not relevant when evaluating the final product, which depends on what listeners hear. Measurements in product specs and advertisements are often misleading if not completely dishonest. This is just salesmanship.

[Tony Lauck]

Who said anything at all about buggy code, speaking of going off subject.

 

The assertion was more along the lines of "any audible differences in file formats has to be caused by the playback chain, and is not inherent in the formats." That hardly deals with "buggy code."

 

Whatever reason [some] people are able to hear differences in audio formats, it certainly isn't "buggy code." The code in most engines reliably produces the "right" answer every single time.

 

I raised the issue as a thought experiment. It depends on what constitutes a "bug". If bit perfect player output is all that is required then a bug introduced to corrupt the bits of one format but not another could easily be audible and could easily be caught. However, it good sounding music is required and one is working with a real-world DAC that doesn't have perfect isolation that makes "bits just bits" then there could be a bug that affects sound quality of only one format but not another, and yet both formats pass the "bit perfect" test. Here we would have the objectivists saying the player was not buggy, but the subjectivists saying it was.

[gmgraves]

As to wine and beer, they are both nice, but neither is a substitute for music

 

 

No but they can enhance the listening mood (in moderation, of course) Also I remember Mad Magazine's spoof of a Hi-Fi magazine in the early sixties. Under "Hi-Fi Definitions": "Loose Pickup - Someone to listen to hi-fi music with." These also can enhance listening to music!

[audiventory]

Agreed. There are so many other vastly more important variables than different container formats for uncompressed audio data, that even if there were some conceivable and reasonable reason that this made a difference, it would still be a waste of time for me to consider.

 

Buggy software does not "count" because that has nothing to do with any real difference between AIFF and WAV. That would be an "artifact" of a testing procedure.

 

Buggy or not buggy software for us it's black box.

 

Even learning of alien open source code is very problematic.

 

Even in own code found "transparency sound" bug is problematic. If simple learn code.

 

Fastest way capture and compare. We know what in input. Thus we know what must be at output.