"Colin B." wrote in
message
Arny Krueger wrote:
"Colin B." wrote in
message

Plugged the DVD player into the preamp, burned a copy of
Kind of Blue, and compared it very informally to my
Denon DCM-340. First thing I noticed is that (since I
didn't have any way of adjusting levels, although I
could have measured them) when there were drums or
trumpet playing, the DVD player was louder.

You know this is really sad. You may be bright enough
that you seem to realize that your listening test might
not be worth squat unless you adjusted the levels of the
two players within 0.1 dB.

Arny, I have defended DBT to the n'th degree.

Mere words with no actions to back them up.

I've agreed
ad nauseum on the criticality of proper testing and the
existence of listener bias.

Lip service.

Thus, please allow me to offer the following advice.

**** OFF! Take a valium. Take two! Wipe the spittle off
your chin, and then come back and reread my post.

This childish language just goes to show how immature and
irrational you are.

Nowhere did I mention the word "test" in my post, except
at the end.

You're just playing with words.

This was an evening of playing. This was
entertainment. This was interest. This was at the VERY
most, a way of deciding for myself if I should pursue
real testing methodology.

You're just defending doing some stupid stuff and then
extensively bragging about it in public.

You say you have the means to match levels, which I might
doubt but I'll take what you say at face value.

You misread. I said that I do NOT have the means to match
levels--only to measure them. A test-tone CD and an
oscilloscope (or even a good DVM, for that matter) should
accomplish that quite nicely. Matching them is another
matter altogether of course, and neither player has an
output level adjustment.

Adding external volume controls isn't rocket science. It's
not even very costly.

Nevertheless you just launched into a long rambling
dissertation about what you thought you heard, when your
listening test is obviously, grotesquely and
fundamentally flawed.

Well yes, that was sort of the point. Again I'll point
out that this wasn't a test.

You're dissembling.

You're lazy, both practically and intellectually.

Wow.

I'm speechless. Congratulations Arny. You win.

"DaveL" AKA Snake wrote in message
. ..
Actually I did hear of the mod from several sources. I did not do a
before
and after test but I can tell you that this unit sounds really good and
far
better than my Yamaha unit. If you believe that they all sound the same
then go ahead and keep your head (or ears) in the sand. How many
audiophiles are spending thousands on high end cd players and separate
dacs?
I guess they are all wasting their money when they could have done like
you
and bought the cheapest no name unit and had the same sound.


Or they could have bought a cheapish player and spent the difference on
better speakers, giving a *FAR* greater improvement. The reason they don't
is ignorance, or the desire for something *other* than a sonic improvement.
(eg. bragging rights)

If you believe
that all cd players have a perfectly flat frequency response and virtually
no distortion then you are simply ignorant to the truth.

If you believe you can really hear the minute differences in any *competent*
player, then you should do a double blind reality check.
OTOH, anyone can hear the differences between speakers. Put your money where
it does some *actual* good, or throw it away, it's your choice.

MrT.

"Colin B." wrote in
message
Wow.

I'm speechless. Congratulations Arny. You win.

I'm not here to win.

I'm here to wake you up.

On Fri, 4 Nov 2005 08:47:31 -0800, "DaveL" AKA Snake wrote:

Hi Arny,

All I know is what my ears tell me. But your measurements prove my point.
None of the analog output specs are the same. They all vary. This means
the all sound a little bit different.

Utter rubbish. These variations are *way* below the threshold of
audibility.

The difference may be slight but it
is still there. It could be like Stewart says that the newer players have
less variance. I can accept that. But please believe me that my Denon does
sound better than my Yamaha. This is no lie or misjudgment.

I'm sure you are not *deliberately* failing to tell the truth. I'm
equally sure that what you're saying is hogwash, as Arny has pointed
out.

--

Stewart Pinkerton | Music is Art - Audio is Engineering

"Colin B." wrote in message
...
Quick question for the techies out there.

Are there any currently available CD or DVD players out there which are
audibly flawed?


Wow, lot of nasty sniping going on here. From my own viewpoint and from
various non-scientific experiementation I've done personally, I find there
are a number of things that can influence CD sound quality. The digital
info basically goes into a receiver chip, then through a DAC, then through
an opamp. Any one of these (plus all the other assorted filtering
components, wire traces, RF interferece, etc.) can vary the sound. I am
using an aging dual 18-bit mono DAC setup that's more than 10 years old and
it sounds excellent. I have upgraded the op-amp to one which has better
specs. From what I have read (and I have read a fair amount about it) the
op-amp and capacitors used in the audio stage of the DAC and/or CD transport
play a far greater role than the DACs themselves... for example I use a new
(1yr old) decent quality DVD player as my CD, HDCD, and MP3 transport.
This sucker has 24-bit/96KHz DACs (actually probably a stereo dual DAC
given the price). A side-by-side comparison with my external DAC shows that
the sound quality sucks compared to the older external DAC which was built
with MUCH MUCH higher quality components in the output stage. There's just
no comparison.

When you spend more money on a CD/DVD player, generally speaking they are
built with higher quality components in the audio stage, ONE of which is the
DAC. You can and do have crap-quality players out there with fancy DAC
chips. You are also paying for R&D to design the circuit in such a way to
minimize different types of interference, be it by adding decoupling caps,
filtering and/or regulating the power supply, locating components which may
interfere with each other as far from each other as possible, etc.

Unless you are lucky enough to find a sound equipment dealer with a
listening room who is willing to set up side-by-side comparisons for you
(think higher-end stuff), you are always shooting in the dark somewhat when
purchasing a component. Spend as much as you can afford, do your research,
and hopefully you come home with something you can live with for a few
years.

One last thing: sound quality is subjective. Yeah, yeah, there are ways to
measure the purity of the output, but what it comes down to is this: you
either like the sound or you don't. One person's "better" may be another's
"worse".

Just my 2 cents

Dave

Dave wrote:

"Colin B." wrote in message
...

Quick question for the techies out there.

Are there any currently available CD or DVD players out there which are
audibly flawed?



Wow, lot of nasty sniping going on here. From my own viewpoint and from
various non-scientific experiementation I've done personally, I find there
are a number of things that can influence CD sound quality. The digital
info basically goes into a receiver chip, then through a DAC, then through
an opamp. Any one of these (plus all the other assorted filtering
components, wire traces, RF interferece, etc.) can vary the sound. I am
using an aging dual 18-bit mono DAC setup that's more than 10 years old and
it sounds excellent. I have upgraded the op-amp to one which has better
specs. From what I have read (and I have read a fair amount about it) the
op-amp and capacitors used in the audio stage of the DAC and/or CD transport
play a far greater role than the DACs themselves... for example I use a new
(1yr old) decent quality DVD player as my CD, HDCD, and MP3 transport.
This sucker has 24-bit/96KHz DACs (actually probably a stereo dual DAC
given the price). A side-by-side comparison with my external DAC shows that
the sound quality sucks compared to the older external DAC which was built
with MUCH MUCH higher quality components in the output stage. There's just
no comparison.

When you spend more money on a CD/DVD player, generally speaking they are
built with higher quality components in the audio stage, ONE of which is the
DAC. You can and do have crap-quality players out there with fancy DAC
chips. You are also paying for R&D to design the circuit in such a way to
minimize different types of interference, be it by adding decoupling caps,
filtering and/or regulating the power supply, locating components which may
interfere with each other as far from each other as possible, etc.

Unless you are lucky enough to find a sound equipment dealer with a
listening room who is willing to set up side-by-side comparisons for you
(think higher-end stuff), you are always shooting in the dark somewhat when
purchasing a component. Spend as much as you can afford, do your research,
and hopefully you come home with something you can live with for a few
years.

One last thing: sound quality is subjective. Yeah, yeah, there are ways to
measure the purity of the output, but what it comes down to is this: you
either like the sound or you don't. One person's "better" may be another's
"worse".

Just my 2 cents

In which case, if one is taking the digital data stream via optic from the CD
player does it matter at all as to its quality as long as it gets the data off
the disc?

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

"Dirk Bruere at Neopax" wrote in message
...

In which case, if one is taking the digital data stream via optic from the
CD
player does it matter at all as to its quality as long as it gets the data
off
the disc?

Yes and no. Your digital filter, dac, and analog output stages all impact
the final output, but they all work with the same 16-bit, 44kHz source. Any
CD transport with equivalent quality output will read and output the same
info. That having been said, cheaper transports and/or DVD/CD players tend
to have equally cheap, non-decoupled, nonregulated power supplies, poor
circuit components and/or design, which (and that's not the whole list) may
add unwanted digital noise or corruption to the output stream. So in that
regard not all transports are created equal.

There are reasons why people might pay $9,000 for a Krell CD transport or
high-end DAC... I don't claim to be able to tell the difference (nor have
that kind of cash to lay out on a CD transport) but I CAN tell the
difference between a poorly designed, poorly executed digital source and a
well-designed, well-built one. I guess it all boils down to what your
standards are. I will grant you, a $100 Sony or Panasonic CD player will
sound pretty good next to a cassette tape. The difference in fidelity is
HUGE and painfully obvious even to the most tone-deaf listener. Not so with
digital audio, where the unwanted background noise has been virtually
eliminated. Most people get used to hearing what comes out of their stereo.
If they've only ever had a lower-end model, then that's what they expect
and, as such, are not unhappy with the output. BUT, sit that big middle
demographic down with a side-by-side comparison with a higher-end system and
they'll hear the difference. Whether they're willing to pay for it is
personal choice.

Dave

Dave wrote:

"Dirk Bruere at Neopax" wrote in message
...

In which case, if one is taking the digital data stream via optic from the

CD

player does it matter at all as to its quality as long as it gets the data

off

the disc?


Yes and no. Your digital filter, dac, and analog output stages all impact
the final output, but they all work with the same 16-bit, 44kHz source. Any
CD transport with equivalent quality output will read and output the same
info. That having been said, cheaper transports and/or DVD/CD players tend
to have equally cheap, non-decoupled, nonregulated power supplies, poor
circuit components and/or design, which (and that's not the whole list) may
add unwanted digital noise or corruption to the output stream. So in that
regard not all transports are created equal.

There are reasons why people might pay $9,000 for a Krell CD transport or
high-end DAC... I don't claim to be able to tell the difference (nor have
that kind of cash to lay out on a CD transport) but I CAN tell the
difference between a poorly designed, poorly executed digital source and a
well-designed, well-built one. I guess it all boils down to what your
standards are. I will grant you, a $100 Sony or Panasonic CD player will
sound pretty good next to a cassette tape. The difference in fidelity is
HUGE and painfully obvious even to the most tone-deaf listener. Not so with
digital audio, where the unwanted background noise has been virtually
eliminated. Most people get used to hearing what comes out of their stereo.
If they've only ever had a lower-end model, then that's what they expect
and, as such, are not unhappy with the output. BUT, sit that big middle
demographic down with a side-by-side comparison with a higher-end system and
they'll hear the difference. Whether they're willing to pay for it is
personal choice.

I was really thinking about CD data ripped in .wav to HDDs.
PC CDROM drives are about as cheap as you can get.
I haven't noticed any difference in quality of final output.
Would one really see differences in data between different CDROM drives?

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

"Dirk Bruere at Neopax" wrote in message
...
I was really thinking about CD data ripped in .wav to HDDs.
PC CDROM drives are about as cheap as you can get.
I haven't noticed any difference in quality of final output.
Would one really see differences in data between different CDROM drives?

You make a good point. The answer, of course, is No. Even one bit out of
place could make a data cd useless. I believe that you can dub cd's to hard
drive with no loss of quality, but then I believe in the Great Pumpkin, too.

Your question is beyond the scope of my abilities... I am pretty sure that
noise on the digital line has GOT to affect the sound quality... why this
does not affect the ability of a PC to correctly read data I do not know.
Maybe somebody can help me out here....

DAve

In article mR8ef.108238$y_1.4778@edtnps89,
Dave wrote:

I was really thinking about CD data ripped in .wav to HDDs.
PC CDROM drives are about as cheap as you can get.
I haven't noticed any difference in quality of final output.
Would one really see differences in data between different CDROM drives?

You make a good point. The answer, of course, is No. Even one bit out of
place could make a data cd useless. I believe that you can dub cd's to hard
drive with no loss of quality, but then I believe in the Great Pumpkin, too.

Your question is beyond the scope of my abilities... I am pretty sure that
noise on the digital line has GOT to affect the sound quality... why this
does not affect the ability of a PC to correctly read data I do not know.
Maybe somebody can help me out here....

Well, there are several different issues involved here.

As far as "ripping" and CD-ROM drives are concerned - the issues are
those of proper reading from the disc itself (e.g. accurate Red Book
audio CD error detection, error correction, and concealment) and audio
block-address accuracy (what's often misleadingly called "jitter").

These days, any high-quality CD-ROM drive ought to be able to read the
Red Book data from the disc accurately, applying the Red Book C1/C2
Reed-Solomon error correction coding, and doing error concealment
(interpolation or muting) to "hide" any errors which are too severe
for proper error correction. I have seen some drives (older ones,
mostly) which fouled this process up pretty badly - they didn't do
adequate C1/C2 error correction/concealment of digital audio data, or
suffered from really severe block-addressing inaccuracy (bad "jitter").

Many CD "ripping" packages have the ability to read each section of
the disc multiple times and compare the result... a good way to catch
uncorrected or badly-concealed errors and retry the reads until the
drive delivers the data correctly.

With a decent CD-ROM drive and good ripping software, you should get
data that is essentially error-free. Further processing won't care
which drive the data came from.

Transports and DACs involve a different set of issues. The transport
plays through the data once, applying the Reed/Solomon
error-correction coding and de-interleaving, and then packages the
data up in S/PDIF data frames and sends them to the external DAC-box.
The DAC-box must receive the S/PDIF data, and:

[1] Extract the data,
[2] Recover a clock signal, and
[3] Check the parity in each block, and
[4] Feed the data, and a clock signal, are then fed to the DAC chip
(or a digital filter which preceeds it) for conversion to analog.

The trickiest part of this problem involves the clock signal. S/PDIF
does not have a distinct clock signal on a separate set of conductors.
Instead, the clocking is "embedded" in the data - the S/PDIF receiver
must reconstruct a clock signal based on the transition times of the
data signal. This is usually done by the S/PDIF receiver chip, using
a phase-locked loop circuit of some sort.

Many external DAC-boxes simply feed this clock signal from the PLL
right into the DAC chip or digital filter. This is the commonest
approach, I believe, and it's not a good one. Timing or amplitude
imprecision in the clocking (jitter) can induce errors in the
reconstructed analog audio waveform... they're measurable, and in some
cases they may very well be audible. This is one area in which the
presence of noise on a digital signal can have an effect on the analog
signal.

Better-design DAC boxes do a better job of creating a stable timing
signal for the DAC-chip to use when converting digital samples to
analog. This may be done by using multiple stages of phase-locked
loop (filtering out the jitter), or by buffering the digital samples
through "deep" first-in, first-out FIFO buffer and using a stable
quartz-crystal oscillator to clock the signals out of the FIFO into
the DAC, or by using an asynchronous sample-rate converter to resample
the data stream before feeding it into a crystal-oscillator-timed DAC.

This is one of the areas in which the market, and its perceptions, can
be a bit backwards from reality. Some DAC-boxes have a reputation for
"revealing" the differences between different transports, and this is
often touted as a good and impressive characteristic. I see it
otherwise... a good DAC-box should be entirely immune to timing
jitter, noise on the S/PDIF signal, etc., and should always sound at
its best. DAC-boxes which "reveal" transport-related differences in
the S/PDIF signal are, I think, showing that their clock recovery
circuits are not robustly designed.

Single-box CD players (potentially less expensive than transport/DAC
combinations) don't have the S/PDIF clock-recovery problem at all -
they're immune to this particular problem. A single-box player runs
its internal DAC from a stable quartz-crystal oscillator, not from a
clocking signal recovered from the disc or data.

--
Dave Platt AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

On Mon, 14 Nov 2005 22:31:36 GMT, "Dave"
wrote:


"Dirk Bruere at Neopax" wrote in message
...

In which case, if one is taking the digital data stream via optic from the
CD
player does it matter at all as to its quality as long as it gets the data
off
the disc?

Yes and no. Your digital filter, dac, and analog output stages all impact
the final output, but they all work with the same 16-bit, 44kHz source. Any
CD transport with equivalent quality output will read and output the same
info. That having been said, cheaper transports and/or DVD/CD players tend
to have equally cheap, non-decoupled, nonregulated power supplies, poor
circuit components and/or design, which (and that's not the whole list) may
add unwanted digital noise or corruption to the output stream. So in that
regard not all transports are created equal.

There are reasons why people might pay $9,000 for a Krell CD transport or
high-end DAC... I don't claim to be able to tell the difference (nor have
that kind of cash to lay out on a CD transport) but I CAN tell the
difference between a poorly designed, poorly executed digital source and a
well-designed, well-built one.

Actually, if true (which is doubtful) that would simply indicate that
you have a really poor DAC. I have not in about fifteen years now seen
any digital output which had such poor performance that it was
*audibly* different when used with a decent DAC. It is the DAC which
is utterly critical here, not the transport.

Use a properly designed DAC such as the impeccable Benchmark DAC-1,
and transport 'quality' is quite simply irrelevant.
--

Stewart Pinkerton | Music is Art - Audio is Engineering

On Mon, 14 Nov 2005 23:12:18 GMT, "Dave"
wrote:

"Dirk Bruere at Neopax" wrote in message
...
I was really thinking about CD data ripped in .wav to HDDs.
PC CDROM drives are about as cheap as you can get.
I haven't noticed any difference in quality of final output.
Would one really see differences in data between different CDROM drives?

You make a good point. The answer, of course, is No. Even one bit out of
place could make a data cd useless. I believe that you can dub cd's to hard
drive with no loss of quality, but then I believe in the Great Pumpkin, too.

Your question is beyond the scope of my abilities... I am pretty sure that
noise on the digital line has GOT to affect the sound quality... why this
does not affect the ability of a PC to correctly read data I do not know.
Maybe somebody can help me out here....

Sure, no problem. Your certainty has no basis in fact. The whole
*point* of digital signal transmission is that, unless it is so big
that it causes bits to be dropped, noise on the datastream makes
absolutely *zero* difference to the reconstructed analogue signal,
given a properly designed digital to analogue conversion system, aka
DAC.
--

Stewart Pinkerton | Music is Art - Audio is Engineering

Stewart Pinkerton wrote:
On Mon, 14 Nov 2005 23:12:18 GMT, "Dave"
wrote:


"Dirk Bruere at Neopax" wrote in message
...

I was really thinking about CD data ripped in .wav to HDDs.
PC CDROM drives are about as cheap as you can get.
I haven't noticed any difference in quality of final output.
Would one really see differences in data between different CDROM drives?


You make a good point. The answer, of course, is No. Even one bit out of
place could make a data cd useless. I believe that you can dub cd's to hard
drive with no loss of quality, but then I believe in the Great Pumpkin, too.

Your question is beyond the scope of my abilities... I am pretty sure that
noise on the digital line has GOT to affect the sound quality... why this
does not affect the ability of a PC to correctly read data I do not know.
Maybe somebody can help me out here....


Sure, no problem. Your certainty has no basis in fact. The whole
*point* of digital signal transmission is that, unless it is so big
that it causes bits to be dropped, noise on the datastream makes
absolutely *zero* difference to the reconstructed analogue signal,
given a properly designed digital to analogue conversion system, aka
DAC.

So can we conclude, for CD players, that the only (or major?) reason for
differences in price are due to the DACs?

--
Dirk

The Consensus:-
The political party for the new millenium
http://www.theconsensus.org

"Colin B." wrote in
message

Quick question for the techies out there.

Are there any currently available CD or DVD players out
there which are audibly flawed?

Typically, audible flaws are due to the player being broken
or having some fairly gross design issues.

There are also some degenerate classes of CD players such as
the CD ROM drives in computers with analog outputs and/or
headphone jacks, and cost-effective portables.

From all I've heard, CD players seem to have hit
essential perfection a few years ago. I've been
considering getting a
replacement for my ancient (i.e. ~16 years old) player,
but want to do some listening first, to see how important
it is in the grand scheme of things.

One approach is to buy a modestly-priced *universal* player
such as the Pioneer DV 588 .

However, the only modern CD player I have available is a
no-name DVD player
(matsumagna****asonic or some such thing).

The worst problem I've had with these is that they don't
last. I got less than 18 months out of the last two no-name
DVD players I bought, and they were used very lightly. In
contrast I have a Pioneer DV 525 that has got to be 5-6
years old, and does yoeman duty for both audio and video.

I have to admit that I rip a lot more CDs than I listen to
directly, and most of the CDs I listen to directly are CD's
I produced from live performances.

Can I count on
something this cheap to be audibly nonexistent, or am I
going to have to borrow at least a name-brand item from
someone?

If you have a PC with a pretty good sound card, you could
run the freebie AudioRightmark on your player via a CD-R of
their test data, and see how yours works. Unless you have
something special in the way of a sound card (i.e., a AP
24192 or LynxTwo) the player will probably outperform your
sound card. But if the sound card is good, you'll know the
player is at least that good.

"Dirk Bruere at Neopax" wrote in
message

So can we conclude, for CD players, that the only (or
major?) reason for differences in price are due to the
DACs?

Not at all. The major reason for differences in price are
parts of the player other than the audio signal chain from
converter out. IOW, the case, the display, the transport,
the buttons, the image, etc.

The signal path from the converter out has a parts cost of
about $3 for a top-quality well-engineered player, and much
less for a real cheapie. This translates into a
cost-justified consumer price increase of no more than $20.

I find that there still be be significant differences in
sound quality due to things like ability to track difficult
media. One leading common source of difficult media is
home-burned CDs. The degree to which light mistracking can
be confused with problems in the analog domain may surprise
many.

"Harry Lavo" wrote in message

"Arny Krueger" wrote in message
...
"Colin B." wrote in
message

snip



Nevertheless you just launched into a long rambling
dissertation about what you thought you heard, when your
listening test is obviously, grotesquely and
fundamentally flawed.

Not given to overstatement, are you Arny?

No, I was understating the problem.

"Dave Platt" wrote in message
...
..

The trickiest part of this problem involves the clock signal. S/PDIF
does not have a distinct clock signal on a separate set of conductors.
Instead, the clocking is "embedded" in the data - the S/PDIF receiver
must reconstruct a clock signal based on the transition times of the
data signal. This is usually done by the S/PDIF receiver chip, using
a phase-locked loop circuit of some sort.


Is there some "raw" format which bypasses the S/PDIF and it's inherent
clocking limitations which could be output to a redesigned external DAC?
Maybe I2S? I mean, if it's the S/PDIF encoding/decoding which introduces
clock error (and hence "jitter") hasn't anyone said "there's got to be a
better way"? I am thinking not, as everybody seems to be trying to build a
better S/PDIF-based (external) DAC. But hypothetically, if a transport
output both the datastream AND a clock signal in realtime instead of
packaged in frames requiring decoding at the receiving end... well, why not?


Single-box CD players (potentially less expensive than transport/DAC
combinations) don't have the S/PDIF clock-recovery problem at all -
they're immune to this particular problem. A single-box player runs
its internal DAC from a stable quartz-crystal oscillator, not from a
clocking signal recovered from the disc or data.

--
Dave Platt AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

In article n%mef.112190$y_1.66453@edtnps89,
Dave wrote:

"Dave Platt" wrote in message
...
.

The trickiest part of this problem involves the clock signal. S/PDIF
does not have a distinct clock signal on a separate set of conductors.
Instead, the clocking is "embedded" in the data - the S/PDIF receiver
must reconstruct a clock signal based on the transition times of the
data signal. This is usually done by the S/PDIF receiver chip, using
a phase-locked loop circuit of some sort.


Is there some "raw" format which bypasses the S/PDIF and it's inherent
clocking limitations which could be output to a redesigned external DAC?
Maybe I2S? I mean, if it's the S/PDIF encoding/decoding which introduces
clock error (and hence "jitter") hasn't anyone said "there's got to be a
better way"? I am thinking not, as everybody seems to be trying to build a
better S/PDIF-based (external) DAC. But hypothetically, if a transport
output both the datastream AND a clock signal in realtime instead of
packaged in frames requiring decoding at the receiving end... well, why not?

From what I recall, I'm fairly sure that there have been some
transports made which generated I2S, and some DACs made which would
accept it. This of course requires a different cabling arrangement...
the setups I remember used mini-DIN connectors and cables, the same as
are used for S-Video.

Using this approach decreases the clocking problems, but doesn't
eliminate them entirely. You've still got the master oscillator
(which is a quartz-crystal type) sitting in the transport box, being
sent over a transmission line to the DAC box. Ground loops, noise,
etc. can still get into the clock on its way to the digital filter and
DAC chip and mess up the conversion to some extent.

Another way to do this is to reverse the direction of the clocking.
Put the quartz-crystal oscillator in the DAC box, and feed its (clean,
low-jitter, well-shielded) signal directly to the filter/DAC-chip.
The clock signal would also be buffered, and transmitted down the
clock line in the multi-conductor cable to the transport. The
transport would then slave itself to this clock signal, feeding the
bits up the cable to the DAC-box under control of the external clock.

This approach pretty much replicates, in a two-box system, the clock
distribution strategy used in a single-box CD player. The DAC chip
itself is fed from the cleanest and most stable clock in the system,
and the transport is slaved to this clock (rather than the other way
around).

I don't know whether anyone has built a transport / DAC-box product
line using this approach.

--
Dave Platt AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

On Tue, 15 Nov 2005 15:18:43 GMT, "Dave"
wrote:


"Dave Platt" wrote in message
...
.

The trickiest part of this problem involves the clock signal. S/PDIF
does not have a distinct clock signal on a separate set of conductors.
Instead, the clocking is "embedded" in the data - the S/PDIF receiver
must reconstruct a clock signal based on the transition times of the
data signal. This is usually done by the S/PDIF receiver chip, using
a phase-locked loop circuit of some sort.


Is there some "raw" format which bypasses the S/PDIF and it's inherent
clocking limitations which could be output to a redesigned external DAC?
Maybe I2S? I mean, if it's the S/PDIF encoding/decoding which introduces
clock error (and hence "jitter") hasn't anyone said "there's got to be a
better way"? I am thinking not, as everybody seems to be trying to build a
better S/PDIF-based (external) DAC. But hypothetically, if a transport
output both the datastream AND a clock signal in realtime instead of
packaged in frames requiring decoding at the receiving end... well, why not?

It's called SDIF-2, has separate master clock and data lines, and has
been used in the recording industry for decades. However, the
existence of top-class sample-rate converting DACs like the Benchmark
render the use of this standard moot for home listening.

--

Stewart Pinkerton | Music is Art - Audio is Engineering

On Tue, 15 Nov 2005 11:01:14 +0000, Dirk Bruere at Neopax
wrote:

Stewart Pinkerton wrote:
On Mon, 14 Nov 2005 23:12:18 GMT, "Dave"
wrote:


"Dirk Bruere at Neopax" wrote in message
...

I was really thinking about CD data ripped in .wav to HDDs.
PC CDROM drives are about as cheap as you can get.
I haven't noticed any difference in quality of final output.
Would one really see differences in data between different CDROM drives?


You make a good point. The answer, of course, is No. Even one bit out of
place could make a data cd useless. I believe that you can dub cd's to hard
drive with no loss of quality, but then I believe in the Great Pumpkin, too.

Your question is beyond the scope of my abilities... I am pretty sure that
noise on the digital line has GOT to affect the sound quality... why this
does not affect the ability of a PC to correctly read data I do not know.
Maybe somebody can help me out here....


Sure, no problem. Your certainty has no basis in fact. The whole
*point* of digital signal transmission is that, unless it is so big
that it causes bits to be dropped, noise on the datastream makes
absolutely *zero* difference to the reconstructed analogue signal,
given a properly designed digital to analogue conversion system, aka
DAC.

So can we conclude, for CD players, that the only (or major?) reason for
differences in price are due to the DACs?

No, the differences in price are down to what the marketing department
thinks the market will bear. Manufacturing costs are down to the DAC
chips, the complexity of the output stage, and the number and
complexity of the power supplies. In many 'designer label' cases (pun
intended), the above costs are totally outweighed by the cost of the
inch-thick laser-etched alloy casework, and wafer-thin heavily damped
loading mechanism (or even fancier top-loading arrangement). The
actual transport mechanism which retrieves the information from the
disc, will cost about $20 in every case.

--

Stewart Pinkerton | Music is Art - Audio is Engineering

On Tue, 15 Nov 2005 18:52:56 -0000, (Dave Platt)
wrote:

In article n%mef.112190$y_1.66453@edtnps89,
Dave wrote:

"Dave Platt" wrote in message
...
.

The trickiest part of this problem involves the clock signal. S/PDIF
does not have a distinct clock signal on a separate set of conductors.
Instead, the clocking is "embedded" in the data - the S/PDIF receiver
must reconstruct a clock signal based on the transition times of the
data signal. This is usually done by the S/PDIF receiver chip, using
a phase-locked loop circuit of some sort.


Is there some "raw" format which bypasses the S/PDIF and it's inherent
clocking limitations which could be output to a redesigned external DAC?
Maybe I2S? I mean, if it's the S/PDIF encoding/decoding which introduces
clock error (and hence "jitter") hasn't anyone said "there's got to be a
better way"? I am thinking not, as everybody seems to be trying to build a
better S/PDIF-based (external) DAC. But hypothetically, if a transport
output both the datastream AND a clock signal in realtime instead of
packaged in frames requiring decoding at the receiving end... well, why not?

From what I recall, I'm fairly sure that there have been some
transports made which generated I2S, and some DACs made which would
accept it. This of course requires a different cabling arrangement...
the setups I remember used mini-DIN connectors and cables, the same as
are used for S-Video.

Using this approach decreases the clocking problems, but doesn't
eliminate them entirely. You've still got the master oscillator
(which is a quartz-crystal type) sitting in the transport box, being
sent over a transmission line to the DAC box. Ground loops, noise,
etc. can still get into the clock on its way to the digital filter and
DAC chip and mess up the conversion to some extent.

Another way to do this is to reverse the direction of the clocking.
Put the quartz-crystal oscillator in the DAC box, and feed its (clean,
low-jitter, well-shielded) signal directly to the filter/DAC-chip.
The clock signal would also be buffered, and transmitted down the
clock line in the multi-conductor cable to the transport. The
transport would then slave itself to this clock signal, feeding the
bits up the cable to the DAC-box under control of the external clock.

This approach pretty much replicates, in a two-box system, the clock
distribution strategy used in a single-box CD player. The DAC chip
itself is fed from the cleanest and most stable clock in the system,
and the transport is slaved to this clock (rather than the other way
around).

I don't know whether anyone has built a transport / DAC-box product
line using this approach.

TAG Maclaren used this much more rational approach, but of course they
went bust.
--

Stewart Pinkerton | Music is Art - Audio is Engineering

"Dave" wrote in message
news:n%mef.112190$y_1.66453@edtnps89

"Dave Platt" wrote in message
...


The trickiest part of this problem involves the clock
signal. S/PDIF does not have a distinct clock signal on
a separate set of conductors. Instead, the clocking is
"embedded" in the data - the S/PDIF receiver must
reconstruct a clock signal based on the transition times
of the data signal. This is usually done by the S/PDIF
receiver chip, using
a phase-locked loop circuit of some sort.

Is there some "raw" format which bypasses the S/PDIF and
it's inherent clocking limitations which could be output
to a redesigned external DAC? Maybe I2S? I mean, if it's
the S/PDIF encoding/decoding which introduces clock error
(and hence "jitter") hasn't anyone said "there's got to
be a better way"? I am thinking not, as everybody seems
to be trying to build a better S/PDIF-based (external)
DAC. But hypothetically, if a transport output both the
datastream AND a clock signal in realtime instead of
packaged in frames requiring decoding at the receiving
end... well, why not?

The industry took a more direct route. They routinely and
inexpensively implement digital gear that accepts the
so-called "flawed" SP/DIF signal and produce exceedingly
clean analog signals.

"Arny Krueger" writes:

snip

I find that there still be be significant differences in
sound quality due to things like ability to track difficult
media. One leading common source of difficult media is
home-burned CDs. The degree to which light mistracking can
be confused with problems in the analog domain may surprise
many.

Hmm, the only CDs I have serious problems with are CDs I have bought.
My home-brewn LP-CD 'products' have never caused me any problems.
I am actually considering clone one of my problems CD to be able to
listen to the last tracks on my stereo.

--
================================================== ======================
Martin Schöön

"Problems worthy of attack
prove their worth by hitting back"
Piet Hein
================================================== ======================

"Dave Platt" wrote in message
...
In article mR8ef.108238$y_1.4778@edtnps89,
Better-design DAC boxes do a better job of creating a stable timing
signal for the DAC-chip to use when converting digital samples to
analog. This may be done by using multiple stages of phase-locked
loop (filtering out the jitter), or by buffering the digital samples
through "deep" first-in, first-out FIFO buffer and using a stable
quartz-crystal oscillator to clock the signals out of the FIFO into
the DAC, or by using an asynchronous sample-rate converter to resample
the data stream before feeding it into a crystal-oscillator-timed DAC.

I am confused as to how all these various clocks interact. For example in
my external DAC I've got a receiver chip (CS8412) which has its' own master
clock pin (MCK), a voltage-controlled oscillator which is part of the PLL.
This clock can be an input or output externally. The only outputs from my
receiver are the serial clock (SCK), word clock (FSYNC) and serial data
(SDATA). These go into an 8x oversampling digital filter (YM3433) which
ALSO has a clock (in fact an external 10MHz crystal oscillator). Outputs
are then DATA-R, DATA-L, word clock out (WCO) and bit clock out (BCO) which
are fed, respectively, to two DACs (AD1860's).

How do the digital receiver and digital filter clocks interact? What's the
relationship between these clocks and the clock in the transport?

I am confused as to how all these various clocks interact. For example in
my external DAC I've got a receiver chip (CS8412) which has its' own master
clock pin (MCK), a voltage-controlled oscillator which is part of the PLL.
This clock can be an input or output externally. The only outputs from my
receiver are the serial clock (SCK), word clock (FSYNC) and serial data
(SDATA). These go into an 8x oversampling digital filter (YM3433) which
ALSO has a clock (in fact an external 10MHz crystal oscillator). Outputs
are then DATA-R, DATA-L, word clock out (WCO) and bit clock out (BCO) which
are fed, respectively, to two DACs (AD1860's).

How do the digital receiver and digital filter clocks interact? What's the
relationship between these clocks and the clock in the transport?

Based on what I see in the YM3433 data sheet, I believe that the
following is the case:

- The clock in the transport is highly stable. Things are good
up to the point at which it feeds the S/PDIF encoder. At this
point, the clock signal loses its independent existence, and is
passed to the downstream DAC-box via the edge timings in the
encoded S/PDIF data signal.

- The CS8412 uses its PLL circuitry to recover the embedded clock
from the incoming S/PDIF signal. It outputs this clock signal
(with whatever jitter was not filtered out by the PLL) to the
YM3433, feeding its SCK clock output to the YM3433's BCI (bit clock
in).

- The YM3433 uses the incoming BCI signal from the CS8412 to clock
in the incoming data.

- The YM33 takes a separate crystal-oscillator clock, which is used
to run the math engine in the digital filter. This clock is
not synchronized to the BCI. It just has to run fast enough to
allow the digital filter multiply/accumulate logic to complete
the calculations needed to generate each output sample quickly
enough... if the MAC core is done sooner than necessary, it's
put into an idle state to kill time until the previous output
sample has been emitted.

- The YM3433 also generates BCO (bit-clock out), WCO (word clock out),
and two deglitcher outputs, which are used to control the DACs...
specifically, the moment at which each DAC chip grabs the new sample
that has been clocked in via BCO, and starts converting it to analog.
These clocks are generated from the crystal-oscillator input, not
from BCI.

So... it looks to me as if short-term jitter from the S/PDIF
will be partially filtered out by the CS8412's PLL, and then
almost entirely eliminated from consideration by the fact that the
YM3433 is generating "new" bit-clock and word-block signals
from its crystal oscillator clock.

However, this approach would not seem to be entirely immune to timing
problems... it doesn't guarantee absolute timing stability. The
YM3433 still has to track the incoming data rate to some extent... it
must adjust its WCO timing to match the long-term rate of the incoming
samples. The WCO timing isn't strictly synchronized to either the BCI
(incoming bit clock) or to the crystal oscillator, but its falling
edge always occurs "during the period between BCO pulses"... which
means that its timing is quantized to some extent rather than being
smoothly variable. This quantization of the WCO timing will,
necessarily, introduce some short-term jitter as WCO tries to track
the recovered transport-clock signal's long-term drift.

Without examining the jitter spectrum of the WCO line, and comparing
it to the spectra of the CS8412's output clock and to the crystal
oscillator, it's not possible to say just how well the YM3433 actually
performs in this regard. I'd guess that it's probably doing better
than a system which used the "raw" CS8412 clock, but not as well as
one which fed the DACs directly from a crystal oscillator and then
slaved the transport to this same oscillator... but that's just a
guess.

--
Dave Platt AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

"Dave Platt" wrote in message
...
I am confused as to how all these various clocks interact. For example
in
my external DAC I've got a receiver chip (CS8412) which has its' own
master
clock pin (MCK), a voltage-controlled oscillator which is part of the
PLL.
This clock can be an input or output externally. The only outputs from
my
receiver are the serial clock (SCK), word clock (FSYNC) and serial data
(SDATA). These go into an 8x oversampling digital filter (YM3433) which
ALSO has a clock (in fact an external 10MHz crystal oscillator). Outputs
are then DATA-R, DATA-L, word clock out (WCO) and bit clock out (BCO)
which
are fed, respectively, to two DACs (AD1860's).

How do the digital receiver and digital filter clocks interact? What's
the
relationship between these clocks and the clock in the transport?

Based on what I see in the YM3433 data sheet, I believe that the
following is the case:

- The clock in the transport is highly stable. Things are good
up to the point at which it feeds the S/PDIF encoder. At this
point, the clock signal loses its independent existence, and is
passed to the downstream DAC-box via the edge timings in the
encoded S/PDIF data signal.

- The CS8412 uses its PLL circuitry to recover the embedded clock
from the incoming S/PDIF signal. It outputs this clock signal
(with whatever jitter was not filtered out by the PLL) to the
YM3433, feeding its SCK clock output to the YM3433's BCI (bit clock
in).

- The YM3433 uses the incoming BCI signal from the CS8412 to clock
in the incoming data.

- The YM33 takes a separate crystal-oscillator clock, which is used
to run the math engine in the digital filter. This clock is
not synchronized to the BCI. It just has to run fast enough to
allow the digital filter multiply/accumulate logic to complete
the calculations needed to generate each output sample quickly
enough... if the MAC core is done sooner than necessary, it's
put into an idle state to kill time until the previous output
sample has been emitted.

- The YM3433 also generates BCO (bit-clock out), WCO (word clock out),
and two deglitcher outputs, which are used to control the DACs...
specifically, the moment at which each DAC chip grabs the new sample
that has been clocked in via BCO, and starts converting it to analog.
These clocks are generated from the crystal-oscillator input, not
from BCI.

So the YM3433's crystal oscillator times the digital filter and (indirectly)
the DACs. The raw clock in the CS8412 is not used for anything.

So... it looks to me as if short-term jitter from the S/PDIF
will be partially filtered out by the CS8412's PLL, and then
almost entirely eliminated from consideration by the fact that the
YM3433 is generating "new" bit-clock and word-block signals
from its crystal oscillator clock.

However, this approach would not seem to be entirely immune to timing
problems... it doesn't guarantee absolute timing stability. The
YM3433 still has to track the incoming data rate to some extent... it
must adjust its WCO timing to match the long-term rate of the incoming
samples. The WCO timing isn't strictly synchronized to either the BCI
(incoming bit clock) or to the crystal oscillator, but its falling
edge always occurs "during the period between BCO pulses"... which
means that its timing is quantized to some extent rather than being
smoothly variable. This quantization of the WCO timing will,
necessarily, introduce some short-term jitter as WCO tries to track
the recovered transport-clock signal's long-term drift.


If there is a highly stable clock in the transport, and that clock is used
to S/PDIF-encode the signal, how/why would the incoming digital signal to
the CS8412 (and, since the timing is unaffected by this device, the YM3433)
vary in frequency, i.e. drift? Also, if the YM3433's oscillator were fast
enough to perform the logic in realtime with cycles left over, why couldn't
WCO rate be adjusted in the same "real" timeframe as opposed to the
"long-term rate of incoming samples" you mention, above? Or would this just
be passing along the jitter to the DACs?

Without examining the jitter spectrum of the WCO line, and comparing
it to the spectra of the CS8412's output clock and to the crystal
oscillator, it's not possible to say just how well the YM3433 actually
performs in this regard. I'd guess that it's probably doing better
than a system which used the "raw" CS8412 clock, but not as well as
one which fed the DACs directly from a crystal oscillator and then
slaved the transport to this same oscillator... but that's just a
guess.

--

Interestingly, I note that by varying the select pins on the CS8412, this
device will accept input in I2S format, no doubt for use within cd players
where no S/PDIF encoding/decoding is required. Again, I ask myself "who
came up with this S/PDIF format" when I2S is a) built in to every cd
transport/player and b) inherently more accurate/stable. I would gladly pay
for the extra conductors required to carry the transport clock signal. Ah,
but it is a tad more time-consuming to get that DIN connector oriented
properly, especially in a dark room...

Dave Platt AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

In article FJOef.113673$S4.19842@edtnps84,
Dave wrote:

So the YM3433's crystal oscillator times the digital filter and (indirectly)
the DACs. The raw clock in the CS8412 is not used for anything.

That's how I see the situation.

If there is a highly stable clock in the transport, and that clock is used
to S/PDIF-encode the signal, how/why would the incoming digital signal to
the CS8412 (and, since the timing is unaffected by this device, the YM3433)
vary in frequency, i.e. drift?

No crystal oscillator is perfect, and S/PDIF is definitely not perfect.

The transport's oscillator will suffer from some amount of absolute
error, and some amount of thermally-induced drift. Typical
off-the-shelf canned oscillators seem to be specified to have
accuracies and stabilities on the order of 50 - 100 parts per million.
Warm up the can a few degrees, and it'll drift. There's essentially
no chance at all that the transport and DAC xoscillators will have the
same absolute error and precisely the same amount of drift. You're
always going to be left with a synchronization problem of some sort,
in any multi-oscillator system.

If the oscillator drifts as much as 10 parts per million during use,
then that's equivalent to 1 sample per 100,000 change in timing. The
DAC must be able to compensate for this in some way, or it'll
occasionally get ahead of or behind the transport by 1 sample. Trust
me, in many signals, a single duplicated or discarded sample is
audible (it makes a slight but detectable "tick" in the music).

The DAC using a 1:1 converter, or an N:1 oversampling digital filter,
has to adjust its conversion rate in real time in order to keep this
from happening. DAC systems using asynchronous sample rate converters
deal with the problem on a more gradual and continuous basis.

Also, if the YM3433's oscillator were fast
enough to perform the logic in realtime with cycles left over, why couldn't
WCO rate be adjusted in the same "real" timeframe as opposed to the
"long-term rate of incoming samples" you mention, above? Or would this just
be passing along the jitter to the DACs?

Bingo. Yes, it would be passing along the jitter.

Interestingly, I note that by varying the select pins on the CS8412, this
device will accept input in I2S format, no doubt for use within cd players
where no S/PDIF encoding/decoding is required. Again, I ask myself "who
came up with this S/PDIF format" when I2S is a) built in to every cd
transport/player and b) inherently more accurate/stable. I would gladly pay
for the extra conductors required to carry the transport clock signal. Ah,
but it is a tad more time-consuming to get that DIN connector oriented
properly, especially in a dark room...

My recollection is that I2S came along somewhat later than S/PDIF -
first-generation chip sets used a variety of proprietary,
nonstandardized clock-and-data busses.

S/PDIF has the advantage of simplicity, and compatibility with the
wide range of 75-ohm coax cables and connectors available. It can
also be used over a single optical fiber using inexpensive LED drivers
and phototransistor receivers.

As is often the case, cheap-and-convenient won out over technically-
better in the mass market.

--
Dave Platt AE6EO
Hosting the Jade Warrior home page: http://www.radagast.org/jade-warrior
I do _not_ wish to receive unsolicited commercial email, and I will
boycott any company which has the gall to send me such ads!

""Schöön" Martin" wrote in
message
"Arny Krueger" writes:

snip

I find that there still be be significant differences in
sound quality due to things like ability to track
difficult media. One leading common source of difficult
media is home-burned CDs. The degree to which light
mistracking can be confused with problems in the analog
domain may surprise many.

Hmm, the only CDs I have serious problems with are CDs I
have bought.

Burn enough CDs on enough different types of media and play
them in enough different players and sooner or later... ;-)

My home-brewn LP-CD 'products' have never
caused me any problems.

The so-called law of averages comes into play. I was trying
to figure out how many CDs I've burned over the years, and
its up past 1,000 probably past 2,000 and maybe even 5,000.
50-and 100 disc spindles and packs have been known to
"disappear" in numbers within a day or two.

I am actually considering clone one of my problems CD to
be able to listen to the last tracks on my stereo.

This can work - I've played this *trick* a number of times
with good success. The key to sucess here is that the better
ripping packages (CDEX, EAC) can read and reread a disc
until they find consistent results. CD players as a rule do
everything on the fly - once and only once.

"Arny Krueger" writes:

""Schöön" Martin" wrote in

I am actually considering clone one of my problems CD to
be able to listen to the last tracks on my stereo.

This can work - I've played this *trick* a number of times
with good success. The key to sucess here is that the better
ripping packages (CDEX, EAC) can read and reread a disc
until they find consistent results. CD players as a rule do
everything on the fly - once and only once.

Well, I think my CD-player is part of the problem because these
CDs play without any problems in my computer and other CD-players.

--
================================================== ======================
Martin Schöön

"Problems worthy of attack
prove their worth by hitting back"
Piet Hein
================================================== ======================