Dec 2013
1 / 44
Dec 2013
Dec 2013
uhesltj
Dec 2013

Problem: At roughly six hours and forty six minutes into a long recording, a clicking, choppy sound appears during playback of the recording and continues to the end of the recording. It occurs at the same place each time a new recording is made (at 6:45:47), and occurs likewise during subsequent playbacks as well as stops and restarts of the program.

Things done to try to eliminate the problem, but to no avail:
• Successfully applied all pending Windows and driver updates.
• Installed latest drivers for the M-Audio interface.
• Changed internal sample size from 32 bit float to 16 bit.
• Disabled all shields in my Avast virus protection software.
• Tried the long recording twice after rebooting the computer.

Environment:
• Dell XPS 8300, with 8 GB DDR3 RAM, Core I7 processor running at 3.4 Ghz, 1 TB hard drive, with over 450 GB free at the start of the recording session, and still well over 430 GB free at the end of the session.
• Running Audacity 2.0.5, the latest version for Windows.
• Recording with an M-Audio FastTrack Ultra 8R USB audio interface. Running Windows 8 pro with all updates applied as of this morning.
• I’m recording live Internet radio streams, played via Internet Explorer, and routed to the M-Audio FastTrack Pro.
• Aside from the background processes, only Internet Explorer and Audacity are running when this happens while recording.
• The audio from IE sounds fine, and things look good in the waveform view in the track display, even after the choppiness starts. This is true during recording as well as in subsequent playback. My hunch therefore, is that the sound is being recorded probably, but Audacity can’t play it properly after 6:45:47.

Observances during recording and in subsequent playback:
• Resource meter shows that about 2.8 GB of memory is used, 5 MB reserved for hardware, 0 MB of RAM is free (this value gradually declines to zero during recording, and hits zero a few minutes before the choppy sound appears), Standby is at around 5336 MB.
• If I stop the recording at around 6:45:30, and then append to it, no choppy sound appears in the appended portion, even several minutes after where it begins when the recording session is allowed to extend past the 6:45:47 time.
• If I append to the recording after the choppiness begins, the appended part is not choppy, but the choppiness prior to that point remains.

There’s a long list of tasks given in the documentation, to free up computer resources for Audacity. But before embarking on that time-intensive path, I wanted to see if anyone here has seen this before, and if so, ask them to respond with how they solved this problem.

Thanks much,
Tom Hesley

read 6 min
steve
Dec 2013

I’ve not come across this problem, but the time 6:45:47 is intriguing.
What sample rate are you using?
Is this a 64 bit machine?

uhesltj
Dec 2013

Yes, it is a Windows 8 Pro 64-bit platform, and I’m using 44100 internal sample rate.

Tom

kozikowski
Dec 2013

What, exactly, are you recording? What’s the show? Can you make it worse? Sometimes gazing too closely at the problem isn’t valuable. Run a million applications and fill the machine up. Does a recording still start cracking at the same place?

What assurance do you have that the show doesn’t start cracking as a measure to prevent people from hogging the stream? If they wanted you to have six hours, they would have provided a file download.

Or did they and it’s money-based?

I’ve had smaller companies do that.

Koz

steve
Dec 2013

6 hours 45 minutes and 47 seconds at 44100 samples per second is almost exactly 2^30 samples (in binary that is 0100 0000 0000 0000 0000 0000 0000 0000), which seems like more than a coincidence. I don’t see an obvious explanation but it may be worth running a thorough memory check on your computer.

uhesltj
Dec 2013

The choppiness is not heard at all while making the recording. It’s only after I finish the recording and then play it back that it appears at 6:45:47.

steve
Dec 2013

2^30 samples at 44100 Hz sample rate works out as 6:45:47.887165533
That must be too close to be a coincidence.

steve
Dec 2013

I don’t see how that is relevant (other than that you are probably breaching copyright).

uhesltj
Dec 2013

Work around: Adjusted the Recording->Latency->Audio to Buffer setting from the default of 100 MS to 1000 MS. The choppiness no longer occurs, and since I don’t need immediate responsiveness for this time-shift recording I’m doing, the resulting increased latency is no problem for me. Thanks for the help.

Tom

uhesltj
Dec 2013

Yes, I’ll run a complete memory test in the next day or so. I had to replace one memory module a year ago. Will advise when the test results are in.

kozikowski
Dec 2013

Memory modules need to precisely match. Memory locations are addressed at blinding speed and having a bank slightly off is very ungood.
Koz

uhesltj
Dec 2013

Ran the memory pattern stress test that Dell supplies with this computer. All memory passed.

kozikowski
Dec 2013

All memory passed.

Which is the bad news.
Now you have nothing to fix and your machine still takes more than normal attention and care to record a show.

Koz

steve
Dec 2013

Have you determined if the choppiness is in the actual recording or is a playback issue? Are you able to zoom in close on a glitch and find a gap or discontinuity in the waveform? If so, could you select a couple of seconds containing the glitch, export the selection as a WAV file and post it to the forum for us to examine. It is often easier to locate the position of a glitch by zooming in fairly close, then switching to the track Spectrogram view (Audacity Manual) Glitches will often show as a vertical line in the spectrogram display.

uhesltj
Dec 2013

I’ve monitored the output of the soundcard during recording. No chops ever appear there, but only during playback of the recording.

However, the chops DO NOT appear in the waveform display before exporting; they’re only heard. They remain present when I exit Audacity and start a fresh instance, and reload the project.

They do show up in an exported MP3 file of the original recording, in both the audio output as well as the visual display when this MP3 file is loaded.

steve
Dec 2013

What happens if you select from 6:46:00 to 6:47:00 and export that as a WAV file using “Export Selected”? Is there choppiness in the exported file?

uhesltj
Dec 2013

I’ll try that. Stand by for results, probably sometime tomorrow.

Gale_AndrewsEmeritus
Dec 2013

Is the choppy exported MP3 from the project where you recorded with lower buffer setting?

That is, you have not tested yet exporting from a seven hours recording with a higher buffer setting?

Do you make sure to File > Close before starting new recordings? This clears out the Audacity temporary folder.


Gale

uhesltj
Dec 2013

Yes, I’m only working with one project for this problem. So, all recording and exports have been done from the same project.

Yes, before beginning each recording, I exit Audacity and start a new copy. I also reboot the computer.

kozikowski
Dec 2013

Ran the memory pattern stress test that Dell supplies with this computer. All memory passed.

Just a note since we haven’t resolved this yet.

Memory Stress Tests don’t run once and we’re done. They loop and run all night while you’re sleeping. A memory stress test on a healthy machine should run perfectly correctly for 8 or more hours.

…
…
PASS 31 WAVE OVERLAY SHIFT TEST – 100% COMPLETED
PASS 31 ALTERNATE RECURSION INJECTION TEST --100% COMPLETED
PASS 31 COMPLETED – NO ERRORS

PASS 32 RUNNING DOG CHECKBOARD LOOPBACK TEST – 57% COMPLETED.

I had an marginally stable machine that passed all sorts of tests until I left Mem-Check running all night. Somewhere round 3:30am (Pacific) one of the memory torture tests failed and the machine went face-first into the gutter.

PASS 83 SPARKLE REVERSE ADDRESS TEST FAILED!! - BANK 4 ROW 1.
PASS 83 TEST HALTED

I fixed the bank and it’s been running for years since then.

Koz

uhesltj
Dec 2013

What program did you use to accomplish this iterative memory test? I’ll run it overnight.

steve
Dec 2013

Years ago I used to use a free program called MemTest86. I believe it is still around, still maintained, and still free.

uhesltj
Dec 2013

Going offline now to try memtest86+. Thanks for the suggestion. More later.

kozikowski
Dec 2013

I’m having fun with the test names, but the “checkboard test” is a real thing and there really are names like that. Fill every other memory location and see what leaks. Change each data point rapidly and see which one doesn’t stick. etc.

I always got the one straight from Microsoft. They make a boot device so they can be standing on the smallest possible memory footprint when running. Floor sweepings in low memory. It runs with a text window and one of the few options is [X] Loop.

Everybody wants it to run from within Windows and it’s hard to explain that Windows is standing on the exact memory locations you want to test.

The boot device used to be a floppy. I think I still have one around here someplace. I think they use a Bootable CD now. I wonder if it will run from a thumb drive…?

http://windows.microsoft.com/en-us/windows7/diagnosing-memory-problems-on-your-computer
http://technet.microsoft.com/en-us/magazine/2008.09.utilityspotlight.aspx

Koz

uhesltj
Dec 2013

I’m back. I ran six passes overnight of Memtest86+, version 5.01. Lots of random number and block move tests were noted. However, all tests passed. 0 errors encountered in the eight hours and twenty minutes that I allowed the tests to run.

kozikowski
Dec 2013

I always used the external Bootable Device. I don’t know, either. Then I bought Macs and they have different tools.
Koz

kozikowski
Dec 2013

all tests passed.

That’s too bad. We’re close to running out of ideas.
Koz

uhesltj
Dec 2013

Just ran two passes using the Microsoft memory checker that comes in Windows 8. Both passes passed. Took around nine hours to complete.

Going to attempt the long recording using the internal soundcard, instead of the M-Audio FastTrack USB interface. Then, I’ll try recording with a different computer altogether, and see if the choppiness disappears in any of these cases. This may at least, help rule in or rule out Audacity as a cause.

I was hoping to record a 36-hour Christmas show that starts on Christmas Eve. But perhaps I’ll have to be here, to stop it periodically, or just use a really long latency setting, and pray that the noise stays away for 36 hours.

steve
Dec 2013

Possibly fortunate that you mentioned that.
There is a bug in Audacity that prevents projects longer than 2147483648 samples (2^31) from opening correctly. Attempting to do so results in the loss of the entire audio.
This is mentioned in the release notes: Missing features - Audacity Support

Large Projects

Projects with 2^31 samples or more (just over 13.5 hours at 44100 Hz) will not re-open correctly. Higher sample rates mean proportionally shorter times - so just over 6 hours at 96,000 Hz. We know the cause, and do intend to address this bug. Workaround: Before saving or closing the project, export to audio files of appropriate size, or cut and paste sections of audio containing less than 2^31 samples to new Audacity projects and save those.

A fix has been made for this problem and will be in Audacity 2.0.6 when it is released (expected early 2014).

uhesltj
Dec 2013

Thanks much. I’ll be sure to perform plenty of exports of shorter files during the recording session, to avoid the 13-hour project save bug.

steve
Dec 2013

uhesltj: I’ve asked about the 6:45:47 issue on the developers mailing list as I’m out of ideas.
If they come up with anything I’ll post here.
If you’re not already subscribed to this topic there is a “Subscribe to topic” link at the bottom of the page.

uhesltj
Dec 2013

Tried the long recording with the Realtek High Definition Audio soundcard, instead of the M-Audio FastTrack Ultra 8R USB one. Same results. The choppiness starts at 6:45:47. This problem, therefore, is likely unaffected by the sound device used. Now trying on a different computer; one running Windows 7 Pro, that has much less memory (2 GB instead of 8 GB).

Gale_AndrewsEmeritus
Dec 2013

I don’t see any gaps (dropouts) in the waveform in the WAV file you posted “Chops.wav”.

What buffer settings did you have in Audacity and the Fast Track Ultra control panel when you recorded that?



Gale