Ok and thx.
I feel like Captain Needa.
Of course, the customer tries to discover the wheel again and again and again…
Once again,
the number of samples is needed here!
Sorry for being such a nuisance. But we are talking about a reasonable option, imho.
48 kHz
0 samples + 8.4 ms != 8 ms
22 samples + 0 ms != 0 ms
25 samples + 0 ms = 1/48000 * 25 = 0.520833333… ms != 1 ms
24 samples + 0 ms != 0ms
If one is interested in why 1 ms is not good enough, check this video for instance.
Latency compensation should be perfect, I agree—down to the sample, not just to the millisecond. However, WaveLab already does this, provided plugins correctly report their latency (I am repeating myself…). I don’t intend to add an option for plugins requiring manual latency compensation (which is what you’re requesting, as far as I understand) because those plugins fail to report their latency accurately.
Suppose one does not want the latency compensation, but explicitly some samples of difference.
Then use the WaveLab SampleAlign plugin, this is done for this.
Well, then why give the latency anyways? Wouldn’t it be more appropriate to give the exact number of samples (in parentheses the ms, maybe) in the first place.
The granulation of 1 ms is very dependent on the sample rates.
The higher the latency at a specific point in the audio chain, the longer it takes for an edit made before that point to become audible. Providing latency values in human-friendly units (milliseconds) can be a helpful hint for users.
1 Like
Sure, nothing against userfriendly information. But it should be at least exact, which mere ms is not.
I guess for most users of WL the additional show of samples wouldn’t be that hard. There are lots of other things in WL, that are far more advanced than this.
Since there are no rational arguments against showing the numbers of samples (at least optional!) of latency, there might be some other motives beyond reason, which are not clear.
1 Like