I do not see a route forward on this one. I have heard distortion when I started ripping, not severe distortion but certainly audible, just like sibilance. Not know what to do I just pressed Audacity Stop followed by Record and the sibilance disappeared. I do not know what this says. I think we can rule out the sound card but I am not sure if we can rule out the DAC. As I said, unfortunately I pressed Stop followed by Record. If I had thought clearly I should have pressed Stop followed by Shift Record. Next time I will be wiser.
@Gale:
An issue that I really don’t want to bring up (again), but it is relevant, Please add a link to the thread of the above discussion is that there is no benefit to recording in 24 bit with any release build of Audacity on Windows because PortAudio (the library that acts as an intermediary between Audacity and the computer sound system) only passes 16 bit data to Audacity - the last 8 bits of 24 bit audio are replaced with padding (8 zeros if I remember correctly).
Could you please add a link to the thread of the above discussion
This statement re 16/24 bit and padding has thrown up a number of questions:-
i) Where does it say in the manual 24 bit Audacity is 16 bit + 8 bits of zero padding
ii) Why do you recommend 32 bit if Audacity is only receiving 16 bit?
iii) What is the purpose of having 24 and 32 bit settings if Audacity is only receiving 16 bit data?
As you have said, it is easy to convert from 32 to 16 bits likewise, it is easy to convert from 16 to 32 bits so why use 32 bits as the default if Audacity only has 16 bits from PortAudio?
Is this an Audacity or Windows or Windows Interface limitation?
As I said, I’m not sure where the data corruption is occurring, just that there’s clear evidence that it is occurring throughout the recording - mostly with little audible effect, but occasionally with very severe audible effect.
but this audible effect was not present at the time of ripping… at least, the very severe effect was not present. The severe effect is just too obvious to have been missed.
As to why you don’t hear the problem while monitoring the recording, are you sure that the S/PDIF output of the M-Audio Delta 192 is playing the audio from Audacity’s Software Play-through and not simply looping the output from its S/PDIF input?
Yes: I am 100% sure. If I turn Audacity play-through off I hear nothing when in monitor mode and I am permanently in monitor mode. Of course Audacity may be so smart it is not using the PC RAM but the sound card RAM, however I doubt this very much therefore I can say I am 100% certain.
If it is using the Software Play-through then there should be a noticeable delay between signal in and signal out,
Correct: and there is a noticeable delay.
whereas if the signal is looping from input to output in hardware there should be virtually zero delay (zero latency). Perhaps you can test this by plugging headphones in somewhere in the chain after the turntable but before the M-Audio Delta 192. Do either the pre-amp or ADC have a headphone socket?
The only headphone socket I have is on the Beresford DAC box so your suggestion is not possible.
@Koz:
Since I couldn’t exactly follow the signal flow at the computer, I’m just guessing based on what it sounds like.
Where is the problem with my description? I am sure you understand the 3 head tape recorder scenario with record IN and play OUT so I have exactly the same set-up but I haver replaced the tape recorder with an ADC box, Computer and DAC box. The signal flow is Pre-Amp Monitor OUT (this would connect to record IN of the tape deck) to ADC Box IN- ADC Box OUT to PC IN. Followed by PC OUT - DAC Box IN & DAC Box OUT - Pre-Amp Monitor IN (this would be the tape deck to pre-amp Monitor connection) I cannot find any useful block diagrams on the Web so cannot really help you any further.
You can override feedback with musical volume depending on what’s unstable and where.
Please forget feedback, the set-up has never been unstable even when recording with the speakers at full volume so I cannot see this as a feedback issue.
It’s still perfectly possible that you’re listening to a carefully prepared monitor feed during capture divorced from the show going onto disk.
Agreed and the very point I am trying to make. I suspect that what is captured is NOT what is going onto disc.
Macs have two Play-through options, so it’s not chiseled in stone that there’s only one correct one.
You missed, “Software: Audacity 2.0.0, Win7 x32 SP1 2GB RAM” I am using Widows and not MAC.
The purpose of the Overdub setting is play an existing say, music track to you while you sing along for recording on track two. Mix one and two for a finished song. That’s greatly oversimplifying. The purpose of Play-through is to turn around a copy of the incoming show to the output so you can hear what you’re doing. It’s always late by one round trip. If you’re not overdubbing, then Overdub should be turned off.
Thanks
other than when I am testing Audacity and have to change the Audacity settings to force an Audacity crash.
What sort of testing requires this?
When the audio cache is enabled Audacity crashes on MY Win7 and XP systems and it is very repeatable.
I’m not shocked that a military-grade sound system could have instability and/or feedback and create trash as far up and down as it could to include ultrasonics and low radio frequencies.
Of course and irrelevant. I quoted ‘broadcast quality’ before someone chirps in with S/PDIF is renowned for this that and the other. If the ADC box is used in broadcast studios I would hope, only hope, it is stable.
Oh, and you’re not listening to the tape simul-play heads. You’re listening to the feed that Audacity carefully prepared for you and not the show going onto the disk.
Precisely, as I said above, “Agreed and the very point I am trying to make. What is captured is NOT what is going onto disc.” Therein lies the rub.
There is an additional complexity. We can usually recreate the poster’s symptoms at home and generate a better than even chance of explanation of what’s happening. Can’t do that with you. it’s uncharted waters.
Par for the course. As I stated in a previous thread, “In my electronics days I had a reputation (good I might add) at breaking SW systems. I was so adept at breaking SW systems I was often tasked to test the systems before release to customers.”
Reading back through this. Only one song (so far) is affected, right, after hundreds of hours of transfers?
I am not sure as I have not played many of the ripped albums, I have played maybe two or three so I really cannot comment however, having heard the sibilance today I believe I have heard very slight sibilance on a small number of recordings but just thought it was due to the album being in poor condition.
Have the drives filled up enough to slow down past the point of accepting fast data?
No: Half full with 235GB free (the drive is SATA II)
You didn’t get drive errors right?
Correct:
I can’t find where you said you’re using SSDs.
That is because I did not say I was using SSD’s 
I have an SME arm on an Empire belt-drive.
separate power amplifiers and speakers
What and by whom?
Musical Fidelity MA-50 and Cambridge Audio R50 speakers; see link http://www.gramophone.net/Issue/Page/June%201972/135/850915/Cambridge+R50+Monitor+loudspeaker#header-logo
Nobody asked. Is the song broken exactly the same way each play?
No: I have even ripped this section at 24/192 with no problems