See my edited post above MAS. Halo/Nuendo correct on 7.1, and broken on 7.1.2 Atmos bed. Frustrating.
I have had quite a bit of back and forth with them on other bugs. They have always been exceedingly responsive and polite, and clearly stated they have no plans whatsoever to fix glaring multi-year bugs in several products (automation not rendering during bounce in Sequoia or Nuendo was one).
Let me add to the list that all recent VSL software products route 7.1 (and related 3D-formats) properly in Nuendo, most notably Vienna Suite Pro and Vienna MIR Pro 3D.
No, I am not disappointed. Because I already thought something like that. I just didn’t want to write it. Not in a forum for Nuendo.
Too bad. I have installed the new version of Upmix, but haven’t used it yet. (Don’t need the plug-in in the current project.)
Would have been a glimmer of hope that NUGEN would then fix this bug in the other plug-ins.
I’ve thought of that as well. Would be worth considering. (A separate thread would also be clearer.)
Reply from Nugen support, on the topic of Halo and inconsistencies with channel routing in Nuendo:
We’re aware of this routing issue. There should be a correct routing to match the Nuendo channel order in both 7.1 and 7.1.2, however you might need to manually select it. If you go to the settings area, you should be able to select the Output Routing manually. For 7.1 tracks, you can leave it on ‘Auto’. For 7.1.2 tracks, you should have the correct routing by selecting ‘NM 7.1.2’. Unfortunately this routing is not yet available on 7.1.4 tracks. We’re hoping to include a fix for this on a future update, although I can’t confirm exactly when this will be available.
If NUGEN had labeled the setting more clearly with, for example, “Nuendo 7.1.2”, maybe one of us would have figured it out before. (NUGEN should perhaps take PSPaudioware as a good example.)
This setting also exists in Halo Vision and it works (this changes the order of the speaker names):
Too bad I (also) placed the plug-in in a 7.1.6 bus.
I would like to reproduce your problem. But I need some more information.
You created a 7.1.2 and a 7.1.4 group bus, right? Both go to your 7.1.2 atmos bed via send? Or via output routing? And then you send a (mono) signal to one of the group busses via send? Or via output routing? Or did you do it differently in your project?
So how do I deal with a 7.1.4 interleaved file exported from the Dolby Renderer, dropped into Nuendo, and the sides and rears are the wrong way around? Is there a plugin to swap them? Or do I have to split the files and manually re-assign?
If import an ADM the channels are correctly mapped in Nuendo. If I import a 7.1.4 render, they are not.
Grrr. This ties one in knots. So many possibilities for error. There really needs to be a preference for this.
I do feel like a “channel flipper” VST would be something that would be great to have. Just a little VST that flips sides and rears with a simple on/off selector. While that isn’t a nice as having an industry wide standard, that’d make things a ton easier. Just insert that inline and turn it on when needed.
Just to complicate matters further, has anyone else tried to export 7.1.4 or 7.1 re-renders from an Atmos mix in the Dolby Renderer?
Perhaps it’s just me, but the order prescribed for both re-renders is as you would expect (i.e. Atmos / SMPTE order):
7.1.4 - L R C Lfe Lss Rss Lrs Rrs Lfts Rfts Lrts Rrts
7.1 - L R C Lfe Lss Rss Lrs Rrs
However, while the 7.1.4 re-render is correct, what I actually get from the 7.1 re-render is L R C Lfe Lrs Rrs Lss Rss. In other words the sides and rears flipped. No wonder Nuendo was tying me in knots.
If you open this file in RX, you can see the channels correctly labelled, but the sides are on the bottom tracks.
I tested it the way an Atmos master file is normally used: Output from Nuendo with the internal Atmos renderer and then encoding into a consumer format (AC-4, E-AC-3 JOC or TrueHD with Atmos) with e.g. the Dolby Encoding Engine (DEE) or the Media Encoder (DME).
In this case, the channels are reproduced exactly as intended. Also with 7.1 mixdown. (The downmix itself is properly handled: The Rw channel is played back proportionally by the right front channel and Rs(s). The Ltm channel (top left center) from the Ls(s) channel. And so on.)
For the test with RX please have to describe me which way you output your project from Nuendo? Because as far as I know, RX can’t read ADM BWF files. (Unless that has changed with the last update. Haven’t tried it for a while.)
Maybe I was not clear. I am exporting 7.1.4 and 7.1 re-renders from an Atmos mix in the Dolby Renderer (interleaved wavs).
In other words, open your ADM in the standalone Dolby Atmos Renderer, then use the re-render function to save 7.1.4 and 7.1 rerenders (interleaved wavs). Then open the 7.1 wav in RX. That’s what I am doing and getting the sides and rears swapped in that 7.1 wav.
The 7.1.4 wav is too many channels for RX, but the surrounds are in the right order.
It’s definitely in the offline downmix render from the Dolby Atmos Renderer. The live playback downmix from the renderer is fine, so the ADM is fine. It’s fine if I re-import the actual ADM into Nuendo. It’s not happening in RX - that just reads the channels in order.
How did I originally spot it? Well - as above, we talk about importing a down-mixed interleaved wav into Nuendo and having to swap the rears and surrounds. I noticed that was only the case with a 7.1.4 file. The 7.1 file does not need the swap - they’ve already been (wrongly) swapped in the render from the Dolby Atmos renderer. I merely used RX to open the file and confirm the hypothesis.
Precisely. If you have the Standalone Dolby Renderer - give it a go. I’d be happy to know it’s not just me. Or, indeed, if it is just me and someone can point to what I am doing wrong!