Sorry, missed this, busy with work and rehearsals for Easter and upcoming orchestra concert so my evenings have not been free.
Disclaimer: I am no expert on CD standards. I did a little background search on Red Book to address the data rate and clock questions. As for different formats and such, I'll (or somebody) will have to tackle that a little later.
For now, let's start at the bottom. Your CD uses 16-bit samples, in stereo, at 44.1 kS/s. I remember Sony and Phillips arguing over that a bit; I think Sony wanted fewer bits, and Phillips wanted a slightly slower rate to be compatible with video frame rates (but I could be wrong). The word clock relates to the actual sampling rate, 44.1 kS/s is the rate at which (stereo) samples are finally delivered from your CD to the DAC that converts them into analog audio.
Now it gets a little complicated to move up the clock chain... You might think the bit rate is simply 44.1 kHz * 16 bits * 2 for stereo or 1.4112 Mb/s, and thus the bit stream clock is twice that or 2.8224 MHz. In fact, it does work out that way at the DAC itself, but the actual path is a little more convoluted. Those not wanting a bunch of explanation and some (simple) math should stop here.
The problem with CDs is that they can have defects. Alas, nothing is perfect. There is also the need to keep the data stream "busy", that is no long strings of 1's or 0's, to keep the clock synchronized. The actual clock circuit, a phase-locked loop, needs edges to detect the phase and stay in synch. No edges, and it can drift away, eventually losing lock (it gets lost and out of synch with the data stream). These two considerations mean extra bits get added for error correction and to ensure the bitstream is always "busy". The standard also defines a minimum data package, called a frame, to simplify the buffering and provide space for all the extra overhead.
The frame in a CD comprises six samples, or 24 bytes (192 bits, 6 samples * 16 bits/sample * 2 samples for stereo). To that is added 8 bytes (24 bits) for error correction (CRC), and another byte for control and display functions, so there are 33 data bytes in each frame. Next, to make sure bits toggle all the time, those 8-bit bytes are encoded into 14 bits, with an extra 3 "merge" bits between each encoded byte. Now, we are up to 33 bytes * (14 + 3 bits/byte) = 561 bits/frame. At this point a 27-bit synchronization code is added to keep all the data bits lined up in the right order, so at the end we have 588 bits in every frame. Whew!
The next mind-numbing discussion relates to decisions made about physical implementation on a CD. Like other disc drives, they divided the data regions on the CD into sectors, with 98 frames per sector. (I am sure there is a reason for all these strange numbers but I did not dig that deeply.) The CD transport is designed to deliver data at a constant rate of 75 sectors per second, which works out to 57,624 bits/sector and 4.3218 Mb/s net data rate. But, this doesn't look anything like that 2.8224 MHz number, does it? Hmmm...
Ah, remember that there are only six stereo samples in each frame, or only about 1/3 of each frame is what we listen to. Six samples is 192 bits (6 samples * 16 bits/sample * 2 for stereo = 192 bits) per frame. Now take that total data rate and convert to "useful" bits at the end: 192 audio data bits / 588 bits/frame * 4.3218 Mb/s = 1.4112 Mb/s. The clock runs at twice that rate, and viola! We are back at 2.8224 MHz for the bit clock. The extra bits are used and then stripped off before the data stream goes toward the DAC.
The master clock is simply four times the bit rate, 4*2.8224 = 11.2896 MHz, and is needed to provide margin for various timing issues that might happen in the real world, as well as extra bandwidth for all that overhead in the bitstream. As has been mentioned, designs may use some other master clock if they choose. Why they chose this instead of some multiple of the actual data stream, I do not know, but I am sure it can be found someplace in the standard (I do not have a copy at hand). However, having it be a multiple of the actual audio data stream is a Very Good Thing for those designing clock circuits for DACs.
There, probably more than anyone really wanted to know about CD bit streams!
HTH - Don
References:
http://en.wikipedia.org/wiki/Compact_Disc and a couple of audio handbooks I have at home but forgot to write down (just have the numbers with me -- this was my lunch hour today!)
p.s. I would have to do more on clock schemes to answer the questions about USB vs. SPDIF vs. whatever. I will note that bitstreams used for data tend to have lots of error correction schemes, including retries and such, may use spread-spectrum clocks (that move around a little) to reduce spurious output (EMI/RFI), and have fairly high digital noise (including jitter) that is fairly easily suppressed in a digital data system, but that plays havoc when trying to recover a clean low-jitter clock for an audio DAC from the digital data stream. USB was not designed with low jitter in mind. Audio SPDIF is much cleaner, probably because it is used in so many professional recording systems, but then we went and shot ourselves in the foot by letting the video guys saddle us with HDMI. Since we are generally less sensitive to video jitter (the TV and our eyes integrate it out), HDMI is a fairly noisy signal. Some components use sophisticated reclocking schemes to reduce the jitter to acceptable levels, but many others do not.
