Login

Transient loss

Tips & tricks, working results, technical support

Re: Transient loss

Postby yr » Mon Apr 09, 2012 7:43 pm

voidar wrote:Well, that might be, but if you use SPLITH mode SMOOTH will be turne to off.

From the manual:
"5 – SMOOTH
This parameter represents the smoothing algorithm. This mode is useful for minimizing distortion and
aliasing for the H1 kernel. There are 21 different algorithms available. When activated an additional
kernel player called S is instantiated. The player is shared with Split-hybrid, so the two modes cannot
be active at the same time."


I don't use the Splith mode for preamps/tapes etc, only the classic one. I haven't tested the sound difference between the 2 modes, but (commercial) 3rd party developers seem to be using the classic mode for preamps/consoles & tapes.
Reuven | post-production & sound-design | scenography |
website | nebula presets
User avatar
yr
Beta Tester
Beta Tester
 
Posts: 438
Joined: Mon Mar 29, 2010 9:04 am
Location: Amsterdam

Re: Transient loss

Postby voidar » Mon Apr 09, 2012 8:30 pm

Well, try it. You might be surepriced.

I am not sure I find a tenfold increase in CPU to be worth it. Especially when looking under the scope.
voidar
User Level III
User Level III
 
Posts: 33
Joined: Thu Dec 23, 2010 11:20 am

Re: Transient loss

Postby yr » Mon Apr 09, 2012 9:02 pm

You're right, it's worth testing. I'll try both modes on some tracks/loops and post the files later this week.
Reuven | post-production & sound-design | scenography |
website | nebula presets
User avatar
yr
Beta Tester
Beta Tester
 
Posts: 438
Joined: Mon Mar 29, 2010 9:04 am
Location: Amsterdam

Re: Transient loss

Postby TranscendingMusic » Mon Apr 09, 2012 9:55 pm

Hey guys...may be this could help with the idea of diminishing returns and what is worth the extra cpu here.
Or may be you won't agree with it at all :D

First, I will say these tweaks do create differences however pretty small and not necessarily beneficial. And as some of you guys pointed out, may be not worth it. There is one change that creates the most significant difference and I'll get to that in a second.

Comparing sum-differences with all tweaks vs. themselves AS WELL AS vs. each other where each one is summed to the raw file/source tells us the most. Listening is the best judge however ultimately, but sum-differences confirm for us that there is a change. Then further sum differences paired with the raw source file tells us where the change is. The one step of nulling is not enough for it only tells you there is a difference but you don't know which one is the one that is really different. So your list of test files should look like this at the end:

Raw track
Processed FreqD
Processed FreqD EVF17
Processed TimeD
Processed TimeD EVF17
Raw + Processed FreqD (SumD)
Raw + Processed FreqD EVF17 (SumD)
Processed FreqD + Processed FreqD (SumD)
Processed FreqD EVF17 + Processed FreqD (SumD)
Processed FreqD EVF17 + Processed FreqD EVF17 (SumD)
Raw + Processed TimeD (SumD)
Raw + Processed TimeD EVF17 (SumD)
Processed TimeD + Processed TimeD (SumD)
Processed TimeD EVF17 + Processed TimeD (SumD)
Processed TimeD EVF17 + Processed TimeD EVF17 (SumD)
Processed TimeD + Processed FreqD (SumD)
Processed TimeD EVF17 + Processed FreqD (SumD)
Processed TimeD + Processed FreqD EVF17 (SumD)
Processed TimeD EVF17 + Processed FreqD EVF17 (SumD)

If you followed each listening stage and went to the next logical file to rule out doubts or discrepancies, you may arrive to this conclusion:

TimeD = apparent more knock, weight with the clean Kernel on at least 10ms. (Turns out to be 'mud')
EVF17 = has more affect on compressor programs

Then after hearing and confirming where differences are there, let's make sure the modes themselves are not vastly different or not while all other things being equal:

Raw + FreqD Splith
Raw + FreqD Classic
Raw + TimeD Splith
Raw + FreqD Classic

Again, after following a certain scheme of logic where you listen to a certain pair and then move on to rule anything out you'd probably notice at this point that:

TimeD Classic (When button reads "Splith") vs. Time D Splith = most knock, weight (mud) difference
But also,
FreqD Classic = more knock compared to FreqD Splith
With,
Time D Classic out weighing them all.

FINALLY, the question is: is it the mode or the ms value under the Kernels???

So if you now compare the modes but with the same ms Clean Kernel value under TimeD column, you'll notice now that's the key for the most difference: when the ms value in that column is at least 10ms.
So we confirm that TimeD Clean Kernel set to at least 10ms gives us the most difference, sonically.

Difference doesn't mean better but it could.

The CPU difference with the increased ms value is:
1 - 3% using 2 instances of for example the excellent Doc Fear EQ.
4 - 13% using the same 2 instances with the increased ms value.

Most of the other differences regarding the sum-difference files were around -96 dBFS to -75 dBFS.

The MS value change again gave us the most change, confirmed by listening and nulling well in the significant audible range.

So it really is a question of your own preference and if you think the change is worth it vs. the CPU hit. I know we can all agree that no matter what way Nebula is set, it still sounds superior off the bat compared to a lot out there.

I personally do not prefer this tweak. In the grand scheme of a mix with all tracks engaged I get more of a "mud", low frequency build up with actually less clarity. This may bode well for some tracks but again for me the differences - and being detrimental most of the time - are not enough to compromise everything else.

EDIT: my most up to date opinion is that this tweak, at a min of 10ms, is more detrimental than beneficial. May be higher values work better? Anyway I'm sure everybody will do what they believe is right though :D
mixing | mastering
Win 10 x64 | Sonar Platinum x64 | 3930K(OC)
User avatar
TranscendingMusic
Expert
Expert
 
Posts: 1132
Joined: Sat Mar 27, 2010 7:01 am
Location: USA

Re: Transient loss

Postby Cupwise » Mon Apr 09, 2012 10:39 pm

again, i don't think it's fair to compare timed to freqd (classic modes) unless both have the exact same length. also again, i don't think any comparisons are meaningful unless they were made with the same prog rate, which depends on kernel lengths at least being similar. maybe one reason why people talk about timed having better transients is because with even 10ms timed, you (can, and automatically do by default) get a much faster prog rate than with 50ms freqd. i would imagine that might affect transients.

as for splith taking away the smoothing kernel, might be a thing to think about, maybe splith is best just used for non-dynamic stuff like eqs. on the other hand, maybe not every dynamic program will give artifacts without a smoothing kernel, so for those maybe splith is ok.

personally i'm leaning towards using freqd classic with 50ms length for listening while working on something, then switching to 50ms timed mode just before render. one thing i think is a benefit to this is that it's quick and easy, just a couple of clicks. if the program is set to splith while mixing/working, it takes more clicks, and more time to switch to timed before render, because you have to wait for the samples to re-load, and you might have to go turn on smoothing which requires ANOTHER re-load and several clicks. it becomes a huge hassle if you have several instances to switch over.

i only do it with the clean kernel though. i have noticed artifacts if all the others are switched over too. yr's graph seems to indicate that maybe it's ok to switch over even harmonics but not odd ones (or just not both?), for whatever reason.
Cupwise
Expert
Expert
 
Posts: 773
Joined: Tue Nov 23, 2010 2:03 am

Re: Transient loss

Postby misterambient » Mon Apr 09, 2012 10:48 pm

can anybody confirm artifacts in the odd and even kernels? I usually have good results setting all 3 kernels to timed with 10 to 12 ms, depending on the source (preamps, tape and consoles, not reverb and delays). things can get unstable when increasing odd and even kernels to 30 ms or more.
User avatar
misterambient
User Level V
User Level V
 
Posts: 55
Joined: Sat Mar 05, 2011 3:11 am
Location: The Netherlandz

Re: Transient loss

Postby yr » Mon Apr 09, 2012 11:10 pm

Cupwise wrote:personally i'm leaning towards using freqd classic with 50ms length for listening while working on something, then switching to 50ms timed mode just before render.


I've been doing the same last week (switching only the clean kernel for rendering). I think it's a good compromise.

You can switch either even or odd kernels to timed without adding artifacts apparently, but not both at the same time.

misterambient wrote:can anybody confirm artifacts in the odd and even kernels? I usually have good results setting all 3 kernels to timed with 10 to 12 ms, depending on the source (preamps, tape and consoles, not reverb and delays). things can get unstable when increasing odd and even kernels to 30 ms or more.


Just looking at the analyzer, kernel length doesn't seem to solve the artifacts when all kernels are switched to timed. Short clean kernel lengths do seem to negatively effect the amount of aliasing, but only listening tests can say if it's a meaningful difference:

MWC clean 50ms vs 10ms:
50&10.jpg
50&10.jpg (65.15 KiB) Viewed 1170 times
Reuven | post-production & sound-design | scenography |
website | nebula presets
User avatar
yr
Beta Tester
Beta Tester
 
Posts: 438
Joined: Mon Mar 29, 2010 9:04 am
Location: Amsterdam

Re: Transient loss

Postby david1103 » Mon Apr 09, 2012 11:36 pm

great work everyone researching this!

personally i'm leaning towards using freqd classic with 50ms length for listening while working on something, then switching to 50ms timed mode just before render.


interesting! if a program, like doc fear has a clean kernal length of 90ms, would reducing it to 50ms not effect quality? some eq's have 180ms clean kernal. has anyone tested the effect of reducing kernal length? why would developers have such long ones?

yr wrote
You can switch either even or odd kernels to timed without adding artifacts apparently, but not both at the same time.


is this a bug?... sounds odd.

i thought i heard it sound better on TIMED for the 10ms distortion kernals.

could giancarlo, join this thread and straighten things out?!

1. are distortion kernals ok for TIMED
2. what are the artifacts being shown in the analyser on the distortion kernals in TIMED?
3. can TIMED be CPU optimised further?
4. What are the dangers of reducing kernal length?
5. any other info in this exciting subject ;)

THANKS!
User avatar
david1103
Beta Tester
Beta Tester
 
Posts: 516
Joined: Wed Mar 31, 2010 12:26 am

Re: Transient loss

Postby Tim Petherick » Tue Apr 10, 2012 1:42 am

Nice one guys , This thread is going in the right direction,this is what is needed on the forum .

Tim
User avatar
Tim Petherick
Expert
Expert
 
Posts: 1352
Joined: Sat Apr 17, 2010 4:07 pm
Location: Bath , Uk

Re: Transient loss

Postby RJHollins » Tue Apr 10, 2012 3:50 am

First, big THANKS to 'TransMusic' on the last post !
... and of course, our contributing Community !

Admittedly, I've been a 'sideliner' reading through
the experimentations and following comments.

I still have several questions on all of this. Apologies
to others' in that I've not had the time opportunity
since moving into my new Control Room to experiment
with NEBULA settings.

Two issues ...

No one has outright said that 2 versions of a particular
patch can exist [simply by renaming the patch name] so
that a WORKING copy, and a FINAL RENDER copy could
be selected. [the CPU hit seems a major deterrent].

2nd ... The mod being referenced to a 'clean' kernel
ONLY is something that raises the eyebrows :shock:

If only a single, clean kernel is being used ... does
this not fly totally against the efforts of NEBULA's
initial strength ... multi-level convolution ???

Am I not understanding this correctly? I hope so !!

Before I question further, I'd appreciate any clarification
on these question ...

THANKS! :mrgreen:
i7-5820k, MSI X99A Plus, 16 GIG Ram, Noctua NH-D14, Win-7 Pro [64-bit], Reaper-64

NVC [Nebula Virtual Controllers]
RJHollins
Expert
Expert
 
Posts: 2632
Joined: Sun Mar 28, 2010 5:53 pm

PreviousNext

Return to Working with Nebula

Who is online

Users browsing this forum: No registered users and 6 guests