More 'Audiophile' bullsh*t

[scorp]

Mr_Yogi said:

AFAIK there are no DAC's which are impervious to jitter on the SPDif interface, and all transports have some jitter. There are some intersting articles on the web explaining the problems. And I can definately say all transports do not sound the same. Even adding a linear power supply to the Squeezebox touch, which as acting purely as a transport made an obvious difference.

Shouldn't matter, the bitstream will be buffered by components local to the DAC, the DAC will then pull samples from the buffer using it's own clock (not the one recovered from the tranport, which the buffer eliminated anyway).

[Mr_Yogi]

scorp said:

Shouldn't matter, the bitstream will be buffered by components local to the DAC, the DAC will then pull samples from the buffer using it's own clock (not the one recovered from the tranport, which the buffer eliminated anyway).

That's how I thought it would work, but it doesn't work well without a lot of care, read up on it. There are articles, blog posts and forums posts by some of the top digital designers scattered over the web. When Async USB was thought to be the magic bullet a couple of years ago, there was lots of interest in this and loads of posts. IIRC it’s something to do with the way the timing information is embedded into the digital signal, you can’t just fill a FIFO buffer with the stream.

It's why pro equipment uses a central clock to sync up all their digital devices.

It's really difficult to believe without hearing it. Coming from a software development background (although no audio processing) and having a good grasp on computer architecture I was firmly in the 'they must all sound the same camp' until I listened for myself.

The difference the SB toolkit (3.0) makes to the SB touch is staggering considering it's purely sending the digital signal to the SPDif. AFAIU all the tool kit does is turn off a load of non essential services; plug-ins, the screen, the remote control sensor etc. This reduces the power used by the device and less interference is passed to the SPDif interface. It may do other things too but it's only software!

Edited by Mr_Yogi on Thursday 20th March 11:01

[TonyRPH]

Mr_Yogi said:

AFAIK there are no DAC's which are impervious to jitter on the SPDif interface, and all transports have some jitter. There are some intersting articles on the web explaining the problems. And I can definately say all transports do not sound the same. Even adding a linear power supply to the Squeezebox touch, which as acting purely as a transport made an obvious difference.

But what you're hearing is not the difference in transport - it's the interaction between the transport and the DAC.

If you looked at the resulting stream with an Oscilloscope / spectrum analyzer, you'd see an indentical stream, even with the 'enhanced' PSU.

The difference in sound is caused by interaction between the PSU, transport and DAC. This could be an earth loop, RF interference or just a poor interface* between DAC and transport.

• imho this is the cause of many issues.

[Mr_Yogi]

TonyRPH said:

Mr_Yogi said:

AFAIK there are no DAC's which are impervious to jitter on the SPDif interface, and all transports have some jitter. There are some intersting articles on the web explaining the problems. And I can definately say all transports do not sound the same. Even adding a linear power supply to the Squeezebox touch, which as acting purely as a transport made an obvious difference.

But what you're hearing is not the difference in transport - it's the interaction between the transport and the DAC.

If you looked at the resulting stream with an Oscilloscope / spectrum analyzer, you'd see an indentical stream, even with the 'enhanced' PSU.

The difference in sound is caused by interaction between the PSU, transport and DAC. This could be an earth loop, RF interference or just a poor interface* between DAC and transport.

• imho this is the cause of many issues.

Yep pretty much agree with that, but seeing as you can't separate the transport from the digital output and power supply I don't see as it's really worth looking at the CD transport mechanisum in isolation. I was talking about a CD transport as the whole box.

[qube_TA]

This will be able to read your CD's and transmit the data to your computer with 100% reliability:



They're also able to read and transmit the data from a disc far faster than audio CD's are read at.


If it couldn't you'd not be able to use one to install software onto your computer. Games consoles wouldn't use them as it would like the old days of installing games from cassette where you wait 10 minutes for them to only crash.

[Mr_Yogi]

qube_TA said:

This will be able to read your CD's and transmit the data to your computer with 100% reliability:



They're also able to read and transmit the data from a disc far faster than audio CD's are read at.


If it couldn't you'd not be able to use one to install software onto your computer. Games consoles wouldn't use them as it would like the old days of installing games from cassette where you wait 10 minutes for them to only crash.

I don't think ANYONE on this thread is disputing that.

[TonyRPH]

Mr_Yogi said:

Yep pretty much agree with that, but seeing as you can't separate the transport from the digital output and power supply I don't see as it's really worth looking at the CD transport mechanisum in isolation. I was talking about a CD transport as the whole box.

So you mean a CD player really, rather than a transport?

[Mr_Yogi]

TonyRPH said:

Mr_Yogi said:

Yep pretty much agree with that, but seeing as you can't separate the transport from the digital output and power supply I don't see as it's really worth looking at the CD transport mechanisum in isolation. I was talking about a CD transport as the whole box.

So you mean a CD player really, rather than a transport?

No, I ment CD transport

CD transport - transport mechanisum (disc reading thing with laser and spindle), Power supply/s, SPDif or other digital audio transponder (think that's the correct term), digital clock.

As opposed to

CD player - transport mechanisum, power supply/s, DAC, digital clock, analogue output stages, etc.

[TonyRPH]

Mr_Yogi said:

No, I ment CD transport

CD transport - transport mechanisum (disc reading thing with laser and spindle), Power supply/s, SPDif or other digital audio transponder (think that's the correct term), digital clock.

As opposed to

CD player - transport mechanisum, power supply/s, DAC, digital clock, analogue output stages, etc.

Ok, but then we could break it down even further, into the actual mechanical transport and then the associated servo circuitry, laser focus etc. etc.

Where do you stop?

I think that when most here refer to a transport, they are referring to the transport as a whole - e.g. only considering the SPDIF output stream.

You could break it down further an consider the I2C component, but that's getting a little too technical IMHO.

The CD mechanism / laser assembly itself is nothing without some kind of control electronics (servo etc.) anyway.

So I'm not quite sure where you're coming from.

[Mr_Yogi]

TonyRPH said:

Ok, but then we could break it down even further, into the actual mechanical transport and then the associated servo circuitry, laser focus etc. etc.

Where do you stop?

I think that when most here refer to a transport, they are referring to the transport as a whole - e.g. only considering the SPDIF output stream.

You could break it down further an consider the I2C component, but that's getting a little too technical IMHO.

The CD mechanism / laser assembly itself is nothing without some kind of control electronics (servo etc.) anyway.

So I'm not quite sure where you're coming from.

I think we were talking at cross purposes, that is exactly what I was talking about, I thought you were talking about the mechanisum which reads the actual disc in isolation.

As I understand it jitter is introduced in the transport; be it a hifi CD transport, PC based digital streamer, SB/SONOS, from the RF, grounding issues, etc. in the PSU, logic chips, processors, NICs, anything that uses power, etc.

[LordLoveLength]

Mr_Yogi said:

scorp said:

Shouldn't matter, the bitstream will be buffered by components local to the DAC, the DAC will then pull samples from the buffer using it's own clock (not the one recovered from the tranport, which the buffer eliminated anyway).

That's how I thought it would work, but it doesn't work well without a lot of care, read up on it. There are articles, blog posts and forums posts by some of the top digital designers scattered over the web. When Async USB was thought to be the magic bullet a couple of years ago, there was lots of interest in this and loads of posts. IIRC it’s something to do with the way the timing information is embedded into the digital signal, you can’t just fill a FIFO buffer with the stream.

It's why pro equipment uses a central clock to sync up all their digital devices.

It's really difficult to believe without hearing it. Coming from a software development background (although no audio processing) and having a good grasp on computer architecture I was firmly in the 'they must all sound the same camp' until I listened for myself.

The difference the SB toolkit (3.0) makes to the SB touch is staggering considering it's purely sending the digital signal to the SPDif. AFAIU all the tool kit does is turn off a load of non essential services; plug-ins, the screen, the remote control sensor etc. This reduces the power used by the device and less interference is passed to the SPDif interface. It may do other things too but it's only software!

Edited by Mr_Yogi on Thursday 20th March 11:01

I suspect many of these 'articles' are sourced from companies still flogging old top-end designs.

When SPDIF (which is a consumer version of the AES format) was developed, memory was expensive, so FIFO buffers were not in common use, other than some very expensive pro equipment. You had to recover your clock from the incoming bitstream. Any jitter, recovered or introduced by this process causes frequency modulation of the analogue output, which can be audiable.
When memory became affordable, DAC designers went to a FIFO model. It means bitstream jitter has no effect on analogue output and, more importantly means that CD transports don't need to be made to anything like the tight tolerances they had to be previously. The clock was no longer recovered from a mechanical spinning disc.

Pro equipment (generally) uses a common clock because it means that sample-rate converters are not needed on inputs. Although these days most inputs have SRC as a matter of course (and will use a FIFO of of 1 frame length).
The most important thing about the clock at the analogue to digital converter end is that it should be jitter free. Jitter here is irrecoverably 'locked into' the bitstream (as timing errors on the individual samples) and there is no way of recovering from this. I suspect this is what these 'articles' are explaining
and people are confusing ADC clocks with DAC clocks.

USB is another thing altogether - you can't even get a coherent bitstream because of nature of USB. I don't know of any pro audio device that uses usb that is taken seriously.

Also see a lot of people talking about 'error correction' on transports and how much this affects the audio. It doesn't.
The red book CD standard describes the EFM (eight to fourteen modulation schemes) and CRC (Cross Interleaved Reed Solomon Check codes) used on a CD. Errors are corrected by error correction to this standard in real time - that is to say, the correct data is calculated and appears in the transport bitstream. This process is audiably transparent - there is no latency, and the final data correlates exactly to the data originally encoded on the disc.
When you get unrecoverable errors the transport will interpolate - this will be audiable in a lot of circumstances and will vary between manufacturer - it is not defined in the red book.

[qube_TA]

Mr_Yogi said:

qube_TA said:

This will be able to read your CD's and transmit the data to your computer with 100% reliability:



They're also able to read and transmit the data from a disc far faster than audio CD's are read at.


If it couldn't you'd not be able to use one to install software onto your computer. Games consoles wouldn't use them as it would like the old days of installing games from cassette where you wait 10 minutes for them to only crash.

I don't think ANYONE on this thread is disputing that.

Cool, so why spend £XXXXX on a super CD transport if the above can read the optical data with 100% accuracy?

[Mr_Yogi]

qube_TA said:

Cool, so why spend £XXXXX on a super CD transport if the above can read the optical data with 100% accuracy?

Because that will get the PCM file onto a hard disk, not into a DAC.

Edited by Mr_Yogi on Thursday 20th March 19:55

[gizlaroc]

TonyRPH said:

Ok, but then we could break it down even further, into the actual mechanical transport and then the associated servo circuitry, laser focus etc. etc.

Where do you stop?

I think that when most here refer to a transport, they are referring to the transport as a whole - e.g. only considering the SPDIF output stream.

You could break it down further an consider the I2C component, but that's getting a little too technical IMHO.

The CD mechanism / laser assembly itself is nothing without some kind of control electronics (servo etc.) anyway.

So I'm not quite sure where you're coming from.

You're missing the point completely.

The 'official' term for a player that outputs digitally is called a 'transport'.

That is what people were discussing,

That could be a CD transport, digital media file transport etc. etc.


And when people say they all sound the same that is simply incorrect.

Edited by gizlaroc on Thursday 20th March 18:52

[TonyRPH]

gizlaroc said:

TonyRPH said:

Ok, but then we could break it down even further, into the actual mechanical transport and then the associated servo circuitry, laser focus etc. etc.

Where do you stop?

I think that when most here refer to a transport, they are referring to the transport as a whole - e.g. only considering the SPDIF output stream.

You could break it down further an consider the I2C component, but that's getting a little too technical IMHO.

The CD mechanism / laser assembly itself is nothing without some kind of control electronics (servo etc.) anyway.

So I'm not quite sure where you're coming from.

You're missing the point completely.

The 'official' term for a player that outputs digitally is called a 'transport'.

That is what people were discussing,

That could be a CD transport, digital media file transport etc. etc.


And when people say they all sound the same that is simply incorrect.

Edited by gizlaroc on Thursday 20th March 18:52

How am I missing the point? I was responding in part to Mr_Yogi who (to my mind at least) was talking about a CD transport rather than a transport in general.

I know that a device that only outputs an SPDIF / digital signal is referred to as a transport - I only repaired that kind of stuff for about 12 years or so, so I think I know the difference...

[Funk]

I can't do this any more.

Anyone who says one digital stream can sound different to the same digital stream from another device is just....well.....like I say, I'm out.

[Mr_Yogi]

Funk said:

I can't do this any more.

Anyone who says one digital stream can sound different to the same digital stream from another device is just....well.....like I say, I'm out.

So have you listened to different digital transports through the same system?

[TonyRPH]

Mr_Yogi said:

Funk said:

I can't do this any more.

Anyone who says one digital stream can sound different to the same digital stream from another device is just....well.....like I say, I'm out.

So have you listened to different digital transports through the same system?

I tend to agree with Funk.

I have several different players, some have been extensively modified too.

When used as a transport, I cannot tell any difference through the same DAC.

To me, there's also no discernible difference between my Squeezebox and the CD players used as transports.

Just maybe, my system doesn't have sufficient resolution to tell the difference, or maybe my ears don't.

But my son, (a budding musician) can't hear any difference either.

[Mr_Yogi]

TonyRPH said:

I tend to agree with Funk.

I have several different players, some have been extensively modified too.

When used as a transport, I cannot tell any difference through the same DAC.

To me, there's also no discernible difference between my Squeezebox and the CD players used as transports.

Just maybe, my system doesn't have sufficient resolution to tell the difference, or maybe my ears don't.

But my son, (a budding musician) can't hear any difference either.

Well you can't say fairer than that, at least you've tried it

The Cyrus system I heard was: CDXT SE+/ StreamXP -> Mono X300 -> VA Beethoven Concert Grand's, and there was a subtle but definite difference between the streamer and the CD transport.

While my own system is much more modest; SB Touch -> 8XPd qx + PSX -> Kef QX30 Both adding the linear PSU and the toolkit mods made a more substantial difference to the SB than the difference between the CD and streamer in the Cyrus system.

Maybe your DAC is more tolerant of interference?

[gizlaroc]

Funk said:

I can't do this any more.

Anyone who says one digital stream can sound different to the same digital stream from another device is just....well.....like I say, I'm out.

By the time it leaves the transport, or player if that helps, it is not the same though.

It is only the same when it leaves the 'rom drive' if we are talking about a CD Transport, all sorts of manipulation can be done to it before it then leaves the transport to go on its way to the DAC.

Now, there is an argument that says it 'should' always sound the same, and if it sounds different something is broken, but that argument is starting to look a little dated these days.