Add a DAC to a cheap CD player?
 

On Thu, 11 Dec 2003 10:06:03 +0000 (GMT)
Jim Lesurf wrote:

This may be the case if there is no mechanism in the receiver to adjust
its
medium/long-term clock frequency towards that of the transmitter.
However
the S/PDIF stream has clock info encoded into it.

Indeed. but we were discussing reclocking to a perfect clock, which
means the spdif clock is being replaced by one that is not even locked
to it, which will show the effects described (eventually)

Of course, if anyone owns such a system, I'll be happy to sell them a
'thermal clock recalibration and drift elimination tool' (aka, bunsen
burner and hotplate underneath), complete with soft rubber mouts and
counterweighted, balanced platform...

The above treats this as a matter of terminology. In reality, both the
transmitter and reciver clocks will wander about in an apparently
random manner over all timescales of variation. The object then is to
minimise these wanderings and their effects.

Indeed. of course, for the purposes of what I was explaining, its valid
to consider the transmitter clock as perfect and the other running fast
or slow (its the relative difference that matters :-)

I don't know if there is any official timescale defined in audio for
the longest term that is 'jitter' beyond which it becomes 'drift' of
'static error'. Hence I'd be inclined to regard these as all facets of
the same problem and treat them accordingly.

Agreed :-)

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with
ketchup.

Add a DAC to a cheap CD player?
 

On Thu, 11 Dec 2003 13:18:22 +0000
James Perrett wrote:

And, IMHO, the wrong solution to the problem. Can we say 'aliasing' ?

In an ideal world there would be a better way to achieve jitter
immunity, but all the reports that I've heard claim that the SRC is very
transparent and the unit is one of the best (transparent) sounding DAC's
around.

Not denying that, it may sound excellent. I've never heard one :-)

Its just the wrong solution to the problem IMHO :)


--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

Add a DAC to a cheap CD player?
 

On Thu, 11 Dec 2003 13:18:22 +0000
James Perrett wrote:

And, IMHO, the wrong solution to the problem. Can we say 'aliasing' ?

In an ideal world there would be a better way to achieve jitter
immunity, but all the reports that I've heard claim that the SRC is very
transparent and the unit is one of the best (transparent) sounding DAC's
around.

Not denying that, it may sound excellent. I've never heard one :-)

Its just the wrong solution to the problem IMHO :)


--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

Add a DAC to a cheap CD player?
 

On Wed, 10 Dec 2003 21:04:54 +0000, Ian Molton wrote:

On Wed, 10 Dec 2003 17:56:14 +0000 (UTC)
(Stewart Pinkerton) wrote:

With the 'async' SPDIF you will hear every bit correctly (and thats
still dependant on the conversion method). with a reclocked output,
given the clock will NEVER be a perfect match for the SPDIF clock
anyway, you are garaunteed to either drop or stretch a whole bit at
some point. ick.

No, this is simply not true - although it depends on an adequate
buffer.

No, you ARE wrong.

No, I'm right - you appear not to understand how domestic digital
audio works.

there are two scenarios, and jitter really isnt an issue, becaue

Scenario 1:

Two clocks are a *perfect* frequency match. Unheard of unless they are physically
synchronised, which isnt what we are discussing, so discard this scenario.

Agreed.

Scenario 2:
The two clocks are not a prefect match, the DAC clock is either slower or faster than the
data sources clock.

in this case, if its faster, it will (periodically) drain all its buffering, no matter how much
there is, and will end up stretching bits to fill the gap (or playing silence, whatever)

Not relevant to CD, which has a defined 74 minute maximum, and there
do exist fully buffered true reclocking systems such as the Meridian
800 series, which certainly does *not* drop bits.

if its slower, it will, periodically end up with the buffer over-filling and bits will be lost.

See above.

jitter is simply noise above, and will average out to nothing.

This however will not help the FM distortion which it causes in the
analogue output of the DAC.................

If it DIDNT cancel out, it'd
effectvely be a frequency drift of the data sources clock, which is no longer called jitter (duh).

such a 'drift' would imply a loss of data

There will however be *no* loss of data in a domestic audio situation,
so you are flat-out *wrong*.

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

For God's sake, trim your line lengths!!!
--

Stewart Pinkerton | Music is Art - Audio is Engineering

Add a DAC to a cheap CD player?
 

On Wed, 10 Dec 2003 21:04:54 +0000, Ian Molton wrote:

On Wed, 10 Dec 2003 17:56:14 +0000 (UTC)
(Stewart Pinkerton) wrote:

With the 'async' SPDIF you will hear every bit correctly (and thats
still dependant on the conversion method). with a reclocked output,
given the clock will NEVER be a perfect match for the SPDIF clock
anyway, you are garaunteed to either drop or stretch a whole bit at
some point. ick.

No, this is simply not true - although it depends on an adequate
buffer.

No, you ARE wrong.

No, I'm right - you appear not to understand how domestic digital
audio works.

there are two scenarios, and jitter really isnt an issue, becaue

Scenario 1:

Two clocks are a *perfect* frequency match. Unheard of unless they are physically
synchronised, which isnt what we are discussing, so discard this scenario.

Agreed.

Scenario 2:
The two clocks are not a prefect match, the DAC clock is either slower or faster than the
data sources clock.

in this case, if its faster, it will (periodically) drain all its buffering, no matter how much
there is, and will end up stretching bits to fill the gap (or playing silence, whatever)

Not relevant to CD, which has a defined 74 minute maximum, and there
do exist fully buffered true reclocking systems such as the Meridian
800 series, which certainly does *not* drop bits.

if its slower, it will, periodically end up with the buffer over-filling and bits will be lost.

See above.

jitter is simply noise above, and will average out to nothing.

This however will not help the FM distortion which it causes in the
analogue output of the DAC.................

If it DIDNT cancel out, it'd
effectvely be a frequency drift of the data sources clock, which is no longer called jitter (duh).

such a 'drift' would imply a loss of data

There will however be *no* loss of data in a domestic audio situation,
so you are flat-out *wrong*.

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with ketchup.

For God's sake, trim your line lengths!!!
--

Stewart Pinkerton | Music is Art - Audio is Engineering

Add a DAC to a cheap CD player?
 

On Thu, 11 Dec 2003 10:06:03 +0000 (GMT), Jim Lesurf
wrote:

In article , Ian Molton
wrote:


Scenario 2: The two clocks are not a prefect match, the DAC clock is
either slower or faster than the data sources clock.

in this case, if its faster, it will (periodically) drain all its
buffering, no matter how much there is, and will end up stretching bits
to fill the gap (or playing silence, whatever)

This may be the case if there is no mechanism in the receiver to adjust its
medium/long-term clock frequency towards that of the transmitter. However
the S/PDIF stream has clock info encoded into it. Hence a receiver can use
this as it wishes to avoid the phases drifting too far if the designer so
chooses.

Yes, and the Audio Synthesis DAX used a rather cunning system whereby
an essentially free-running low phase-noise oscillator was 'nudged'
every few seconds by a difference signal derived from the datastream.
Essentially a *very* narrow-band PLL, but rather a crafty
implementation.

jitter is simply noise above, and will average out to nothing. If it
DIDNT cancel out, it'd effectvely be a frequency drift of the data
sources clock, which is no longer called jitter (duh).

The above treats this as a matter of terminology. In reality, both the
transmitter and reciver clocks will wander about in an apparently random
manner over all timescales of variation. The object then is to minimise
these wanderings and their effects.

I don't know if there is any official timescale defined in audio for the
longest term that is 'jitter' beyond which it becomes 'drift' of 'static
error'. Hence I'd be inclined to regard these as all facets of the same
problem and treat them accordingly.

Perhaps we could agree that 74 minutes would be a hard limit for
jitter on a CD? :-)
--

Stewart Pinkerton | Music is Art - Audio is Engineering

Add a DAC to a cheap CD player?
 

On Thu, 11 Dec 2003 10:06:03 +0000 (GMT), Jim Lesurf
wrote:

In article , Ian Molton
wrote:


Scenario 2: The two clocks are not a prefect match, the DAC clock is
either slower or faster than the data sources clock.

in this case, if its faster, it will (periodically) drain all its
buffering, no matter how much there is, and will end up stretching bits
to fill the gap (or playing silence, whatever)

This may be the case if there is no mechanism in the receiver to adjust its
medium/long-term clock frequency towards that of the transmitter. However
the S/PDIF stream has clock info encoded into it. Hence a receiver can use
this as it wishes to avoid the phases drifting too far if the designer so
chooses.

Yes, and the Audio Synthesis DAX used a rather cunning system whereby
an essentially free-running low phase-noise oscillator was 'nudged'
every few seconds by a difference signal derived from the datastream.
Essentially a *very* narrow-band PLL, but rather a crafty
implementation.

jitter is simply noise above, and will average out to nothing. If it
DIDNT cancel out, it'd effectvely be a frequency drift of the data
sources clock, which is no longer called jitter (duh).

The above treats this as a matter of terminology. In reality, both the
transmitter and reciver clocks will wander about in an apparently random
manner over all timescales of variation. The object then is to minimise
these wanderings and their effects.

I don't know if there is any official timescale defined in audio for the
longest term that is 'jitter' beyond which it becomes 'drift' of 'static
error'. Hence I'd be inclined to regard these as all facets of the same
problem and treat them accordingly.

Perhaps we could agree that 74 minutes would be a hard limit for
jitter on a CD? :-)
--

Stewart Pinkerton | Music is Art - Audio is Engineering

Add a DAC to a cheap CD player?
 

On Wed, 10 Dec 2003 21:03:31 +0000, Ian Bell
wrote:

Wally wrote:

[original post missing from my server]

In article , Jim H

My point is, with digital better fidelity means better at recovering
data. If high-end dacs were good at this they would find it harder
to justify ridiculous CD transport prices.

How would you square this view with my earlier comment that, if a cheap CD
drive can deliver faultless computer data, then a cheap CD transport
should be able to do so as well? Do CD transports lack error correction
that one presumes is present in computer kit?


I think all decks are basicaly the same at recovering data, its the
conversion to analoguw where the differences lie.

Basically true, any competent player from £50 upwards will recover the
data with uncorrected (but still concealed) errors at a rate of less
than one per ten *million* samples, For audio purposes, I trust that
we can call this perfect.
--

Stewart Pinkerton | Music is Art - Audio is Engineering

Add a DAC to a cheap CD player?
 

On Wed, 10 Dec 2003 21:03:31 +0000, Ian Bell
wrote:

Wally wrote:

[original post missing from my server]

In article , Jim H

My point is, with digital better fidelity means better at recovering
data. If high-end dacs were good at this they would find it harder
to justify ridiculous CD transport prices.

How would you square this view with my earlier comment that, if a cheap CD
drive can deliver faultless computer data, then a cheap CD transport
should be able to do so as well? Do CD transports lack error correction
that one presumes is present in computer kit?


I think all decks are basicaly the same at recovering data, its the
conversion to analoguw where the differences lie.

Basically true, any competent player from £50 upwards will recover the
data with uncorrected (but still concealed) errors at a rate of less
than one per ten *million* samples, For audio purposes, I trust that
we can call this perfect.
--

Stewart Pinkerton | Music is Art - Audio is Engineering

Add a DAC to a cheap CD player?
 

On Thu, 11 Dec 2003 17:56:08 +0000 (UTC)
(Stewart Pinkerton) wrote:

No, you ARE wrong.

No, I'm right - you appear not to understand how domestic digital
audio works.

No, you are WRONG and trying to worm out of it byu changing the argument
and trying to insult my intelligence.

Scenario 2:
The two clocks are not a prefect match, the DAC clock is either
slower or faster than the data sources clock.

in this case, if its faster, it will (periodically) drain all its
buffering, no matter how much there is, and will end up stretching
bits to fill the gap (or playing silence, whatever)

Not relevant to CD, which has a defined 74 minute maximum, and there
do exist fully buffered true reclocking systems such as the Meridian
800 series, which certainly does *not* drop bits.

I didnt specify a CD source, did I?

if its slower, it will, periodically end up with the buffer
over-filling and bits will be lost.

See above.

Yep, adds up to what I said.

jitter is simply noise above, and will average out to nothing.

This however will not help the FM distortion which it causes in the
analogue output of the DAC.................

a few seconds of buffer on any DAC ought to make that 99.999999999%
inaudible.

If it DIDNT cancel out, it'd
effectvely be a frequency drift of the data sources clock, which is
no longer called jitter (duh).

such a 'drift' would imply a loss of data

There will however be *no* loss of data in a domestic audio situation,
so you are flat-out *wrong*.

In the case of CD Im still *correct* its just irrelevant.

in the case of a source capable of more than 74 minutes output, Im 100%
right.

full reclocking systems are as pointless as they are expensive.

--
Spyros lair: http://www.mnementh.co.uk/ |||| Maintainer: arm26 linux

Do not meddle in the affairs of Dragons, for you are tasty and good with
ketchup.