Marianna:

HI there

Created a case 04018094 and asked support to reach out to our develoepr contact and see about connecting with iZotope and see what the scoop might be.

Marianna

There is an 'Enable delay compensation' option in the plugin. Disable that compensation and it's really out of sync. With it enabled, it's a lot better but still not in sync.

Has anyone tried this with RX8? Just wondering if this has been corrected? Seems like a bug on the iZotope side if the rendered effect still shows an audio delay...

And by 'rendered' I mean via mixdown or export.

Again - re-reading this entire thread I see that the delay is for the real-time playback in Media Composer (I keep losing track of this discussion, lol).

So Avid says if this were just 1/3 of a second (16.K samples at 48 kHz) then Avid could slide things into place but given that this is twice that (2/3 of a second) Avid cannot compensate...

So I take back what I said about this being an iZotope bug - it's somewhere between the two, I suppose.

I wonder if Avid's compensation could be tweaked?

Have you considered using RX Connect to send back from RX to Avid? Not even sure if that works with track effects - you might have to mix-down the audio to be corrected and then send the mixdown to RX via the RX Connect audio suite effect (you could send the whole mixdown rather than each clip)...

I'm not in front of my system but I'd really like to try this when I get a chance.

It's the same in RX8 and RX6 when used for realtime playback. Mixing the tracks in RX8 produces the same results as in RX6 - the audio is delayed and you're going to have to pull it back.

The 'Elements' version doesn't have RX Connect but the 'Standard' version doesn't. I haven't tried RX Connect with track effects - I get the impression it's for individual clips.

The other thing I noticed is that once you get a RX effect on the track, it affects how long it takes to open the sequence - it's slow. And it takes longer than usual to remove the effect via the Audio Effect Track Tool. Put 3 on a track and it really slows down a lot.

IMHO, effects like de-click are not intended to be used on an entire track, but rather on individual sections of clips. The extreme delay (and the slowing down of MC when opening the sequence or removing the effect) also tells you something about the processing power needed to identify all these tiny spikes. I would recommend flagging the sections you want to process, then process them individually.

I get that this doesn't match your desired workflow, but still...

(and yes, sending it out to Connect would be similar to applying a non-RT AAX to an individual clip inside MC)

I did revert to applying it to the individual clips in the end and that all works fine. In this case because the audio was from the same source and needed the same correction, using the Audio Effect Track Tool approach made sense. If a bit more delay compensation was available, it would work. I do know the mechanics of whose provide that.

I did notice that putting iZotope effects on the whole track does slow opening a sequence down a fair bit. That's not dependent on the De-click effect. They're great plugins and standalone works great but with MC it's not quite there.

I've since also tried the technique where I mixed-down the audio track and then dragged the mixdown to the AudioSuite tool - I then applied RX 8 Connect and bounced it to the full RX 8 standalone from within Avid. Applied the de-click, rendered it in RX 8 and then sent it back to MC for a final effect render.

This resulted in both an effect and a rendered audio clip in my bin (I think the effect is just to remind what was used to create the audio clip but in this case it's just RX 8 Connect which doesn't really tell us anything).

I then dragged the audio back to the sequence to act as the corrected audio track(s). It's a pretty easy workflow but of course not a easy as it would be if we could just get real-time out of the plugin.

To be honest, I had never used the RX 8 Connect technique, nor was I aware that you could drag a clip on to the AudioSuite window to create a new managed media clip in MC... So much easier than exporting out, doing the correction and then importing it back in.

Cheers

I just ran into that same issue and came to the same conclusions, incidentially on the RX8 De-Click.

And yes, it does make sense to apply that effect to an entire track, if your entire track is 45min of a presenter speaking.

What is more sad about this situation and discussion, is that delay compensation is something that ProTools does seamlessly. Many audio plugins require delays, sometimes because of processing, sometimes because of look-ahead being part of what they need. So Avid was able to solve this issue cleanly in ProTools, yet on the MC side there seems to be bewilderment of about this situation. Several threads I read this morning on the topic seemed to have a hard time wrapping their head around it or question the users why they would need this.

Just yesterday I voted in the Avid feature poll. I wish proper audio delay compensation would have been in the list and I would have known to vote it up.

Yes, we can do an AAF export to a DAW and do the processing there. But as we deal with many less ideal audio recordings when so much production is remote or on skeleton crews, basic audio clean-up as is offered by RX8 is part of everyday life, and round-tripping to a DAW is overkill for simple talking head presentations.

Media Composer uses the Pro Tools mixing engine and uses the same delay compensation technology.  The issue here is really just the maximum delay that can be accomodate by the mix engine. The iZotope plug-ins are requiring unexpectedly gargantuian delay compensations that Media Composer is unprepared for.

I'll see what i can do about getting the maximum delay compensation for Media Composer increased. The current limit is 16384 samples. The quick experiments I did today suggest that it will be more than just a matter of increasing some hard coded limit, as my attempts to use large delays led to other problems that will take some time to sort out.

This has an internally-reported bug number, "MCDEV-6332", so it is, as they say, "on the list".

Good to know. Thanks for clarifying.