[WindowsX]

That's where you get it wrong. Clock signal does involve in computer's digital audio. There're tons of professional sound card does support word clock signal. Even some Async USB devices where it does its own reclocking use high precision clock for better audio performance. Also, there's high precision event timer implemented for multimedia application in computer as well. You can't say it doesn't involve in computer audio from buffer to DAC. Some async USB digital audio interface devices feature high quality clock for superior signal. Even modern Esoteric's D-02/D-01 supporting async USB audio can gain improved performance with masterclock (22.579/24.576MHz) frequency from G-02/G-01.

 

[germanium]

  That's where you get it wrong. Clock signal does involve in computer's digital audio. There're tons of professional sound card does support word clock signal. Even some Async USB devices where it does its own reclocking use high precision clock for better audio performance. Also, there's high precision event timer implemented for multimedia application in computer as well. You can't say it doesn't involve in computer audio from buffer to DAC. Some async USB digital audio interface devices feature high quality clock for superior signal. Even modern Esoteric's D-02/D-01 supporting async USB audio can gain improved performance with masterclock (22.579/24.576MHz) frequency from G-02/G-01.

Of coarse when you are working with a DAW you are generally working with more than one soundcard & the clock signal must then be shared amongst all soundcards. DAW soundcards have that provision but not soundcards that are for consumer playback. What I have said holds true for consumer playback sound cards. In a DAW situation one needs to share a common clock in order to keep all cards in sync with each other. They still buffer the audio for playback of previously recorded material though to a smaller degree than consumer playback cards. Low  latency playback of currently being recorded material  most likely circumvents the buffering in order to achieve time alignment with the original though I'm not entirely sure on that aspect. I am sure about the rest however from a consumer play back perspective though. Sample data on playback of previously recorded material must be buffered due to the fact that computers do not provide a continuous data stream but data is delivered in spurts with no correlation to the playback sample rate other than not letting the buffer on the sound card go empty.

 

[WindowsX]

Esoteric D-02/D-01 has USB input for audio playback and I'm talking about that on customer's point of view using G-02/G-01 for computer audio.

 

[rb2013]

  I posted the captioned software to JPLAY forum at the end of December and would like to share it here as well.  The author is the same person who makes "Bug Head Emperor".
http://jplay.eu/forum/computer-audio/drastic-sound-quality-improvement-rewrite-data-1.0/
 
Download: http://1drv.ms/1nBAKyD
Rewrite data 1.19 (as of today) for Win7/8.1 64-bit
 
The program makes a bit-perfect copy of the original, checks the bit-perfectness, and overwrites the original, retaining its file properties.  If you open Explorer during the process, you see a temporary file whose name consists of digits.
The target files must be on a Win7/8.1 PC.  Applying to a network drive makes no sense.  Copying the processed files as well as moving them to a different drive loses the effect.
It is also effective to a USB memory and an SD card, which can be plugged out and be inserted into other pieces of equipment such as an SD card transport.
The effect vanishes gradually and the program should be applied again.
Please enjoy.

I've been using EAC (Exact Audio Copy) for years it's a pretty awesome program - but a bit daunting to set-up properly.  The program is designed to test the drive on your PC and calibrate itself and detect the Error Correction feature.  It reads each bit of a CD multiple times until it gets a repetitive match - it will keep reading that bit I believe up to 16 times before it gives up.  Once the image file is created it's checked against an online data base called AccurateRip.  I use the uncompressed Test & Copy Action mode.  I don't use the ID3 Taggging but prefer to use a Win Filename based tag - this usually created automatically from the Dbase online.
 
The idea is a spinning disc has to be read in realtime (less a slight buffer) and the player/transport has to rely on error correction frequently - producing a type of jitter.  Additionally the CD head itself is controlled by a servo motor that is notorious for creating jitter and feeding it back into the power supply - effecting the DAC's PS.
 
PS From the EAC website:

  In secure mode this program either reads every audio sector at least twice or rely on extended error information that some drives are able to return with the audio data. That is one reason why the program is slower than other rippers. But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program keeps on reading this sector, until eight of 16 retries are identical, but at maximum one, three or five times (according to the selected error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this effort will help the program to obtain the best result by comparing all of the retries.
If it is not sure that the audio stream is correct (at least that it can not be said at approx. 99.5%) the program will tell the user where the (possible) read error occurred. The program also tries to correct the jitter artefacts that occur on the first block of a track, so that each extraction should be exactly the same. On drives which have the “accurate stream” feature, this is guaranteed. Of course, this technology is a little bit more complex, especially with some CD drives which implements caching. When drives cache audio data, every sector read will be read from the drives cache and is that way always identical. Basically there are several ways to clear the cache. In newer versions it will overread sectors, so that the cache contains sectors from a position elsewhere on the CD.