LP Rip with Distortion at the end of side one

[otwo_pipes]

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.

[steve]

@Gale:
An issue that I really don't want to bring up (again), but it is relevant,

Wrong person. that was me

Re. Windows recording always 16 bit:
http://audacity.238276.n2.nabble.com/24 ... l#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.

i) Where does it say in the manual 24 bit Audacity is 16 bit + 8 bits of zero padding

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

ii) Why do you recommend 32 bit if Audacity is only receiving 16 bit?

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.

iii) What is the purpose of having 24 and 32 bit settings if Audacity is only receiving 16 bit data?

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,

Is this an Audacity or Windows or Windows Interface limitation?

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

Current versions of Windows use WASAPI (http://msdn.microsoft.com/en-us/library ... 85%29.aspx) 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.

If I turn Audacity play-through off I hear nothing
....
and there is a noticeable delay.

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

I think you are far to quick to blame USB

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.

whereas I am now pretty certain there is an underlying problem in Audacity.

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?

[steve]

i) Where does it say in the manual 24 bit Audacity is 16 bit + 8 bits of zero padding

In the release notes (included with the release version of Audacity, displayed during installation, and also available on-line, but rarely read by anyone )
http://wiki.audacityteam.org/wiki/Relea ... _Recording
"(Windows) Recording at 24-bit quality or higher isn't possible even with devices that support it due to current limitations in PortAudio."

[steve]

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.

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.

[steve]

For the very small glitch we seem to have corruption (or whatever) only on the LSB's.

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/h ... ences.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/h ... xport.html

[otwo_pipes]

Steve: Many thanks for your input, most detailed and informative, and for the links. It really is very much appreciated. I have not looked at the links yet as my time today has been spent researching this reply.

@otwo_pipes: I think you are far to quick to blame USB
@Steve: USB is notorious for this type of problem, which is why musicians and audio engineers tend to favour PCI or Firewire.

Continue reading for a full discussion of this very point after I have answered all of your questions. As a clue, it has all to do with Isochronous transfers

@Steve: Your case is most puzzling.
Is this problem occurring when you are recording to RAM, or does it also occur when recording direct to disk?

As you know, I have continuous, and repeatable, recording freezes whenever I write to RAM so my rip set-up has audio cache off therefore I cannot answer your question. I could make an educated guess and state the audio cache would not make any difference. Also, I do not think this error is repeatable, i.e. only sometimes, maybe once or twice a day, do I have the sibilance so this one will not be so easy for me to answer however, having heard the sibilance when in monitor mode I think we can rule out the error being disc writes however, I am still convinced the cut I up-loaded is from a hard drive write data corruption so we could be looking for more than one error. Believe it or not the end of the cut is a drum rap and I was playing air drums, much to the missus' amusement. I could not have missed this distortion hence the reason for my suggesting more than one error. Time permitting I can try ripping with audio cache enabled/disabled but I suspect this quite unlikely due to time limitations.

@otwo_pipes:In Audacity, I see the meters hovering around the -55dB mark with no input, no input means no album playing on the turntable and not an open circuit.
@Steve: That shouldn't be happening. With my cheap Behringer USB sound card connected to a Cambridge Audio line output, the noise level with no no signal is around -80 dB peak. You should be getting better than that with your setup.

Unfortunately I am not seeing this. Investigations have shown I have some low level mains hum but I have not had time to isolate the source and my pre-amp has a switched gain for my MC cartridge. My noise level with the switch in the MM setting is about -75dB. Maybe I should invest in a step-up transformer.
Out of interest, what errors do you see on your Behringer USB sound card?

@Steve: What is startlingly unusual about your problem is that you are not using USB.
S/PDIF and PCI should be extremely robust and reliable.

Nevertheless we have an issue and I think I have covered my opinion as to the root cause in one of the previous paragraphs. It would help if I could make the issue repeatable but this one is not so easy and, as I said, I have had to stop using Audacity for ripping.

Regarding the USB issue I have sought a second technical opinion. The SW engineer I approached is a colleague that I worked with at Texas Instruments in Aalborg, Denmark. My work at Texas Instruments involved design and test of USB interfaces. My SW bud was the SW driver and USB reliability guru. What he has said is very interesting. From this exchange of emails, we have raised some interesting points and issues:-
I know data transmission used in certain cam-corder formats have a preference for FireWire due to transfer speed issues but I did not know there was a renowned USB reliability issue so I discussed this with my SW guru regarding USB data corruption.

> Some audio guys are telling me USB is renowned for corrupting data and that is why musicians use Fire-wire.
No – I don’t think so. I think it’s more related to history and traditions (as Firewire was at 400Mbps a few years before USB2.0 => USB was at 12Mbps which was too slow). This being said there are no CRC check on real time isochronous data transfers => Errors would pass just right through, but as far as I remember the same is the case for Firewire, and cable types, impedances, etc. are pretty identical, so I would expect HW error to be in the same level as well. This being said I think the Audio business managed to get some “higher quality stamped into the Firewire brand” compared to USB which is more consumer like… For transferring off line audio (files etc.) using USB bulk traffic there is always CRC check and no error would be allowed as SW will request retransmission in case of a detected CRC error.

There are two point here:-
i) File transfer will not have USB data corruption. This is borne out by the 3-4 TB external hard drives and the multi GB Flash drives. If there was data corruption during file transfers the external drives would in effect, be junk.
ii) Isochronous data transfer is prone to data transmission errors.

My colleague has confirmed USB, when used for real time audio transmission, may have data errors which is the very point you have been making all along. I must admit this has surprised me but there is nothing like reporting as is. However, he has also confirmed these errors are remote (and I quote from my SW guru, "HW errors for correction by SW are typical expected to be at a very maximum of 1 in 10^9"). We have a possibility of a bit error of 1 in 10^9 MAXIMUM. Okay, 1 in 10^9 equates to a 1 bit error at a repetition rate of about once every 2 seconds. Do you really expect to be able to hear a 1 bit error occurring at a maximum rate once every 2 seconds. You would have great difficult finding this one bit error in a manual search of a data waveform let alone hear it. (Think about the frequency content of a 1 but error in this data transmission. If you were felling really generous you could produce a data file with a 1 bit in 10^9 error and produce the spectrogram of this file.

This 1 bit error in 10^9 is not, and I repeat, NOT the continuous errors that Sombunya and myself have been experiencing. We had continuous errors until the record process was stopped and re-started. This has been preceded and followed by periods of no errors (apart form one day when I believe I had significant errors appearing as low level sibilance).

Can I say please guys, think about this carefully and consider the fact there may well be a fundamental underlying error in the data capture process of Audacity. You have a great opportunity, in two independent test facilities having the same error. Use this to your advantage. Unfortunately I have had to stop using Audacity as my audio ripping tool due to the severity of the error I have recently experienced. This in itself is very useful test input because now I am listening very carefully for any sign of sibilance. My rip today of 11 LP's, using Vinyl Studio, was faultless. As soon as I have a sibilance or distortion error using Vinyl Studio, I shall report in this post. Watch this space

You may find the following technical note, regarding a comparison between USB and FireWire, interesting:-
http://www.qimaging.com/support/pdfs/fi ... chnote.pdf

You may also find the following technical description illuminating, I sure did:-
http://www.beyondlogic.org/usbnutshell/usb4.shtml
the relevant section concerns the Isochronous transfer. You may well ask why am I emphasising Isochronous transfers to such a great extent; the answer is simple USB and IEEE 1394 use Isochronous serial data transfer mode. IEEE 1394 is the FireWire standard therefore both USB and FireWire, without error correction, using Isochronous data transfer mode are prone to error rates of 1 bit in 10^9 (Maximum).

This is another cut from my SW guru, talking about Isochronous transfer mode:-
"And just to be 100%. The 100% same problem goes for Firewire (in isochronous mode) (see: ttp://en.wikipedia.org/wiki/Isochronous), so Firewire and USB pretty much are expected to be as good or bad on this, but someone managed to brand Firewire being more reliable."
and this is his words and not mine

I thought I would seek and add an independent opinion from a SW developer who has worked with both low & high level coding in telecoms. His experience includes work coding USB drivers. His knowledge in this area is vastly superior to mine but he seems to echo the same feelings as I have regarding USB data corruption not being a root cause to the issues we are seeing.

I have to reiterate I am convinced this is not a USB error with Sombunya or a hardware error with myself but a SW error with Audacity. The problem you guys have is you cannot reproduce the same error, and I may add, I think you are a little too quick to blame USB for a lot of the ills. My experience is USB is pretty robust. Remember, I was the hardware design engineer for the USB interface on the development platform for mobile telephone chip set for Texas Instruments so I have experience of testing USB when re have ropey code and hardware

Maybe I/(and my colleague) am/are mistaken in my/our reasoning and the above argument is wrong but continuous audible USB errors; I don't think so. I think the evidence is beginning to show I am not mistaken but only time will tell.

[steve]

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

[otwo_pipes]

@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: http://forum.audacityteam.org/viewtopic ... ilit=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: http://forum.audacityteam.org/viewtopic ... 46&t=66431, 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.

[waxcylinder]

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.

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

[Gale Andrews]

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