home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / rec / audio / 17709 < prev    next >
Encoding:
Internet Message Format  |  1993-01-03  |  2.9 KB
  1. Path: sparky!uunet!usc!rpi!bu.edu!news.bbn.com!NewsWatcher!user
  2. From: shetline@bbn.com (Kerry Shetline)
  3. Newsgroups: rec.audio
  4. Subject: Re: CD/LD jitter: I certainly do get it! (Was: Kerry doesn't get it...)
  5. Message-ID: <shetline-030193204048@128.89.19.85>
  6. Date: 4 Jan 93 02:28:28 GMT
  7. References: <shetline-311292220109@128.89.19.85> <shetline-311292221445@128.89.19.85> <1993Jan3.220805.9323@smab.se>
  8. Followup-To: rec.audio
  9. Organization: BBN
  10. Lines: 49
  11. NNTP-Posting-Host: bbn.com
  12.  
  13. In article <1993Jan3.220805.9323@smab.se>, hans@smab.se (Hans C Larsson)
  14. wrote:
  15. > 
  16. > The problem arises when an unstable pulse train is *RECEIVED* by
  17. > a D/A-converter *FROM* a digital transport.
  18. > (I.e. between *TWO* boxes.)
  19.  
  20. I will take it that by 'between *TWO* boxes' you mean between the Theta
  21. transport and an outboard DAC, or equivalently, those functional units of
  22. any CD signal processing chain. Accordingly, I will use 'transport' to mean
  23. the combination of mechanical elements, laser pickup, and support circuitry
  24. that spin a disc and spit out a sequence of digital words representing the
  25. digital signal, and DAC to mean that which takes the digital signal and
  26. converts it to analog form.
  27.  
  28. > The receiver has to Phase Lock on a square wave which might not
  29. > be very "square".
  30.  
  31. The 'receiver', which by your previous usage I will take to mean the DAC,
  32. will get a consistently clocked signal from the transport. The transport,
  33. with its own small buffer and feedback to the servo motor that spins the
  34. disc, will have no trouble providing this regular signal. It in fact must,
  35. if for no better reason than as a side effect of the necessary data
  36. shuffling, error-detection and correction, and sub-code sifting that must
  37. precede output to the DAC.
  38.  
  39. > From this you will get time-shift on the samples on the *RECEIVING*
  40. > end since (virtually) all D/A-converters lacks any significant
  41. > amount of buffer memory *COMBINED* with re-clocking of the signal.
  42. > (The only exception that I know of is the (horrendously expensive)
  43. > Technics SH-X1000 D/A converter).
  44.  
  45. I don't see any time shift creeping anywhere, certainly not related to the
  46. mechanical characteristics of the transport when it is operating well
  47. enough not to skip or otherwise catastrophically fail. The DAC should need
  48. no buffer at all, since it is the responsibility of the transport to
  49. provide regular data, and only the transport that has the necessary
  50. connections to the disc servo motor to mechanically re-clock its output.
  51. The transport must be successful at this task, or it will fail outright by
  52. skipping or mistracking, not by allowing mechanical jitter to enter into
  53. the timing of the data stream.
  54.  
  55. I would be interested in finding literature on this Technics DAC, which, if
  56. it isn't just high-end BS, must be more than just a DAC. I can think of no
  57. good reason for large buffers in a DAC except perhaps for digital signal
  58. processing or skip protection. (The latter wouldn't function without some
  59. sort of control signal from the DAC back to the transport.)
  60.  
  61. -Kerry
  62.