Choppiness and Skips appear at 6:45:47 in Long Recordings

Audacity Help Forum Windows
1

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

2

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?

3

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

Tom

4

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

5

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.

6

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.

7

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

8

Here’s the stream that I’m recording. . . .

http://www.iheart.com/#live/WARM-1033-5674/

9

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

10

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

11

I was just about to ask the same question (but to increase the buffer size in the Fast Track Ultra control panel).

Just to confirm, do you have the latest driver v6.1.9 from http://avid.force.com/pkb/articles/en_US/Download/Fast-Track-Ultra-8R-Drivers ?


Gale

12

Yes, I’m running the 6.1.9 drivers.

13

You may have a bad memory block.

http://technet.microsoft.com/en-us/magazine/2008.09.utilityspotlight.aspx

It’s a time bomb and may also show up when you do other memory-intensive activities. Machines used to do a memory test when they started, but nobody wanted to wait, so it’s commonly bypassed. You may be able to go into your BIOS, defeat “Fast Startup,” and just let it test.

Koz

14

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.

15

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

16

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

17

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

18

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.

19

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.

20

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?