LP Rip with Distortion at the end of side one

Audacity 3 Help Forum Windows
1

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

2

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

3

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:
firsttrack000.png
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):
firsttrack001.png
That red vertical bar shows the frequency representation of that glitch.
Now lets zoom out a bit further:
window000.png
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).

4

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_guides/fg1mt/pgs/h13f.htm
The ADC has AES and S/PDIF outputs and is a broadcast quality unit. See link HR-ADC1 ‐ Analog to Digital Audio Converter

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.

5

@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 :slight_smile: 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 :frowning:

6

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?

7

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

8

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

9

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 :slight_smile:

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

10

@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) :slight_smile:

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

11

I have just posted:-

I have heard distortion when I started ripping, not severe distortion but certainly audible, just like sibilance. Not knowing what to do I just pressed Audacity Stop followed by Record and the sibilance disappeared. I do not know what this says.

and in the post entilted ‘Occasional Noise’
@sombunya:

Anyway, I was digitizing a vinyl record and I noticed about 3/4 of the way through the record the sound was terrible. My best description would be it sounded like loose connectors on my cartridge, although I’ve never really experienced that particular problem. Without stopping the record I stopped the recording process, went to “edit” and undid the recording, hit the record button and it started recording again, with perfect sound.

This is EXACTLY the same comment I have just posted re stopping and re-starting the record. Maybe we have a real problem with the record process in Audacity v2xx. I think you are far to quick to blame USB whereas I am now pretty certain there is an underlying problem in Audacity. Just like Sombunya I am using the meters to monitor the audio amplitude. 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. Originally I put this down to my pre-amp not being as good as I had thought (jeez, and ex HW engineer and I blame a very good pre-amp) however, I have run the same test with Vinyl Studio and I do not see anything on the VS meters which go to -100dB (and I do not hear the sibilance either). When I play a recording of an LP, captured using Audacity, in Vinyl Studio I see very similar meter levels with both sets of meters so I have no reason to doubt the accuracy of the VS meters. It seems to me Audacity is generating the -55dB noise, in my set-up as stated by Steve:-

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 now believe these errors are generated by Audacity and I do NOT have any USB connections in my system. I am still open to be persuaded otherwise but now, with two posts having similar problems especially regarding the severe noise in the middle of the capture, it may take some convincing. Please note, my first port of blame was with my pre-amp and not Audacity.

If you guys are interested then I can make two recordings, one from Audacity and the other with Vinyl Studio with no input and upload the recordings for you. Just let me know what you want from me. I am quite prepared to work with you if you wish. Sorry guys but I am now convinced this is an Audacity problem.

p.s. Vinyl Studio has its own set of problems which I why I opted for Audacity.

12

Wrong person. that was me :stuck_out_tongue:

Re. Windows recording always 16 bit:
http://audacity.238276.n2.nabble.com/24-bit-recording-on-Windows-td2505042.html#a2505042

For what it’s worth, I think that PortAudio may now be able to handle >16 bit data from the Windows sound system (the Portaudio people have certainly been working on this). but as far as I’m aware Audacity does not currently use a recent enough version to take advantage. It will eventually filter through, but there are always stability risks when upgrading to bleeding edge libraries.

It doesn’t as far as I’m aware.

  1. because it makes processing far more accurate (virtually no “rounding” errors)
  2. because Audacity works internally in 32 bit float format, so if the audio track is 32-bit float format, processing is done without any format conversion.

As an extreme example, try making a 16 bit audio track, amplifying it by -90 dB, then normalizing it to 0 dB.
Repeat the test using a 32-bit float format track.

The problem/limitation is between Portaudio and the Windows sound system.

  1. the issue does not affect imported data, only “recorded” day (on Windows).
  2. the issue does not (as far as I’m aware) affect Linux or Mac OS X.
  3. Audacity has the capability of recording 16/24/32 bit data. The problem is that when recording on Windows with WDM drivers, Audacity does not receive data in higher than 16 bit format.
  4. 24 bit recording works with ASIO drivers (though Audacity ships without ASIO support due to licensing issues).
  5. The 16 bit limitation will hopefully be resolved in the not too distant future. Audacity is ready when the problem is resolved,

It’s a limitation between Portaudio (which Audacity uses to access the sound system) and WDM drivers.

Current versions of Windows use WASAPI (About WASAPI - Win32 apps | Microsoft Learn) which does fully support higher bit depths, but for several years WASAPI drivers were so horribly buggy that it was not really practical for software developers to support it. The benefits of WASAPI are starting to come through now and will eventually benefit Audacity users, but not quite yet.

That sounds pretty conclusive, but sadly I don’t have an answer to what is going on. :frowning:

USB is notorious for this type of problem, which is why musicians and audio engineers tend to favour PCI or Firewire.
What is startlingly unusual about your problem is that you are not using USB.
S/PDIF and PCI should be extremely robust and reliable.

Other than with USB or badly damaged hard drives, data corruption is extremely rare (virtually unheard of).
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?

13

In the release notes (included with the release version of Audacity, displayed during installation, and also available on-line, but rarely read by anyone :confused: )

“(Windows) Recording at 24-bit quality or higher isn’t possible even with devices that support it due to current limitations in PortAudio.”

14

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.

15

It’s not LSB.
LSB errors are to be expected, but the error shown is very much greater than LSB (as shown by the dB figures in my earlier post).

The spectrograms were generated as here: http://manual.audacityteam.org/manual/help/manual/man/spectrograms_preferences.html
I used a window size of 128 for more accurate time resolution.

The numerical data came from the new “Sample Data Export” tool: http://manual.audacityteam.org/manual/help/manual/man/sample_data_export.html

16

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 :slight_smile:

@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 :slight_smile:

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 :slight_smile:

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 :frowning:

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.

17

You appear to have made up your mind, and I am of no mind to argue.

18

@Steve:

You appear to have made up your mind, and I am of no mind to argue.

I am not arguing; It is called a technical discussion.
I have backed up my opinion with the view of a respected (by his industrial peers) colleague who, I think, happens to be a damn good engineer. I could not know what he would say. He could have told me I was utterly wrong and you guys were correct. I would have posted his opinion irrelevant of what he had to say on this issue. The only way to solve technical issues is to be completely open. When we worked together at TI we did not always agree but we always discussed and eventually resolved the issue to the benefit of all concerned.

I spent a great deal of time trying to formulate a balanced opinion.
I have offered you independent and impartial assistance which would not have been biased as you appear to be assuming.
You however respond to the considerable time I spent trying to assist by issuing a one liner dismissal and close the issue. That is okay by me.
During my career, many years of which I have been engaged as as a freelance consultant, I have made many seemingly outrageous statements to companies on technical issues. A classic was were I was engaged to resolve a hardware issue. After a few weeks I informed the company I thought the fault was a software issue and predicted the root cause as byte overflow due to a mathematical operation. No-one, but no-one, believed me however, as the unit was being deployed in a remote and inaccessible place the technical director decided he could not take the risk and so, due to pressure of work, they employed a contractor. Within a week the contractor had found the software issue I had predicted; the byte overflow was due to a wrongly coded multiplication operation.

At the time of writing I see Sombunya has not updated his ‘Noise’ post see: occasional noise whereby you state his distortion is due to the notoriously bad data corruption of USB links. I pointed him in the direction of this post. No response; maybe here is another potential customer you have lost!

In another thread on this forum, see: Audacity Recording Freeze at 38m 47.5s: Win7 we have been discussing Audacity Freeze, which again, you have not been able to reproduce. What is your solution? Remove the offending code from Audacity without resolving the underlying issue. Problem solved that is until the offending error raises it head in another area with further consequences. I have been there, done that, seen it all before. Be careful guys, life does not get better by burying your head in the sand.

Audacity is your product, it is your choice and, I fear, this will certainly be your loss. You have a great product. It is very straightforward and quite intuitively easy to use. Technically, I think Audacity is good. I am a degree (I know, a degree is just a piece of paper) qualified engineer with over 30 years experience in the industry working as a design engineer in fields as diverse as power generation, broadcast video, military communications, radar and mobile telecomms involving both base station and handset design. I think you can agree this is quite a varied and interesting portfolio. Anyone that knows me will realise I do not give compliments lightly and yet I have praised Audacity. I have only met a handful of damn good engineers in my 30 odd year career so it takes a great deal to impress me.

I have seen somewhere on the web you guys are contemplating turning Audacity into a commercial venture. Best of luck folks, and I really meant that, because the real world is damn hard nut to crack.

19

I think rumour-control needs a reality check here - not under disussion or even consideration AFAIK

The problem with USB is that it sometimes struggles to keep up wth the exacting demands of recording digital audio, particularly on slower older processors - recording the audio is absolutely real-time any interrupt and audio gets lost - and in extreme cases the USB device appears to go AWOL and just generates “noise” until the whole system is reset.

I personally have used USB devices with Audacity from 1.2 4 to current to transcribe hundreds of LPs and tapes, initiallly with a USB TT which was rubbish (electronics good but platter lousy with too much wow&flutter) and latterly withe an ART preamp and an Edirol UA-1EX USB soundcard with my old Technics TT and SME 3009. These have produced excellent recordings throghout with no USB or Audacity problems (and I listen on high-end kit QUAD electrostatics ESL-57’s and QUAD pre and power amps).

I originally had my Edirol running in 16-bit mode with standard Windows drivers - it’s now running in 24-bit mode wirth Edirol’s own drivers (Gale asked me to do some testing this way - and yes I know Audacity/Portaudio is downsampling to 16-bits).

One thing I have noticed from several years of reading and working on this forum is that folk who deploy high-end-kit running at extreme settings seem to be the folk that often post issues - those who stick to industry “standard” bitrates etc. for CD/DVD production seem to suffer less of these problems.

WC

20

VinylStudio ( http://www.alpinesoft.co.uk/ ) apparently records up to 32-bit 192 kbps. What quality do you use in that program?

Sombunya doesn’t say what quality he is recording at. He does not say if he is using software playthrough, but using playthrough (bidirectional transfer) over USB is responsible for a lot of these types of problems. Sombunya seems to mostly get the problem when he monitors first.

I know you (Dennis) are not using USB but I guess if you are not present during any recording you could try not using Software Playthrough. Koz I think told you to stop using Overdub, though that should not be relevant unless you are recording with another track already present.

To me the most likely reason is the very high sample rates combined with some event when the computer has to do some short intensive task. Possibly this is more likely to happen if you are using playthrough. Possibly if Vinyl Studio does not distort, it may be that it is a lighter footprint application or doesn’t write blocks every few seconds. 1.2.6 may be sufficiently “lighter” to record properly under circumstances where you are at the point of tipping over the edge into distortion to the high sample rates/bit depth.

I don’t recall, but is there anywhere else in your chain where you are using a different sample rate and bit depth than you are setting in Audacity?

Are you choosing Windows Direct Sound as Host in Audacity Device Toolbar? DirectSound should have much lower latency than MME on XP.




Gale