[little-endian]

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif LE, I did read that post and do agree with your statement. I also want you to realize that we have characterized and held listening test's at CES with dealers, media and other even competing companies.

If you recognized and agree, it should be clear that listening tests are not even necessary or helpful to follow up what I referred to. Logic's nature is to lead to the same result if one is following the same steps no matter who follows them.

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif It was plain to hear that when converting a lossless file to another format (WAV/AIFF) which was uncompressed that there was a differential in sound that was easily heard. It more true in slower machines but we did the test on both OSX and Windows as both the MAC mini we had setup and the MacBook both had bootcamp installed with Vista Ultimate.

There are two possible explanations while the first one is by far more likely: Either something is really going wrong during the realtime conversion from the compressed data to PCM (restored data doesn't match the original one) or the conversion process affects the output's jitter the player device isn't taking care of good enough (catchword: "time is the enemy").

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif The thing you further have to understand is this. With a product like the Benchmark that puts the data through a upsampler to remove the jitter there should be LESS of difference in sound.

If Benchmark's claims are correct, any jitter won't be less audible but at -130dBFS definately not audibly at all.

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif As I am sure from your alias (don't you hate these things, just say who you are) that you have some programming and therefore math background then I would suggest re-reading LaPlace and Forier work in math. This math was conceived in the early 1820's (why???) and is the basis for much of how digital audio works.

Well from my alias, I think I'd have to vote for WAV instead of AIFF.

When it comes to digital audio, I rather think about Nyquist / Shannon. However, to understand the fact that characters are just characters (and thus bits just bits of course), none of these principles are needed but pure logic.

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif But in the end Joijwall did hear a difference from the same file. Which means as bits are not bits as they would be identical in nature.

Wrong. It means that it was either imagination or the data didn't arrive on time, in fact resulting in different sounding audio.

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif Guys for years we have struggled with SPDIF and originally people would say bits are bits why does this digital cable sound different than that one. Now we know allot more of why that is.

Well, I have my doubts that the "mass" really knows what's going on. It can be proven that a cable doesn't matter at all when it comes to transmissions as long as the jitter and attenuation is low enough to allow the receiver to properly detect the signal. In the case of real-time applications like D/A conversion, it depends on the specific device. It's not the cable's job to keep the jitter as low as possible for unjustified amounts of money if a simple buffer for a few cents could have the same effect.

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif Missinformation is the biggest crime in Computer Audio.

That's why I'm taking the time to reply here. However I feel the battle has been already lost long ago.

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif The idea that the KMIXER is bit perfect. Common.... There is not a person alive who has heard the KMIXER then bypassed it and heard the difference and said they where the same. If the KMIXER is truely bit perfect then... bits are bits correct?

I don't know much about Windows' kmixer.sys, but I know if my data from the S/PDIF-output matches the DAE-results or not and that's enough for me. If one connects the Benchmark DAC1 USB directly to the PC, it's of course by far more difficult to check if the data will really remain intact. You'd either simply have to believe Benchmark's tests or perform your own by sniffing the data between the USB-port and the DAC.

Thus, the S/PDIF connection has one big advantage here: one can record the output from the PC soundcard or a stand-alone player with a cheap recording device and compare. If the data matches, one can be sure that the DAC1 or any other DAC will get the same data as well (assuming the receivers are of the same "recognition quality") and satisfy the paranoia.

 

[KarateKid]

Quote:

Originally Posted by emmodad /img/forum/go_quote.gif 1/ read the thread 2/ use the search function

Okay buddy, why do you care? He said he does not recommend balanced headphone cables out of the dac1 or in general however I wanted to know if the sound is better out of a balanced AMP instead of directly out of the back of a DAC1. So cool it.

 

[emmodad]

Quote:

Originally Posted by KarateKid /img/forum/go_quote.gif Okay buddy, why do you care? He said he does not recommend balanced headphone cables out of the dac1 or in general however I wanted to know if the sound is better out of a balanced AMP instead of directly out of the back of a DAC1. So cool it.

"so cool it"?!?! my, how droll.

poor Elias has responded directly to the topic of balanced cans on DAC1 XLR outs before, IIRC several times. and many, many others have posted, expressed opinions, discussed technical pros and cons....

the subject of your query has been addressed to death a/ in this thread and b/ in many, many others discussing impressions / appropriateness / technical issues / subjective impressions wrt use of DAC1 balanced outs to directly drive balanced cans.

so the suggestions wrt reading and searching do stand. BION, all you have to do is invest a small amount of your own energy and time.

 

[joijwall]

Back today in the forum and A LOT to think about. Thanks all! Please let me clarify:
a) I took a Lossless file (made in iTunes from CD), converted it to AIFF, and compared the two files played from iTunes and think I heard a difference.
b) Using my Linn CD as transport with DAC1 was better than the Linn CD. At least at first, but after my last try I don't know anymore.
c) DAC1 has of course great value, no question about it! But I actually expected MacBook/iTunes/DAC1 to beat the Linn Majik CD clearly.
These are my thoughts:
1) Benchmark has tested earlier MacOS Tiger/iTunes with bitperfect result, but the Leopard tests are not yet completed. I cannot be sure my setup is bitperfect.
2) There could be a bit-difference between Lossless and AIFF/WAVE, depending on the player used. In my case MacBook/iTunes might not be able to decode perfectly on the fly. You seem all to agree on that.
3) If everything is indeed bit-perfect from the source all the way to DAC1, the DAC1 analog output quality is what could effect the sound. What I understand, Benchmark suggests a removal of the headphone-mute-function for best quality?
I'm pretty sure though the DAC1 outputs is at least as good as the ones in Linn Majik CD.
4) I don't know much about ground loops, but I could try optical or run on batteries and listen. I've also moved my music files to a separate HDD not long ago, maybe that has some influence also.
5) Regarding CD-players, are there other important things involved than reading from the disc, D/A-converting and the electronic components (including analog outputs)? I thought perfecting these three gave better sound (and higher price). How does DAC1 perform in these areas? I listened to Linn Klimax DS ($30000 HDD/Streamer/DAC-combo) and it sounded fantastic. Which led me in on the DAC1 path by the way.
6) Listening comparison is really difficult and we're easily affected by expectations.
So, in the end, I'm interested in three things:
- Give my DAC1 the original source bits
- Make sure DAC1's analog output is well taken care of
- Relax and let the music speak
/Joachim

 

[Wavelength]

Quote:

Originally Posted by EliasGwinn /img/forum/go_quote.gif Can you please explain in detail the configuration for this listening test? This issue deals with the quality of format conversion within the media player. I make no claims in that regard. Can you explain this in more detail?

Elias, this was covered earlier in the thread but sure. We had 2 idential Cosecant v3 dacs, both MACs (2.2GHZ/2GB/250gb MacBook Core 2 Duo, MacMini 1.6ghz Core Duo 2gb/250gb) connected via Opticis cables and then using idential lengths of Nirvana Audio SX cable to my Royal Preamplifier and Cardinal Ag amplifiers.

We took a group of 5 songs on each platform (Vista Ultimate J River and iTunes OSX 10.5.1) that were in lossless format and converted these to WAV (PC) and AIFF (iTunes). So in a sense they are identical. Same way I told Joijwall to do this.

We played the 5 songs one in lossless then using the AIFF/WAV in eight fomations. MacBook to Mini and then MacBook to MacBook, Mini to Mini both with Vista and iTunes.

It was clear that more spatial information was apparent in the non-lossless files. It was more apparent on the slower machine (mini).

After the show we took a 8 core 3GHZ MacPro with lossless and AIFF files and found there to be no difference. So it is assumed by this that slower machines have problem decoding the files on the fly. Someone told me that the original lossless format on the Mac was done with the Altivec process and that the Intel base machines don't fair as well.

Maybe why my G4 still sounds very good to me.

Quote:

I don't want to speak for Joijwall, but I believe he was comparing the difference between his transport's internal DAC vs. the DAC1. However, I could be very wrong about that.

Well that is what he was asked to do and that is how he responded.

Quote:

It is important to make a distinction between data integrity and transmission integrity.

Granted and that is why I don't feel recording a stream will give you total detail. If for example as I have said that XP does not preform as well as vista does because the USB drivers are not as good. This does not mean the recording of the stream would be any different. There is TIME and DATA too consider, especially in your case with Adaptive mode.

Quote:

I don't hear any difference with the DAC1 USB when I bypass kmixer. And I am alive.

Common be serious... If that was the case then why even tell people how to bypass it?

As for the KMIXER being bit perfect, I have run tests on the Prism and we can truely tell that the LSB is changing which causes changes in the THD and the Spectral response.

This is the same results Microsoft came up with and they use the AP and spent years figuring out how to get rid of the KMIXER so all's I can say is who you going to believe?

Thanks
Gordon

 

[little-endian]

Quote:

Originally Posted by Wavelength /img/forum/go_quote.gif After the show we took a 8 core 3GHZ MacPro with lossless and AIFF files and found there to be no difference. So it is assumed by this that slower machines have problem decoding the files on the fly.

Sorry, but if such systems shouldn't be able to decode a "simple" lossless file in realtime, I would be seriously worried about them.

Take a old, dusty P1 @ 133 MHz and a Transit USB for instance and you'll have your data 100% restored in realtime, I'll bet you. Today's processors do this almost in standby.

 

[Crowbar]

Wavelength, are you sure you're getting identical bits? If you are, and you use asynch so there's no interface jitter at all, then I also can't see why it makes a difference.

There's a simple test that can be used to check. Run a pseudorandom number generator on the DAC controller and send the same data from the PC, then compare the streams for match in the DAC (obviously pseudorandom number generators are deterministic so the sequence will match if you use the same seed).

I've found that sometimes sending between two computers with the second emulating a USB Audio sink will give errors (though the first one is a pretty old computer so it could be just its lousy USB hardware). The omission of error correction from the standard definitely was a bad idea.

 

[joijwall]

Sorry Gordon, here's my setup:
Linn Majik CD, Linn Exotik Pre, Linn C2200 Amp (all grounded from same outlet), Inoaudio Pi60 speakers. Linn Silver interconnects, Lejonklou powerchords.
I want to beat the CD using a MacBook 2,16GHz/2 GB/120 GB MacOSX 10.5.2/iTunes 7.6.2 (all latest)+DAC1 USB using the Benchmarks USB cable and Linn silver interconnects.
Seems like a fair competition to me, and I'd like DAC1 to win big.
/Joachim

 

[joijwall]

By the way, how is it possible to test the bit-transparancy at all on the Mac? When directing the output to DAC1 in Audio/Midi setup, I can choose sample rate, but I cannot set wordlength, it is always 2ch-24bit.
Doesn't this mean bits sent to USB is changed? I mean, the original CD is 44,1/16, but the USB output is 44,1/24, thus we cannot compare the bits unless we convert it back after the USB?
If I understand Benchmarks wiki correctly, the 16->24 conversion is done by iTunes. Will a 16->24 conversion change the "music" information in any way, resulting in DAC1 presenting a different analog output than if the original 44,1/16 was feeding it?
In my case, I guess DAC1 gets a 44,1/24 from my MacBook, but a 44,1/16 from the optical output on my Linn Majik CD.
In short: Since DAC1 wants the 24 bits, and setup forces iTunes to convert 16->24, don't we need to check for bit-transparancy somewhere inside DAC1?
/joijwall

 

[Tarkovsky]

No.

Resampling and word length change are entirely different. You can store the exact same number in 4 digits as you can two. For example. 99 and 99.00.

Using 24bit is always a benefit.

 

[Wavelength]

Quote:

Originally Posted by little-endian /img/forum/go_quote.gif Sorry, but if such systems shouldn't be able to decode a "simple" lossless file in realtime, I would be seriously worried about them. Take a old, dusty P1 @ 133 MHz and a Transit USB for instance and you'll have your data 100% restored in realtime, I'll bet you. Today's processors do this almost in standby.

LE,

We did the samething on a PC, read the post I listed above. The same thing happened with WAV and Lossless files there.

What I am saying is this. You can capture the data from each of these compare them and they will be the same as they should because when compared as files they are.

BUT... when listening it's easy to tell difference on a good system. This system was voted by SoundStage as the best demo room at CES. Believe me I can't afford this stuff and I am building it. The equipment in that room retailed for like $85k not including cables, racks, power conditioner and computer stuff.

SoundStage! Network Las Vegas 2008 Special Show Site - www.AudioVideoShows.com

If you have a clear system and have the skills to listen you can hear a difference.

I have a ton of degrees but as I said before... my more than 40 years of being a musician decide more than anything else how something is going to sound.

Thanks
Gordon

 

[Wavelength]

Quote:

Originally Posted by joijwall /img/forum/go_quote.gif By the way, how is it possible to test the bit-transparancy at all on the Mac? When directing the output to DAC1 in Audio/Midi setup, I can choose sample rate, but I cannot set wordlength, it is always 2ch-24bit. Doesn't this mean bits sent to USB is changed? I mean, the original CD is 44,1/16, but the USB output is 44,1/24, thus we cannot compare the bits unless we convert it back after the USB? If I understand Benchmarks wiki correctly, the 16->24 conversion is done by iTunes. Will a 16->24 conversion change the "music" information in any way, resulting in DAC1 presenting a different analog output than if the original 44,1/16 was feeding it? In my case, I guess DAC1 gets a 44,1/24 from my MacBook, but a 44,1/16 from the optical output on my Linn Majik CD. In short: Since DAC1 wants the 24 bits, and setup forces iTunes to convert 16->24, don't we need to check for bit-transparancy somewhere inside DAC1? /joijwall

Joijwall,

In the enumeration (USB setup between the computer and the endpoint device) of the USB DAC1 it declarles all data to be 24 bits. Actually the padding can happen anywhere. What padding means is that 8 bits of 0 is added to each sample to make it 24. There is no upsampling preformed here in this case.

Elias can answer this... but I think what they did was take the output of the TAS1020 (the USB Audio controller) in I2S format to an SPDIF transmitter. They then could feed the USB data and take the SPDIF input into their Ap analyzer and see if it was bit perferct.

So in a sense it would be hard to check bit perfect data with 16 going in and 24 out. You would have to write a program to strip the padding before comparing it.

Thanks
Gordon

 

[Wavelength]

Quote:

Originally Posted by joijwall /img/forum/go_quote.gif Sorry Gordon, here's my setup: Linn Majik CD, Linn Exotik Pre, Linn C2200 Amp (all grounded from same outlet), Inoaudio Pi60 speakers. Linn Silver interconnects, Lejonklou powerchords. I want to beat the CD using a MacBook 2,16GHz/2 GB/120 GB MacOSX 10.5.2/iTunes 7.6.2 (all latest)+DAC1 USB using the Benchmarks USB cable and Linn silver interconnects. Seems like a fair competition to me, and I'd like DAC1 to win big. /Joachim

Joachim,

One thing to try first is to disconnect the MagSafe connector off the MacBook and play it and then play it with it connected.

I suggest 2 cable changes... I would get a Belkin Gold USB 2.0 cable. These run about 10$ and are allot better than the stock which I think is still sitting in my box. I would not use silver cables between the bechnmark and the Linn. Linn prides themselves in system concept. In the case of the Benchmark I would use a good copper cable from Kimber or better yet Nirvana Audio.

I would set the Audio Midi settings to 24/44.1 don't let the upsamplers work.

Thanks
Gordon

 

[Wavelength]

Quote:

Originally Posted by Crowbar /img/forum/go_quote.gif Wavelength, are you sure you're getting identical bits? If you are, and you use asynch so there's no interface jitter at all, then I also can't see why it makes a difference. There's a simple test that can be used to check. Run a pseudorandom number generator on the DAC controller and send the same data from the PC, then compare the streams for match in the DAC (obviously pseudorandom number generators are deterministic so the sequence will match if you use the same seed). I've found that sometimes sending between two computers with the second emulating a USB Audio sink will give errors (though the first one is a pretty old computer so it could be just its lousy USB hardware). The omission of error correction from the standard definitely was a bad idea.

Crowbar,

First there is no golden dagger for getting rid of all the jitter. Sure it is much easier with ASYNC but I don't think that has anything to do with our conclusion.

I did have a USB Analyzer there and we did verify no USB errors occured. While this is true at the line level it is possible at the controller (TAS1020) that an error occured. I have tested this in the lab with the emulator attached with break points and counters on errors. But I think it's still has too do with speed since it happens in both PC and MAC land.

I have been asked to design an ASYNC USB to SPDIF converter for another company I may start with Neil Sinclair (Theta). This may shed more light on the subject as soon as I can get to it.

Thanks
Gordon

 

[Crowbar]

I'm just trying to understand what can cause a difference. An asynch interface is no different conceptually than say transferring the audio file over the Internet. Yet I'm sure no one will claim if it goes over servers ABC it will sound different than if it goes over servers XYZ. If it's not the bits, then what? Perhaps somehow the input timing jitter is cross-coupled in a non-obvious way to other circuits. Or just RF crap coming in over the USB cable is not perfectly filtered.

What's the point of asynch USB to S/PDIF? The whole benefit of USB is that it avoids S/PDIF's problem. This only makes sense if there's a clock line from the DAC to the converter driving its timing.