Have you considered the possibility that your actions in the vicinty of your turntable/computer are creating sufficient vibration to disturb a loose or poor connection? Have you ever had the noise problem when you’ve started a recording session and walked away and let it run?
Cables are new and tight. The Rega has high quality gold-plated connectors. The usb cable from a to d converter to my pc is also of decent quality, I believe.
No actions by me are causing this, I’m sure. The staic is steady and persistent, when it occurs.
As I’ve mentioned before, I can stop and immediately start the recording an the noise disappears.
I’m recording another vinyl as I type this, working good. I don’t wish to become a nuisance here so I won;t post anything unless it is substantive.
It definitely sounds like a USB sync problem. Nothing major wrong, just enough to mess up a recording.
I think it’s unlikely to be a driver problem, but there are a number of issues on these pages to check (if you’ve not done so already):
http://manual.audacityteam.org/man/FAQ:Recording_-_Troubleshooting#skips
@Steve:
I know we may never agree on this one but I have just copied 492GB of data, my LP album recording files, to my external USB hard drive. As I have two drives for backup this operation was actually performed twice and I have not seen any issues or the dreaded USB sync problem. I would have thought transferring almost 1TB of data would show a number of sync issues considering Sombunya is seeing this issue quite frequently compared to the amount of data he is transferring. Also, my desktop HD is 500MB so 492MB of recordings meant my HD was almost full before the transfer and there were no recording issues.
You, and others, have stated many times the USB interface needs to be reset if this ‘noise’ symptom occurs. Could you please confirm, or otherwise, the USB interface is reset by stopping and restarting a recording in Audacity as per Sombunya statement. The reason I ask the question is Sombunya’s problem only disappears by stopping and re-starting the recording in Audacity. If the USB interface is not reset by the action of stopping the Audacity recording then it begs the question as to what is reset by his action.
I have now transferred 152 albums (and rising) to my HD, admittedly using VS and a different M-Audio interface, without any recurrence of the sibilance problem (see post https://forum.audacityteam.org/t/lp-rip-with-distortion-at-the-end-of-side-one/25334/1). I have an end in sight of my mammoth recording task and, when completed, I shall return to using Audacity with the new M-Audio interface to see if the sibilance issue recurs or has been fixed. Obviously I will report my findings in this post for the benefit of all, myself included 
There’s a big difference between “copying” data via USB connections and “recording” data over a USB connection. The former is done asynchronously to real time. The latter has to be done in true real time. Any delay will cause some sort of problem in real-time mode. A delay during a copy just means that the copy takes a few milliseconds longer.
I don’t think that I said that USB is inherently unreliable, so apologies if I gave that impression.
What I have said is that USB is notorious for not being reliable with streaming audio (or video).
I use a USB interface for audio recording and playback on a daily basis and it is extremely reliable - no problems at all.
I also regularly use USB for my mouse, and for data transfer - no problems there either.
However, a couple of years ago we had hundreds of cases of USB problems with cheap ION USB turntables. Typically they would record for a while, then the signal would turn to static. This occurred with all recording software and was using “plug and play” generic Windows USB drivers. The problem could sometimes be resolved by plugging into a different USB port. Sometimes it required exchanging the device under warranty.
At a place that I worked previously we had 15 mid-range M-Audio USB sound cards. When they worked they were terrific, but all of them had problems with intermittently losing connection. The audio would suddenly become very distorted. The only way to fix the problem was to “Safely remove hardware”, switch the device off and back on again, wait for the drivers to reload, and then it would work perfectly.
A few months ago we had a flurry of problems reported with cheap USB cassette players where data was being dropped, causing bits of data to be missing. This results in a recording that apparently plays back too fast. In each diagnosed case it was not actually playing back too fast, it was playing the recorded audio correctly, but parts of the audio were missing. We are still seeing some of these problems from time to time.
USB is CPU dependent. If the load on the CPU hits 100% then USB data transfer will wait until the CPU is available. That is not good for real time capture (though it does not matter for data transfer).
If a USB device is connected via a USB hub, the hub shares the USB connection to the computer with each of its USB ports. This can cause problems because the USB port that is being used by the audio device is not guaranteed to be available within the audio buffer period.
I could go on, but in short, USB can and often is very reliable, but for real time capture there are lot of things that can go wrong, including, but not limited to, substandard USB hardware, real-time availability, CPU load, substandard drivers, port sharing and other factors. These types of problem are well known and you will find references to such issues all over the Internet. This does not mean that such problems will always occur with USB devices - most users of USB audio devices never see this type of problem, but out of millions of USB audio device users there are a lot of people that do or have experienced such difficulties.
Also I’m not saying that other types of audio device never give problems - sometimes they do, but USB issues are often characterised by loss of connection or dropped / corrupted data.
@PGA:
There’s a big difference between “copying” data via USB connections and “recording” data over a USB connection. The former is done asynchronously to real time. The latter has to be done in true real time.
Agreed
Any delay will cause some sort of problem in real-time mode.
True but, and this is a big but, the problem should be extremely minor on a well designed USB interface!
My 492GB of transfer took just over 5 hours using USB2 which is claimed to be 480Mb/Sec whereas my 492GB transfer equates to a real sustained data rate of about 220Mb/Sec.
24/96 audio is a data rate of aprox. 5Mb/Sec which is well within the real USB transfer speed.
MY USB guru has quoted me measured USB error rates of 10^-9: “In case of a HW bit error rate of 10^-9 for a 192kbps@32bit stereo (extreme case recording) you would get one error for every 81sec as total audio bit-rate is only like 12Mbps and not 480Mbps.”
I have designed USB hw interfaces and supervised the USB PCB layout process to ensure matched impedances. Yes, there are problems with USB but nowhere near the sort of problems Sombunya is experiencing. I even had a USB test set manufacturer admit, very reservedly, that their test set could in itself be providing erroneous information and not portraying the correct USB picture regarding the signals on the USB cables. It was extremely difficult to get the manufacturer to admit their equipment was actually registering an error when none existed. The manufacturer stated that it is very difficult to measure the USB signal without corrupting it. To measure without corruption they had to use high impedence measurement techniques whereas USB requires 45 ohm single ended or 90 ohm differential impedances. I have been involved in detailed USB reliability testing and, in one instance, our error rate was way way in excess of 10^-9. These high errors were eventually traced to sw issues. I can only state what I have seen in my design role; when USB hw and sw is well designed the error rate is extremely low.
A delay during a copy just means that the copy takes a few milliseconds longer.
Agreed
I don’t think that I said that USB is inherently unreliable, so apologies if I gave that impression.
Accepted but everyone asks, “Are you using USB…?” and then proceeds to state how unreliable USB is adding the rider that it is better to use Firewire etc. etc. I am of a different opinion and suspect other, yet to be found, reasons for the noise Sombunya is experiencing. Let me state it could well be a USB issue but I do not believe, in this instance, the problem is USB related. This opinion is based solely on Sombunya’s statement that by stopping and then re-starting the Audacity recording process the error disappears.
What I have said is that USB is notorious for not being reliable with streaming audio (or video).
Agreed; this is due to the Isochronous nature of the audio and video data transmission format. There will be data errors but I do not believe these errors will be continuous as per the issue in Sombunya’s case. This statement does assume Sombunya is using well designed USB hw and sw
I use a USB interface for audio recording and playback on a daily basis and it is extremely reliable - no problems at all.
Agreed but this is as I would expect.
I also regularly use USB for my mouse, and for data transfer - no problems there either.
There is a significant difference between mouse/data and audio/video transfer. Sorry to get technical but I feel it is necessary at this point:-
For an external USB storage medium be it a flash or hard drive the data transfer format uses what is called “bulk” transfer which is CRC protected and upon error detection the data is retransmitted up to 5 times before sending an error flag to the upper layer SW. The main point is: data transfer is either safe and correct or abandoned.
For a mouse/keyboard the data transfer uses an “interrupt” driven format. Again this is CRC protected and data transfer is either safe and correct or abandoned.
For setting up a link to control a HUB, the data transfer format uses “control” transfers. Again this is CRC protected and …
For real time streaming i.e. USB turntables, Webcam or USB speakers etc. data transfer is “Isochronous” which is NOT CRC protected because there may not be time for retransmission if errors are detected. Bandwidth is calculated to just fit the need and keeping the phase is judged more important than the validity of the data…
The above are extracts from my USB software guru and as I have outlined earlier data errors are of the order of 10^-9 and this error rate would be barely audible as per your USB recording experience.
However, a couple of years ago we had hundreds of cases of USB problems with cheap ION USB turntables. Typically they would record for a while, then the signal would turn to static. This occurred with all recording software and was using “plug and play” generic Windows USB drivers.
but what was the ION USB turntable manufacturer doing with the data from the hw and processed by the sw BEFORE the data was passed to the generic Windows USB drivers. I wrote the following, “I have been involved in detailed USB reliability testing and our error rate was way way in excess of 10^-9. These high errors were eventually traced to sw issues” before reading this section. I can only hope you believe this statement because it is the very crux of my case. Yes, you can and will see huge USB errors if there are design issues. The high USB errors occur because there is something fundamentally wrong with the equipment design. I have never stated otherwise; just it is wrong to always jump to blame USB. Maybe the ION USB turntable is a case in point because you state some turntables were returned under warranty.
The problem could sometimes be resolved by plugging into a different USB port. Sometimes it required exchanging the device under warranty.
Agreed
At a place that I worked previously we had 15 mid-range M-Audio USB sound cards. When they worked they were terrific, but all of them had problems with intermittently losing connection. The audio would suddenly become very distorted. The only way to fix the problem was to “Safely remove hardware”, switch the device off and back on again, wait for the drivers to reload, and then it would work perfectly.
AGREED: but this is not the case with Sombunya. Sombunya STOPS and RE-STARTS the AUDACITY RECORDING PROCESS. How does stopping and re-starting the Audacity recording process tie into the re-setting of the USB port? If the USB port has not been reset surely the USB errors would continue?
A few months ago we had a flurry of problems reported with cheap USB cassette players where data was being dropped, causing bits of data to be missing. This results in a recording that apparently plays back too fast. In each diagnosed case it was not actually playing back too fast, it was playing the recorded audio correctly, but parts of the audio were missing. We are still seeing some of these problems from time to time.
I will pass on this one
USB is CPU dependent. If the load on the CPU hits 100% then USB data transfer will wait until the CPU is available.
This is not true for Isochronous i.e. audio/video, transfer. The data is lost as per your cheap USB cassette example.
That is not good for real time capture (though it does not matter for data transfer).
Agreed
If a USB device is connected via a USB hub, the hub shares the USB connection to the computer with each of its USB ports. This can cause problems because the USB port that is being used by the audio device is not guaranteed to be available within the audio buffer period.
Agreed
I could go on, but in short, USB can and often is very reliable, but for real time capture there are lot of things that can go wrong, including, but not limited to, substandard USB hardware, real-time availability, CPU load, substandard drivers, port sharing and other factors.
Agreed
These types of problem are well known and you will find references to such issues all over the Internet. This does not mean that such problems will always occur with USB devices - most users of USB audio devices never see this type of problem, but out of millions of USB audio device users there are a lot of people that do or have experienced such difficulties.
Also I’m not saying that other types of audio device never give problems - sometimes they do, but USB issues are often characterised by loss of connection or dropped / corrupted data.
Agreed but again, I do not believe the distortion Sombunya experiences is USB related solely because of his statement re stopping and re-starting Audacity. If that statement is erroneous then my discussion would be null and void. If Sombunya re-started his PC then, like everyone else in this forum, I would not rule out an USB.
Maybe it would be useful if Sombunya could post a snippet of the erroneous recording for you guys to analyse. Maybe there would be some underlying issue that was quite obvious. Only a suggestion.
Steve: The good news is that at least we seem to agree on a great deal regarding USB 
Oh and by the way: I have just remembered about today’s problem with the USB mouse on my desktop PC recording studio implementation. On this PC the mouse works perfectly for between 5 and 20 minutes and then the tracking led extinguishes and the keys stop functioning. This happens on 4 different USB ports on the desktop. The mouse has flashing lights, like a child’s toy, so it is still powered but no cursor or button click detection. Unplugging and re-plugging; normal operation is resumed for 5, 20 maybe 100 minutes and then a repeat performance. The mouse worked perfectly on one of the USB ports of my wife’s net-book but not on the other two ports. This is obviously a USB issue. Somehow, the engineer in me says this is not a USB issue rather a cheap and nasty mouse design issue. The USB keyboard on the desktop continued to function normally whilst the mouse went AWOL. It is all too easy to blame USB when there can, and often are, underlying issues which are not related to USB per say.
and YES the above really did happen except it was yesterday and not today
Please don’t get me wrong as I am not anti-Audacity. I think Audacity is a brilliant programme and free: unbelievable. That is high praise indeed coming from me
I have just discovered this morning that even file copy operations can be very adversely affected by a “bad USB setup”. I was doing the weekly backups (using Vice Versa software) and was getting numerous failures to read the input device and also failures to write the output device. I tried with two different Seagate USB HD devices (each with their own cable) as the output device and had similar problems on both. During the previous week I had tidied up the cable chaos and I suddenly realised that I had both the input and output devices connected to the same Belkin, mains-powered USB hub. I switched the output device to a second powered USB hub and, as I write, the backup is proceeding steadily along (apparently trouble-free). I need to do some more checks but it seems as though the single hub could not handle the data load.
The moral of the story: USB might be “plug and play” but it isn’t “plug and forget”, you still need to consider what you are asking the equipment to do for you.
@PGA:
I have just discovered this morning that even file copy operations can be very adversely affected by a “bad USB setup”.
Did this ‘bad set-up’ which adversely affected the data transfers result in corrupted backup files or slow/abandoned transfers? I would suspect, and hope, it was the latter.
It was the latter!
And the new attempt is still chugging along and is, as I write, still error-free. However, the failed attempts do seem to have “trashed” the file systems on the other two disk drives that I tried as output devices. Once I have completed a successful backup, I’ll have to try and format these two drives. Interestingly, I had had problems with yet another target backup drive once before and had assumed it was a defective device. But thinking back to those days, I’m fairly sure it was also connected onto the same hub as the source disk drive. I’ll have to get it out of the junk cupboard and give it a second chance on a different hub.
Good, or even excellent because this is what I have been saying. More importantly, if you have a USB turntable, or any USB audio output device, then maybe we can progress on this front.
Use your ‘bad USB set-up’ (when you know it is bad).
Connect the USB sound source to the same USB hub, if I have understood your set-up correctly and use Audacity to capture the audio.
Actually you could use any audio capture program and now we should have corrupt USB captured audio that can be used as a comparison basis. If you do succeed in generating corrupt, USB captured, audio from this scenario, I would certainly be interested in having a snippet uploaded to Sendspace at:-
http://www.sendspace.com/premium_upgrade.html
The results of this test may be illuminating but, on the other hand, there may be no conclusions to be drawn. Just some ideas on my part.
At the moment, I have no idea on the trashed file system so I will have to think about that one.
I do not record using the computer. All my recording is done using a Zoom H4 and then that connects as a USB storage device and the files are copied onto my hard disk.
Status on the two “trashed” drives:
- one is OK (I have checked it using both Windows device “Properties > Tools > Check now” and IoBit Advanced System Care’s Disk Repair. Both say the file system is error free). I have deleted all the files that were on it, re-checked it, and it is now an available spare.
- the other is totally trashed. Windows does not recognise it enough for me to even attempt to reformat it.
Let’s close this discussion now and let this topic get back to its original purpose.