bounce mono, loss of gain

Hiya Dream,

I think this’ll help…

Create a mono group track and route the tracks you want to bounce there at the volume you want.
That way you’ll be monitoring the same level in the mix as you’ll get in the bounce :slight_smile:

Cheers

Thanks Paul for you tip. :slight_smile:

Probably I’m gonna stick with changing the panning law setting because its’ a little bit faster.
I didin’t realize that bouncing a mono groups is different form a mono track, very helpful to know that. :slight_smile:

It isn’t, but you would have the pan at center so no shift to pan law.

Quick check:

PANNING LAW Setting: -3dB

  1. track in mono PAN L62 → I lost 1.73dB;
  2. track mono PAN C → I lost 0 dB;
  3. track mono routed to a Group panned to L62 → I lost 1.73dB;
  4. track mono routed to a Group panned to C → I lost 0 dB;

PANNING LAW Setting: -0dB

  1. track in mono PAN L62 → The track has now 2.83 dB more than the original;
  2. track mono PAN C → The track has now 6.02 dB more than the original;
  3. track mono routed to a Group panned to L62 → The track has now AROUND 2.83 dB more than the original, but the null test doesn’t give me silence, somehow the export is not perfect;
  4. track mono routed to a Group panned to C → The track has now 6.02 dB more than the original.

So I deduce that the the purest method is:

  1. leave the the panning law setting to -3dB;
  2. put the pan at the center and now bounce the track;
  3. once reimporting the track put the pan the same way it was before.

I deduce also that mono groups and mono tracks are the same if we’re talking about dBVU but the bounce doesn’t seem sample accurate if originated from a group.

Although I’m not 100% sure, I don’t believe you deduce correctly. I do mono bounces through groups quite a bit. The only part that I would question as not being sample accurate is maybe CC automation. The actual channel automation has worked as expected.

Sure, I can be totally wrong about my deduction. :slight_smile:
To do that experiment I created a session with only three tracks, I didn’t do anything but changing pan or routing to a group.
Any other suggestion why the bounce through a group doesn’t give me a perfect null but through a mono tracks it does?

no, but I just did a quick test using a -12db sine wave and it did null.

by the way, I’m not saying you’re wrong … just that I’ve used that for quite awhile and have never been “bit” by it. Of course, if it sounds good I couldn’t give a crap if it nulls or not.

I did another quick check and the bounce seems to be sample accurate. But when I bounce and the pan is not at its center position (also with extreme setting, meaning L or R) I can’t get a perfect null. Maybe the cent accuracy (0.00 dB) is not enough? I don’t know, just thinking out loud. But how many variables are involved here in addition to pan and level? I would understand not enough precision from an intermediate pan position, but form an extreme position too?


EDIT: of course I’m doing these tests with a new session, no plugins at all.

Don’t know, this stuff is usually at the who gives a crap level. It will have a non-audible impact on the final mix.

Hiya dream,

So often get at cross purposes when communicating this way, put it down to my crappy language skills…

Anyways, my initial plan of bouncing through a mono group is that you bypass all panning thus pan law stops being an issue.
Try this, Create a mono group channel, name it mono bounce or whatever and set it’s fader to +3db but assign no outputs to it, actually at this point forget about it, certainly don’t send anything to it.
Do your mix as normal till you want to print some mono tracks.
Then route the tracks you want to bounce to the mono group (still no output though) and select that group channel from your export audio. Done!
Only use the mono but when you’re actually bouncing, the rest of the time forget about it.

Re the bounces no passing the null test: I think that’s because any change in the clip volume or in the mixer, including pan, channel fader, master fader and even pan law settings, is processing the file through the (64bit?) mix engine and then being printed at whatever resolution your export is set at.

It won’t Null, even if you dither it, won’t be ‘exactly’ the same, but really you won’t hear it and as JMCecil said “this stuff is at the who gives a crap level”.

Someone correct me if I’m wrong, but I think I’m remembering my digital audio theory correctly!

Cheers

PC

@Paul,

I believe you are wrong-ish :stuck_out_tongue: Just kidding, I think you know and intended the correct answer. The OP asked or commented after your post that he didn’t know that the mono group tracks are different. I just provided the additional … they aren’t. It only works if you don’t pan the group channel. Otherwise, you’re right back where you started. That started the always baffling, “but it isn’t sample accurate” stuff.

Y’know, we need to continue that campaign for better export options!! For example, export pre-fader, pre-pan, or pick a position in the effects chain etc. It makes sense and would sort out all these problems with export levels.

There’s many times when I want to render the first FX slot (e.g. Melodyne and/or autotune) but not the others, and I’d rather not have to write down my fader/pan settings just so I can zero everything for an export.

Mike.

ditto… also to easily turn highly edited tracks into a single file without freezing everything

Thanks!

My goal was also trying to avoid any gain change while doing exports if not necessary.

you’re probably losing gain because there’s some Side information that’s getting subtracted while doing the L+R summing in the conversion.

Hi Lukas, thanks for your answer. :slight_smile:

There is no side information on a mono track, for definition. And the “lost” happens with a mono track panned to the center.
Maybe I misunderstood what you’re saying. Sorry in that case. :slight_smile:

There is no loss when you use audio / export mixdown to bounce a mono track when the track is panned centre, if you ensure that you use the same bit resolution as the original for the exported file. The original and the exported file null perfectly.

it’s probably me who misunderstood, i thought you had some stereo information to begin with in the signal.

but yes-- the ‘same file properties’ bit is important. the peak value of a signal will vary quite a bit if exported into a different samplerate for instance (brickwall limiting to 0dBFS is not really useful if you export to another samplerate as your peaks will be all over the place afterwards). sorry i can’t be of a more concrete help.

Hi stringray, it doesn’t always null. :slight_smile:
Try a different panning law setting for example. At 0dB for instance you “gain gain” (sorry about the pun, LOL).
You pointed that out correctly, so, just to clarify, there is not change of sample rate or bit depth on test I did above.