Add a DAC to a cheap CD player?
 

In article , Wally
wrote:
Jim Lesurf wrote:


Listened to on a Quad 67 the sound just got very vague and dull. (This
was using the Meridian DAC outboard from the Quad, so reading the same
data/errors in each case.) The Quad seems to try and 'hide' serious
losses by smoothing them over when the meridian seems to decide
"bugger it! I'd better let them hear this isn't right!" :-)

Vague and dull is more like what I get from the Schneider player.

It is therefore possible that this is due to smoothing over lost data.
However it may simply be that the frequency response is poor and is rolling
off the HF. Hard to say without some measurements, etc.


Pay yer money and take yer choice on which approach you'd prefer...

Given that I don't have a handy DAC with which to test my cheapie
player, I suspect it's more a case of paying my money and taking my
chance... :-)

:-) That does tend to be the way around - unless you can pursuade someone
to loan you a DAC on a 'try before buy' basis.


Afraid I can't really say. In normal use, my experience is that DACs
do not often make large differences once the system is essentially
decent.

That leaves me feeling that almost any external DAC is going to be an
improvement over the player's internal one. Which leads me to wonder if
something at the (very) cheap end of second hand would make a good
improvement.

I'm biassed, but my recommendation would be for an old meridian DAC as
these seem well engineered, and sound excellent to me. Other DACs may be
superb, though. Some makers do seem to engineer a specific 'sound' which
you may prefer.

I've noticed in my browsing that some are listed as doing 30-something
KHz, as well as 44.1 and 48, and assumed that some were designed to
handle different rates. I've been wondering if I should be looking for
something which will handle 48KHz as well as 44.1, as a future-proofing
thing, but I'm feeling now that 44.1 will be sufficient for a good while.

If you are going to play the sound from DVDs then 48kHz is required. Also
check that your DVD can be set to output S/PDIF, not just the 'bitstream'
for surround Dolby, etc. Older DACs can understand S/PDIF but not the
bitstream.

(BTW This is yet another multiple-use of a word as 'bitstream' has also
been used for something quite difference to its meaning in this context.)

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

Add a DAC to a cheap CD player?
 

In article , Ian Molton
wrote:
On Wed, 10 Dec 2003 09:36:54 +0000 (GMT) Jim Lesurf
wrote:

DACs like the Meridian ones apply control loops to read in the data,
and then play them out under the control of a 'smoothed' local clock.
This can reduce the effects of jitter provided the input isn't too
bad.

well, there comes a point where cumulative jitter is more or less the
same as either no jitter, or (effectively) a different than expected
clock speed (with resulting loss of bits if it goes on long enough).

This all comes down to how you view what is happening - phase modulation or
frequency modulation. :-)

a 'smoothed' clock would basically be a 'super long timebase PLL' (is
that what you were getting at there?)

In effect, yes. The 'new' local clock has a frequency that only changes
(relatively) slowly. This clearly has to be limited as if it is too slow
the system will get out of step and you'll risk problems like buffer
under/over-flows or bit-skipping somewhere. Within the scope of such
problems, a longer slower clock should be better. Clever systems adapt this
to the quality of the data, but I doubt any domestic DACs go beyond the
Meridian approachs. There are various ways to skin this cat. The main doubt
is to how much effort is worthwhile as the problem may be less in practice
than magazine articles might lead us to believe.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

Add a DAC to a cheap CD player?
 

In article , Ian Molton
wrote:
On Wed, 10 Dec 2003 09:36:54 +0000 (GMT) Jim Lesurf
wrote:

DACs like the Meridian ones apply control loops to read in the data,
and then play them out under the control of a 'smoothed' local clock.
This can reduce the effects of jitter provided the input isn't too
bad.

well, there comes a point where cumulative jitter is more or less the
same as either no jitter, or (effectively) a different than expected
clock speed (with resulting loss of bits if it goes on long enough).

This all comes down to how you view what is happening - phase modulation or
frequency modulation. :-)

a 'smoothed' clock would basically be a 'super long timebase PLL' (is
that what you were getting at there?)

In effect, yes. The 'new' local clock has a frequency that only changes
(relatively) slowly. This clearly has to be limited as if it is too slow
the system will get out of step and you'll risk problems like buffer
under/over-flows or bit-skipping somewhere. Within the scope of such
problems, a longer slower clock should be better. Clever systems adapt this
to the quality of the data, but I doubt any domestic DACs go beyond the
Meridian approachs. There are various ways to skin this cat. The main doubt
is to how much effort is worthwhile as the problem may be less in practice
than magazine articles might lead us to believe.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

Add a DAC to a cheap CD player?
 

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.

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.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

Add a DAC to a cheap CD player?
 

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.

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.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

Add a DAC to a cheap CD player?
 

On Wed, 10 Dec 2003 14:45:27 +0000 (GMT)
Jim Lesurf wrote:


does it have an optical input?

Pass.

Apparently it does. I'll let you all know what I think of its output when it arrives ;-)

--
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 14:45:27 +0000 (GMT)
Jim Lesurf wrote:


does it have an optical input?

Pass.

Apparently it does. I'll let you all know what I think of its output when it arrives ;-)

--
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?
 

Ian Molton wrote:

On Wed, 10 Dec 2003 18:33:51 GMT
"Wally" wrote:

The best value for money in jitter immune DAC's is reputed to be the
Benchmark DAC1 which uses a sample rate convertor in front of the DAC.
It is a little out of your price range at $850 (no UK distributor
either).

Aye, a tad pricey. :-)

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.

Cheers.

James.

Add a DAC to a cheap CD player?
 

Ian Molton wrote:

On Wed, 10 Dec 2003 18:33:51 GMT
"Wally" wrote:

The best value for money in jitter immune DAC's is reputed to be the
Benchmark DAC1 which uses a sample rate convertor in front of the DAC.
It is a little out of your price range at $850 (no UK distributor
either).

Aye, a tad pricey. :-)

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.

Cheers.

James.

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 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.

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.

Add a DAC to a cheap CD player?
 

In article , Ian Molton
wrote:
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)

I need to distinguish between two situations:

1) Where the receiver/output clock rate is intended to be essentially the
same as that which we expect to receive. In this case I would call this
process 'reclocking' if a new clock is used at the receiver, rather than
just taking a filtered version of what arrives.

2) Where the receiver deliberately processes the data to a somewhat
different data rate (e.g. converting 44.1kHz data streams to 48kHz). I do
not call this 'reclocking' although I have seen it described as such.

In this thread I am primarily considering (1), not (2). On that basis
reclocking may or may not include a subsystem to adjust the long- or
medium-term frequency of the new clock to be in line with that being
received. Hence reclocking may or may not mean using a receiver clock that
"is not even locked".

In practice, it may well be advisible when converting to also do some form
of locking as well, so that in the example mentioned in (2) you might phase
lock the new 48kHz to the old 44.1kHz.

You always end up needing some amount of data buffering. However if you
have no attempts to lock the clocks over the long term, these buffers may
need to be very large. This may or may not be a 'good idea'. In the end,
with each approach, it comes down to "how well did the
designer/manufacturer impliment their solution as being appropriate for the
intended use?"


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 would not view in that way if the practical problem was that the TX clock
shows serious variations which - if allowed to affect the eventual DAC
conversion rates - would cause the output signal patterns to become audibly
phase-rate modulated. This would create a nasty form of intermodulation
distortion with components anharmonic with the music. In this situation it
may make sense to employ a smoother reciever clock, and treat that as being
the one to follow by reclocking the data to it! I would not normally choose
to conside *either* clock as "perfect", just look to see if they were
adequate for their intended purpose.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

Add a DAC to a cheap CD player?
 

In article , Ian Molton
wrote:
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)

I need to distinguish between two situations:

1) Where the receiver/output clock rate is intended to be essentially the
same as that which we expect to receive. In this case I would call this
process 'reclocking' if a new clock is used at the receiver, rather than
just taking a filtered version of what arrives.

2) Where the receiver deliberately processes the data to a somewhat
different data rate (e.g. converting 44.1kHz data streams to 48kHz). I do
not call this 'reclocking' although I have seen it described as such.

In this thread I am primarily considering (1), not (2). On that basis
reclocking may or may not include a subsystem to adjust the long- or
medium-term frequency of the new clock to be in line with that being
received. Hence reclocking may or may not mean using a receiver clock that
"is not even locked".

In practice, it may well be advisible when converting to also do some form
of locking as well, so that in the example mentioned in (2) you might phase
lock the new 48kHz to the old 44.1kHz.

You always end up needing some amount of data buffering. However if you
have no attempts to lock the clocks over the long term, these buffers may
need to be very large. This may or may not be a 'good idea'. In the end,
with each approach, it comes down to "how well did the
designer/manufacturer impliment their solution as being appropriate for the
intended use?"


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 would not view in that way if the practical problem was that the TX clock
shows serious variations which - if allowed to affect the eventual DAC
conversion rates - would cause the output signal patterns to become audibly
phase-rate modulated. This would create a nasty form of intermodulation
distortion with components anharmonic with the music. In this situation it
may make sense to employ a smoother reciever clock, and treat that as being
the one to follow by reclocking the data to it! I would not normally choose
to conside *either* clock as "perfect", just look to see if they were
adequate for their intended purpose.

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

Add a DAC to a cheap CD player?
 

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

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? :-)


Make it a shade over 80 mins. I have some 80 min CDRs. :-)

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html

Add a DAC to a cheap CD player?
 

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

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? :-)


Make it a shade over 80 mins. I have some 80 min CDRs. :-)

Slainte,

Jim

--
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Audio Misc http://www.st-and.demon.co.uk/AudioMisc/index.html
Armstrong Audio http://www.st-and.demon.co.uk/Audio/armstrong.html
Barbirolli Soc. http://www.st-and.demon.co.uk/JBSoc/JBSoc.html