Are DVD players any good as cd transports?

jag1967 · Jan 22, 2004

Hi All

I'm interested in finding out whether relatively inexpensive dvds, especially universal players (such as the pioneer 565 or 656), can operate effectively as cd transports when the digital output is used?

Is it worth using dvd players in this way, compared with the transports on a dedicated cd player? And are there any specific makes which are known for their quality of dvd transports, eg. denon, H/K?

any views much appreciated

Rob Babcock · Jan 24, 2004

The Denon DVD-2200 is an excellent transport, and lot's of guys that have used the '2900 that way have raved it up.

Yamahaluver · Jan 25, 2004

The Pioneers are very well built and long lasting players and so is the Yamaha DVD-S540, they can play difficult discs and make excellent transport and are priced really nice.

Audioholic · Jan 25, 2004

I believe that all the players mentioned above will play great for there money, but if you plane on listening to cd’s and not dvd’s its better that you get a good cd player or a cd transport that will have a really better digital signal than a dvd player..

av_phile · Jan 27, 2004

I have some CDs that won't play or skips badly on my Yamaha CDX1000 CD-only player but will play flawlessly on an ordinary generic DVD player. I have read that the DVD player's optical reader has a finer laser beam than do CD players. Does this account for my experience? Are DVD player's better at extracting the digital bits than CD players?

Chuck · Jan 29, 2004

Audioholic : Why would "a good cd player or a cd transport" have "a really better digital signal than a dvd player?"  It's easy to show that the digital data read from a CD using a CD player will be identical to the digital data read from a CD using a DVD player (assuming competent design in both players and media that is not damaged or defective).  In what way is the identical data "better" when ready by the CD player?

Why would "a good cd player or a cd transport" have "a really better digital signal than a dvd player?"  
It's easy to show that the digital data read from a CD using a CD player will be identical to the digital data read from a CD using a DVD player (assuming competent design in both players and media that is not damaged or defective).  In what way is the identical data "better" when ready by the CD player?

pam · Jan 29, 2004

Reading a CD or a DVD is simply read numeric data. The price has no bearing on the data read.

The only important part is the DAC. This is the reason why some of the high end audio CD player were having a separate box for the DAC part (upgradable for mucho dineros por favor).

Considering that all of this is electronic, we can apply the Moore rule: every 18 month you get double for the same price. What could you get for 500$ in June 2002? Now you can get better for 250$

BTW, the term transport does not seem to apply to the DAC part. I always thought that transport was the part moving and reading the CD/DVD signal (which is very cheap). Can any one explain?

Chuck · Jan 30, 2004

pam : BTW, the term transport does not seem to apply to the DAC part. I always thought that transport was the part moving and reading the CD/DVD signal (which is very cheap). Can any one explain?

Pam, you're right. What gave you the impression that it might be otherwise?

Dan Banquer · Jan 30, 2004

One would generally think that this would be true.
In the past I have had the chance to look at some of the SPDIF 75 ohm drive outputs of CD players and some of the DVD units. I have not exactly been impressed as to how well the the drive will comply with a 75 ohm impedance over the bandwidth required. Or to put it another way; this is not the place I would use a pulse transformer. The real shame of this is that good high speed video op amps are not exactly rare or expensive, and I don't understand why they are not used.
If GDS has schematics of some of the contemporary units I would be interested in his comments.
d.b.

pam · Jan 31, 2004

Sometimes people talk about transport but the text refers to the whole thing (all the electronics surrounding it).

Chuck · Jan 31, 2004

pam : Sometimes people talk about transport but the text refers to the whole thing (all the electronics surrounding it).

Hi Pam,

I guess most of us get a little sloppy sometimes, but it usually doesn't cause any confusion, as the context usually makes the meaning clear. Not always though. I'm not at all sure where "transport scrambling flag" gets its name. Given your depth of knowledge you might be able to enlighten me.

I've found it more difficult to discuss the DAC than the transport. If I use the term "transport" most people will know exactly what part of the CD/DVD/Tape-recorder I'm talking about. IF I use the term "DAC" I haven't actually communicated clearly (in many cases). Am I talking about a chip called a DAC, or am I talking about the DAC on the chip that we call a DAC. The DAC-chip and the DAC-proper are quite different things, but we call them both DAC's. Sometimes the difference matters; Sometimes it doesn't.

If we want to get technical I think we can all agree that...

1) A transport provides transportation. Movement is involved.

2) A DAC-proper is a device that converts numeric data into analog data. The thing we usually call a "DAC" is actually an integrated circuit that contains both a DAC-proper and other circuits.

3) A CD, DVD, or even tape, "player" includes both a transport and playback electronics. CD, DVD, and digital tape players always contain a mix of analog and digital playback electronics. Analog tape recorders (normally) have only analog playback electronics.

I'm not sure who Dan was responding to (above), but I sometimes use a 25' coax with F connectors (a 75-ohm cable intended to be used to connect a TV antenna) and F-to-RCA adapters. Using this cable to feed the SPDIF input on my sound card I've captured the digital data from both my CD and DVD player (digital music data from CD's) and then recorded this data to CD-R. To check the accuracy of the recordings made this way I've done bit-for-bit comparisons of the audio data on the copy and original CD, and there are absolutely no differences. I get the same results with the DVD player that I get with the CD player (even with the long cable). Dan, I take it from what you said that you may have had some problems (???) with SPDIF, but I can't see that a few shoddy designs is any indication that CD players are inherently going to produce "better" digital data than a DVD player. Certainly if I can drive 25-feet of antenna wire with every player I've tried, nobody is going to have any trouble (with any of those particular players at least) using more typical SPDIF cables. I don't think anyone would put their DAC 25-feet away from their transport.

Just for the halibut I also tried using a few feet of 300-ohm coax with impedance matching transformers at the ends. The flat 300-ohm twin-lead would offer the advantage of being flat, so I could run it over to the PC under the carpet, but I couldn't make the link work. Works fine with a TV antenna but doesn't work at all with SPDIF. My guess (and it is only a guess) is that the problem comes from the transformers rather than the twin-lead. I've actually used a short audio cable for SPDIF without problems, but the 300-ohm twin-lead and transformer setup just doesn't seem to work.

See ya,

Chuck

Dan Banquer · Jan 31, 2004

It's not the bit for bit transfer that's the problem. It's looking at these output drivers and coming rapidly to the conclusion that the VSWR/Return Loss is not what it should be because the output impedance of the drivers just doesn't look like a flat 75 ohms to me. Assume for a minute that there is a VSWR issue, That will effect frequency response, and most importantly timing. Those rise and fall times on the SPDIF output need to accurate, otherwise we will have timing jitter. Sure the DIR has a filter for this but you have to remember that the filter has it's bandwidth and roll off slope. In short the filter is really an attenutor, leaving higher values of timing jitter, due to higher values of timing jitter on the SPDIF line.
The general idea here is to keep the timing jitter low to preserve the dynamic range. It's not exactly hard to do if you recognize the problem.
Your 300 ohm cable shows us the VSWR is now so bad that bit for bit transfer is now compromised.
A good test for this would be to use a test CD that will give you signals to measure dynamic range, (-60db down from full scale), measure THD + N, lowest THD + N indicates greater dynamic range and typically less jitter.
Hope this explanation helps, I'm just an old RF guy at heart.

Chuck · Feb 1, 2004

Dan Banquer : It's not the bit for bit transfer that's the problem. It's looking at these output drivers and coming rapidly to the conclusion that the VSWR/Return Loss is not what it should be because the output impedance of the drivers just doesn't look like a flat 75 ohms to me. Assume for a minute that there is a VSWR issue, That will effect frequency response, and most importantly timing. Those rise and fall times on the SPDIF output need to accurate, otherwise we will have timing jitter. Sure the DIR has a filter for this but you have to remember that the filter has it's bandwidth and roll off slope. In short the filter is really an attenutor, leaving higher values of timing jitter, due to higher values of timing jitter on the SPDIF line.
The general idea here is to keep the timing jitter low to preserve the dynamic range. It's not exactly hard to do if you recognize the problem.
Your 300 ohm cable shows us the VSWR is now so bad that bit for bit transfer is now compromised.
A good test for this would be to use a test CD that will give you signals to measure dynamic range, (-60db down from full scale), measure THD + N, lowest THD + N indicates greater dynamic range and typically less jitter.
Hope this explanation helps, I'm just an old RF guy at heart.

Hi Dan,

Let's look at a block diagram from Burr-Brown:

Obviously this particular DAC has a serial data input, and as far as I know this is pretty standard. We have a serial data stream that is being converted into two 16-bit parallel data streams. We have to do this conversion before we can do the over sampling (we have to reconstruct the samples before we can over sample). The only jitter that can affect the output of the DAC proper is jitter in the clock that is triggering the DAC. This clock will be crystal controlled and use a PLL, so while it is derived from the serial data stream I don't see how its jitter level is going to be affected by jitter in the serial data stream. If it is, it seems that we would have a major problem with all optical players, because the bit rate of the serial stream coming from the laser pickup has a ton of jitter. The rotational speed of the optical disk varies constantly, as the servomechanism hunts. Every time we play a CD or DVD the jitter patters of the detector output are quite different, and they're not likely to be low in jitter under any circumstances. Are they?

Here's a timing diagram that goes along with the block diagram above:

As you can see, the timing diagram shows the three lines going into the serial interface. Each bit is actually clocked into the serial interface on the rising edge of BCLK. BCLK is derived from the system master clock, which is crystal based and should have very low jitter. If the jitter in the data stream exceeds the allowable jitter a bit error results, but the incorrect value will still be clocked in at exactly the same time it would have been clocked if the data line had been jitter free. I understand what you're saying about the cable creating jitter, and in fact I suspect that it is the transformers used with the 300-ohm twin lead that rounds off the square waves so badly that we get a massive error rate.

What I don't understand is how jitter in the data itself is going to cause jitter in BCLK. True, the switching of every circuit in the DAC is a potential source of jitter in every clock in the DAC, but a good crystal clock and PLL aren't exactly budget busting components. I may be missing something, but I just don't see how jitter in the data stream could cause BCLK jitter or change the "bit arrival time" in any way. Because I was once called a fool for asking this very question I actually talked to the application engineers at TI/Burr-Brown, and the question ("Is there any way for jitter in the serial data stream to make its way to the DAC output?&quot

apparently had them scratching their heads a little. Before responding they had a meeting (I'd asked for an interview for a possible magazine article), and the app eng I talked to was given the task of presenting the majority opinion. Although they took a clear position on the matter, I really got the impression that they weren't quite sure. I pushed hard for a firm yes or no answer, and eventually got a negative response, so at the time that was their official position (jitter in the serial data can't sneak through to the DAC proper), but they really didn't seem to feel like they were on solid ground. That's just an impression I got, after talking to the guy on the phone for just over an hour (I still have the tape of the interview). Perhaps there is some way for jitter to get through from the serial data stream to the DAC proper, but it isn't obvious to me. What am I missing?

While it has no bearing on the CD vs DVD player question, I have actually run tests using optical cable to loop the output of my soundcard back to the input, and I've run S/N and distortion measurements using the loop-back. The optical cable I used certainly didn't degrade the S/N or increase noise in any way, but your suggestion to make similar measurements with my antenna wire is a good one. If the cable does anything to increase the jitter at the clock input of the DAC proper we should see a decrease in S/N and THD+N, both of which I can measure with SpectraPlus. It's actually moot given the way I use the cable. Once the audio data is converted to a .wav file and stored on a block device (hard drive) there is no jitter.

As long as the copy can also be read accurately by the player that is ultimately used any subtle differences in pit/land timing won't matter because they'll be swamped by the hunting of the drive servo, and it will all go away when the data is re-clocked by BCLK at the serial input buffer. Right?

If I'm coming across the way I said the guy at TI/Burr-Brown came across it is probably for the same reason. I can't see any way for the data stream to jitter BCLK or the system master clock, and it looks like the first affect of serial data jitter that we will ever see is bit errors, which won't be seen until the error correction schemes fall down. Then it will obvious due to either silence of nasty noise. How can jitter in the serial data stream get past the rising edge of BCLK and all the way through the buffer in the serial to parallel converter, its output clock, the over sampling buffers and their internal and output clocks, and so on? What is the path that the jitter takes?

I'm not saying that it ain't so, Dan, just that I don't understand it.

Thanks,

Chuck

Dan Banquer · Feb 1, 2004

Chuck: Try taking a look at the Crystal Data books. There are application notes and AES papers on this very subject. They'll explain it better than I will. Also try the Bob Katz web site at www.digido.com. Also try the THD+N test at - 60 db down at full scale. If your not getting -36db THD+N for 16 bits coming out of the anaolg LP filter, then in all probability you've got a timing jitter problem. If your running 20 bits or greater than you should see -44db THD+N or better. Best I can do for a sunday morning.
d.b.
P.S. The key thing to remember here is that jitter is really only a problem at the point of conversion.

Dan Banquer · Feb 1, 2004

Well I've had another cup of coffee which has jogged my memory. Put the scope on the word clock input to the DAC. Look very carefully on the rising edge of the word clock at 5 nS per div. Look for timing jitter here, the less you see the better. Most DAC's are triggered on the rising edge. Also check the word clock input, or sometimes known as frame, at the Digital filter input.
Crystal Semi did a number of studies on timing jitter and phase locked loops in the 90's. The VCXO's in the DIR chips can be a real problem if not carefully filtered and supplied.
Hope this helps.
d.b.

Chuck · Feb 1, 2004

Dan Banquer : Chuck: Try taking a look at the Crystal Data books. There are application notes and AES papers on this very subject. They'll explain it better than I will. Also try the Bob Katz web site at www.digido.com. Also try the THD+N test at - 60 db down at full scale. If your not getting -36db THD+N for 16 bits coming out of the anaolg LP filter, then in all probability you've got a timing jitter problem. If your running 20 bits or greater than you should see -44db THD+N or better. Best I can do for a sunday morning.
d.b.
P.S. The key thing to remember here is that jitter is really only a problem at the point of conversion.

Hi Dan,

TI/BB also has loads of information on jitter, and the volume of material available is an indication of how confusing it can be at times. My Crystal Data book is as old as the hills and has nothing on the topic. Can you point me to a specific page or group of articles on Bob Katz's site? There seems to be a lot of unrelated material there and I'd rather not have to search for the stuff (especially since I don't really know what you want me to read). It seems to me that we are actually in total agreement. You said:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Quote </td></tr><tr><td id="QUOTE">The key thing to remember here is that jitter is really only a problem at the point of conversion.</td></tr></table>

That's really the same thing I said, without all the extra drivel.

Here are the measurements I did this morning. The first is the soundcard loop-back, the second is a loop out the SPDIF out, through the 25-foot antenna lead, and back to the SPDIF in. Both plots were made using the THD+N method described in the SpectraPlus application notes.

THD+N - Soundcard Loop

THD+N - SPDIF/25-Foot-Antenna-Wire Loop

I don't think this has any direct relevance to your observation that some CD and DVD players use crummy drivers for the SPDIF interface, but it does seem to show that the cable I'm using isn't doing anything to clobber the signal. To me this seems to indicate that if the additional jitter in the serial data stream caused by the cable causes jitter in the analog output, it must be due to a flawed design or corner/cost-cutting. The small difference in the THD+N and the FFT may be to differences in the jitter due to secondary effects, but it is equally likely to be simply a matter of the point in time at which I captured the image of the running measurement. Those last few decimal places jump around a lot, and don't mean much. Note that the difference in THD+N is only 0.00012%, and while I can only speak for myself, I'm sure I can't hear that level of difference.

I have no doubt that you are correct when you say that some of the audio equipment exhibits poor design decisions or tradeoffs. I think you and I are in agreement, but I'm not absolutely sure. If the clock at the point of conversion has sufficiently low jitter, we don't have a problem. Since we've both made that assertion we obviously agree on that point. Where I'm unsure is on the issue of jitter in the serial data stream. It does have the potential to affect the converter, all the way to the conversion clock, but with good design that won't happen. Crystal is not the only company to have looked into the matter in depth. BB/TI has done likewise, and they provide plenty of information to allow almost anyone to design a successful digital audio system that works very well within the design limits of the format. It's not that expensive to do it all well and properly, so as with the SPDIF output drivers, there is really no good excuse for cutting corners.

Dan, please note that I am not recommending using 25-feet of antenna wire between a CD or DVD transport and the DAC. A consumer audio product is not usually over-engineered. That's a nice way of saying that most cut corners. It is no doubt assumed that most consumers will be using digital interconnects of 6-foot or less, and that they'll be using standard optical or coaxial SPDIF cables. It is probably also assumed that the receiver and serial input circuitry on the receiving end will meet spec, so a few pennies can be saved on every unit by using cheaper SPDIF output drivers. It's not a corner I'd cut in any design but when the market is driven by price and features I don't think the designers have much choice. A penny saved times several million sales isn't chump-change. I simply would not try to drive a long digital cable with a CD or DVD player without being sure that the device had decent drivers and was up to the task at hand. For copying CD's, the cable works well enough, as the wave files are bit-for-bit accurate, and so is the resulting CD (when it's not, I discard it and try again). In using the same cable between a CD or DVD player and an external DAC I'd have some additional concerns, unless I had confidence that the DAC was designed well enough to do the job properly. I'll try to find a little more time to devote to this, because it might be interesting to see how that 1kHz. THD+N test comes out when the data is burned to a CD and played back from the CD and DVD players. Since the cable isn't causing problems in the SPDIF loop-back test, if it does cause problems with either player, then there has to be some problem with the output section of the player(s). Right?

Speaking of doing more tests and posting results, I have a small problem. We're about to have broadband installed, and sometime next week we'll be switching to a new ISP. As a result, all the measurements and stuff I've posted to go with my posts will soon be lost. Is there any way for Audioholics to set up an area where images that go with posts can be uploaded?

Thanks,

Chuck

Dan Banquer · Feb 1, 2004

Chuck;
  Try the same test at -60 db down from full scale, not -10 db down.
             d.b.

Chuck · Feb 1, 2004

Dan, since I had the cable out I decided to do some stress testing. I got a couple of jumpers and a short length of cheap audio cable (3-feet) with an RCA connector on one end. Then I made this inelegant SPDIF cable...

The chrome RCA jack you see is actually the F-to-RCA adapter on one end of my antenna wire. You can see the two jumpers connecting the RCA plug to the two bare wires at the one end of the audio cable. The other end of the audio cable, the one with the RCA plug that you can't see, goes to the soundcard to complete the SPDIF loop. When I cobbled this up I had no idea of what I might see, but I figured that I might be able to move the thing around and bugger the connections in different ways, to see how much of a disturbance I could create in the THD+N measurements. It may be worth mentioning that in these measurements we are seeing the results we get IF there is a low jitter clock at the point of conversion. If the design allows that clock to become contaminated we will see a difference in THD+N, as you have noted. Here's a plot from TI/BB that addresses this very matter.

Well, here's the THD+N with my jumper-wire/antenna-wire/audio-coax SPDIF contraption.

I think all this really tells us is that I'm using a low jitter clock at the point of conversion, but it also seems to show that even very nasty SPDIF cables don't necessarily increase the jitter at the point of conversion. After seeing that I was getting exactly the same values for the crazy jumpered cable mess as I got with a direct internal loop-back, I thought perhaps my test setup wasn't measuring what I thought it was, but disconnecting either alligator-clip disrupts the signal, so it's definitely passing through the loop.

I can't make the SPDIF THD+N or S/N measurements change AT ALL, until the connection breaks down completely. It's either very respectable (to spec) THD+N and S/N or it's no signal at all. I'm not using the most expensive gear in the world to do this, so if it's a problem in a CD or DVD player it's simply got to be the result of a poor design decision. Obviously the SPDIF interface I'm using is robust enough for most applications using more normal length cables of more conventional configuration. Don't ya think?

If I let a little jitter creep into the conversion clock we'll certainly see it in the noise measurements, so I think you and I are actually in total agreement. I have no doubt that if we take a scope and look at the conversion clock, we'll see the jitter change as operating conditions change, but I think the measurements here show clearly that as long as the conversion clock is clean there isn't a problem (and also that the conversion clock can be clean if the hardware is sufficiently well designed).

I think we've gotten somewhat adrift of the original question, which involved differences between CD and DVD players, when playing CD's. There was a response that stated that the digital data from a CD player was "better," and of course in some cases it might be, but that's not a given. If both the CD and DVD player are designed by guys who can follow the advice of companies like TI/BB or Crystal they are both going to perform identically. One of the trends in the chip industry has been to move more and more of the support circuitry on to the DAC chip, both for the economies of scale, and because it makes it easier for designers. "Making it easier for designers" is a nice way of saying that they are trying to protect us from ourselves. It won't be long before the DAC chips contain all the circuits needed to insure a clean conversion clock (as well as keeping all the other derivatives of the system clock pristine). TI/BB appears to be aware that some designers have had problems keeping the final clock signal clean, because they've discussed the associated problems extensively. There is no more excuse for excessive jitter in the conversion clock than there is an excuse for not using decent drivers for the SPDIF outputs. I'm inclined to believe that we see both problems in some audio equipment, even though I haven't seen it myself. Obviously the output drivers you mentioned are a sign that corners are being cut to save pennies.

As an RF Engineer, do you have any idea of what the total VSWR might be in my crazy SPDIF jumper-wire mess?

See ya,

Chuck

Chuck · Feb 1, 2004

Dan Banquer : Chuck;
Try the same test at -60 db down from full scale, not -10 db down.
d.b.

I did measure at -50dB; My level control gets too touchy to hit -60, but...  at 50 dB down rather than 10 dB down, the signal to noise ratio is reduced 40 dB, and the THD+N increases accordingly.

I swear it almost looks like I'm testing the same internal loop in both every case, so I keep having to disconnect my antenna wire cable to make sure that it's actually in the loop.  I've tried, and I can't even force the SPDIF cable misbehave.  If it's transferring a signal without so many errors that there is no link, then the measurements are identical.  (Naturally they're different when there is no signal due to errors or a broken connection.

)

Dan, please keep in mind that I'm not representing these results as something we might expect with any given CD or DVD player.  All I'm saying (and trying to show) is that if the system is well designed, jitter at the serial input doesn't have enough of an effect on the conversion clock to worry about.  You agree that jitter only matters at the conversion point, and all I'm doing is using a converter with a clock that is clean at the conversion point.  It's well (or should I say "properly?&quot

isolated from disturbances elsewhere in the system.  If it weren't, we'd see changes in the THD+N with that nasty SPDIF mess I used in the last test.  Seriously Dan, I really expected to see *something* in that last crazy test, but nada.

I have no doubt that you've seen what you've seen, so some equipment must have more problems than other equipment.  Actually, that's not much of a surprise.  Haven't I shown pretty clearly that a crummy SPDIF cable doesn't necessarily cause an increase in THD+N due to increased jitter at the conversion point?  Take note of my use of the word "necessarily."  That leaves leeway for lots of things like design errors and corner cutting.

I really don't have any idea of what I might be looking for here.  If the clock is jittered excessively at the point of conversion we'll see it in the measurements, but I know going in that I'm using a clock that won't be affected by such things.  It makes me feel like I'm playing with loaded dice.  The only way I can lower my S/N with jitter would be to go in and inject something at the point of conversion.  The DAC I'm using is well designed, and the clock has very low jitter at the conversion point.  It's also sufficiently well isolated from the other clocks and signals, and frankly I don't see how a clock can be said to be clean if it's not well and thoroughly isolated from common external disturbances.  The whole thing here is just what you said a while back.  As long as I keep the clock at the conversion point clean we're not going to see anything in these measurements.  We both know that, but it seems that you expect some combination to eventually corrupt my converter.  That would be a monumental surprise to me, but it wouldn't be the first.  

Think of it this way Dan.  I'm cheating, because you ain't a-gonna jitter my conversion clock, no way, no how.  The jitter will always be low enough to give the noise floor you see in the measurements, as long as the thing sees a usable or recoverable data stream.  Since we agree that as long as I keep the clock clean at the conversion point, and since I have every intention of keeping it clean at the conversion point, we are really just spinning our wheels.  There is no reason for a good audio component to have more problems with digital audio than a modestly priced sound card has, and that's all I'm saying.  If I can do it in my PC for a few bucks, using common chips found in home audio gear, it should be at least as easy to do it in a stand-alone digital audio player.  The PC environment is a not nastier than the typical audio environment.

Did you know that TI/BB has actually targeted some of their cutting edge audio products at the computer industry rather than the audio industry?  They are more interested in getting a quick return on their investment than they are in advancing the state of the audio art.  It isn't the engineers that feel that way, but simply a result of the corporate business model, and the state of the market.

This all makes me wonder if a really cheap soundcard, if carefully selected, might not actually outperform some of the DACs in some of the more expensive receivers.  You guys see a LOT more consumer equipment than I'll ever see.  Is it really all that bad?  I thought I had a jaded view of the audio industry, but I've managed to keep myself believing that there are still a few competent designs and designers out there.  Read the app notes and design a converter.  If you can follow instructions and don't cut corners you can do what I'm doing at low cost.  For free if you register and can qualify for evaluation samples from TI.  I suspect that the latest data from Crystal is equally complete, so how come we have all these problems cropping up in audio gear?  It's mind blowing, Dan, because half the time it's the result imagined problems, and the other half it's the result of bad design decisions, and I just don't get it.  (Sorry for that rant, but I really DON'T get it.)

I wonder if there would be any merit in stress testing the DACs in receivers.  The DAC should do what my DAC does, simply ignore jitter in the serial input data stream, and that should be pretty easy to test.  Just use a crummy cable with a high VSWR and clobber the waveform just short of causing unrecoverable bit errors, then compare the THD+N figures with what you measured with a high quality (and short) optical or coaxial digital cable.  Any difference would (or might) indicate that the DAC is unnecessarily.  I for own would like to know how common such "problems" actually are.

See ya,

Chuck

Dan Banquer · Feb 1, 2004

If you can't be bothered to follow a simple test that has been outlined by both Burr-Brown and Analog Devices and supported by such distinguished engineers such as lord helmet Pierce as a definitive test; then I see no reason to continue this thread.
d.b.

Are DVD players any good as cd transports?

jag1967

Audiophyte

Rob Babcock

Moderator

Yamahaluver

Audioholic General

Audioholic

Enthusiast

av_phile

Senior Audioholic

Chuck

Enthusiast

pam

Audioholic

Chuck

Enthusiast

Dan Banquer

Full Audioholic

pam

Audioholic

Chuck

Enthusiast

Dan Banquer

Full Audioholic

Chuck

Enthusiast

Dan Banquer

Full Audioholic

Dan Banquer

Full Audioholic

Chuck

Enthusiast

Dan Banquer

Full Audioholic

Chuck

Enthusiast

Chuck

Enthusiast

Dan Banquer

Full Audioholic

Latest posts

Sitemap

Sitemap

Site Information

Site Information

HTML