I’ve got a live-recorded concert, 48 kHz, 24-bit. The audio files all contain some very odd electrical fuzz or glitch. It’s not synchronous between files - it occurs at different times on each channel, including the guitar, which is recording through two pick-ups via a stereo cable into two different channels (i.e. the two guitar pick-up channels also contain asynchronous instances of this noise). It’s not a noise floor, because it’s not constant, but it is present every few seconds on all channels. I’m just curious if anyone has ever encountered this prior and how they (maybe) addressed it.
Here are three channels zoomed in as much as possible - the fuzz or static is apparent as small completely vertical lines. Weird!!
Possibly, though that’s a bit beyond my pay grade, but if so, would not all channels be synchronous instances? The sound board was running each channel flat into Reaper, and then they simply sent them to me for mixing and such. The sound person checked things from his end and confirmed that it’s not something odd on my end or some transport issue. It’s not actual audio, because if it were I might be able to correct it in Melodyne with a script, but even though I can hear it in Melodyne, they don’t actually appear as audio notes.
I’m assuming that a digital clock synch issue would be fundamental and not correctable, yes?
Correct and no it wouldn’t necessarily be synchronous. It will sound like clicks and pops throughout the recording and comes from recording a digital signal but not clocking correctly to a single device.
Hmmm… thank you, that’s extremely helpful!! I’m trying to think in the signal chain where that asynch would occur. (As I said - this issue is new to me so I’m not sure of how to ID it) So the analog audio coming from the stage routes into each channel of the board and from there into the recording laptop. I’m guessing the clock(s) on the main soundboard controlling each channel were not in synch with the primary Reaper clock? Something along those lines?
I don’t think I can attach a sound clip to this, otherwise I would for confirmation.
You’ve been commenting and helping me on these boards for well over a decade. Thank you!!!
It was either USB 3.2 or a Thunderboldt port; transfer speed in excess of recording write speed (AFAIK). The sound person had done this prior and not encountered the issue, or at least, nobody had noticed it, though I confess I’d have a hard imagining NOT noticing it.
That is the short of it most likely. So in the situation you describe there are two clocks:
The audio console
The audio interface of the console.
It varies a bit console to console what you need to worry about or not, but it is possible on some consoles to be recording at a different clock than the console is running at. This is especially true if, for instance, reaper was told to record at 44.1, while the console is running at 48k, but even if Reaper was told 48k, and the console was running at 48k, but the console was using an internal clock, and the interface was also using an internal clock rather than locking to the console.
Sadly hard to tell at this point. So keep in mind that while this was an initial guess, it is not the only possible cause.
Yea you would need to upload the sound clip somewhere else (Drive, Dropbox, Onedrive, S3, etc.) and then provide a link here.
Before I pull the plug on these tracks as being unfixable, here’s a 10 second clip of one of the guitar mic channels, with the fuzz/static (not even sure what to call it) clearly audible. (If it were sufficiently quiet I might try and repair it with a gate but it’s not). Does this still sound like a clock error?
So while not exactly indicative of sync issues I commonly see, it certainly is very possible it is a sync issue. It probably was not noticed live unless someone was listening on headphones on the DAW, which doesn’t sound like it happened.
So nothing we do at this point is going to get that repaired most likely. There are some tricks that can be used to alleviate it if re-recording is not an option, but you will always be striking a balancing act between the amount you can ‘clean up’ and the artifacts caused by that cleanup.
As an example, this was a first pass using the declick algorithm from Izotope RX…
It is far from great, and this was a VERY quick pass, but definitely better than before, but on the flip side definitely some artifacts that are noticeable as well. Always that tradeoff of time and quality here, better quality means much more time invested, but also you will never be able to make it as if it never happened to a trained ear.
Seablade
EDIT: I just realized I forgot to apply the effect in Izotope before exporting, so I just updated the example above, sorry about that. considering it was within minutes of posting I doubt anyone heard the ‘original’ but if you did listen again for a comparison.
It’s entirely possible that I wouldn’t have noticed something like this until after the fact, if at all. I’ve done some gigs myself where I set up the recording to set-and-forget, and then focus all of my effort on the live production. If the live production doesn’t have this problem, then I’ll never notice at all that the recording is bad.
If you think I should check the recording periodically, yes, that’s a valid point, but when the live part is trying all it can to go to **** and I end up leaving some of that un-optimized while I try to at least hold the basic structure together. . . . . . . .
Then I package up the audio files and send them off to the post-producer without checking them because, “What am I going to do with it now anyway? I can’t re-record, and that’s pretty much what it would take to fix anything different from what he would do.”
If it were me, I’d appreciate the feedback that it was bad, and how, so I can think about how I might do better next time. And it’s entirely believable to me that he wouldn’t know at all until you tell him.
Oh, the sound person was great and did fine work- no assignment of blame anywhere. These things happen, and aside from this, the audio files are most excellent indeed. I’d certainly never have thought to check for clock sync. It’s just new to me and I wanted to understand it better before trying to fix it. I did mention it to him and he sent the files again, just in case it was some sort of transit error. But he did find the clicks in the original as well.
The RX10 tool suggested by Seablade has so far been extremely useful. As he points out, it’s not perfect and in some cases may remove one artifact but leave its own behind, depending on settings and such. On the other hand, it’s a live concert recording and a few artifacts here and there aren’t going to break anything.
