How exact are the latency values?

[Sunnyman]

When using plugins, there is sometimes the amount of latency in ms available, sometimes not.

1. Why are those times not available for every plugin?
2. How accurate are those number actually? (I did’t measure them yet…)
3. Can it be changed to an accurate number? Like # of samples ?
4. How often are they recalculated?

Thx

Addenum
43 ms at 48 kHz should be 2064 samples, right?
Using 2 identical tracks.
First track: MSpectralDelay plugins does nothing, except for “43ms” latency.
Second track (phase inverted): Check with MUtility → set to 488 Samples (to get cancelation, check in Mastersection)

As expected: When changing the samples in MUtility for just one, i.,e. 487 or 489, we hear a lot of sound again. So 488 samples seems the delay. But it should be 2064 samples, because of 43 ms, right?

What is wrong here? What do 43ms want to tell us here?

I start to wonder of how accurate Audio Montage is.

Does Wavelab make use of the feature “Report as latency” (“negative delay”) ?

[PG1]

@Sunnyman

• Why are those times not available for every plugin?

Not all plugins have latency.

@Sunnyman

• How accurate are those number actually? (I did’t measure them yet…)

The latency is provided by the plugin, as samples. According to the sample rate, WaveLab convert this to milliseconds, which is more friendly.

@Sunnyman

• Can it be changed to an accurate number? Like # of samples ?

No. And I don’t see a reason for such an option.

@Sunnyman

1. How often are they recalculated?

When playback starts.

[Sunnyman]

Thx,

it would be conveniant to have at least an option to choose what to show, ms or samples. I prefer samples, because it is as accurate as it can be.

In the example stated, it should be clear, that something is wrong.
Either the plugins gives a wrong number of ms or the calculation afterwards in ms is wrong.
If the plugin gives the information in samples, than why not show this as an option?

The good reason seems to me the exact timing adjustment of the tracks.
There are cases, when a sample counts.
It also makes a difference, when working with 32 kHz or 192 kHz. 192 kHz is 6 times more precise than 32 kHz; somewhere in between 0ms and 1 ms…

Does Wavelab make use of the feature “Report as latency” (“negative delay”) ?

[PG1]

@Sunnyman

The good reason seems to me the exact timing adjustment of the tracks

To do the latency compensation, WaveLab uses samples internally, not milliseconds. Hence I still don’t see what the latency information could be useful for as samples, for you to use.

@Sunnyman

Does Wavelab make use of the feature “Report as latency” (“negative delay”) ?

I don’t know what you mean.

[Sunnyman]

Here is a very basic example.

Take 2 mono tracks, one for the left, one for the right channel output.
Now, on channel one, there is a plugin (like MSpectraldealy) with some latency, say 43 ms. The other channel has no plugin (or a different one).
Than the resulting stereo file as two channels of different length.
To adjust the length of both channels, I have to introduce some extra latency to match the exact ending.

For this the exact information of samples is needed.

Before:

After (without correction)

With 43ms correction

So, it would be really helpful to see the exact number of samples for the latency.
Imagine the phase issues afterwards when mixing mor together… I am not sure, if many people here are aware of this issue. One may try to fix this later on with EQ etc. But the cause is the latency in the chain. And for this, the exact number of samples might be helpful.

And it should not be that much of a problem, becuase as you said already “WaveLab uses samples internally, not milliseconds”.

Converning the “negative latency”, I can only refer to this

Does Wavelab handle this?

---

Addendum
Concerning the mentioned 43 ms and the number of samples, I will ask Melda about it, because approximately43 ms (2064 samples) seems correct. What those 488 samples are to adjust remains a new mystery by now.

This is the end after 43 ms… not exactly

Some more samples are needed for the exact match

This is the sweet spot:

2135 samples != 2064 samples = 48000 (samples/sec) *43sec /1000

→ Therefore an exact information beyound “ms” is necessary.

---

→ I just need some clarification of how Wavelab handles the latencies in order to get exact results in the end.
Thx!

Idealy, every sample carries an extra flag with its enumeration (first sample, second sample, third sample and so on…) and after a plugin, the program checks wheteher the flags of different chanels are still in correct position to each other… but I doubt, that this will be feasible, so it’s just an idea… there would be a substantial amount of extra book keeping necessary, which I do no expect. So, fine, year…

[PG1]

@Sunnyman

Take 2 mono tracks, one for the left, one for the right channel output.
Now, on channel one, there is a plugin (like MSpectraldealy) with some latency, say 43 ms. The other channel has no plugin (or a different one).
Than the resulting stereo file as two channels of different length.

If that happens, that means your plugin does not report the latency correctly (plugin bug).
Because, of course, WaveLab does latency compensation between tracks when the plugins declare correct latencies.
Hence, if your plugin does not report the latency correctly, I see even less sense to report the latency it declares as samples.

[Sunnyman]

I added some information in the previous text.

Finally we see, that the mere information of ms is not enough, becuase it is only an approximate value.

[48000Hz]
The difference is exactly 2135 samples
Wavelab says 43 ms

43 ms = 2064 samples
44 ms = 2112 samples
45 ms = 2160 samples

So the (example) plugin produces a latency of 2135/48000 ms = 44,479 … ~ 44,5 ms of latency

And to match this exactly, the number of samples is needed.
Ok, maybe it is not possible in principle to give a generalized answer to this., because the samples have no internal enumeration (which as said, could not be expected easily).

Sorry, to bother with such nitpicking details, but I have usecases here, where this matters.
And yes, fun is something completely different…
Sure, if this would be the only problem the world has, it would be a phantastic world.
Have a nice day.

It should be no big deal to add one or two lines of code to show the #samples next to the ms.
It’s actual a string out of a calculation, right?
Something like that, I guess…
string latency= “[” + latency_in_ms().ToString() + “]” + " " + “[” + latency_in_samples().ToString() +“]”;
Not rocket science

[PG1]

I will repeat myself: you don’t need latency figures if your plugin has no bug. And if your plugin has a latency report bug, the latency value, be in samples, has no value.

You say you have usecases where this matters. But I don’t understand this usercase.

[Sunnyman]

Pls, don’t tell the customer what he needs, ok?

No need to repeat oneself, just solve the issue - it’s that simple.

Needed is a realiable information on the sample level about latency after using plugins of different tracks… That’s it.

If it’s too much to ask for a simple extra line of code to give this answer, than sorry.

[PG1]

Implementing a new feature requires spending resources, time, manual work, testing, etc. Hence, before I accept implementing something, I need good reasons, and the new feature must address a real issue that affects more than one user. Perhaps I’ve overlooked something, but as I tried to explain, I don’t see what problem displaying latency in samples would solve, assuming the plugins are bug-free. I don’t want to implement something to solve a problem caused by a plug-in with bugs.

@Sunnyman

just solve the issue

There is no issue. You are requesting a new option, which is not the same thing.

@Sunnyman

about latency after using plugins of different tracks

Please read what I have already explained twice on this topic. WaveLab has full latency compensation across tracks, provided your plugins correctly report their latency. If you don’t understand something in my explanation, ask me.

[Hko]

Finally we see, that the mere information of ms is not enough, becuase it is only an approximate value.

[48000Hz]
The difference is exactly 2135 samples
Wavelab says 43 ms

43 ms = 2064 samples
44 ms = 2112 samples
45 ms = 2160 samples

It seems to me that you just ignored what PG stated about how Wavelab deals with latency. Internally Wavelab uses the latency which the plugins report as samples and compensates for the latency using these values. Your usecases are based on the need to see the latency as samples because some plugins obviously report false latency values - how would it help you if you saw the faulty latency value as samples instead of milliseconds? You would still need to inspect and adjust the outcome by studying what the real latency is. When plugins report the real latency, it does not matter which values are shown as plugin latency value, because it is compensated for and the audio is in synch.

[Sunnyman]

Nope!
Use two monotracks, one has a plugin, the other not. The latency caused by the plugin must be compensated afterwards. For this, the latency in samples is needed.
Rewasd my post for word and try to understand the case, pls.

[S-EHansson]

Try this…

Voxengo Latency Delay - Audio Latency Compensation Plugin VST, AU, AAX

regards S-EH

[Sunnyman]

Thx a lot!!!

I’ll try this for sure.

[PG1]

@S-EHansson

Try this…

Voxengo Latency Delay - Audio Latency Compensation Plugin VST, AU, AAX

WaveLab 12 has a somehow similar plugin called SampleAlign.

[Sunnyman]

Thx PG

Ok, since it appears, that the latency is beforehand in general unpredictable, I came to the following solution:

• Use one track with plugins, routed to the left.

• Use another track completely without any plugins, i. e. the original, routed to the right.

• Both tracks contain, for the first second, complete zeros. Than one sharp impulse of one sample to -1 dB.

• The actual datatransformation will start after 5 seconds.

• Afterwards, we check the resultand stereo file and look for the first impuls and extract here the latency as number of samples.

• Than adjust accordingly.

Two question remain:

• Is there a way for Wavelab to do this automatically? (I doubt it, though)
• How to start the plugin chain in audio montage/clip 5 seconds after the render process has begun?

[Sunnyman]

No, I am not satiesfied with “ms”!
The exact # of samples is needed!

Here is another example with 16 samples difference and it says 0 ms.

ShaperBox in its init state:

ms needs division, which creates rounding errors, therefore 0 ms is plain wrong here!

16 (samples)/48000(samples/second)=0.0003333333…(seconds)=0,3333333…ms > 0 ms
→ round (0.33333…)=0

→ This needs a fix (display the number of samples), no matter what!

Why does this matter?
Imagine s stereo signal out of two slightly different tracks. One can get a lot of unwanted comb filtering, cancellation or other stuff. This is surely not something we want, right?
I wonder how many people are running into this problem and they assume ms is enough and start eq-ing or other procedures to correct this?
So, please provide the exact number of latency samples.
(Wavelab can show 0ms or other numbvers, fine. They are calculated out of raw data, the samples. So why not show the number of samples directly? Or at least as an option for the nitpickers… Why show 0ms at all, if it is true zero? Because it is not, it is a rounding artefact here.)

Decades ago in a lecture of numerical mathematics I learned something very fundamental:
“When in integer - stay in integer! - float is evil !”

[PG1]

@Sunnyman

Decades ago in a lecture of numerical mathematics I learned something very fundamental:
“When in integer - stay in integer! - float is evil !”

I agree with that, this is why WaveLab uses integers internally to make perfect latency compensation (for plugins that report their latency correctly, and this always as integers).

I don’t know what plugins you are using, but try to use Steinberg plugins, for example, to see that sample accurate latency compensation is done by WaveLab.

@Sunnyman

Is there a way for Wavelab to do this automatically? (I doubt it, though)

Maybe the Null Test track feature can help you.

[Sunnyman]

What is the purpose of this Null Test?

If it is done exactly as it is written, of course we get zero.

1. Render the track - fine, we get a new file, ok.
   2 and 3. Adding the Null Test Track, which invertes the previously rendered file.
2. Great surprise it all nulls out. We hear nothing…

{
written is this, maybe the automatic numbering of the editor needs improvement?

}

Result: The produced playback, consisting of the original plus a phase inverted same signal, gives no sound.
Year, that seems like magic, like rocket science to me (I am being sarcastic here.)

What’s the use of this?
Of course we get zero… A + (-A) = Zero,… what an amazing statement this is.
And how could it be of use to get the exact number of latency samples?

The plugins used here are:

MSpectralDelay | MeldaProduction

Cableguys | ShaperBox 3

It seems like you want to avoid the main topic:
ms + # of samples
Which I don’t understand, because from a programmers point of view, the # of samples is clear instead of programming a function, that gives ms after some calculation. As you said before

And is this possible?

---

Anyway, if it’s not possible or not feasible to implement this, fine, the world will continue to exist - no big deal.

[PG1]

@Sunnyman

It seems like you want to avoid the main topic:
ms + # of samples

The topic of latency compensation is something I have been working on for 25+ years, so I know what I am talking about. I will not explain again what I tried to already explain earlier in this thread.

@Sunnyman

• Is there a way for Wavelab to do this automatically? (I doubt it, though)

WaveLab 12 has a DSP tool to align correlated clips. This is an offline process.

Other than that, there is the SampleAlign plugin, already mentioned, to delay audio channels, by manually entering sample offset.

There is nothing else.

@Sunnyman

• How to start the plugin chain in audio montage/clip 5 seconds after the render process has begun?

Not sure what you mean. A clip plugin begins processing with the start of the clip. There is no way to start the processing 5 seconds after. Else, split the clip and have the first 5 seconds without any plugin.