Supposed bug with Export Audio Mixdown - cannot be replicated and veryfied

Usually I do full mixes with my DM2000 involved, but for a podcast production I decided to go with a mixdown and the Audio Mixdown function, which I have used very often over the years with no ill effects whtsoever.
Recently it was not possible to get with the mixdown funtion the same audio I’m hearing. There was only Stereo Out 1+2 (from 48 outputs) used. In this podcast is some music (which I composed in another project in Nuendo) as simple audio files included, with some fades and automation. This music was drastically altered in the position it started and ended in a mixdown of the podcast, rendering the file useless. It didn’t matter if it was realtime or non-realtime mixdown. Of course, the plug ins then acted differently - it was a difference in music from some more ambient like parts to more groove oriented parts. I probably did around 10 mixdown tries with several ASIO buffer and realtime/non-realtime settings and the result was always the same, in the meaning of “the same way wrong”.
I was only able to deliver the audio, by playing it thru my DM2000 and back to Nuendo.
We’re not talking here about very minor, slight differences - it was like the audio file was shifted several seconds forth or back into other parts of the cut audio. This brought me to the idea, to bounce and replace the audio, but to my surprise - the problem persisted.
Things like that should never show up in such a pro software.
The system this problem occured: Mac Pro 5.1 with RME PCIe MADI and HDSP card (to DigiFace), macOS Mojave, Nuendo 11.0.41

I’m sorry to say… it all works flawless here, and I guess this works on many other systems as well… There must be something wrong with your settings or your project file.
If this was a general problem, many had already complained about it.

1 Like

As mentioned, I never had any problems for many years with Export Audio Mixdown, that’s why I was so surprised. My settings are fine, I double checked everything. The project file works otherwise flawless, there were no crashes or shaky performance - ASIO settings on default. This is a very stable system I rely on every day.
Maybe it has to do with some plug in combinations. I restarted Nuendo and loaded just the project - same result, as if some problem was baked into it, but doesn’t show up until internal mixdown.

Sorry to ask the obvious - but is there a conflict with Control Room outputs, maybe?

I don’t use Control Room on this machine - as mentioned I have a Yamaha DM2000 which gets 48 channels from Nuendo via a RME MADI card. My other Nuendo machine has Control Room activated, but not this one → main machine.

You probably have to just troubleshoot it methodically. I’m not sure what your project looks like but I’d either a) start with the most likely culprit and eliminate it and try again, or b) do it in some sort of order, maybe by track number or plugin type or whatever, or c) by disabling “half” and see if the problem still exists. If not then it’s a problem with the other “half”. Then continue to “halve” the project until you’ve isolated the issue.

You could also try by starting a new clean project without anything in it and import tracks according to one of the ways above and try exporting again.

I’ve not seen this problem yet.

I’m absolutely able to think methodically and did lots of beta testing during my career. There were some efforts in that sense from my side to nail down the problem, but I cannot spend too much time with this. That is the reason I reported it.
Maybe there are some plug in combinations running havoc with Nuendos audio engine - I don’t know. This project has less than 10 audio tracks running, but channels have a lot of demanding plug ins, like Softube Weiss stuff etc. To test all out it would take many hours.
My trust in this Export Audio Mixdown function isn’t of course anymore like it was.
I could try to load the project on my other machine (HP workstation) and check if export would run without problems. That wouldn’t be to time consuming.

Yeah, sorry, I didn’t mean to be condescending or anything. We’re really just anonymous to each other a lot of the time on the internet so I didn’t assume anything really.

Since you label the thread “massive bug” though I think it would be good if you investigated it further. Without any information at all really all you’re likely to get is “well it works here”.


True - I would have written this too until then. I do what I can, but better to report it anyway than just being silent about it. Sometimes bugs can be very dependend on complex, multiple and tiny details, occuring very rarely. I have a very stable system here otherwise.

Have checked the samplerate of the files in the pool? As well as the clocking of your project?


That is a very good thought. The sampling rate of the project is 48 kHz and I double checked the Mixdown rate - also 48kHz (32 bit FP). I could do this, because I haven’t used Export Mixdown since then.
In the pool of the project was only one 44.1 kHz file as an FX, but it was NOT used in the actual project - just in the pool.
If there would be a SR mismatch, all sorts of blinking from devices would need my attention here - the DM2000 is the master clock and the RME cards are synced by it. And I have of course a clear routine to double check everything before producing masters.
One question comes to mind: can plug in chains interfere in such a bad way weaken the Export Mixdown function, that wrong audio parts get used during the mixdown?
If something goes wrong, someone would expect more things like crackles, clicks etc. But audio parts are missplaced. When this first occured, I thought I had accidently done something wrong and played in parallel the original mix and the mixdown - and it was at certain points so different! All audio in the project was correct - the mixdown had wrong parts in it! Even realtime mixdown gave the same errors.

Can you try to route your MasterBus thru a “Bus” onto a audiobtrack and do a real Realtime recording of it?

Route all AudioTracks as well as all groups, Fx, parallel comp stuff all to a bus called Master (instead of MainOutput). Now creat an audiotrack and select that Master bus as its input. Then print your mix in realtime.

Does every part play at its intended place?

All the best

Good idea - I think I will try this soon. Thank you.

Do you use hardware inserts? Maybe there is something getting “loose”

Yes, a lot - for two TC6000, two Quantecs, Jünger … but these are all connected with AES/EBU going into MADI. There is nothing “loose” … haha.
Beside that, the project with the failed mixdown was a complete ITB project, so to say. When I use external devices in Nuendo, the realtime mixdown was automatically suggested by Nuendo and never failed so far. This is a great feature.

What about a plugin that is oscillating an FX on the track(s) that have caused the issue. This type of not trusting the export mixdown is definitely a scary thing. I have run into a recent problem last year on export mixdown not related to this that has made me less trust worthy of it these days, but so far since a few recent updates all seems to be exporting properly.

Will be very interesting to hear what the conclusion of this is. I’m using Weiss myself, Gullfoss and Soothe, which all adds tremendous latency. It sounds like some issue with latency compensation or similar.

Good thing is that this specific project can reproduce it. Please report back if you find anything!

Damn, I tried to replicate the problem and I cant! All works just fine with the same project.
And I cannot trace the problem down anymore. I saw, that “Open In WaveLab” was also activated. Maybe that played a role too, although it worked fine now.
It can be a combination of problems, even combined with user error, although I cannot image what went wrong.
But I don’t want to damage the reputation of a very fine product and a great company (Steinberg). Therefore I will try to edit the headline and leave it to the moderators to delete this thread.
Something went wrong, but I cannot pinpoint the problem anymore.
Sorry, I was reporting this with the best intentions.