FreeG vs. Trim

[mhschmieder]

I should point out that I have EXTREMELY good ears, I don't mean that in a braggart way; it's a gift, and also comes from having been trained by professional musicians in my family since I was not quite 3 years old.

Nevertheless, the drummer could hear it as well. He too has very well-trained ears. To both of us, the difference when FreeG (even with 0 dB attenuation) is in the insert chain, is more noticeable than some other changes that we make during mixing.

I did the latest update to FreeG in December (near Christmas), when Sonalksis updated quite a few of their plug-ins. I am using it in 64-bit mode. I'm starting to wonder if maybe that port wasn't done correctly -- especially since it's a free plug-in. One of my specialties is Numerical Analysis (my Graduate School focus, actually), and I'm quite aware of how many software engineers make non-obvious programming errors that result in downstream computation errors.

[mhschmieder]

Thanks for the offer on checking my file using your test; I'll try to remember to package it up in a few days (the rest of this week is going to be crazy, and we're also affected by the storms in terms of bad internet since the weekend, so I get dead links most of the time right now).

One thing I forgot to mention is that the bass is fairly hot by the time it gets to the trim insert slot, peaking at close to -3 dBFS and averaging somewhere around -12 dBFS. I usually aim for no hotter than -6 dBFS peaks and closer to -18 dBFS RMS, and generally track to -24 dBFS RMS.

[EMRR]

Some real differences might show up in a spectrogram of noise below -102 dBFS and absolute noise floor which could account for observed differences. In short I'd really want to see the very bottom of the residual in detail to make a call. This could be a case of differences in noise shaping, which would be way down there and not show up on a peak meter.

Do you think noise that low would be audible? MH is hearing discernible differences between the tracks and says they even look different. Sounds like there's more going on here than stuff below -102dB. Don't you think?

Phil

Without being in MH's shoes, I can't say. It does sound like more is going on, I agree. I quite simply have little trust for featureless metering (DP), period. A null test on a peak meter tells you very little real info, it's a good quick check. That was my only real point. I could look at it in Spectrafoo complete, I could look at it with an Audio Precision unit, I have both. Plenty of better options that should be employed in a test like this, otherwise we are guessing.

[monkey man]

Well, you may not have seen my edited updates to my posts, which I made to avoid confusion for anyone reading them later down the pike. It turns out that MOTU's Trim is very transparent up to at least 9 or even maybe 12 dB of reduction.

Aah, thank you Mark.

That's transparent enough for me. Good ol' MOTU.

[EMRR]

Around here it's always things like tambourines and shakers that end up with the fader at -20 to -30 in a mix. Some reverb returns at -15 to -20. Electric guitars on occasion as low as -15, and still very loud in the mix.

[mhschmieder]

Oh, I rarely get down much below -18 dB for actual mixer faders, as I leave so much headroom at the recording phase. Mostly hi-hat and ride cymbal spot mics get pulled down a lot.

One thing I forgot to mention, is that I always render in real-time, having lost faith in background processing years ago (though I still use Bounce to Disc for my final stem mix to create the pre-master). It's easy to make hidden assumptions, and I wouldn't be surprised if the null test was done against non-real-time rendering. We already know those results can differ (though it's a bug, correct?).

Also, it occurs to me that the issue might be incorrect delay compensation, and a free plug-in would be the one most likely to not report the correct value. In a combined bass guitar stem, the phase interaction that results, could easily cause the differences we are hearing (and seeing).

So, to be clear, the different waveforms are from a combined bass guitar stem track (still mono though), as opposed to rendering processing on an individual bass track to a new track. I haven't tried that experiment yet, but will try to do so this weekend. This is a critical week at work so I won't be doing any mixing until Friday at the earliest; I'm spent by the time I get home.

[EMRR]

Incorrect delay compensation: easily the case. Curious to hear any reports.

[EMRR]

I had a look in spectrafoo, compared trim with freeG on adjacent identical channels. Pink noise nulled to unmeasurable levels at any setting for me, flat line at the bottom. Something else is up. My FreeG is from a 11/1/13 installer, it appears.

[Phil O]

Thanks for doing that Doug. I wonder if it's version related.

Phil

[mhschmieder]

I've been busy, off the grid for the most part. Am in the middle of a session as I write this but the delay compensation problem came up again tonight so I'm wondering how best to deal with it since Buffy is really for hardware vs. plug-ins and related to the hardware buffer setting.

Tonight I verified that AmpliTube is not reporting the correct delay compensation. I was doing another pass on a bass stem, and noticed that pushing the DI track ahead by one tic got all the tracks aligned again, when processing was enabled, but that this was an unnecessary step on the naked tracks (meaning there was not an issue at the recording stage).

Granted, it is an intensive plug-in, but I have iZotope Alloy on another track (though I shut off its EQ and am only using it in Expander Mode to replace the compressor I was using as my goal tonight was to further reduce low frequency sustain resonance). I would think they're equally CPU-intense.

I feel like an idiot that I'm forgetting how I used to deal with this -- it's been awhile since I've had enough plug-ins on one pass (as I make extensive use of auxes, groups, stems, etc.) that it's been a problem. Possibly this was contributing to the FreeG problem though, as it was last in chain.

It's interesting that those who have run null tests have old versions of the plug-in. Mine is practically brand-new, from around the end of the year (late DEC 2014).

I'll check DP settings again to see if something slipped. I had a disaster yesterday morning and almost lost my system drive. I had to go to Time Machine to get my DP settings back. Possibly something isn't set right after that disaster recovery.

[mhschmieder]

Just to elaborate upon the likelihood of improper delay compensation being behind the problem, the characteristic of the waveform shift of the combined tracks when producing a stem that has FreeG on one (and only one) of the tracks, is definitely in line with time alignment effects on bass frequencies.

[mhschmieder]

Also, in case I didn't mention it earlier, I am working mostly in 48 kHz these days (occasionally in 96 kHz and rarely in 44.1 kHz when "demanded").

Not sure if anyone not experiencing the problem is working in different sample rates than 48 kHz. Possibly it could matter, depending on how they implemented the plug-in.

[EMRR]

Usually 88.2 or 96 here.

[mhschmieder]

I'll try to remember to give it a try in a 96 kHz project soon then. I always work in 96k for my own stuff, but as collaborators and clients can rarely handle that (or have a bias against it), I try to at least talk them into 48k. And as I put others' projects ahead of my own, that means I'm usually in 48k land, or 44.1k for the extra-stubborn (luckily I have good SRC from iZotope).

[mhschmieder]

After reviewing some topics on Automatic Delay Compensation from the past year (since DP 8.07 in particular), I decided it likely that this was the cause of my issues with FreeG and IK Multimedia AmpliTube.

Indeed, this proved to be the case.

I just spent a half hour right now with both plug-ins, disabled and enabled, and FreeG vs. Trim, with different buffer settings, and found that I don't need to pull my Bass DI track ahead by one tic anymore to "compensate" for the downstream effect of incorrect delay compensation when a heavy duty plug like AmpliTube is not balanced with similar heavy plugs on the three mic tracks.

Furthermore, there is no longer any coloration of the sound when using FreeG vs. Trim.

Lesson learned, for DP8 at least.

I had been using a buffer size of 1024 when mixing, as I didn't need real-time as when overdubbing. I set it to 128 and all is fine; not sure I'll bother experimenting with other buffer settings at this point.

The problem didn't show up on the guitar tracks because I was using LiveRoomG on the DI track (since it was the DI from an amp head vs. a DI directly from the guitar) and various Delay auxes on the mic track (only one mic as someone else did the guitar recordings before I came into the picture), so there was likely a processing balance on the two tracks and hence no relative latency during the combination into stem-ready guitar tracks.