UNRELIABLE REAL TIME EXPORT

I was volume automating a snare track and I noticed the track level meter giving different peak levels on different playbacks of the same hits.

So I rendered a mixdown twice - with just the snare soloed - then used the wavelab file comparer. it determined that the files were different. There were no plugins involved by the way - just the snare track soloed with volume automation.

I then tried non real time rendering and 2 different exports come up identical. So the issue is unpredictable playback - which it’s doing during real time rendering. i use external effects, so I have to use real time rendering…

No response yet?

This strikes me as a rather severe bug: think about it; every time I export a mixdown it will be different. This forum should allow audio examples, but of course it does not, so I cannot at this point demonstrate what cubase is doing.

Going over my test exports yesterday, within the first 12 seconds I found an incidence of a snare drum hits with a difference of 4dB between files! Just to be clear we are talking about THE SAME DRUM HIT as exported 2 times using real time export!

I tend to think this issue is limited to high transient material, because were cubase to be this unreliable with everything, playback would be a jumbled mess. I have no idea how this would happen, but even if this issue is, bizarrely enough, limited to snare drums - think of the implications!

Have you tried this in a new project with one snare track only?

(Also, is this an audio recording you’re talking about, as opposed to a VST?)

Yes. A real snare drum, and there were no plugins or other processing involved. Not sure why I should have to take out other tracks. Normally I have to mix songs with all the instrumentation intact. It’s happening with several different projects, so it’s not just one corrupt project file if that’s what you’re thinking.

This should not even be possible.

Hoping for a response from Steinberg soon. This is unacceptable.

By the way, when NOT using real time export the results of 2 separate mixdown exports ARE identical.

However, I use a lot of hardware for mixing, so that fact is of little help. Plus I would think most everyone assumes the the file export will be exactly the same as what they have been listening to, but evidently, this is NOT a valid assumption.

(just to be clear, again, there was nothing inserted in the signal path when I did my test - I do understand that when hardware is involved the results will never be identical. Also, this isn’t a theoretical or inaudible difference - 4dB is easy for anyone to hear, and I think what it’s doing is occasionally shaving off the loudest part of the initial transient. When i compare 2 hits that are supposed to have been identical but are way different, the quieter one seems to have less attack)

Of course it shouldn’t be possible! I asked the questions strictly with an eye to creating a bug report.

The behavior has to be isolated to determine what’s going on, so the testing has to be done excluding external gear, in a clean project.

For troubleshooting.

Please include your system info too.

Apologies.

I created a fresh project, imported a snare over and snare under track, then real time exported it twice. The results were not identical.

My system is:
Cubase 7.5.30
Lynx aes16e, driver 2.0 build 019g
Lynx L22
PC, Intel core i7 875K
Asus P7P55-D
16 gb DDR3 ram
Nvidia Gforce 7300 SE/7200 GS graphics card
UAD 2 Quad
UAD 2 solo
Windows 7 64 bit, up to date

And, as you can see, I’ve now included that info in my sig. :slight_smile:

And finally, I removed the snare under track so there was just mono track going to the stereo output and exported it twice; again the results were not identical.

By the way this was a different snare track - I just picked one randomly for this test.

i would guess at this point I could begin testing other sources, but I actually have work to do. I would have to think this isn’t only happening with snare tracks, but that, for some reason the impact is most noticeable with snares perhaps due to the high transient content. When I compare the results from different exports of what should be identical hits - the quietest one sound as if the attack has been shaved off to some extent.

i am no where near clipping by the way :slight_smile:

Is this with or without voume automation now?

I just did some more tests.

When the volume automation is removed, the inconsistencies become inaudible - you have to test, generate a difference file, then normalize it to hear anything.

So I guess this is mostly a volume automation problem - although I tend to think the results of subsequent renders should still be mathematically equal

I think you’re right. It’s related to Cubase not having sample-accurate automation.

Between posts I checked with someone who has expertise in that area, and that’s what he said.

So a solution might be to make the automation less precise - i.e. automate it up a good bit before transients. It’s still odd to me that I never notice this problem with other automations. I have noticed the inconsistent playback on snare tracks before, but I assumed it had something to do with the timing of starting the playback together with the hardware inserts I usually have on the track before I automate, and that it would be somewhat consistent (minus the inherent inconsistency of incorporating hardware)…

Is the lack of sample accurate automation considered an issue that Steinberg intends to fix?

I wouldn’t know that, but they have acknowledged it: [R-8250] Automation delayed by ASIO latency setting

Here’s a longer discussion too. Automation playback delayed based on latency?

So a solution might be to make the automation less precise - i.e. automate it up a good bit before transients. It’s still odd to me that I never notice this problem with other automations

Yes that solution will work…As you’ll see from those other threads, the automation timing changes with buffer settings, so if you have a particularly large buffer/latency this may be why you are noticing it now when you haven’t before??

Well, there’s 3 aspects of the situation -

  1. I guess the playback behavior is non linear and variable
  2. I have occasionally noticed artifacts, but as you add 18 channels of hardware, it takes cubase longer to get playback up to 100%, so what I had noticed in the past, I attributed to that.
  3. I just updated to 7.5, so this is the first time I’ve used Alt to Transient and hence made the automation consistently tight to the transients

So, I’ve found that globally moving the automation points back makes the playback consistent.

Question: how far back is the minimum required to assure that the automation point will work in time and (in this particular application, manual gating plus volume automation) no transients are chopped off? If my buffer is 1024 and sample rate 88.2?

I’ve always unconsciously known this to be the case.
(Automation not being sample accurate)
I usually automate Tom fills instead of gating them.
If the automation was too near the hit, the attack was too soft.
So I learned to leave a little room before the hits.

At least now I know why…

Any particular reason why this thread was moved out of the issue forum? I’ve done a few more tests (see here: http://www.steinberg.net/forums/viewtopic.php?f=181&t=33083&p=386276#p386276 )

Based on a 10 second test, I’ve found that essentially the automation points can result in the automation actually occurring up to 10ms before or after the point was placed in the timeline.

Is this really not considered a problem that the developers ought to be trying to solve?