Audio disaster during live recording?

[TinenTech]

Has anyone here ever experienced a case where you were recording a live session in DP, everything looked normal, everything sounded normal, and then later found that all the audio tracks (10, in this case) were ruined by a kind of modulation noise/distortion? It's like a zipper noise that only sounds when there's audio on the track. A stream of digital junk. You can see these little ripples in the waveform display when you zoom in, so all the audio files are corrupted in the same way.

It happened to me at the worst possible time...while recording a live concert. We can get into the nuts and bolts of the situation if you want, but it ruined the entire almost hour-long first set. No problems at sound check, of course.

The only clue I got of something abnormal before I rewound and hit PLAY was when I hit STOP, I got the "samples may have been dropped" message. Any time I've gotten that message before, it was in the middle of recording, not at the end, and it was a disk buffer problem--and the audio was OK anyway.

I totally reset everything for the second set, and had no problems, so it was only half lost. Back home, I set everything up the way it was for the first set to try to recreate the bug...no problems.

Any ideas? I'd like to diagnose this.

P.S. Luckily the client was OK with a redo of the first set in the studio, but man, this was a one-time show and has shaken my faith in a setup that has worked well for me for years. (MOTU interfaces in FireWire to a MacBook Pro writing to a USB 3.0 hard drive.)

[stubbsonic]

UGH!!! I hate hearing stories like this!! Maybe post a little example of the audio. Sometimes that can give a clue about what is damaged, and (knock wood) perhaps how to rescue (?)

[MIDI Life Crisis]

While the first instinct is to suspect the app doing the recording as the culprit, that is sometimes misguided in my experience.

"Zipper" noise as you describe it is almost always (I meant ALWAYS) the result of some external device sending data over a USB, Firewire, or device. Sometimes it's the cable, or a cable crossing in that tangle of wires we call an interface. Other times it is a device itself, a pedal, a keyboard controller, etc. And it could also be a clock being sent and the data might pick it up.

Or it could be DP, but I would suspect some other source. It sounds like this was a unique setup or situation for you, so perhaps something was added to the usual studio that interfered with the audio signal. That would be my best guess. There's no reason DP would fu#% up just that one, unique session and revert back to normal operation without a trace. If the app is somehow corrupting the signal it's not going to give up the ghost all of a sudden.

The solution (in the case of cables) is usually to just move the errant cable away from the drive, or hub, or whatever device is sending out little magnetos to your cable. If it's a device, that's usually as easy as checking the audio channels to see if it is on one channel or all. But again, if you're not hearing it now and it was only in that one recording, I'd suspect that something unique in that setting interfered with the signal. The fact that it didn't appear in the test recordings may only be that one little wire moved into the wrong place or a musician (I'm assuming these were musicians... lol) turned on or added another piece of gear that was the problem.

And it could be goblins!

[TinenTech]

OK, the problem finally recurred in a situation where I could find out what's going on. I think the issue has to do with FireWire clocking, and may be related to what MIDI Life Crisis said as well.

I was in my own studio this time, running two MOTU interfaces over FireWire into a Mac: an 896mk3, and a Traveler. I've almost always run this system with both MOTU units set to Internal clock, unless I was using ADAT Optical somewhere. Never had a problem.

But this day, I had a known good signal, and it was "zipping" like crazy. Switched the input to the other interface, it was clean. Sounded like clocks to me (and this time, DP wasn't involved; it was coming from the hardware).

Long story short, in MOTU Audio Setup I set the 896 to "Internal" clock and the Traveler's clock to "896" (I confess I'd never even been seen that as a clock option in the list). The problem went away. Oops. I thought "Internal" meant the Mac was clocking both interfaces via FireWire, and it probably does, most of the time, but if there's interference for a few periods... The manual does say you ought to select one interface as Internal, and clock the other interface off of that master.

It's still a mystery why at the live recording, why the clock noise didn't come through the speakers, only printing to Digital Performer, and why it suddenly appeared the other day after a few hours of "normal" operation. It works 99% of the time, but, that 1% can be a real problem.

A studio I work with might shed its Rosendahl Nanosync clock, maybe I'll buy it and have a nice solid word clock as we're supposed to have.

[daniel.sneed]

Hope this makes sense and may help.

AFAIU, *internal* stands for *interface internal clock*, not *computer internal clock*.
AFAIU, there is no such thing as *computer internal clock*.

But in case you use your computer built-in audio card, this card does have its own clock.
Which, if I understand correctly, is not your setup.

So setting first interface as master (internal clock), you need to set the 2nd as slave (clock received from 1st, thru any digital wire : spdif, adat, wordclock, aes, ...).

To make it short, if you use 2 different cards at the same time, and both are running on internal clock, this will lead to some sort of clock conflict.