I’ve read of others having static on recording, but it goes away when the file is exported. Unfortunately in my case it is still there after exporting and playing it in ITunes. I’ve exported to .aiff and MP3 with same results. I’m recording in Mono and at a 22050 project rate.
I’ve tried 2.0.6 and the nightly build of Jan 4th 2015. 2.0.6 was far worse.
On 2.0.6 it starts after about 5-7 minutes of recording speaking and is very much like static, but only occurs when there is speaking. When the recording is silent there is no “static”. I can see lots of little spikes when I spread the audio out. Most are only about 6 samples long.
On the nightly build of Jan 4th it was fine for about 50 minutes then started having issues.
I don’t know if this is related, but on both occasions I recorded another speaker with no problems at all. Immediately after that recording I saved the recording and selected close from the menu. After that I selected a new session. When I clicked on record to start the next recording Audacity crashed. I then restarted Audacity and did the recording that had the issues. Could the crash have left things in a state that is causing the problem?
I hope someone has some answers/work arounds as I need to do these recordings each week and I need an answer or else will have to find another recording solution. I’ll upload a short section for someone to see what I mean.
I’ve read of others having static on recording, but it goes away when the file is exported.
It’s possible to hear static and instability during the recording and have it turn out to be a playback problem. In other words, the show is being recorded perfectly OK, but the machine can’t play it back. You know this because the crackles happen in a different place every time.
You have an actual recording problem. Your export is damaged and you can point to each of the actual pops on the timeline.
Try posting another sound file. This time hum into the microphone at as stable a way as you can. This will save us having to dig each pop and click out of Leviticus to analyze it. I’m interested in seeing any repetition and which way they go when they do. The system will allow you to post a much longer sound file than you did, so do two passes, the second one at a different volume. mmmmmmmmmmm [pause] MMMMMMMMMMMMM.
I know you want to get this fixed, but please pay attention if you can make it worse. Any change in the performance is good data.
Have you messed with Audacity > Preferences > Recording > Audio To Buffer value? Default is 100.
It did work fine on Mavericks with 2.0.5. It would be a pain to go back on this machine, but I’m thinking I’ll record it on another machine in parallel using Mavericks and verify the difference.
I’ll mmmm into a mic as you say, but the problem hasn’t yet occurred in the beginning and in the one case it was after 50 minutes. I doubt that the mmmmmming into a mic would give any good data, but I’ll try. Remember that I recorded almost an hour of another message before the problem one without any issues. The issues only occured after the crash and restart of Audacity. One thought I had was to try recording a non-crucial source for a long time and see if I can find a definite pattern. If it only happens after the crash then maybe that would be helpful input also, yes?
Also I looked at the wave form more after my initial post and the spikes definitely are part of the noise, but there is also the noise superimposed on the audio where you can’t see any spikes.
“You said a scary thing. It’s usually a bad idea to “Y” cable a microphone. How are you going to dual capture?”
I’m recording via a lapel mic so have a line output from the receiver that I split. I’ve done the parallel recording before without problems when dealing with some issues unrelated to the current one.
I’m recording via a lapel mic so have a line output from the receiver that I split.
Perfectly valid. I was afraid you were going to try and split a dynamic microphone or something like that.
So you are in the camp of trying to make it worse. “I swear, Mr Mechanic, my car was making this noise yesterday…!!”
Rough to fix something that isn’t broken.
Do evil things. Fill up the machine. Run Photoshop (What’s the classic memory killer? Gaussian Blur?), an Excel Calculation and listen to an on-line video podcast — and make a recording.
If it’s digital stress, that should create layers of skipping, popping and trash.
We both know it’s not going to have any effect at all, but it will be very good to know that.
We need to be sure whether this is a recording issue or not. I’m not 100% clear it’s a recording issue.
If you never played the recording before exporting it, the playback “uninitialised buffer” bug that is fixed in the nightlies after 21st December could occur and you could definitely get crackle exported (even if the recording was perfect).
A good test would be to play before exporting. If you hear crackle in different places each time then as Koz says, that’s a playback issue.
Really I would try to test with the nightlies, not just because of the uninitialised buffer playback fix, but because there are some other Yosemite-specific interface and effects fixes. 2.0.6 does not officially support Yosemite.
Another obvious question is your use of 22050 Hz project rate in Audacity. Can you say what your recording device is (make and model number)? If it’s any kind of upmarket external device it will not be defaulted to 22050 Hz. It will absolutely be expecting 22050 Hz to be set for it in “Input” and “Output” in /Applications/Utilities/Audio MIDI Setup if your recording software is set to that rate. Mismatched sample rates are a primary cause of recording and playback issues.
Changing Audacity "Audio to buffer “might” help, but reducing the buffer usually only helps if it’s really a playback problem.
If this was in 2.0.6 it could be relevant, given this was a playback problem and not a recording problem.
It should not be relevant in the current nightlies.
I do significant editing and playing of the recording in Audacity before exporting so am sure it is not just a playback issue. I would be very glad it it was playback only, but it doesn’t seem to be so. The Crackle, once started, continues for the entire recording so isn’t just a momentary issue like system overload. On a particular recording it always starts the same place which is also evidence that it is on the recording and not just playback.
You raise an interesting point regarding the Midi settings. I have never touched them. Looking at their settings I find that the “hardware rate converter” is disabled and the input is 44,100. I’m only using Audacity for recording and the input to the computer is analog line-in so do the Midi settings make any difference? I’ve been recording using the 22050 only because that is the eventual sample rate that I have to end up with to post the file on-line and it takes less space in storage that way. I could record at the 44100 I suppose and covert it later if that was a solution to the problem.
You say that the crashing/restarting issue should not be relevant when using the nightlies. What could explain being able to record for 40 minutes with zero problems and then and hour later doing another recording with the same software and hardware setup and no changes made between times except that Audacity crashed when trying to start the second recording so it was restarted and the second recording was messed up? This has happened two weeks in a row with the first time using the Jan 4th nightly and this last week using 2.0.6. I’m not saying that you are wrong, just trying to understand what would trigger the issue after that long a time of working well.
I’ve been trying to break it most of the morning. I did download the Jan 10 nightly and used that and can’t seem to break it so far. I loaded the computer up to the max with recording a video from my camera via iMovie, recording with Audacity, starting and running a Virtual Machine of Ubuntu, doing other things with FireFox etc. Memory was more than used up and CPUs maxed out and no issues cropped up.
Audacity did start crashing when it was running and I either hit stop or one time the mouse just brought it to the foreground and it crashed. I’ve never seen Audacity so unstable as it is these days. It seems ok as long as I’m just using it and not doing other things. At least the Jan 10 version restarted ok and didn’t seem to mess up the subsequent recording.
One question - I was recording music, is there any likelihood that voice would make any difference over music in terms of the problem we’re chasing?
I guess I’ll go back to 2.0.6 and see if I can make it mess up to prove I can duplicate the issue here at home. Maybe the Jan 10th build fixed something.
Thanks Gale and Koz for hanging in there with me. Hopefully we can “catch this rabbit”.
You still have not said what device you are recording from. Is it line-in to the Mac or a USB or Firewire external device? If it’s a USB device, connect it to an empty USB port on the Mac. Do not connect it to a USB hub connected to the computer.
Perhaps if rates are mismatched as they currently are, you should enable the “hardware rate converter”, but I would very strongly suggest that you make rates match if you want to solve this. If you only want to record at 22050 Hz, it’s probably more convenient to change both the input and output rates of this device to 22050 Hz in Audio MIDI Setup. If there is no option to set it to 22050 Hz then I suggest setting Audacity sample rate to 44100 Hz instead.
If this device has any control panel or settings of its own for sample rate, set those to 22050 Hz too. If it has any buffer settings of its own, look at those too.
I am saying only that if there was corrupted audio in the buffer due to the crash, that could be a problem in 2.0.6 but not in 2.1.0-alpha, because that later version now resets the buffer.
Please remember that Audacity does not officially support Yosemite so we are in somewhat uncharted territory. Also we do not know what device you are recording from or (if it’s an external device) whether it has correct drivers and firmware. All we know is you are running with mismatched sample rates which I strongly suggest you correct.
If you provide the Mac crash reports for Audacity we can see what they say. To do that, open Finder, then choose Go > Go to Folder and type (assuming you are using Yosemite):
/Library/Logs/DiagnosticReports/
Those two paragraphs seem a little contradictory, but I would personally try providing some crash reports and shutting down as many apps as possible when using Audacity. Reintroduce other apps one by one to see if you can find an individual culprit app or a stress point beyond which Audacity becomes unstable.
Recording music from where and how? From a loopback cable? Using Soundflower?
If you mean you were recording a hymn rather than a sermon by the same method, no that makes no difference.
I would stay with the 2.1.0-alpha (latest one you have). We won’t be going back to 2.0.6 to fix that.
Status report: This last weekend’s recording went off without a hitch using the Jan 11 Debug version and with matched sample rates. My attempts to cause a crash have failed so far. Spent several hours trying everything I could think of to duplicate past crashes or just to cause the OS to get confused and nothing happened. Guess that is good, but I wish I could get good data with the debug version to help track down the crashes. Will keep using the debug version for a while and if anything strange happens I’ll report here. I hate it when things appear to have fixed themselves for no good reason.
Thanks to everyone for your help and suggestions!
BTW, is there any way to find out what the differences are in the nightly versions? Thought that might be helpful in seeing what could have changed that fixed a problem.
Guess what! The crackling/static/whatever is back in full force!!! Using Audacity Jan25 Nightly Debug version on Yosemite 10.10.2. It really messed a very important recording and there is nothing I can do about it now. Grrrrr…
I hadn’t done any recordings for a while as I only do it as a backup person. Had to do one again this Sunday and the situation is exactly the same as before. Do one recording and all is fine. Save file then close Audacity to try and keep from having any issues. Restart Audacity and let sit for probably 45 minutes then start recording. First 15 minutes are fine then gradually the popping sound starts and gets worse until the recording is finished, about 30 minutes. The popping is only heard when other sounds are being recorded. During a speaker’s pause, all is quiet including no popping. The sound at the end reminded me of a machine gun. Very regular sharp pops. On the medium volume passages the pops are visible on the wave form.
I am using a wireless mic to a receiver and the receiver’s output is routed to Line-in on my 2009 MacBook Pro. The midi sample rate is set to the same as Audacity, 44,100. I am recording mono since there is only one channel coming from the mic. Now that I think about it I may have gone to Stereo recording at the end of my last episode several months ago. Hopefully that wouldn’t be an issue.
The laptop has other programs minimized, but none that use audio and none are actively running doing anything. Swap file is not being used, lots of extra memory. No Internet connection available.