Testing CD transports

[RM7]

Hello everyone,

On the EAC website I discovered a tool for testing the quality of CD transports - called DAE.

However, it's more dedicated to computer CDs (although the author did one of the tests with a hifi CD player).

Does anyone know of any alternative software for testing hifi CD transports that detects reading errors, hardware corrections performed, jitter values?

The idea is to have some data of mine small collection of players, mainly from 2 of them that I decided try some typical mainstream "tuning" and further evaluate the objective improvement of each tweak.

Best

RA

 

[Booker]

In my case, I can imagine using the RME ADI-2 DAC with built-in bit test, while using test files burned to CD.

 

[Salt]

A perfect question for @NTTY

 

[NTTY]

Hi,

As I explained on my More than we hear post here, there are multiple elements of difference that we can test.

The RME test is a good one the verify the digital output is not modified, but it requires RME hardware. My tests are more universal and also about tracking capabilities of the laser head together with Servo control.

Tracking capabilities are tested as described below:

Test type​	Technical test​
Variation of linear cutting velocity​	From 1.20m/s to 1.40m/s​
Variation of track pitch​	From 1.5µm to 1.7µm​
Combined variations of track pitch and velocity​	From 1.20m/s & 1.5µm to 1.40m/s & 1.7µm​
HF detection (asymmetry pitch/flat ratio)​	Variation from 2% to 18%​
Drop-outs resistance​	From 0.05mm (0.038ms) to 4mm (3.080ms)​
Combined drop-outs and smallest pitch​	From 1.5µm & 1mm to 1.5µm & 2.4mm​
Successive drop-outs​	From 2x0.1mm to 2x3mm​

Physical tracking tests capabilities of a CD player.​

I also introduced a new test with the review of the TASCAM CD-200, that is about to verify the data are not modified. It is simply reusing the intersample overs test at 5512.50Hz, with a phase shift of 67.5°. This signal generates an overshoot of +0.69dB and so if the signal would be modified before being sent, it would show either a reduction of amplitude or we'd see some sort of saturation and added distortion/noise. Of course this test is done in digital domain which means I'm capturing the digital output of the CD Player via either coax or optical SPDIF outputs.

In this test I compare the WAV File (directly processed by the PC), with the digital output of the CD-Player:

5512.50Hz @0dBFS with 67.5° phase shift, comparison between original WAV file and from the digital output of the CD Player​

The two traces (and measurements) are identical, including the +0.69dBFS that the measurement software (REW) sees from the phase shift. This means that the digital data sent by the TASCAM is the same as what it was from the WAV File.

I still complement this test with few others, but it's sufficient alone to confirm "digital perfect" output.

Note that one thing people don't talk about is the precision of the clock. Some CD Players use a separate clock for the output, but all might suffer from a lack of precision that will transition to the DAC, as the PLL will not suppress that (only filter the variation, say the carrier of that imprecision). So I run a "pitch control" test that is based on a 19'997Hz sine and I calculate the deviation from that frequency, and show it in ppm. A result of 70-50ppm is good enough for audio. Modern CD players should have no issue to reach 1ppm, which is the limit of what I can calculate (and that would be 19'9997.01Hz measured instead of 19'997.00Hz).

I can share my Test CD with you, if you want.

 

[audio_tony]

I'm capturing the digital output of the CD Player via either coax or optical SPDIF outputs.

This may be a dumb question, But when you say capturing the digital output (but yet showing an FFT which must have been generated by some digital to analogue conversion process) - can you please explain the method? Some D to A conversion must be involved here, but by what?

 

[NTTY]

No D/A conversion, bit words are processed by the software.
Actually, I usually have to process incoming analog data via an ADC before processing by the computer (REW software). No need for that when the feed is already digital.

 

[audio_tony]

No D/A conversion, bit words are processed by the software.
Actually, I usually have to process incoming analog data via an ADC before processing by the computer (REW software). No need for that when the feed is already digital.

Ok, forgive my ignorance but I don't have much experience working in the digital domain.

Also, I'm more familiar with building websites in PHP / HTML, designing CSS layouts etc. Building enterprise networks and firewalls - so I'm not trying to be funny or trip anyone up here.

But if I understand you correctly, the signal path as you describe it is: SPDIF OUT -> SPDIF IN (PC) -> REW which then decodes the SPDIF stream?

Do I have that correct?

Otherwise, what does "No D/A conversion, bit words are processed by the software." really mean? What software is processing the bit words into audio data?

 

[NTTY]

There’s no dumb question, it’s much better to ask than to assume you got it

Yes you got it right, except it’s the hardware of the audio card that decodes the SPDIF data and sends it to the audio driver so a software can use it.

I meant that the 16bits binary words are received by the interface, and transmitted via the driver of the audio card to the software for decoding and representation of their content.

Anything unclear, let me know!