Audacity Forum

Software: Audacity 2.0.0, Win7 x32 SP1 2GB RAM
Stereo Equipment Connections:
Short Description-
Record deck looped through external ADC/DAC boxes via PC sound card with Audacity SW set to play through, pre amp in monitor mode connected to stereo system.
Long Description-
Signal sources are a Pink Triangle PToo with a SME series V arm + Audio Technica cartridge
The audio pre-amp is a Musical Fidelity 3A
The ADC used to digitise the audio source is an RDL HR-ADC1 (ADC) broadcast quality unit
Audacity and the RDL HR-ADC1 are set to 96KHz and 24 bit quality
I am using the S/PDIF output of the ADC connected to the S/PDIF in of an M-Audio Delta 192 card
Audacity is set to software play-through in the preferences menu
The M-Audio S/PDIF output is sent to a Beresford DAC
The DAC output is connected to the Monitor input of the Musical Fidelity Pre 3A and hence to separate power amplifiers and speakers

Task: I am ripping hundreds of LP's to hard drive and I am monitoring the record process as explained in the 'Long Description' above. I have checked this set-up by turning off the Audacity sw play-through. During the recording process there has never been any distortion. This suggest the audio has been digitised correctly and Audacity is also routing this digitised data to the DAC correctly via the play-through setting in the preferences menu.

Problem: The audio file I have provided has significant distortion at times 29-34 seconds and 3:01 - 3:15. This file is a cut from the main file which is about 40 minutes long. The cut is from the end of the first side of the album and is at a time stamp of aprox. 20 minutes. I have not had time to thoroughly check this, or any other, recordings though I have spot checked 3 recordings and not seen any errors. I would guess the writes to the hard drive have gone wrong, in the time areas mentioned above, for some reason. Does anyone have any suggestions as to what could have gone wrong?

The link to the file is:-
http://www.sendspace.com/file/01oxdc

It's feedback and I'm pretty sure nobody's going to argue with me. Somehow in the system you got the input service and the output "talking" to each other giving a continuous loop. If you have enough delays or latencies in the system, it won't sound like screaming or howling of normal bar or pub band feedback. The final clue was at 3:08 with that slowly decreasing ringy rumbly sound.

You have playthrough selected so you can hear your work, but do you also have Overdub selected? That would be bad.

You're not recording through your microphone by accident, are you? A number of posters did that by accident and the only way they caught it was the dog started barking.

Are you playing it loud enough so the high room volume is moving the tone arm? You should be on headsets for sessions like this.

All that and I can't figure where the computer connects. I read it four times and I can't visualize where the cable to the computer goes. S/PDif? Analog? Throw more description right there.

Koz

There's an argument that I've had many times with many people, it goes like this:
They say: "Of course 24/192 is better, there's more "bits" so there is better amplitude accuracy and more samples per second so better transient response".
I say: "Not necessarily. Nyquist–Shannon sampling theorem tells us that frequencies up to half the sampling frequency can be reconstructed perfectly, The practical limitations of this being the steepness of anti-alias filters that can be manufactured to a reasonable cost. With modern digital filters, 44.1 kHz sample rate can in practical terms reproduce up to 20kHz audio bandwidth. There are no D/A audio converters currently available (at any price) that can accurately reproduce a full 24 bit resolution, beside which, 16 bit has a noise floor some 90 dB below full-scale. Yes there are some marginal benefits of going above 16/44.1, but there is also a trade-off. Above 22 bit, any additional bits are irrelevant because current state of the art electronics are only accurate to 22 bits, so any bits beyond 22 produce only "noise". Similarly, beyond about 80 kHz sample rate there is no additional information within the audio frequency band that can be gained."

I realise that you are not talking about going as extreme as 24/192, but trade-off still occur. The more data per second that the hardware has to handle, the harder it is for the hardware. At 24/96 there are 576,000 bytes of data per second, compared with 176,400 for CD quality. The question is, can the hardware cope with 3 times as much data in real time with accuracy?

Let's have a close look at the waveform:
You see that little notch in the left (upper) channel - that is not audio. It has a frequency beyond 40 kHz, What's it doing there?
These are the actual sample values (in dBFS) for the selection in left channel:
-11.80586
-11.71143
-12.10506
-12.30383
-11.29587
-10.98052
-10.72715
-10.58610
-10.56283
-10.64639
-10.66720

What seems to have happened here is that a couple of binary "1"s have come out as "0"s (or vice verse).
This particular glitch is hardly audible, but it's an indication that there are data errors, which is an indication that the hardware is struggling to keep up.

Switching to the spectrogram view and zooming out a little (same selection):
That red vertical bar shows the frequency representation of that glitch.
Now lets zoom out a bit further:
Holy smoke Batman, there's hundreds of them.

I've no idea if it's the sound card, the S/PDIF, or somewhere else in the system, but you are stressing some part of the system and there are a lot of data errors.
I'd suggest that you try making some recordings with exactly the same set-up, but lower the data rate. Try doing some test recordings at 44.1, 48, 96 kHz and 16, 24 and 32 bit (or whatever options are available). Ensure that the sample rate is set the same throughout the system (the A/D, S/PDIF, Windows settings and Audacity).

Hi Koz, nice to see you back. Have you been following the other thread I raised? If not, please read my last page in the other thread, the relevant paragraph is towards the end of my posting on page 6 that begins, "What conclusions can we draw."
@Koz

It's feedback and I'm pretty sure nobody's going to argue with me.

Sorry, I will argue with you (but only in a nice way).
i)If it is feedback why do both occurrences happen at low(ish) recorded signal amplitude and not at the higher recorded amplitudes when the speaker volume has not been changed?
ii) Why did I not hear the feedback at the time of ripping? Remember, I am monitoring the rip and not the LP source. Digital data is written to RAM, by Audacity, and read from RAM, by Audacity because play-through is selected. This set-up will immediately alert me to feedback or any other set-up/connection problems. This is why I work in monitor mode.
iii) An easy way to check for feedback is to turn up the volume of my stereo. So, I have recorded the same track and wound my pre-amp to full volume when the LP Record had high levels (no other system changes). No feedback. I must admit you did have me worried as the system does not have perfect isolation but the isolation is certainly good enough, as I have just proved.

Somehow in the system you got the input service and the output "talking" to each other giving a continuous loop. If you have enough delays or latencies in the system, it won't sound like screaming or howling of normal bar or pub band feedback. The final clue was at 3:08 with that slowly decreasing ringy rumbly sound.

Sorry but I have dismissed this because it is not present on the monitored audio at the time of ripping but only after having been written to the hard disc.

You have playthrough selected so you can hear your work, but do you also have Overdub selected? That would be bad.

Yes I have overdub selected. Why is this bad?

You're not recording through your microphone by accident, are you? A number of posters did that by accident and the only way they caught it was the dog started barking.

No microphones; only one (analog) stereo ADC input and one (digital) serial output.

Are you playing it loud enough so the high room volume is moving the tone arm?

No, I am at low volume for exactly the reasons you stated. At high, read very high, volume I have no feedback.

You should be on headsets for sessions like this.

1000 hours of ripping rules out headphones.

All that and I can't figure where the computer connects. I read it four times and I can't visualize where the cable to the computer goes.

Apologies I will try again.
Most pre-amps have a tape monitor setting. This is normally used with 3 head tape decks so you can monitor what has been recorded on the tape.
For a 3 head tape deck you connect the pre-amp monitor out to the record input on the tape deck.
The playback head output of the tape deck is connected to the monitor input of the pre-amp.
I am using this set-up with the tape deck replaced with the following:-

The pre-amp monitor output is connected to the ADC input (the ADC is the RDL-ADC1)
The serial ADC output is connected to the PC
The tape head loop-back is performed by the play-through setting of Audacity
The Audacity output is converted to serial format and sent to a Beresford DAC
The DAC output is connected to the pre-amp monitor input.

As you can see I have replaced the 3 head tape deck with an ADC-PC-DAC set-up. As I have said, any feedback would be instantly audible at the time of recording.

S/PDif? Analog? Throw more description right there.

The ADC has a S/PDIF (Sony/Philips Digital InterFace) output. See link http://whitefiles.org/b1_s/1_free_guide ... s/h13f.htm
The ADC has AES and S/PDIF outputs and is a broadcast quality unit. See link http://www.rdlnet.com/product.php?page=506

To summarise: If there was a problem anywhere in the electrical set-up it would be audible on the speakers, just as in the 3 head tape deck scenario. The recording sounded perfect at the time of recording and yes, I did have the monitor selected. In fact, due to the work load I never change the set-up other than when I am testing Audacity and have to change the Audacity settings to force an Audacity crash.

@Steve:

There's an argument that I've had many times with many people, it goes like this:
They say: "Of course 24/192 is better, there's more "bits" so there is better amplitude accuracy and more samples per second so better transient response".
I say: "Not necessarily. Nyquist–Shannon sampling theorem tells us that frequencies up to half the sampling frequency can be reconstructed perfectly, The practical limitations of this being the steepness of anti-alias filters that can be manufactured to a reasonable cost. With modern digital filters, 44.1 kHz sample rate can in practical terms reproduce up to 20kHz audio bandwidth. There are no D/A audio converters currently available (at any price) that can accurately reproduce a full 24 bit resolution, beside which, 16 bit has a noise floor some 90 dB below full-scale. Yes there are some marginal benefits of going above 16/44.1, but there is also a trade-off. Above 22 bit, any additional bits are irrelevant because current state of the art electronics are only accurate to 22 bits, so any bits beyond 22 produce only "noise". Similarly, beyond about 80 kHz sample rate there is no additional information within the audio frequency band that can be gained."

Hej Steve I can support you on this and agree with everything you have said and that deservers a I think I may be the only one that has agreed with you on this point and I personally cannot hear any difference between an original and the recording captured at 16/44 from an a/b test were I was selecting the a/b. Not a blind test so I could easily say oh yes one is better but no chance. No audible difference, to my ears, between the original and 16/44 capture. I have also listened to commercial LP's and CD's 16/44 of the same performance and the difference is significant. It is not the CD is inferior it is the CD 'Master Recording' is an inferior mix. Then, with an a/b test the wrong conclusions are drawn. Why after all this, you may ask, do I insist on 24/192? Read on.....

However, there are significant (and please to not ask me to go into significant in this forum, I do not wish to get banned like others) benefits if you are post processing i.e. many stages of filtering. As you may know, digital filters consist of multiplication and summation. If your work is recorded at 16/44 and past through many stages of multiplication/summation, you will have problems especially if the filters are brick wall low pass. As I said I agree with everything you said and at my age, I would begin to suspect good (high bit rate) MP3 is more than adequate but as raw audio which has to be post processed, this is a different matter. There has to be a very good reason why audio recording studios work in either 24(32)/192. As you have previously pointed out, 32 bit floating point is 24 bit data + 8 bit mantissa. If my words are wrong it is now very late....

It is now very late and I am too tired to look in detail at the spectrograms you have generated though I am pleased you analysed my waveform. I take it you have analysed my waveform, please correct me if I am mistaken on that assumption. I must ask you the same question I asked Koz, "Why is this distortion so easily audible on replay from the data on the hard disc and was not audible at the time of recording?" Are you really suggesting that my hard disc is too slow to take the data rate I am recording at? The RAM is obviously fast enough because of the Audacity play-through. I am at a loss to explain this one other than suggesting Audacity writes. I have just recorded and played back two minutes of music at 24/192 and sounds perfect (audio cache was disabled) and my really really slow Celeron XP has no problems at 24/96. Just maybe a one off again on my Win7 system

otwo_pipes wrote:However, there are significant (and please to not ask me to go into significant in this forum, I do not wish to get banned like others) benefits if you are post processing i.e. many stages of filtering. As you may know, digital filters consist of multiplication and summation.

There most definitely are benefits to processing in 32-bit float format, that's why it is the default in Audacity. I would definitely recommend that you set the bit format in Audacity to 32-bit float (Quality tab in preferences).

An issue that I really don't want to bring up (again), but it is relevant, 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). Does it make a difference to the recording? Yes, but not very much, it means that there will be digital noise at a level 96 dB below full scale.

Yes, the screenshots in my last post are from a "good bit" of your posted recording,

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.

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 Playthrough and not simply looping the output from its S/PDIF input? If it is using the Software Playthrough then there should be a noticeable delay between signal in and signal out, 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?

I do not wish to get banned like others

Which others? I can only remember one banning in a very long time, and that wasn't for discussing the significance of a position or technology. You will get quickly banned if you insist on selling us male enhancement products....

Since I couldn't exactly follow the signal flow at the computer, I'm just guessing based on what it sounds like. You can override feedback with musical volume depending on what's unstable and where. It's still perfectly possible that you're listening to a carefully prepared monitor feed during capture divorced from the show going onto disk. Macs have two Playthrough options, so it's not chiseled in stone that there's only one correct one.

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 Playthrough 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.

*** The serial ADC output is connected to the PC
The tape head loop-back is performed by the play-through setting of Audacity
***The Audacity output is converted to serial format and sent to a Beresford DAC

That's the part I was looking for. So it's S/PDIF in and out of the computer. Most machines won't do that, so you have a higher end soundcard?

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?

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.

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.

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.

Reading back through this. Only one song (so far) is affected, right, after hundreds of hours of transfers? Have the drives filled up enough to slow down past the point of accepting fast data? You didn't get drive errors right? I can't find where you said you're using SSDs.

I would expect data errors to show up as noise and trash, not as orderly pulsing singing and then slowly declining science fiction music. I would also expect something to care very much if you were generating enough errors. So you're probably not.

I have an SME arm on an Empire belt-drive.

separate power amplifiers and speakers

What and by whom?

Koz

Nobody asked. Is the song broken exactly the same way each play? Koz

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/Ju ... eader-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

@Steve

What seems to have happened here is that a couple of binary "1"s have come out as "0"s (or vice verse).
This particular glitch is hardly audible, but it's an indication that there are data errors, which is an indication that the hardware is struggling to keep up.

I find it interesting that a couple of binary "1"s have come out as "0"s which I agree with however, I am not sure I agree with the statement the hardware is struggling to keep up. More in the next para.

I've no idea if it's the sound card, the S/PDIF, or somewhere else in the system, but you are stressing some part of the system and there are a lot of data errors.

For the very small glitch we seem to have corruption (or whatever) only on the LSB's. That in itself is very interesting. Why only the LSB's, random errors should affect random bits equally therefore I would expect something far more serious, FS spikes are not out of the question here or maybe distortion similar to the severe audio distortion in the section section I posted rather than just the LSB's. Maybe the hundreds of small errors are either due to timing on the serial link, thereby pointing to the S/PDIF interfaces on the ADC and sound card, or the 24 bit to 16 bit truncation process. I would expect you to rule out the truncation process but we have to test to be sure before we can rule anything out.

I'd suggest that you try making some recordings with exactly the same set-up, but lower the data rate. Try doing some test recordings at 44.1, 48, 96 kHz and 16, 24 and 32 bit (or whatever options are available).

I have ideas on to how to test to hopefully find the root cause of the distortion. Could you please assist me by directing me to a tutorial showing how you produced the spectrograms so I can analyse the results of my tests. If you have a document on how to analyse the results of the tests maybe you could froward the document to me. Many thanks in anticipation for saving me some time here (I know I know, RTFM but time is something I do not have with this ripping so lets try to be efficient with what time I time I can devote to testing)

Ensure that the sample rate is set the same throughout the system (the A/D, S/PDIF, Windows settings and Audacity).

I do have everything set to the same sample rate and bit depth but thanks for the reminder