if you use a digital out on a cd player is there a sound difference between players? (1 Viewer)

[Kevin C Brown]

Data CDs are encoded using a different data format than music CDs. Not applicable. (Check out www.cdrfaq.com for more info. In general, a really good CD site.)

And, I was doing some more thinking... (Hee, hee. ) Manufacturing tolerances of the hardware components that go into the players as welll as the manufacturing of the discs. Al is used as the substrate for most CDs. Al reflectivity depends heavily on the vacuum integrity of the sputterers used to deposit the film. There will also be tolerances for the reflectivity of the pits and non-pit areas of a disc. There will be "good" lasers and "bad" lasers in the global population of units used to make a player. Obviously, better players will have tighter specs for output, defects within the semiconductors used to make the lasers, etc. Same with the detectors. *All* these things go together. Better players have a better ability to handle deviations in the manufacturing of a disc for example.

 

[Craig_Kg]

Thanks for the selective quote, Kevin. What I said was "unless the transport is so bad that it is introducing gross bit errors, the ONLY sonic differences that there can be between transports are ENTIRELY due to jitter."
Hence my "almost ANY transport" is allowing for a truly crappy one (which is probably about to fail) introducing gross bit errors.

I have been totally consistent in my case and all the stuff you say can contribute to bit errors are accounted for in the spec of players from the $49 KMart special to the Meridians and Krells - it is the redbook standard to which all CD players must adhere. There is a MINOR exception and that is when you try to use a CD player that is not spec'd for CDR or CDRW on that media. In this case, the transport can read improperly (if it will read at all) because it is not spec'd for the media.

 

[Craig_Kg]

Data CDs are encoded using a different data format than music CDs. Not applicable.

Yes CD-ROM uses 304 of the 2,352 bytes in each block for additional error correction but the underlying CD format of the blocks has 8 bytes of parity information for each 24 bytes of data in each of the 98 frames making up the block. The extra error correction in CD-ROM is pretty inconsequential as a result. It was done more as a convenience for operating system interfacing than a lack of robustness in the CD format.

You'd be surprised by what I know about CD. I used to work in the CD-ROM production area back before CDRs were developed.

 

[John Royster]

Craig..

CD-ROM does not equal CD.

 

[Craig_Kg]

John, read this explanation of CD-ROM format http://www.disctronics.co.uk/technol...cdrom_spec.htm CD-ROM is an EXTENSION of the basic redbook CD format.

 

[Kevin C Brown]

unless the transport is so bad that it is introducing gross bit errors

Exactly, just one of my points.

Hmmm, why did DCC, Mo Fi and a few others ever make gold CDs? Sure does look more expensive, so there's probably some "marketing" there, but also the fact that you can get a better quality data stream off the disc due to the properties of Au vs Al too. And, I bet that those differences diminish with better transports too...

 

[KeithH]

Kevin, even most audiophiles I have encountered have said that gold provides no improvements related to sound. The advantage of using gold, of course, is that it is resistant to oxidation, unlike aluminum.

 

[Kevin C Brown]

If the Al does oxidize, that will affect the difference in reflectivity between the pits and non-pits. (Al gets "cloudy" with O2 contamination.) A player with a poor quality laser, optics, & detector can have a harder time differentiating the 1's from the 0's. If that gets bad enough, the sound quality will certainly be affected, and that's non-jitter related.

Oh yeah, and I have noticed that Craig refers a lot to the redbook. The redbook obviously includes how all these things are supposed to work together, but it says nothing about the quality of the components that a manufacturer is required to use to get there. The reason why Mintek/Apex/pick-your-favorite-cheap-player have poor performance isn't simply related to jitter.

 

[ManW_TheUncool]

Kevin,

I think you might be missing something that the others are implicitly saying. They are not necessarily disagreeing that better parts and design will improve transport output. They are saying practically ALL the differences result in the cumulative problem of jitter on the transport output. Jitter is not only found on the disc itself or the disc reading or various other things that happen before output, but rather contributed by all of the above.

So far, all the things you point to sound like they are relatively insignificant issues or will merely contribute to jitter. If there are gross bit errors, then you're really at the point of player malfunction, not just a difference between a $2K transport vs a $200 transport. At least that's what I'm hearing so far.

_Man_

 

[Craig_Kg]

Thankyou Man-Fai and Keith.
Yes, if the Redbook standard is not being met, then the player or media is not meeting the requirements for CD and this can be seen as faulty equipment or media. CD transports MUST meet the Redbook spec before they can be marketed with the little CD logo (and DVD players must include Redbook capability as part of their spec to get the DVD logo).

We are discussing sonic differences with functional systems here. Otherwise, you might as well discuss the performance of cars when some have leaky piston rings, blown head gaskets or flat tyres vs others which are perfectly maintained.

 

[Lee Scoggins]

CD transports MUST meet the Redbook spec before they can be marketed with the little CD logo

Well this is true in theory but implementation quality differs in my experience.

Another issue is pressing-induced jitter from the glass master & manufacturing process. Both my buds Michael Bishop (Telarc) and Mike Hobson (Classic) have encountered this phenomena and switched to more precise duplication plants as a result.

 

[Craig_Kg]

Lee, I wasn't referring to jitter - just the ability to read the data correctly (forget the timing for moment). Jitter is not tightly spec'd in Redbook.