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/Release_Notes_2.0.0#Playback_and_Recording
“(Windows) Recording at 24-bit quality or higher isn’t possible even with devices that support it due to current limitations in PortAudio.”
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.
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
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/firewire_usb_technote.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.
You appear to have made up your mind, and I am of no mind to argue.
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: https://forum.audacityteam.org/t/occasional-noise/25186/1 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: https://forum.audacityteam.org/t/audacity-recording-freeze-at-38m-47-5s-win7/25136/1 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.
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
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
I think rumour-control needs a reality check here - not under discussion or even consideration AFAIK
Ok and out of interest, you are only the second person I have seen using ‘AFAIK.’ The first was my sw guru colleague.
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.
Interestingly, I seem to recall Sombunya only had to stop the recording (I only have to pause) and re-start to remove the problem and not reset his system.
My sw guru has been reading this discussion and, completely without provocation, wrote the following:-
"In case of a HW bit error rate of 10^-9 for a 192kbps@32bit stereo (extreme case recording) you would get an error for every 81sec (as total audio bitrate is only like 12Mbps and not 480Mbps) and not every 2nd second as you mentioned in the thread, but it’s just a minor detail => What you see is certainly not USB HW bit errors I’m 99% sure.
In case SW can’t follow the speed, I would as well find it very strange. After all 12Mbps is nothing on a newer PC. (like 2.5% USB utilization). I recognize the hard real time requirement and being coded wrong it could be a problem, but I find it strange to believe. A 15fps VGA Web camera would need 15640480*8 = 36Mbps (just as an example)…
Even in case of storing data to USB hard drive connected to same USB Host controller, it would still only yield like 5% total USB but utilization with 2.5% being able to get moved to when it would fit in time… As you mention as well storage to Harddrive is guaranteed to be 100% fail safe (as it’s bulk). Only the potential isochronous input won’t be…
The above has been copied verbatim. I think on this point we ought to agree to differ. There are a number of persons that will agree with your statement that USB causes problems and FireWire does not even though they are both isochronous and, give or take, operating at similar speeds. Having designed USB interfaces and been responsible for stress testing to prove hw design and PCB layout, which does have consequences at 0.5GB/sec (the edges are much higher frequency than 0.5GHz), it will be extremely hard to convince me. My sw guru was my cohort when we were working at TI in Denmark, hence the understanding between us. I do not dispute that you have seen problems with USB interfaces but I do not believe for one moment Sombunya’s problem is the data rate on the USB link. As I said, I think we ought to let this one die a death, especially as I am not using USB. If you wish, I will allow you the final word I can’t be any fairer than that can I
and in effect you almost seem to be agreeing with me with and I quote:-
I personally have used USB devices with Audacity from 1.2 4 to current to transcribe hundreds of LPs and tapes, initially with a USB TT which was rubbish (electronics good but platter lousy with too much wow & flutter) and latterly with 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).
You have ripped hundreds of albums using a USB connection and I assume, though you never stated, did not have any problems. Surely if USB is such a big problem you would have had many many problems with rips going wrong or is it you did have problems and have not reported these problems in this post?
You also state:-
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.
and I have to wonder why as well; I believe I now know the root cause of the problem or at least a strong pointer to the problem in my system but more on that later…
@Gale:
VinylStudio ( > http://www.alpinesoft.co.uk/ > ) apparently records up to 32-bit 192 kbps. What quality do you use in that program?
I am making all my rips at 24/96 and for testing purposes I use 24/192. I have run Vinyl Studio on my, very slow, XP system capturing audio at 24/192 until the 4GB file limit is reached. I have run three successive tests and there was no problem. I can run more tests, and also run the same tests on my Win7, if you think this can be of any benefit. The 24/192 is only set in sw because, although my ADC box will do 24/192, I have not succeeded in getting the S/PDIF interface on my M-Audio card to lock to the higher sampling frequency. The M-Audio card seems to divide any sample rate above 96kHz by 2. I could use the 24/192 card to generate samples at 24/192 if you think this could make a difference though I do not see how running the sw at twice the sample rate of the ADC box could be a problem.
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.
I am always present during recording or at least the recording process is always within earshot so I do not wish to turn off play-through especially as I would then have to listen to everything ripped later. I have about 900 albums to rip in 90 days. This is quite a task ahead so I have little time for repeat playing or ripping.
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 agree, it seems as if something is overloaded but the rate is not so high for hardware or software so I am not sure I can agree with you. There is enough going on here to leave me very puzzled.
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?
No, when I am recording everything is set identically. I only use a higher sample rate for testing and never a lower rate. My tests have shown virtually identical 2:1 ratios when I halve the sample rate.
Are you choosing Windows Direct Sound as Host in Audacity Device Toolbar? DirectSound should have much lower latency than MME on XP.
I have been using the default which, I believe is MME.
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.
Agreed, it seems like a work loading and task conflict. In the following paragraphs I would hope you can see why one has to keep an open mind when trying to diagnose problems.
Ok, now to the crux of the problem, this is part of the email I sent today to my sw guru:-
I have changed to Vinyl Studio and no problems, that is, until a couple of hours ago i,e, the rip of my 5th album today, prior to this I had ripped 24 albums with Vinyl Studio. On the 5th album there was severe distortion at the start of the recording, press pause, and start and everything is okay. Why one asks. Hopefully the reason is simple. Last night I changed my Audio card I use for the S/PDIF interface back to the 24/192, I am using the 24/96 card for testing on my XP system. I suspect the S/PDIF interface, RAM or some other hw, on the 24/192 card is not behaving properly. I not only changed to Vinyl Studio when I had the distortion, I also changed my hw set-up from the S/PDIF interface using the 24/192 M-Audio card to one using the 24/96 card. I know I know, one change at a time. So now I am back to ripping using the 24/96 card as the S/PDIF interface. However, our discussion regarding the USB distortion, which is were we came in, is still valid. It just goes to show you have to keep an open mind on these issues. I was convinced this was a sw issue but now it seems, almost certain, there is a problem with the S/PDIF interface/hardware circuitry on the 2nd audio card. I also had other recording issues today whereby the record function did not work i.e. Vinyl Studio was not communicating correctly with the sound card drivers and I had to re-boot my Win7 system + the S/PDIF interface lost sync on two occasions after stopping a rip which required the M-Audio interface and Vinyl Studio to be restarted. (The previous sentence has been added for completeness.) I have not seen these types of error before in all of the rips. Problems problems and no test gear to be certain as to the root cause.
I was so surprised at the distortion I did not think carefully and I failed to record the sample, actually I overwrote the sample. In Vinyl Studio you have to give the file name at the start of the rip. I do not know if the distortion has occurred at capture, replay or even in the ADC or DAC boxes.
I do not believe Audacity could have random data capture buffer errors so unfortunately that only leaves an error on my part. Put into words of one symbol, I must have missed the distortion when I was monitoring the album rip. How, why, I could have missed this I have no idea. I still have doubts that I could have missed distortion that is so bad. Maybe the monitor function was switched off but I do not think this was the case. Suffice to say I cannot give any concrete root cause but I no longer believe Audacity is at fault unless of course there is a common function or library that both Audacity and Vinyl Studio are using. I still have a long way to go with my rip so there may be more progress…
There are only two good things that may have come out of this discussion:-
i) It is most important to keep an open mind
ii) At the present time-slice my noise seems to be caused by a faulty audio sound card; it will be interesting if I have another occurrence of distortion. Now that would really put the cat amongst the pigeons, as we say.
I will have to make the appropriate connecting cables and then I will start to rip using the suspect, 24/192, M-Audio card do digitise the audio thereby removing the ADC box and S/PDIF input interface from the data collection path. This is not a 5 minute task as I do not have the appropriate connectors to make the required cables so please be patient and of course, I may have to rip a large number of albums to have a high confidence level.
Let me ask a question, how can the identical symptoms that both Sombunya and I have experienced be caused by USB in his case and a hardware sound card in my case? The identical symptoms was described by Sombunya as if the LP was a bad pressing, static, loose connections etc. and sibilance by myself. These errors were resolved by breaking the audio capture process. Using both Audacity and Vinyl Studio, my error was resolved by pausing, maybe Sombunya stopped and restarted his recording session. Something still does not seem correct here but what, I do not know.
If I have any news I shall update this post.
Yes I kind of am agreeing with you, I agree that with a good USB cable, a good USB socket, a good USB soundcard (with a good ADC) and a resaonably sized and fast computer (one that is not engaged on other tasks) then the USB should not be a problem. And certainly that has been my experience.
The reason that I wrote about the problems with USB comes from the experience of working on this forum where we have fixed issues for folk by:
- using a different USB port
- replugging the original USB port
- replacing the USB cable with a better quality (and sometimes shorter one)
- not chaining USB cables together (though I have done that myself successfully)
- getting a better USB soundcard (the Griffin iMic seemed to be particularly problematic at one time).
- not using a USB hub
- a combination of the above …
One thing that I do do to avoid having to unplug and re-plug my audio USB all the time (with the objective of trying not to introduce noise/bad connections) is I purchased a three-way passive switch (SkyTronic, nice low noise-floor). This is fed from my: TT+pre-amp, FM Tuner, tape-deck. It then is permanently plugged to my Edirol soundcard which in turn is permanently plugged to my desktop recording PC (which is used mainly only for dedicated recording/editing).
But like you I too am puzzled that both you and Sombunya seem to be experiencing similar symptoms and with similar resolutions with abd without USB
WC
That may be slighly problemmatical. I seem to recall from reading previous threads that what Audacity feeds you through Software play-through is the signal that it is going to record, not the signal has been recorded. I.e. it is not operating like a 3-head taperecorder.
That’s ambitious, good luck - I’ve managed about 500 in 5 years (and I’ve still got one boxful of Mrs. Waxcylinders LPs to work on …
WC
otwo_pipes wrote: I am always present during recording or at least the recording process is always within earshot so I do not wish to turn off play-through especially as I would then have to listen to everything ripped later.
@Waxcylinder:That may be slightly problematical. I seem to recall from reading previous threads that what Audacity feeds you through Software play-through is the signal that it is going to record, not the signal has been recorded. I.e. it is not operating like a 3-head tape recorder.
I was only using the 3 head tape recorder as a simplified example so people that could not understand my convoluted description could replace one, easily understood block, with my complex set-up. It would be unique if sw could replay the open file that is being written to disc. I did realise the replay is from RAM and not the hard disc so I hope I did not miss-lead any of our readers.
otwo_pipes wrote: I have about 900 albums to rip in 90 days. This is quite a task ahead so I have little time for repeat playing or ripping.
@Waxcylinder:That’s ambitious, good luck - I’ve managed about 500 in 5 years (and I’ve still got one boxful of Mrs. Waxcylinders LPs to work on …
Very ambitious but Thailand and SE Asia will not wait. It is, come October and I am off for maybe 5 or 10 years. I want to have my music collection with me so, with dedication and luck, maybe this is achievable. I can easily average 9 albums per day as long as I do not have any hiccups like today. The dreaded buzz came back but somehow it was different. Most confusing as it was present on live and monitor, hmmm thought me. To cut a long story short this buzz was eventually traced to the mains socket of the cable that was powering my XP system. This was a PC that was switched OFF, off meaning no current but the socket was causing a very low level buzzing interference on my audio system. The buzz was so low that it was only easily audible with the amplifier at full volume and that is 50 watts RMS per channel. How did I find the root cause, I flipped the mains switch I have in series with the power lead to the XP and almost took my speakers out. The XP PC was not in standby because the series mains switch was off; the current really was zero but the socket was arcing and causing the buzzing interference on my stereo system. Moral of the story, keep an open mind
Yes I kind of am agreeing with you, I agree that with a good USB cable, a good USB socket, a good USB sound-card (with a good ADC) and a reasonably sized and fast computer (one that is not engaged on other tasks) then the USB should not be a problem.
Very good; we have some agreement at last and that can only be good for this forum. No-one should dispute your points 1-7, I certainly do not. The only point I was trying to make, in the previous discussion, is you should not immediately decide it is a USB issue without including other possibilities as well. It is better to have a balanced response than to hi-light only one issue which may, or may not, be the root cause.
But like you I too am puzzled that both you and Sombunya seem to be experiencing similar symptoms and with similar resolutions with abd without USB
Yes puzzling but that does not mean it cannot be resolved especially as I pointed out, I can re-configure my system hence I can test and rip at the same time then report any ongoing problems.
Hey O2P,
I’ve just notice that Brain Davies has just released a new piece of software that may help you speed up your workflow.
ClickRepairRT is a real time version of CR that enables you to process thge capture signal as it passes through. I’ve no idea how to route the output to Audacity - but it’s worth a try. CR-RT is bundled with CR so if you download the latest version of CR from Brian’s site you will also get CR-RT.
Do let us know how you get on if you try this.
WC
Thanks for the info but my workload with ripping is so onerous I decided a long time ago to only rip. I can easily process with CR, or any other sw, when I am based in Thailand after all, I will need something to do
Thanks for the info; it is much appreciated.
@'Steve:
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.
The important section in the quotation is, “(the library that acts as an intermediary between Audacity and the computer sound system)”
Does the 16 bit PortAudio limitation apply when the ADC is an external box, as in my case? I am not, as far as I am aware, using the computer sound system because the external ADC interfaces to Audacity via S/PDIF. Audacity sees the M-Audio driver interface because I can select the S/PDIF input.
Does anyone know of a good link whereby I can read about the data format of the digitised audio when stored to the hard drive as a WAVE file?
Do you have a link to the format of the data file Audacity writes to the hard drive when storing data in WAVE format?
I have tried this link:-
https://ccrma.stanford.edu/courses/422/projects/WaveFormat/
but I cannot completely decode the audio data. I am trying to see if my data is in 16 or 24 bit format. I am using a Hex editor to look at the WAVE data file.
Thanks.
As far as I’m aware the limitation applies to any kind of sound card on Windows when using the version of Portaudio that Audacity currently uses when using Windows drivers.
24 bit capture is, as far as I’m aware (subject to hardware, drivers and making the correct settings) available if ASIO drivers are used, but due to licensing restrictions Audacity cannot be distributed with ASIO support. ASIO support may be added if building Audacity from the source code for personal use only. (details here: http://wiki.audacityteam.org/wiki/ASIO_Audio_Interface )
I’ve read encouraging reports about Portaudio suggesting that this limitation will not be an issue in later versions so we can look forward to full 24 bit support on Windows in the future.
As I understand it, we have to implement WASAPI support to get 24-bit recording on Windows, not merely update PortAudio.
The other strong reason to implement WASAPI support is that it should provide a native way for Audacity to record streaming audio irrespective of the sound device.
Gale
@Gale Andrews:
As I understand it, we have to implement WASAPI support to get 24-bit recording on Windows, not merely update PortAudio.
In which version of Audacity is WASAPI incorporated?
It isn’t yet: “we have to” - future tense!
Ooops!
Thanks for the update