Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site tekcad.UUCP
Path: utzoo!linus!decvax!tektronix!tekcad!shauns
From: shauns@tekcad.UUCP
Newsgroups: net.audio
Subject: Rise time measurements of CD players-really?
Message-ID: <535@tekcad.UUCP>
Date: Tue, 9-Aug-83 19:37:08 EDT
Article-I.D.: tekcad.535
Posted: Tue Aug  9 19:37:08 1983
Date-Received: Wed, 10-Aug-83 04:56:52 EDT
Organization: Tektronix, Beaverton OR
Lines: 80

There's been a lot of rise time figures for CD players bandied about here of
late, and to me they have just sounded WRONG, though the pictures are there for
all to see in test reports.  After playing with my handy dandy network theory
book, I'm sure that a large part of the perceived `problem' is due to the
test system.

Let's consider three types of 8th order filters; a Bessel (constant time delay)
filter, a Butterworth, and a 1/2dB Chebyshev.  It's well known that the Bessel
filter approaches a Gaussian response for order->infinity, and its also well
known that the bandwidth-rise time product is a constant and approximately
equal to .35.  For a 20KHz cutoff, this implies a 17.5uS 10-90% rise time.
The 8th order bessel approximation comes close to this, 18us.

It's obvious from the horrendous(?) ringing on the slick mag test reports that
CD player manufacturers in general are NOT using constant time delay filters,
so let's take a look at the Butterworth and Chebshev filters, which exhibit
much sharper cutoff characteristics than the Bessel but have the atrocious
ringing observed.  The 8th order versions of these filter alignments yield
rise times of 23uS and 22uS respectively with about 25% overshoot.

All this has assumed a perfect step input with zero rise time, which, if you
think about it for a minute, the CD test disk cannot provide-indeed, the fastest
edge available to the filter is a transition that occurs in one sample period.
At a 44.1kHz sampling rate, this period is 22.7uS long, comparable to the rise
time of the reconstruction filters.  

The total system bandwidth is the RMS of the input rise time and the system
step reponse, or about root 2 x 23uS = 33uS.  A test waveform with a rise time
of 2 sample periods would yield a system rise time of about 44-50uS, dominated
by the test waveform.

Test results have indicated rise times from 40uS(for the magnavox, NEC, etc) to
the 60uS reported for the Sony CDP-101 (I have a hard time believing that last
figure.  Perhaps a measurement error?).

CONCLUSION-------------------

1) A properly adjusted 20KHz reconstruction filter will exhibit about 20-25uS
	rise time practically speaking independent of alignment.

2) Test results are meaningless unless we can characterize the measurement
	system.

3) We haven't been told the rise time of the standard 1KHz square wave test
	signal.

4) Therefore, existing test reports are valid only as a weak relative
	measurement;
	In fact, what the slick mags may be doing is to a large extent
	characterizing the rise time of the test waveform.

5) 40uS rise times for CD players tested with the Philips disc are PERFECTLY
	NORMAL and DO NOT imply clearly inferior performance
	(to, for example, a SHURE V-15V cartridge with 15uS rise time.).

------------------------------

Of course, the excessive ringing is a problem, but this is more a function of
filter alignment than order.  If everyone used a Bessel or some sort of delay
equalizer the ringing would go away.  Unfortunately, the 44.1KHz sample
frequency presents severe limitations to CD player manufacturers as we have
seen.  Magnavox and NEC may have the right answer to this dilemma in
oversampling. I would guess that their superior transient response arises from
the fact that this technique has allowed them to use correct
filter ALIGNMENT.

Of course, as I've said earlier, the question now is:
	Take a look at any high-end cartridge.
	They look very similar to a CD, yet (supposedly) sound great.
	Does the ringing really matter?

I feel better now...

Shaun Simpkins
-- 
				Shaun Simpkins

uucp:	{ucbvax,decvax,chico,pur-ee,cbosg,ihnss}!teklabs!tekcad!shauns
CSnet:	shauns@tek
ARPAnet:shauns.tek@rand-relay