Steve: Many thanks for your input, most detailed and informative, and for the links. It really is very much appreciated. I have not looked at the links yet as my time today has been spent researching this reply.
@otwo_pipes: I think you are far to quick to blame USB
@Steve: USB is notorious for this type of problem, which is why musicians and audio engineers tend to favour PCI or Firewire.
Continue reading for a full discussion of this very point after I have answered all of your questions. As a clue, it has all to do with Isochronous transfers 
@Steve: Your case is most puzzling.
Is this problem occurring when you are recording to RAM, or does it also occur when recording direct to disk?
As you know, I have continuous, and repeatable, recording freezes whenever I write to RAM so my rip set-up has audio cache off therefore I cannot answer your question. I could make an educated guess and state the audio cache would not make any difference. Also, I do not think this error is repeatable, i.e. only sometimes, maybe once or twice a day, do I have the sibilance so this one will not be so easy for me to answer however, having heard the sibilance when in monitor mode I think we can rule out the error being disc writes however, I am still convinced the cut I up-loaded is from a hard drive write data corruption so we could be looking for more than one error. Believe it or not the end of the cut is a drum rap and I was playing air drums, much to the missus’ amusement. I could not have missed this distortion hence the reason for my suggesting more than one error. Time permitting I can try ripping with audio cache enabled/disabled but I suspect this quite unlikely due to time limitations.
@otwo_pipes:In Audacity, I see the meters hovering around the -55dB mark with no input, no input means no album playing on the turntable and not an open circuit.
@Steve: That shouldn’t be happening. With my cheap Behringer USB sound card connected to a Cambridge Audio line output, the noise level with no no signal is around -80 dB peak. You should be getting better than that with your setup.
Unfortunately I am not seeing this. Investigations have shown I have some low level mains hum but I have not had time to isolate the source and my pre-amp has a switched gain for my MC cartridge. My noise level with the switch in the MM setting is about -75dB. Maybe I should invest in a step-up transformer.
Out of interest, what errors do you see on your Behringer USB sound card?
@Steve: What is startlingly unusual about your problem is that you are not using USB.
S/PDIF and PCI should be extremely robust and reliable.
Nevertheless we have an issue and I think I have covered my opinion as to the root cause in one of the previous paragraphs. It would help if I could make the issue repeatable but this one is not so easy and, as I said, I have had to stop using Audacity for ripping.
Regarding the USB issue I have sought a second technical opinion. The SW engineer I approached is a colleague that I worked with at Texas Instruments in Aalborg, Denmark. My work at Texas Instruments involved design and test of USB interfaces. My SW bud was the SW driver and USB reliability guru. What he has said is very interesting. From this exchange of emails, we have raised some interesting points and issues:-
I know data transmission used in certain cam-corder formats have a preference for FireWire due to transfer speed issues but I did not know there was a renowned USB reliability issue so I discussed this with my SW guru regarding USB data corruption.
Some audio guys are telling me USB is renowned for corrupting data and that is why musicians use Fire-wire.
No – I don’t think so. I think it’s more related to history and traditions (as Firewire was at 400Mbps a few years before USB2.0 => USB was at 12Mbps which was too slow). This being said there are no CRC check on real time isochronous data transfers => Errors would pass just right through, but as far as I remember the same is the case for Firewire, and cable types, impedances, etc. are pretty identical, so I would expect HW error to be in the same level as well. This being said I think the Audio business managed to get some “higher quality stamped into the Firewire brand” compared to USB which is more consumer like… For transferring off line audio (files etc.) using USB bulk traffic there is always CRC check and no error would be allowed as SW will request retransmission in case of a detected CRC error.
There are two point here:-
i) File transfer will not have USB data corruption. This is borne out by the 3-4 TB external hard drives and the multi GB Flash drives. If there was data corruption during file transfers the external drives would in effect, be junk.
ii) Isochronous data transfer is prone to data transmission errors.
My colleague has confirmed USB, when used for real time audio transmission, may have data errors which is the very point you have been making all along. I must admit this has surprised me but there is nothing like reporting as is. However, he has also confirmed these errors are remote (and I quote from my SW guru, “HW errors for correction by SW are typical expected to be at a very maximum of 1 in 10^9”). We have a possibility of a bit error of 1 in 10^9 MAXIMUM. Okay, 1 in 10^9 equates to a 1 bit error at a repetition rate of about once every 2 seconds. Do you really expect to be able to hear a 1 bit error occurring at a maximum rate once every 2 seconds. You would have great difficult finding this one bit error in a manual search of a data waveform let alone hear it. (Think about the frequency content of a 1 but error in this data transmission. If you were felling really generous you could produce a data file with a 1 bit in 10^9 error and produce the spectrogram of this file.
This 1 bit error in 10^9 is not, and I repeat, NOT the continuous errors that Sombunya and myself have been experiencing. We had continuous errors until the record process was stopped and re-started. This has been preceded and followed by periods of no errors (apart form one day when I believe I had significant errors appearing as low level sibilance).
Can I say please guys, think about this carefully and consider the fact there may well be a fundamental underlying error in the data capture process of Audacity. You have a great opportunity, in two independent test facilities having the same error. Use this to your advantage. Unfortunately I have had to stop using Audacity as my audio ripping tool due to the severity of the error I have recently experienced. This in itself is very useful test input because now I am listening very carefully for any sign of sibilance. My rip today of 11 LP’s, using Vinyl Studio, was faultless. As soon as I have a sibilance or distortion error using Vinyl Studio, I shall report in this post. Watch this space 
You may find the following technical note, regarding a comparison between USB and FireWire, interesting:-
http://www.qimaging.com/support/pdfs/firewire_usb_technote.pdf
You may also find the following technical description illuminating, I sure did:-
the relevant section concerns the Isochronous transfer. You may well ask why am I emphasising Isochronous transfers to such a great extent; the answer is simple USB and IEEE 1394 use Isochronous serial data transfer mode. IEEE 1394 is the FireWire standard therefore both USB and FireWire, without error correction, using Isochronous data transfer mode are prone to error rates of 1 bit in 10^9 (Maximum).
This is another cut from my SW guru, talking about Isochronous transfer mode:-
“And just to be 100%. The 100% same problem goes for Firewire (in isochronous mode) (see: ttp://en.wikipedia.org/wiki/Isochronous), so Firewire and USB pretty much are expected to be as good or bad on this, but someone managed to brand Firewire being more reliable.”
and this is his words and not mine 
I thought I would seek and add an independent opinion from a SW developer who has worked with both low & high level coding in telecoms. His experience includes work coding USB drivers. His knowledge in this area is vastly superior to mine but he seems to echo the same feelings as I have regarding USB data corruption not being a root cause to the issues we are seeing.
I have to reiterate I am convinced this is not a USB error with Sombunya or a hardware error with myself but a SW error with Audacity. The problem you guys have is you cannot reproduce the same error, and I may add, I think you are a little too quick to blame USB for a lot of the ills. My experience is USB is pretty robust. Remember, I was the hardware design engineer for the USB interface on the development platform for mobile telephone chip set for Texas Instruments so I have experience of testing USB when re have ropey code and hardware 
Maybe I/(and my colleague) am/are mistaken in my/our reasoning and the above argument is wrong but continuous audible USB errors; I don’t think so. I think the evidence is beginning to show I am not mistaken but only time will tell.