Methodology for merging parts of a large post-production project

Question for post-production professionals.

For a project lasting 2 or 3 hours, which can be broken down into chapters or parts, it seems necessary to create several projects (let’s say sub-projects) on the same configuration basis, and then merge them (after the final rendering - in stems - of each track or group of tracks). At this point, the prior organization of the sub-projects and the overall project comes into its own, as the overall project must have a precise logic in terms of track, directory and group names, AUX and Sends, not to mention the audio configuration. Otherwise, of course, it’s an insurmountable mess.

I’m aware that it can take a long time to answer my question, but I was wondering about the main steps to follow and the pitfalls to avoid in this type of project, which will eventually integrate several sub-projects. I’ve also read on this forum that Nuendo isn’t yet perfect when it comes to these mergers or to importing project tracks, especially when it comes to panoramas.

Added degree of difficulty: I’m talking about a Dolby Atmos project based on a physical 7.1.4 installation.

Any advice would be most welcome!

We have digitization and restoration projects with a playing time of around 500 hours per project. That’s often more than 1.000 GB. Nuendo has no problem processing the playing times of 25 days. Therefore, a project of only 3 hours seems extremely short to me. I would never divide this.
For us, the magic limit of a project is 1.2 TB (1200 GB) audiofiles. The project should not grow beyond 1.5 TB, so that it still fits on the hard drive (4 - 8 TB).

Thank you THambrecht. I’ll take that advice on board.

However, I find that a project with, say, a hundred sound effects tracks, a hundred ambient tracks, a hundred music tracks, plus narration or dialogues, VCAs, Groups, etc, is diffcicult to manage, if only visually.

But if I understand you, it’s better to learn how to manage all this in a single project than to learn how to integrate several sub-projects, in the end, into a single one? Final integration is probably not that easy.

Nuendo is also used to add music to films with all effect tracks, soundtracks and speaking voices as well as dubbing into several languages. In addition, Nuendo is even network-compatible so that the same project can be called up at several workstations at the same time.
On the other hand, merging / importing from other projects is currently very immature.
It works when importing bare audio tracks. Unfortunately, as soon as there are effects - or routing to groups - importing from other projects ends in a catastrophe at the moment.
I recommend daily !! backups so that you can eventually go back to an earlier version.
But maybe the colleagues from the film will also say something about it.

When I’ve done this (TV shows) I’ve always used the same fundamental template for all sub-projects. This ensures that the “skeleton” of the project remains the same: Same group tracks and same output buses. If I remember correctly Steinberg improved import functionality with the latest version so that “import tracks from project” or whatever it’s called supposedly links more accurately to existing group tracks. In other words if you have a dialog track that you’re importing and the sub-project’s dialog track goes to a group called “DIA” and that same group exists in the master project then the dialog track should map to that group in the master after import.

I suppose that if you’re doing Atmos it might be slightly different. I’m not experienced enough there to comment. My guess though is that you’re still likely benefitting from using a common template for main project and sub-projects.

Yes, of course, I’m doing all that (except the network part). I’ll try to keep it all in one project. I’ll also try import-merge, just out of curiosity. As Matthias says below, Nuendo has improved. Are you on Nuendo 12? If so, and disasters are common, as you say, that’s disappointing.

I second what Mattias is saying and would recommend not splitting up unless there is a cpu limitation on playback… but then just get a better computer :slight_smile:
With regards to the necessity to split into sub projects. I don’t see a practical reason besides collaboration with newbies that don’t know your workflow. However i really like how good i can manage all the different tracks (in folder) within n12 and coloring them helps a lot.
If you really need to work in sub projects… the first thing i would do is some tests. What happens when you import and does it work as expected.
Finally, atmos editing+routing is not necessary if you work on dialogue and even on hard effects (doors/impacts) or foley… that all get’s worked out in the premix/final mix. So keep that in mind when you want to work in sub projects.
Good luck.

I take note of your opinion. I’ll do some tests, but I’m worried. When I think that Nuendo has difficulty (or I do!) keeping only my Mixconsole configurations for a single project…it’s not reassuring…

Update: I’ve just carried out a single test: integrating an existing project into a new template exactly like it, including the Renderer. It doesn’t work at all on the Atmos side. The Renderer has lost all the source tracks! So, don’t use this method. Keep everything in the same project, at least in Atmos. We’ll see about that in version 13 (or 14).

As I said in Update, the first Atmos test was not successful (loss of Renderer links and source tracks). So it’s better to keep everything in a single project. My computer is powerful, no problem. And I’m equipped with UAD. I can also use Vienna ensemble 7 with a second computer for virtual instruments.

I’ve yet to delve deep into Atmos, but the way I see it you’ll always have to pay attention to and ‘futz’ with resources if you’re going to merge projects. I don’t see a way around it.

What I’d say though is that any sub-path in your mixer should be easy enough to reconnect… should… what I mean by that is that if you have for example an Atmos bed for SFX then that’s essentially just a surround track, but for Atmos. So I would think that panning into it would be no different than panning into a ‘normal’ group of the same width (someone correct me if I’m missing something here). Perhaps it would then be a solution to simply set up a pre-group before the bed and route to the group instead of straight to the bed? In other words, rather than routing your FX audio tracks to the bed directly you would go to an FX group of the same channel setup and that group would be equal in both of your projects and in both cases go to the bed group.

That way when you import tracks you should be able to reassign the audio tracks to the correct group if necessary - or not at all, and the bed destination remains unchanged because it wouldn’t be a part of what you import in the first place… because it is “after” the ‘regular’ group… It’s obviously not a solution for objects but perhaps it’ll save some time…?

Am I thinking straight about this?

What you say is true for beds (and their sources are indeed groups), less so for objects (which can be numerous and which, given their often unique panoramic movement, cannot be routed in a group - unless I’m mistaken).

Having said that, I don’t like the idea of correcting each time what is announced as possible and should work. Because we don’t know what’s waiting for us on this bumpy road, given the complexity of Atmos projects in post-synchro (I’m using this cinematographic example, but here I’m doing audio books in Atmos, which isn’t very common yet).

I suppose if there was a preference that allowed the renderer to automatically reassign new imported objects available resources that would possibly solve the problem. I’m wondering if this is perhaps just a limitation that depends on Dolby. In fact, I would probably guess they would have to solve it since it’s their application and plugin after all.

That’s right. However, I’ve kept the names of tracks, groups, beds and objects exactly the same. So it doesn’t work in Atmos. It’s important to understand that this is relatively new, but a mention in the manual wouldn’t go amiss.