Nuendo 6

[narcoman]

Originally Posted by oceantracks

When would you do this...buss a buss to a buss or multiple busses? I'm just curious....could you give examples? Just trying to learn here..

T

Subdrum busses - not so much for pop music - but in soundtrack stuff do this sort of hierarchical approach a lot. Nested VCAs and groups as well - something Logic doesn't have a hope in hell of doing at the moment. Intrigued by N6s possibilities though. We'll upgrade next year after a few months.

[ErikG]

I have a list of needed improvements for MediaBay, but even then I still feel the integration within the program makes it a better choice than soundminer.
I have yet to actually try to use basehead for real, perhaps it's better, but it's still another non integrated program.

[oceantracks]

narcoman...

Doesn't it drive you crazy in Nuendo/Cubase not to be able to move mixer channels around (without going to yet another window FIRST to do so)?

I mean on a large session that is a total nightmare. Another long requested feature Steinberg ignores...must not be possible or something.

[narcoman]

Originally Posted by oceantracks

narcoman...

Doesn't it drive you crazy in Nuendo/Cubase not to be able to move mixer channels around (without going to yet another window FIRST to do so)?

I mean on a large session that is a total nightmare. Another long requested feature Steinberg ignores...must not be possible or something.

It would if I was a big Nuendo user - but thats the other guys here. Yeah - that would be a pain for me .

[Steven1145]

Originally Posted by oceantracks

When would you do this...buss a buss to a buss or multiple busses? I'm just curious....could you give examples? Just trying to learn here..

T

Dialog tracks to separate mono groups for either separate processing (denoise, deess, comp...) and then going to the main DIAL stem, then to the MAIN mix. I do it all the time here, and it can be done easily in Nuendo.

Sent from my XT910 using Tapatalk

[ErikG]

And just because Steven wrote mono, doesn't mean they have to be, they can be any channel format.
And we can pan those busses as well, no problems. In PT you still can't pan multichannel buses or tracks (without extra plugins)...

[oceantracks]

Originally Posted by Steven1145

Dialog tracks to separate mono groups for either separate processing (denoise, deess, comp...) and then going to the main DIAL stem, then to the MAIN mix. I do it all the time here, and it can be done easily in Nuendo.

Sent from my XT910 using Tapatalk

Wouldn't that be the same as sending those tracks to a mono Aux for processing and then from that Aux to the main DIAL Aux?

TH

[dmitri]

Originally Posted by apple-q

Just just couldn't see the logic in your other posting. You couldn't anything below 1000$ for PT (EdiCue+EdiPromt is about 1100$ bundled) so you want to demo a 2000$ alternative.

Regarding ADR software, I want to demo every option: EdiCue+Edipromt, VoiceQ, Synchronos, Nuendo, anything else... Seeing different approaches and possibilities enriches one's own workflow.

[kdm]

Originally Posted by Steven1145

N5 video engine is really quite solid, and a good step up from the N4 one which had dodgy sync.
FWIW the PT video engine could also display cases of "variable" sync, hence the introduction of tools like Syncheck.

Sent from my XT910 using Tapatalk

N5 was drifting by about 10 frames in the first 0:30-1:00 on every Quicktime file I used. I found it with my sync-check file. I tried many different compressed/uncompressed formats to be sure - even PJPeg drifted. The same files did not drift in ProTools, or any other DAW on the same system (I typically check 3 when I can just to be sure ProTools is accurate as well - for the reasons you've stated).

That's where I had no choice but to move to ProTools. I never found a reason for the drift, but it did not lend confidence in Nuendo 5 to say the least. I did have N4 on this system as well - perhaps the N5 install shared some component with N4 that caused this problem.

[ErikG]

I've never had drift like that ever, that's crazy!
but I think there's a bell ringing somewhere...
kdm you are american right?
If I remember right they did have problems with pulled pictures for a while. We don't do that here in Europe, so not a big problem for us. All good now to my knowledge.

[apple-q]

Originally Posted by ErikG

I've never had drift like that ever, that's crazy!
but I think there's a bell ringing somewhere...
kdm you are american right?
If I remember right they did have problems with pulled pictures for a while. We don't do that here in Europe, so not a big problem for us. All good now to my knowledge.

10 frames in 30seconds isn't even remotely close to pull-down (0.1%)

[kdm]

Erik - yes I am, and I do recall some issue with pulled, or maybe 29.97 in general, but that wasn't it. Correct apple-q - that was my first clue it was a different issue. It was way outside of pulldown, and I wasn't doing any pull with my test sync file (or any other I tried).

I tested 24fps, 23.98, 29.97 drop/non, etc. Same result.

It was very unsettling to say the least. I think I even removed/reinstalled a couple of different versions of Quicktime just to see if N5 somehow introduced compatibility issues with one version or another, all to no avail.

I reported it on the forum, and to Steinberg directly, but got no response at all. As long as someone else said it wasn't happening, they ignored my reports - that's really what ended my time with Nuendo. It wasn't my system. I was positive of that (this was an ADK system). I actually think I tested 4-5 DAWs and Nuendo was the only one drifting. If Nuendo 5 was that system-sensitive, it wasn't reliable enough for a longterm solution.

So with deadlines looming, PT was my only option, and it has worked perfectly ever since. I would like to reconsider Nuendo, but this experience (and the truncated video imports in N4) leaves me very suspect of putting it into a production environment.

[ErikG]

Weird, I have never had that happen ever. I have seven Nuendo licenses and have never ever had a issue like that since I started using Nuendo 3.x.
But the thing I heard of (way back) was that there was a bug with dropframe timecode or pulled video or something causing video to play out of sync.
When was it that you had the problem?

In PT however we get cut off video files, out of sync playback using h264 (i know h264 sucks but it should still work, it does in nuendo).
Not to mention the fact that when trying to re-record ONE stem gets out of sync like 15 frames, all delay comp is green. Reduce the number of simultaneous recorded stems and then there's no problem. Oh and no problem when NOT recording. NO high latency plugins at all...

So if you changed platform because of bad video sync, if you've had similar tething problems we've had with PT10 then you might have considered a return to Nuendo? :-)

[kdm]

Sometimes I think Steinberg gives you guys in Europe a different build of Nuendo. lol

The problem was with Nuendo 5 (5.1?) - 400 hr demo key from Steinberg.

Yes, if PT had similar issues, I would have to look elsewhere, but the difference is I know many other PT/post people here that have never had similar problems with PT in years of cutting shows, film, etc. PT has never failed sync here, and I check it from time to time just to be sure. It doesn't make it the perfect DAW, but sync is one thing I can't simply hope will work. I also never use H264 unless it's a short scoring job - it's a recipe for sync problems for anything longer.

I'm not trying to slag Nuendo here - it just has a more rocky history with me and everyone I know who has used it here in the US. I like ProTools, but know it also has it's faults and limitations. They just don't seem to fall in the critical path as often as Nuendo's faults seem too (i.e. Steinberg is good at adding cool features, while leaving basic requirements up in the air - AAF anyone?).

I hope N6 can turn that around, but client relationships require some caution and pragmatism when considering a DAW that has yet to prove a consistent level of reliability in the post world. I would like to see the ADR taker work well, but in this case I think it pays to be skeptical. Then there is the loudness metering that seems to have omitted the US-required LKFS/1770-1 (unless I missed something in the videos/feature list?).

[tom_lowe]

Originally Posted by kdm

Then there is the loudness metering that seems to have omitted the US-required LKFS/1770-1 (unless I missed something in the videos/feature list?).

EBU R.128 is based on ITU. 1770/1 so shouldn't be an issue. the biggest difference being EBU R.128 aims for -23 not -24. Recommendations from the EBU were adopted in 1770-2, so they are incredibly similar.

In N6 you can also set custom levels in the loudness meter, so you can use it for any loudness specs.

[kdm]

Originally Posted by tom_lowe

EBU R.128 is based on ITU. 1770/1 so shouldn't be an issue. the biggest difference being EBU R.128 aims for -23 not -24. Recommendations from the EBU were adopted in 1770-2, so they are incredibly similar.

In N6 you can also set custom levels in the loudness meter, so you can use it for any loudness specs.

I was assuming so as well, but according to what I'm reading, in the US the CALM act refers specifically to 1770-1, which does not include the gate in EBU R.128/1770-2, and broadcasters here are legally bound to that law, even if by a misleading semantic. ATSC A/85 is based on the anchor concept (dialog, lead vocal, etc for loudness), where gating would apply when the anchor isn't present (though it seems like this has never really been implemented since there is no simple way to do it). All of these are based on 1770-1, but the problem seems to be that North America took a detour from 1770-1 where Europe continued into 1770-2 (and now TC Electronic says LM6 supports 1770-3).

I know this is technically OT for this thread, but it seems to leave some question as to whether N6's implementation will actually work here in the US for a final compliance pass. I've talked to other engineers that are saying their comparison results of gated vs. non-gated are different enough on some material that it won't. I need to do some testing myself this week.

Maybe you, or some of the other US post people here will have a better take on this than I do, and how N6's implementation will affect us (or not)?

[Fredo]

The main difference between 1770-1 and 1770-2 is the gate which "freezes" the loudness reading when the audio drops below a certain thereshold. Since CALM is used for commercials, and commercials only, it is highly unlikely that the gate function will kick in.

Fredo

[UnderTow]

Originally Posted by Fredo

The main difference between 1770-1 and 1770-2 is the gate which "freezes" the loudness reading when the audio drops below a certain thereshold. Since CALM is used for commercials, and commercials only, it is highly unlikely that the gate function will kick in.

Fredo

Still strange that Steinberg didn't include ATSC A/85. At least if that is really the case. Maybe they just demoed everything in R128 mode. They are Europeans after all.

Alistair

[Fredo]

The problem is that the CALM act is not clear.
The ATSC A/85 adopts the ITU-R 1770 standard.
They don't specify that it should be 1770-1. At the time of the creation of FCC 11-84 however, it was 1770-1.
The document also mentions that "ITU is currently considering improvements to its recommendation" (which is/was 1770-2)
But FCC 11-84 is not clear about using 1770-1 (at the creation of the document) or the current 1770-2.
They just say "1770". In theory, this should refer to the lastest spec.

There is another conflicting thingy somewhere -which I can't seem to find now/it has been a while since I worked on this- which makes it even more unclear if 1770-1 or 1770-2 needs to be used for CALM.
In this respect I have contacted the people at EBU and it was confirmed by two members of the R128 board that:

a) CALM is unclear about which spec to use (1770-1 or 1770-2)
b) in 99,9% of all cases there should no difference if the commercial is measured by the 1770-1 or 1770-2 algo. And even if the readings are off, they will still be within specs.


HTH
Fredo

[smurfyou]

Originally Posted by apple-q

Can N6 superimpose TC, and wipes out a blackmagic card running 1080p video? That would indeed be a step ahead.

Just wanted to point out Fairlight has been able to do this for 5 years now. TC, wipe, beeps, and optionally the script. Although I've always thought having the script on-screen is distracting so I just have it print the cue number.

I still think the loudness curve is a neat idea if it works properly. On PT, the Waves WLM meter will write an automation track but it just registers overs and unders. Still neat but having the full curve would be nice.

[kdm]

Originally Posted by Fredo

There is another conflicting thingy somewhere -which I can't seem to find now/it has been a while since I worked on this- which makes it even more unclear if 1770-1 or 1770-2 needs to be used for CALM.

You are probably referring to the anchor material requirement (or more likely, "recommendation" since there seems to be no specific resolution) - dialog or VO being the reference point for LKFS measurement, supposedly with gating only including non-anchor material.

a) CALM is unclear about which spec to use (1770-1 or 1770-2)
b) in 99,9% of all cases there should no difference if the commercial is measured by the 1770-1 or 1770-2 algo. And even if the readings are off, they will still be within specs.

Assuming all ads are squashed to the hilt there might not be much difference, but I thought part of the reason for CALM (from the audio community perspective at least) was to improve dynamic range. It's partly there, but maybe not really.

I need to do more thorough tests, but just ran a quick test of -1 and -2 on a short promo with a bit more dynamic than the average, and got noticeably different results - which would mean 2-3 db lower mixes depending on which spec I use on what material. Basically, an ad could be rendered noticeably quieter under one or the other, depending on material, and whether there are quieter spaces, as is common in some mostly VO, light FX and ending music ads.

I could be wrong since it may all even out to some degree, but think this lack of clarity will become audible to the consumer - maybe not consistently, but there will still be noticeably quieter ads, and noticeably wider dynamic range ads.

I think the "mix programmer" concept may have just found a career in advertising.....

[Fredo]

Originally Posted by kdm

dialog or VO being the reference point for LKFS measurement, supposedly with gating only including non-anchor material.

No, ITU-R BS 1770 doesn't have dialog reference/detection like the Dolby LM100.
Or did I misunderstood the question?

Regarding the gate:

2.3 The measurement gate
The ‘integrated loudness’ shall be measured using the gating function specified in ITU-R BS.1770-2, summarised as follows:
1. using an absolute 'silence' gating threshold at -70 LUFS for the computation of the absolute-gated loudness level;

2. using a relative gating threshold, 10 LU below the absolute-gated loudness level;

3. The measurement input to which the gating threshold is applied is the loudness of the 400 ms blocks with a constant overlap between consecutive gating blocks of 75%.

If the end of an integrated loudness measurement lies within a gating block, the incomplete gating block shall be discarded.

So it would take a few seconds of near silence to trick the system into showing different readings between 1770-1 and 1770-2.

but just ran a quick test of -1 and -2 on a short promo with a bit more dynamic than the average, and got noticeably different results

That seems odd to me. Identical, "normal", program material, onec measure by 1770-1 and once by 1770-2, resulting in different readings?

Basically, an ad could be rendered noticeably quieter under one or the other, depending on material, and whether there are quieter spaces, as is common in some mostly VO, light FX and ending music ads.

Yes, of course. It's exactly the same as with Leq(m) mixing. A client who wants a loud Voice-Over from wall to wall, will result in a commercial that "feels" less loud than a commercial with more dynamic content. That's where the mixing skills of the engineer comes in. I also have noticed that using little to no compression on voices isn't the better solution. It's about finding that subtle balance between making a "sound", making it loud without compromising loudness.

I recently had to deal with a 20" add with a loud Voice-Over and a bunch of Monsters Screaming in the back + a loud music track. That is a recipy for disaster in terms of making the commercial "loud". Strangely enough, I got much better results with squashing the complete M&E and balancing it versus the Voice-Over, than to keep the dynamics in the M&E and nicely drop the Voice-Over in between the violence. So, yes. It's different for every commercial. But in the end, a skilled engineer should be able to mix any commercial equally loud, while staying within R128 specs.

Fredo

[dmitri]

Originally Posted by smurfyou

I still think the loudness curve is a neat idea if it works properly. On PT, the Waves WLM meter will write an automation track but it just registers overs and unders. Still neat but having the full curve would be nice.

Seems like the new Izotope Insight writes a loudness curve as an automation line in Pro Tools, as well as marking overs.

[kdm]

Originally Posted by Fredo

No, ITU-R BS 1770 doesn't have dialog reference/detection like the Dolby LM100.
Or did I misunderstood the question?

It doesn't apply to you, but the US CALM act is based on ATSC A/85, which uses an "anchor element" for the target loudness measurement. This could be dialog, voice over, effects or music.... or if none is prevalent, all of the above, and that overall level would be reported as "Dialog".

Here's the problem that seems to be a common theme with a lot of reports on this standard (including some manufacturer white papers); ATSC A/85 and by virtue, CALM, really don't say whether to exclude overall loudness from consideration, or whether to isolate dialog and only measure it to -24 LKFS (though that almost seems implied).

This same doc also says +/-2db variance from the -24 LKFS recommendation (and it reads like a recommendation, not an absolute requirement), is to be expected.

Okay, fine, we can figure out what we think will work best, but what happens when broadcasters or spot check services decide on their own method of determining the anchor element, or how to ignore it for a mass-qc process? Eventually this will settle out to some commonly accepted practice, but to me it seems like a half-baked "standard".

Regarding the gate:

[I]2.3 The measurement gate
The ‘integrated loudness’ shall be measured using the gating function specified in ITU-R BS.1770-2, summarised as follows:

The CALM act and ATSC A/85 only say to "refer to the latest version of 1770" and that the gate (at the time) was being investigated. Apparently there is now 1770-3 that suggests using Leq(RLB).

So that implies that we should be using 1770-3 in the US - Leq(RLB), but I don't find it applied anywhere yet, and 1770-3 looks like more of a recommendation - using the "latest version" of a recommendation is hardly a basis for establishing any standard. Welcome to the US legal system.

That seems odd to me. Identical, "normal", program material, onec measure by 1770-1 and once by 1770-2, resulting in different readings?

Why? The gate is going to eliminate quieter material from measurement, depending on length. For more dynamic material, that is going to be more of a factor. So, that implies that R128 from Nuendo/Steinberg may not suffice for US broadcast delivery. At least I and everyone I talk to is leary of sending material out based on this version of the spec alone, when we have a legal requirement that implies otherwise.

So, yes. It's different for every commercial. But in the end, a skilled engineer should be able to mix any commercial equally loud, while staying within R128 specs.

I think the assumption of "a skilled engineer" in this context is implied, and beside the point. While I'm arguing against the ambiguity of this "spec", I'm fine with the additional complexity as that creates job security for us in the audio world and appeals to my uber-tech geek side. :-))

The way I interpret this spec on the US side, and how weighted loudness is calculated, I can see it causing as many problems as it is intended to solve, simply by virtue of it's own ambiguities.

[danijel]

Originally Posted by dmitri

Seems like the new Izotope Insight writes a loudness curve as an automation line in Pro Tools, as well as marking overs.

Yes it does.

[ErikG]

I'm sure there CAN be differences. I havent tested enough material yet, but comparing Waves WLM to the built in meter and PPMulator3 the difference is quite small comparing R128 to ATSC 85 A2 (WLM) and ATSC 85 DialogWhen I get exactly -23 on R128 I'm getting -24 on the other LKFS meter, and thats the goal right?
With material that has only a little dialog there IS a difference though. With sparse dialog and high dynamics there's about 0.5 dB on my material. Still within spec.

With raw unmixed material I can get a bigger difference about 2db.

What kind of material are you running to get any significant differences?


EDIT:OK there ARE differences... Sorry about doubting. First time actually comparing...
Yes there are differences when comparing, the more "polished" the mix is the less there is a difference, with a rough bad sounding mix the difference can vary a bit more approx 3db so far. So that's a total difference of 2db (since LKFS should be -24 and LUFS shoud be -23. Still there IS a clear difference.
So the more of a mess the sound is the larger the difference it seems to me.
So I agree we need a US standard metering as well. Only question is WHAT standard to use...

[smurfyou]

Seems like the new Izotope Insight writes a loudness curve as an automation line in Pro Tools, as well as marking overs.

Originally Posted by danijel

Yes it does.

Are you already using the Insight meter? Does anyone know what the CPU usage is like with it?

[ErikG]

Izotope Insight indeed writes to a automation track, but not in the way the Nuendo meter does, it will just write overs so the user can find the problem areas. The Nuendo loudness track seems to be more intelligent.

[danijel]

Originally Posted by smurfyou

Are you already using the Insight meter? Does anyone know what the CPU usage is like with it?

I've been testing Insight during the beta phase, but I'm not really into metering, and loudness metering is not yet required where I am, so I can't give you a real-world opinion. However, I just tried this - exit Nuendo, fire up PT10+CPTK on Win7x64, make 20 audio tracks and 10 aux tracks, insert a couple of random plugins and audio files - look at CPU usage - it says 6%. Load up Insight on the 5.1 aux - it jumps to 14%, and when I hit play, it's between 14 and 15. My CPU is i7 2600k.

BTW, Insight is in its default state, meaning - all modules ON.

New test - no matter which modules are ON or OFF, it will always eat up the same amount of CPU. But if I close the GUI, my meter drops to 10%.

[smurfyou]

Originally Posted by danijel

I've been testing Insight during the beta phase, but I'm not really into metering, and loudness metering is not yet required where I am, so I can't give you a real-world opinion. However, I just tried this - exit Nuendo, fire up PT10+CPTK on Win7x64, make 20 audio tracks and 10 aux tracks, insert a couple of random plugins and audio files - look at CPU usage - it says 6%. Load up Insight on the 5.1 aux - it jumps to 14%, and when I hit play, it's between 14 and 15. My CPU is i7 2600k.

BTW, Insight is in its default state, meaning - all modules ON.

New test - no matter which modules are ON or OFF, it will always eat up the same amount of CPU. But if I close the GUI, my meter drops to 10%.

Thanks for the quick test!