CD transport into Apple Mac

[Marco]

Tim,

Excellent post, I understand and completely agree.

I like your style. I agree completely, even though I suspect our ears sometimes reach very different conclusions. This is a little different, though. You can't "listen" to digital data. There is nothing to listen to until digital to analog conversion and while the stability of the drive can make a big difference in the accuracy of reading the data when "playing" a cd, the methodology used in ripping cds takes the playing of the cd completely out of the equation.

Yep. What I was getting at with listening is the end result with music, not at the stage you're referring to above. 'Music signals' (what we hear after the conversion process) as you know are different from the raw data described above, and is one of the reasons why in hi-fi, electrical measurements via test apparatus mean very little in a real sense. The end 'music signal' (what the ear detects with music) is all that really matters.

I'm just curious if a high quality CD transport will provide a better source signal for ripping than a computer transport using the same DAC. I suspect though what you say will be right. All will be revealed in due course!

Marco.

[NRG]

I think there are two conversations going on here.

Howards initial post was about playing into a Mac/PC. The best way to do this is DAE. Period.

The other conversation seems to be playing a CD vs listening to the same CD but stored on HDD which is a whole different discussion.

No, because cd players are trying to "play" cds in real time, directly off of the cd. There is no RAM buffer, no error correction checking verifying that the zeros and ones at the source (hard drive) match the zeros

No not true. There is a RAM buffer the difference comes in the quality of the transport and if the manufacture bothered to implement C1 and C2 level error detection. The data read from a CD is not one's and zeros as such, the waveform, as I said earlier, is sinusoidal and the quality or 'eye pattern' of that signal is important to the resulting quality of the data stream and thus audio quality. This is why playing from an HDD is so much better, it removes one very large variable from the digital audio playback chain.

Marco has noticed variations in CD transports and he is correct, they are different and sound different but an HDD eliminates this variability leaving really just the DAC as the key arbiter to ultimate sound quality.

I had an interesting conversation over on PFM a few months back in a similar vein and we agreed that early CD transports from Philips/Sony etc showcased the new 'perfect music forever' technology by correctly engineering the transports and utilising C1 and C2.

Later CD mechs seem to be a bit of a lottery with some implementing no error correction and others doing it correctly. I did a bit more research on computer based CD mechs that some manufacturers now choose to use and there is variability on what features and functions can be supported like C2 error correction. It seems to come down to what features the manufacture enables in firmware, some support DAE with and playback with C2, many others don't.

I can't make Chesterfest, would love to come but I'm on hols and significant others would be rather p1zzed off if I attended!

[Marco]

Very interesting, Neal. Particularly this bit:

I had an interesting conversation over on PFM a few months back in a similar vein and we agreed that early CD transports from Philips/Sony etc showcased the new 'perfect music forever' technology by correctly engineering the transports and utilising C1 and C2.

Now I had not even heard of "C1 and C2" before now, yet from listening experience my ears clearly told me that the Sony CD transport I use is an order of magnitude better than most of what's made today and completely pooh-poohs the notion claimed by many objectivist 'measurement types' that transport quality does not matter, as it's all simply just ones and noughts. Like you say, engineering matters, as quite frankly it does in all areas of hi-fi. This is also probably why DVD ROMs don't cut it with music replay on CD unless you up-sample, which imposes its own (IMO detrimental) signature on the music.

Could you explain a little more what "C1 and C2" are exactly? In easy to understand layman's terms please

Sorry you can't make it to the Chesterfest but I'm sure you'll be having plenty of fun on your hols. You'll hear about it all when you get back. Going anywhere nice?

Marco.

[NRG]

Ok I’ll try! It’s not easy…

C1 errors exist or are present on all disks to a certain degree so we have to live with them and correct them… they are small random bit errors. C2 errors are nastier and we don’t want any of them… they are larger burst errors.

All audio CD’s use Cross Interleaved Read-Solomon code (CIRC). It’s the fundamental encoding and error correction scheme used on CD. It consist of three levels, considered good enough for audio data but not good enough for computer data. Audio data that cannot be corrected via C2 correction can be interpolated or guessed. You can’t guess with computer data!

The three error correction levels are C1, C2 and interleaving of the data on the audio CD. IE: the CD is formatted in such away blocks of data are mixed up in a predefined manner to allow for reading of the disk if scratches / imperfections are present. Interleaving cannot correct for errors by itself it only allows you to recover sufficient data blocks for C1 and C2 to work.

C1 and C2 Error Correction Codes (ECC) are applied to the audio data during the mastering process of the CD IE: when interleaving the Audio Data prior to it being placed on the CD. They are used at different points of the de-interleaving process or playback of the Audio data, C1 first then C2.

Now our Audio CD mechanism manufacture may only wish to implement the basic C1 (he has to implement CIRC otherwise he couldn’t read the disk!) and ignore C2 or he can spend a little more money and implement it fully.

However, there is also the physical quality of the mech. to consider. A cheap mech. with poor servos and supply regulation will produce an ‘eye pattern’ of the disk that is not clean (the optics need to track the CD as accurately as possible), this means any error correction scheme has to work harder to correct errors and as the resulting digital stream has to be created from a sinusoidal output from the laser jitter becomes a potential issue. Maybe it’s why you can notice differences in transports…

With a PC based mech. when we perform DAE we are reading the data from the CD in the same way as when we play it except the data this time is directed over whatever computer interface the mech. has (IDE, SCSI etc) and not directed to a DAC. The de-interleaving and error correction schemes are still applicable.

The quality of the mech. is again important and again it really needs to support C2 error correction and have the feature enabled in firmware. The difference now is we have the ability via s/w on the computer to buffer the read data and also to re-read parts of the CD and perform offset reads to recover the audio track. Software can do this because it’s not constrained by playing the CD in real time. However, not all PC based mechs. are equal but the latest DVD multifunction drives seem to do a very good job. EAC is well know and seems to do an incredible job of recovering read errors given a compatible drive.

In theory, playing back the Audio CD from a dedicated player into a DAC compared to playing the same CD extracted to HDD via the same DAC will sound exactly the same…as long as the copy to HDD to bit correct and the dedicated player is capable of recovering in real time the same exact bit data.

I think I’ve rambled on to long!

[Marco]

Neal,

Thanks for taking the time and effort to write that - much appreciated

I get the gist of what you're saying (which is good enough) although quite a lot went over the top of my head!

This bit however is obviously pertinent to what I've been writing on audio forums for years, namely that transport quality matters:

However, there is also the physical quality of the mech. to consider. A cheap mech. with poor servos and supply regulation will produce an ‘eye pattern’ of the disk that is not clean (the optics need to track the CD as accurately as possible), this means any error correction scheme has to work harder to correct errors and as the resulting digital stream has to be created from a sinusoidal output from the laser jitter becomes a potential issue. Maybe it’s why you can notice differences in transports…

I like the explanation of "eye pattern". I think that's pretty much what's going on.

All interesting stuff, this. It's always nice when one's subjective assessments are reinforced by objective data.

Marco.

[tfarney]

Ok I’ll try! It’s not easy…

C1 errors exist or are present on all disks to a certain degree so we have to live with them and correct them… they are small random bit errors. C2 errors are nastier and we don’t want any of them… they are larger burst errors.

All audio CD’s use Cross Interleaved Read-Solomon code (CIRC). It’s the fundamental encoding and error correction scheme used on CD. It consist of three levels, considered good enough for audio data but not good enough for computer data. Audio data that cannot be corrected via C2 correction can be interpolated or guessed. You can’t guess with computer data!

The three error correction levels are C1, C2 and interleaving of the data on the audio CD. IE: the CD is formatted in such away blocks of data are mixed up in a predefined manner to allow for reading of the disk if scratches / imperfections are present. Interleaving cannot correct for errors by itself it only allows you to recover sufficient data blocks for C1 and C2 to work.

C1 and C2 Error Correction Codes (ECC) are applied to the audio data during the mastering process of the CD IE: when interleaving the Audio Data prior to it being placed on the CD. They are used at different points of the de-interleaving process or playback of the Audio data, C1 first then C2.

Now our Audio CD mechanism manufacture may only wish to implement the basic C1 (he has to implement CIRC otherwise he couldn’t read the disk!) and ignore C2 or he can spend a little more money and implement it fully.

However, there is also the physical quality of the mech. to consider. A cheap mech. with poor servos and supply regulation will produce an ‘eye pattern’ of the disk that is not clean (the optics need to track the CD as accurately as possible), this means any error correction scheme has to work harder to correct errors and as the resulting digital stream has to be created from a sinusoidal output from the laser jitter becomes a potential issue. Maybe it’s why you can notice differences in transports…

With a PC based mech. when we perform DAE we are reading the data from the CD in the same way as when we play it except the data this time is directed over whatever computer interface the mech. has (IDE, SCSI etc) and not directed to a DAC. The de-interleaving and error correction schemes are still applicable.

The quality of the mech. is again important and again it really needs to support C2 error correction and have the feature enabled in firmware. The difference now is we have the ability via s/w on the computer to buffer the read data and also to re-read parts of the CD and perform offset reads to recover the audio track. Software can do this because it’s not constrained by playing the CD in real time. However, not all PC based mechs. are equal but the latest DVD multifunction drives seem to do a very good job. EAC is well know and seems to do an incredible job of recovering read errors given a compatible drive.

In theory, playing back the Audio CD from a dedicated player into a DAC compared to playing the same CD extracted to HDD via the same DAC will sound exactly the same…as long as the copy to HDD to bit correct and the dedicated player is capable of recovering in real time the same exact bit data.

I think I’ve rambled on to long!

NRG, I can't claim to have completely understood all of that, but I got enough to get a bit of an education. Thanks!

Tim

[Tony Moore]

Yes, thanks for that Neal! A really good explanation.

A great pity that you can't come to ChesterFest. You would've been made very welcome!

A previous post (not from you Neal) mentioned Inter IC communication. I believe that is called IIC or I2C and is another 3 wire specification for communicating between chips such as microcontrollers, EEPROMS, ADCs, computer peripherals etc. That bus _is_ bi-directional.

I2S is not the same thing although similar in some ways. I2S uses TTL levels and is master/slave with one end permanently master (transmitter), I2C uses passive pullups, active pulldown so multiple transmitters can be on the same bus, it can swap masters is is much more sophisticated than the simple I2S, intended to carry data packets of varying content.

Cheers,
Tony