zoom accuracy

zoom accuracy

I’m wondering if other people here are having the same problem. I’m using 5.08, build 2275. When I’m zoomed in on the waves, everything matches up perfectly. However, once I zoom out past a certain point, the visual representation of a wave jumps out of sync with the audio by anywhere up to a fifth of a second. This makes editing more difficult; is anyone else encountering this?

Hi droppedD:
I think you can lessen the latency of the scanned timeline by closing any applications you might have running in the background… If you look at the lower right-hand corner of the n-Track screen you’ll see the plug-ins latency… That is a factor of how long your system takes to display n-Track’s timeline after you hear the audio of the waveform, or .npk file(s) that is on the timeline… The timeline I’m looking at in the song I have on my setup right now is Plug-ins total latency is 23 ms=1000 samples… That’s quite a significant amount of latency.

You are not alone in looking at latency… There are a number of things you can do to lessen the latency issues…

Bill…

[EDIT]
The higher number of tracks you stream from your hard drive the higher the latency figures…

Thanks, Bill. I don’t think this is a latency issue, unless I’m misunderstanding how n-track generates the waveforms, since nothing is actually playing at the time. Here’s an example of what is happening:

I’ve recorded a guitar in track 1, and one of the played notes shows a peak displayed at 2:16.20. After zooming in, this peak is now displayed just before 2:16.00.

Zooming in shows the “correct” position, at least relative to other tracks. For instance, if I want a kick drum in track 2 to strike at exactly the same time that the note is played on guitar, I have to match the two tracks up while zoomed in. If I then zoom out, the two now simultaneous sounds will not appear in the same place on the timeline, though the audio will play them at the same time.

It’s pretty obnoxious while editing, so I’m surprised no one else has brought it up. If no one else is having this problem, then perhaps I should reinstall or roll back to an older version.

Hi Again:
Some audio cards don’t like Recording-and-Reproducing at sample rates of 44,1 or 44,8 kbs. So as a result, they convert the sample rates on-the-fly… So, for example, if you set your system to record at sample rate that your audio card has to make n-Track convert the sample rate on-the-fly you may see the wave file on the timeline somewhat out of sync from the audio that you hear… So , if you see this , you might try recording and reproducing at 48 kbs. instead of 44,1 kbs.

You’ll see this setting in the Preferences>Record Settings… That might be something for you to consider…

Bill…

Bill, I still think you’re missing the point. This is entirely a graphics issue and has nothing to do with the soundcard. It’s been that way since latter V3 versions, frankly, and I should have filed a bug report long ago – though I don’t think I’ve seen it more than say 100 msec and just guessing at that.

This happens with a wave file imported from anywhere, so it has nothing to do with the soundcard.

To some extent, this kind of thing is inescapable, because each horizontal pixel is a summary of a number of data file points. However, if that were the only issue, then it would be off by at most a pixel, which is not the case. And it drives me nuts too – I have to remember to always zoom in to where the display format changes (goes assymetric above and below the center, for example, and the lines get less thick) when selecting edit points or doing time-sensitive volume evolutions.

While we’re at it, I’d love to see the “summarized” waveform display (the kind where it’s lower rez, where it’s always symmetrical and other differences from the zoomed in version) have the option of showing the peak value in the range rather than an arbitrary data point per horizontal pixel (as I believe it does now). The former would be very useful, but I believe it would take more CPU time when scrolling the timeline. Either that or else much bigger .npk files.

Note that both types of display are useful. The arbitrary-point style gives a much better impression of overall loudness, except for odd cases like a click track zoomed way out, where whole beats often get lost – you get what’s essentially an interference pattern.

Gee, I guess I should put this stuff in a feature request. If it’s not already in V5, that is.

Hi learjeff:
Thanks for your post regarding this thread/topic…

I have this print screen I’m gonna post with this reply… Maybe, I’ll post another one of another timeline with only one .wav file on the timeline… I’ll post this on another reply… later…

Anyway, This one is a Kick track of a project that I’ve brought forward that was started way back in v4.x? maybe earlier. I’m not sure of the original build…

This is v5.0.9 build 2283 beat…the latest build posted…First, you’ll see the kick track solo’d … It now hi-lights… while the other tracks on the timeline are “Darkened”… Is that the descriptive term? Anyway, the cursor is at a point on the timeline that is before the kick sounds on the timeline The meter’s are not displaying any audio output… Yet, the note is playing the from the audio card…



I’m gonna say that the note that the audio card is playing is the waveform that is to the right of the timeline cursor…

Here’s the print of the timeline showing the total timeline as to where the kick track is located compared to what all is happening on the timeline. e.g. The number of tracks, .etc. The cursor on the second screen has not changed… the zoom level has just been backed off to show the total timeline…



I’m gonna estimate the the … Lets call IT… “The View Latency”… for any other term… Remember, the note has already Played/Sounded…

Does this view co-oberate this latency issue?

If these prints show this correctly, then maybe, we can get Flavio to see what he thinks of all this… and see if he can dulicate this on his set-up and see if he can Ponder this…

Bill…

SETTINGS/refresh view - re-calculate waveform -

Dr J

Hi Doc and Gents:
Thanks for posting on this thread…

I promised and here’s the other print that goes with this quandary…

Again… Build 2283 beta…



I have a “Click Track” installed on this file. It represents as close a click as I can make…

The count is: 1 - and - 2 - and - 3 - and - 4 - and - 1 - and - 2 - and - 3 - and - 4 - and - … SO-ON…

This might make another technical exercise… with-in n-Track… But, that’s another quandary/Ponder…

Anyway, I got to a point on the timeline after pushing the Play Button, where I started a “Count” and then Pushed the “Print-Screen” button (on count) to capture the image… This is what I captured… “On-The-Fly”…

What I am able to determine is… there is Little-if-Any Latency on this particular timeline as it relates to this timeline and wave file sync issue…

Notice the lower right-hand corner … There is NO Plug-ins total latency: I have an MPL-1 Pro SE Limiter on the channel strip… but I have it turned Off… Even if I had it turned on the plug-in latency would affect the cursor/timeline latency, very little-if-any… So, I don’t believe the issue is plug-ins Latency.

I have a lot of plug-ins going on that multi-track timeline. I think the total plug-ins latency is 1000 ms, or so…

You’re right… I makes it tough to edit a .npk file on one track…

Doc:
I think I have tried a Refresh/Re-calulate .npk files and I have not seen any improvement of where the timeline cursor and audio re-play times… sync up…

Bill…

Back Again Gents:
I have another print showing this in as simple as I can reduce this whatever-it-is…

Before I closed this n-Track timeline I pushed the play button and captured this image… I should have spent more time doing this as the Sync-Times could have been displayed a little more accurately…

Anyway, can someone explain why the meters are showing amplitude when the timeline cursor is not scanning the .npk file on the timeline… ?????



learjeff:
Do you think Flavio might be able to re-create this and come up with a “Fix” for this “Video” latency ????

Bill…

Hi Gents:
Further to this latency issue… I have a link to the song on the last timeline… Tiqulia Sunrise

This file is an mp3 @192khz. resolution… If you have v5 installed on your DAW an mp3 file can be directly imported into an n-Track timeline… n-Track automatically converts files to .wav files for use on it’s timeline. The wave file properties of this file is… The “Offset” on this file on my n-Track timeline is 0:01:02 the length is 2:57:00

It would be interesting to see if these properties can be re-created on your timeline to equal the identical specs. Is this possible with transportation and converting this file on another DAW that has n-Track installed on it?

It seems to me that this feature was built into the later versions of n-Track… OR… does this only hold true if the transportated files and .wav files… ????

Bill…

Bill, play with the “meters anticipate soundcard output” option (or something like that) in Preferences. At least, I think that’s the issue here.

If you rig your system for low latency, the difference becomes minimal.

I usually use the “anticipates” mode because then the output meters show how far over zero the values go. In the other mode, the meters match the sound as it comes out the soundcard, but the max value above the meter is zero.

We should apologize to droppedD here for all the off-topic stuff. Or maybe I should just file a bug report!

Jeff

Hi learjeff and droppedD:
I don’t see this as “Off Topic” I believe all this is the same as why droppedD opened the topic for…

I wanted to look for the place in the preferences where “the “anticipates” mode” used to be… however I am unable to find that screen now… at least in v5.0.9 beta…

With all the track editing I did in the Hurt Me More project it is an impossible task to do as it appears now… If I remember, most of the editing I did on that timeline was done in build 2099…

I have a feeling that Flavio is ready to bring v5.0.9 out of beta… with v5.0.1 or something… It’s quite possible that this issue is connected to beta…

Who knows ????

Bill…

Hey, thanks for the post, DR Jackrabbit. Very succinctly solved my problem.

Thanks to everyone else too, and I certainly don’t mind any off-topic discussion, so no apologies necessary!

<!–QuoteBegin>

QUOTE
certainly don’t mind any off-topic discussion


Cool! How about that Ichiro!!! :)

(droppedD @ Jul. 10 2007,21:08)
QUOTE
Hey, thanks for the post, DR Jackrabbit. Very succinctly solved my problem.

Thanks to everyone else too, and I certainly don't mind any off-topic discussion, so no apologies necessary!

Interesting, and excellent that rebuilding the ntk files solved the problem.

I wonder why? Still seems to me that there must be a bug here. And I'm sure I tried that years ago when the problem first happened to me, with no luck.

This problem happened seemingly always, when I was mixing a lot, mosty using latter V3 versions. Been doing less mixing since I upgraded to V4 so not sure about that.


(woxnerw @ Jul. 10 2007,04:37)
QUOTE
Hi learjeff and droppedD:
I don’t see this as “Off Topic” I believe all this is the same as why droppedD opened the topic for…

As I explained above, this is a completely different issue.

One is merely a display issue involving the graphic shown in the waveform. You issue has to do with a number of other factors. If you follow my advice it should become a non-issue for you. I believe that your issue is simply how n-Track works (and you get two options, whether it anticipates the output or not, and it IS related to soundcard latency, and you can minimize it by reducing latency).

The OP’s post was about where the waveform sits on the timeline, and that it’s different for zoomed-in versus zoomed out. This has nothing to do with the audio during playback.

Your issue concerns playback and the difference between what you see on the screen and what you hear as it plays. In theory these two issues could be related, but I’m quite familiar with both items, and they’re really not. Actually, since the zoomed-out display places the sound earlier in the timeline, it would reduce your problem rather than cause it.

But in any case, no worries, keep chatting about it. Just try the stuff I said.

Gentlemen:
Go back to post # 1 of this topic…

I don’t see anyone of you using the latest build…

Could it be and maybe, you are talking about past issues or present/past issues?

[Quote]
SETTINGS/refresh view - re-calculate waveform -

Dr J

[EDIT] Doc… You may be dealing with the latest build(s)…

Refreshing and re- calculating/re-building the n-Track peak file doesn’t appear to resolve the problem… At least with the latest series of timeline/lag/latency issues that I’m contending with…

I realize that this series of issues could very well arise from Cross-Builds-and-Versions of n-Track… But that doesn’t mean they’re not there… AND… I’m not having to deal with them…

Who amongst you are dealing with editing/re-importing tracks into the present build that were created in earlier versions/builds of n-Track ????

[Quote]
But in any case, no worries, keep chatting about it. Just try the stuff I said.


Unless we’re using the same (latest build) we may not be on the same page AND we are more-than-likely talking about several un-related issues… I think , if you get back to using n-Track, you may have to deal with this on your Setups, if-and-when you arrive at this space-in-time…


[QUOTE]
The OP’s post was about where the waveform sits on the timeline, and that it’s different for zoomed-in versus zoomed out.


Tell me you use n-Track to edit/cut-and-paste a snare hit, a kick hit, or a bass note using a view that shows the entire n-Track peak file/waveform from start-to-finish… without zooming in on the timeline…

[QUOTE]
This has nothing to do with the audio during playback.


You’re right learjeff…

AND…

What we’re seeing on the timeline (when the cursor is scanning the wave files on the timeline) has nothing to do with the audio we’re hearing from the audio card…

I think that’s one thing we’re agreeing on…

Continuing… ????

I seem to be picking on you by quoting you…

[Quote]
Your issue concerns playback and the difference between what you see on the screen and what you hear as it plays. In theory these two issues could be related, but I’m quite familiar with both items, and they’re really not.


I’m reading between the Lines here by saying this-about-that…

It seems as though you have doubts regarding what I place in my posts on this matter…

In theory, I agree with your statement about the theory of these issues… BUT… Beyond that statement in your quote… In actuality, that is what I hear-and-see when I play a series of track(s) on the n-Track timeline(s) on my machines…

As I see it… Theory… Practice… at this point-in-time, it’s all the same thing…

Seeing-and-Hearing a difference as to what appears on the Meters and Timelines… of n-Track…

[QUOTE]
If you rig your system for low latency, the difference becomes minimal.


Streaming Tracks just don’t happen with a P-111 1.2mhz. XP Desk… I have to rig my machine for the best possible performance specs.


Bill…