A conversation with Charles Hansen, Gordon Rankin, and Steve Silberman

[Mister Wednesday]

Greetings all,

 

A three-way conversation over on the AudioStream website with Charles Hansen, Gordon Rankin and Steve Silberman on some of the problems in the digital domain that must be overcome to get decent sounding music:

 

There's no such thing as digital: A conversation with Charles Hansen, Gordon Rankin, and Steve Silberman | AudioStream

 

I have no connection to or association with any of the persons, companies, products or views expressed in the article referenced above.

 

Regards,

 

Mister Wednesday

[Audio_ELF]

I know who Charles Hansen is (Ayre) and Gordon Rankin (Wavelength) and know their companies are linked via shared technologies (Ayre licensing Wavelength's USB interface) but who is Steve Silberman?

[AlainGr]

I Eloise,

 

He seems to be from Audioquest... After typing just his name in Google, I finally added "Audio" and it brought me to some references to Audioquest...

 

Alain

[jtm]

Steve Silberman ist Head of Marketing at The Quest Group, known as audioquest.

 

@ Mister Wednesday:

thanks for sharing :-)

[Audio_ELF]

I wasn't sure as there is a Steve Silberman at Wired magazine. Wasn't sure if he was moderating the conversation...

[mav52]

I notes who Silberman is in the link.

During a conversation with AudioQuest's Steve Silberman

[burnspbesq]

Steve Silberman was at Ayre prior to moving to Audioquest.

[One and a half]

Mister Wednesday, thanks for the link.

 

Can't wait for the next installment.

 

This should open a few eyes.

[Audio_ELF]

It is interesting ... but like all these things it is presented as absolute fact with 3 industry insiders pretty much agreeing with each other.

 

Where is the counter point; where are the audio designer's opinions who disagree?

 

Things in audio design are not black and white and there are many ways to skin a cat...

 

Eloise

[Audio_ELF]

It is interesting ... but like all these things it is presented as absolute fact with 3 industry insiders pretty much agreeing with each other.

 

Where is the counter point; where are the audio designer's opinions who disagree?

 

Things in audio design are not black and white and there are many ways to skin a cat...

 

One of the most interesting "industry insider" series of articles was a series of questions asked of various designers including Gordon Rankin, Steve Nuget and Daniel Weiss who all gave different responses and felt different things were more important.

 

Eloise

[chriss71]

Sorry that I don't have seeing this thread before, my thought about that article:

 

It's common for people to envision and represent a digital signal as a series of 1s and 0s. As such, there's really no room for error, at least according to this binary theory. Is a digital signal simply a series of 1s and 0s?

 

Charlie Hansen: Unfortunately not. The "1"s and "0"s are just abstractions that are easy to think about.But in the real world, something real needs to represent those two abstract states. In modern digital electronics, we have almost universally chosen a voltage above a specific level (that varies from one "family" of electronic parts to another) to represent a "1" and a voltage below a different specific level (that again can vary) to represent a "0".

 

Here we have the first misunderstanding (in our High-End story). When the stream hits the DAC he is true, in a pure digital domain he is wrong... He explains how the DAC interprets that bitstream. Before, you can do with that bitstream whatever you want, when at the end comes the same bitstream to the DAC it would sound the same...

 

Reading with interest this article...

[chriss71]

But aside from the data being true, there is so much more. How much energy is wasted delivering the data seems to have an effect on sound. As with increased energy usage the amount of EMI/RFI radiation also increases. This might be a reason why applications sound different. If we look at the "top" command in the Terminal application on OS X we see a programs usage and percent time and all the processes associated with that program. In practice the applications with the least required processing time also sounds the best. This may have an indication of why file types sound different. If you unpack a lossless file on the fly the processing time increases measurably and that tends to decrease the sound quality.

 

OK, now he is speculating. He thinks it sound different and is looking for a reason on his observation. Now it comes to a following question for me: Have he EVER looked on his observation on a double blindfold test? We are here in pure computer science. I will tell him the following: All of the computer processes will NOT have an impact (with a small limitation if all CPU cores goes to 100%), because the data are buffered in the cache of the processor or the RAM. So, in this case he is wrong (off-topic: Is it rude, when I say, he is wrong? Is there another word which are not rude?)

 

If the bit changes to the correct state but at the wrong time, this is equivalent to changing to the wrong level at the correct time. These timing errors are known as "jitter".

 

Simple to explain: We don't need error correction at this time, because all of the data get's buffered. So, they are in the right time by the DAC (simplified, but true). Jitter only come important INTO THE DAC, not in the digital domain...

[Audio_ELF]

off-topic: Is it rude, when I say, he is wrong? Is there another word which are not rude?

Not saying I agree with all you write (nor saying I disagree) but to help you...

but never WRONG!!

[mav52]

Just a few guys setting around talking, I'm waiting for

To be continued...

[chriss71]

@Audio_ELF: Thanks!

 

Very interesting article what they have to say...

[The Computer Audiophile]

Hi chris71 - Can you tell us more about your background, experience, or education? We know quite a bit about Gordon and Charles but not much about you. I only say this to help put your opinions in context and help readers understand where you are coming from.

 

Please take this in the spirit in which it's intended. You're saying some very smart people, who are willing to have their comments peer reviewed in public, are wrong. yet, you are just an Internet name "chris71".

[Paul R]

Hi Chriss71 -

 

Umm- I think you are perhaps not totally correct here.

 

Binary Information may be manipulated all you want with no change to the data

 

Storage, transmission, and manipulation of Binary Information requires the binary information to be stored or tranmitted in an analog format. That can be a voltage on a pin or a non-reflective pit on an optical disk, or an RF signal on a cable, but analog it must be.

 

See the difference? The information is binary, but the media is analog. All sorts of interesting things can happen to analog transmissions and storage, without changing the binary information one whit. That sounds counter-intuitive, but it really makes a lot of sense from a detailed viewpoint.

 

However, "bit rot" and such is, IMNSHO, just rot.

 

Once you have transmitted and restored the binary information without error, it is in all measures, a perfect copy of the original binary information. Errors and other factors that can affect how music stored as binary information sounds can occur only during transmission of this data, not while it is sitting peacefully stored as a voltage or pit or magnetic whorl. *

 

-Paul

 

*Okay, outside of being zapped by a stray cosmic ray that just happens to flip a bit in RAM or some other possible - but highly unlikely - event.

 

 

 

Sorry that I don't have seeing this thread before, my thought about that article:

 

 

 

Here we have the first misunderstanding (in our High-End story). When the stream hits the DAC he is true, in a pure digital domain he is wrong... He explains how the DAC interprets that bitstream. Before, you can do with that bitstream whatever you want, when at the end comes the same bitstream to the DAC it would sound the same...

 

Reading with interest this article...

[chriss71]

Hi chris71 - Can you tell us more about your background, experience, or education?

 

My name is chriss and i am born 1971. My homeland is Austria. i am since 25 years in the computer business. The first few years I was a C++ Programmer. Then I went over to Network Technic (I am certified as Cisco CCNP and Microsoft MCITP). Now I am working in my own company. I hope this helps you...

[chriss71]

You're saying some very smart people, who are willing to have their comments peer reviewed in public, are wrong. yet, you are just an Internet name "chris71".

 

That's the reason why I have asked how I should describe it. It is not complete wrong, it is vague.

@Chris: If you want you can delete my sentence in which i wrote wrong... No problem at all...

[chriss71]

Once you have transmitted and restored the binary information without error, it is in all measures, a perfect copy of the original binary information. Errors and other factors that can affect how music stored as binary information sounds can occur only during transmission of this data, not while it is sitting peacefully stored as a voltage or pit or magnetic whorl.

 

Yep, I see it the same way. I have tried many times a real time conversion between WAV and FLAC and then recorded the bitstream which is in the buffer of the DAC and compared it to the FLAC and WAV File on the HD. It's the same stream....

[One and a half]

One of the most interesting "industry insider" series of articles was a series of questions asked of various designers including Gordon Rankin, Steve Nuget and Daniel Weiss who all gave different responses and felt different things were more important.

 

Eloise

 

Ahh, you are thinking of these articles in Positive Feedback.

[One and a half]

I am familiar with serial data and protocols with my work, and appreciate how the choice of cables can directly affect the data stream.

 

For the USB example, the signals are 0.xV to 5V square waves (if you're lucky) in amplitude, the differential receiver setup to receive a little bit less, say 4.x volts. The idea is if there is noise from the computer, or power supply say maybe 0.5V or more the differential receiver still only sees 4.xV, and that increase in voltage level is rejected by the receiver.

 

However the analog noise is still present on the cable, hasn't dissapeared yet, and although it may be ignored by the USB receiver, that crud can find its way to the amplifier, bypassing the DAC altogether. The level is not enough to allow the computer to fall over, since the computer uses differential systems just about everywhere to control and move data streams about the place and uses the same pipes as USB in the example. There is a lot of RF/EMC noise in the computer, but it is benign to normal operation of the PC, but certainly not to amplifiers or other devices connected to the computer.

 

 

USB Data what it looks like (Lens graphs are another story)

 

 

Not USB but CANBUS used by cars, this waveform has spikes and other out of bounds voltages, which are present from the source, but can be ignored by the receiver.

 

The cables do affect the operation of these signals, since a cable is after all, R L and C, just like speaker cables or interocnnects. The more C (capacitance) in the cable, the square waves end up like shark fins and the receiver will miss bits or in the case of USB critical packet information which is lost. Like REShaman found out using a combo of cable with his new W4S dac. Music is there and all of a sudden, nothing or white noise.

 

What I would like to know is how a .WAV just sitting on a HDD is converted to this serial data. Can Paul R. explain, cause then another issue that's critical, is timing to keep the data stream in sequence so that the words (bits) end up where they are supposed to be, on time, like Swiss trains.

 

Then there's the power supply effects on top of all this fascinating discussion.

[Paul R]

(grin) Not quite.

 

The music that a system reproduces from the digital information can - arguably perhaps - be affected by the analog transmission. People immediately think that means the data is corrupted, but that is not the case. The physcial components are affected, perhaps changing the timing of the data at the receive point (i.e. jitter) or the amplitude, which means it can take longer for the system to recognize a value (rise times) and so forth.

 

I am not explaining that very well, but the easy way to think of it is imagine what can happen to a signal carrying digital information that would not prevent the data from being reconstructed, but could affect the efficiency and or timing of that reconstruction. There is more of course, but that's a good place to get a tooth into it.

 

-Paul

 

 

Yep, I see it the same way. I have tried many times a real time conversion between WAV and FLAC and then recorded the bitstream which is in the buffer of the DAC and compared it to the FLAC and WAV File on the HD. It's the same stream....

[Paul R]

What I would like to know is how a .WAV just sitting on a HDD is converted to this serial data. Can Paul R. explain, cause then another issue that's critical, is timing to keep the data stream in sequence so that the words (bits) end up where they are supposed to be, on time, like Swiss trains.[/Quote]

 

Paul Hoffman or Jussi would be a better choice to answer our question there, as they are far more elegant than I. Though I do think I posted an explanation of the the software formats for Windows a year or two ago. I'll see if I can find that post somewhere and put a pointer to it here. That was pretty much software - I do not think you can do much to affect the timing of a USB transmission from a host in software, but some clever devil may have found a way. Other than externally controlling it with something like StreamLength code, I mean.

 

-Paul

[One and a half]

Paul Hoffman or Jussi would be a better choice to answer our question there, as they are far more elegant than I. Though I do think I posted an explanation of the the software formats for Windows a year or two ago. I'll see if I can find that post somewhere and put a pointer to it here. That was pretty much software - I do not think you can do much to affect the timing of a USB transmission from a host in software, but some clever devil may have found a way. Other than externally controlling it with something like StreamLength code, I mean.

 

-Paul

 

OK, no problem, will look for that link with interest.