I have a question for those of you who chase code. I recently discovered our RME tco cards have a “significant” (putting it politely) wrong offset when chasing ltc. While I’m embarrassed I never checked - now I know. There is no method in the RME control panel to fix this.
As far as I can tell Nuendo has no way to compensate for this.
There’s the Display Offset but I think this does not do what I need because it just affects the display so files exported to other apps (common for us) will still be incorrect.
There’s also the Record Offset but that won’t help with playback chasing code.
Seems to me in the Sync Setup window there should be an “offset” field that applies to external sync to fix this.
Thanks for the responses. We use the tco, of course it’s in the sync settings page. It’s just not accurate. That’s not the issue. Every sync device I’ve used (and I was an Adams-Smith expert in the 24trk days!) has an offset. How do I do this in Nuendo? Very basic function. REALLY absurd this does not exist. Anyone?
I use a ff800 with Timecode option.
However thye timecode option ONLY works with a PC not a MAC because it only has an ASIO driver.
If you run MAC, most options within timecode land are very much ignored… (this I found out the hard way)
I now use a MOTU digital timepiece & convert SMPTE to MTC resolved to video. This works a treat but doesn’t help Hugh’s original question re offsets.
I could’ve sworn there is an LTC offset somewhere within Nuendo’s sync page but I can’t find it.
It could be in the ASIO protocol & that’s where I remembered it from… dunno
But my suggestion will work as I’ve just had to offset 30 TV eps to accomodate a 9 sec prize read…
Thanks for the workaround suggestion but I’m not sure how to accommodate. If we record into the project then offset everything by a specific amount, we still have the original timestamps that must be updated before export to the other platform. Reading the manual it appears Update Origin will do this, but the manual indicates it only does it at the cursor location (not sure), so that won’t work on a whole project of files. Unless I’m mistaken. I’ll have to give that a try.
After offset (and possibly Update Origin if that works) we can chase code for playback, but then we record into the project some more, and only those files need to be offset. Probably a better option is to adjust the Record Offset setting (haven’t tried it), but then when we import files to timestamp instead of recording we must offset those imported files before chasing for playback.
No matter whether we offset on Record or before Playback, either way we get into complications importing, exporting, and re-recording stems. Timecode offset is a basic chase function (looking at our X-48s here, even they have it) and it seems odd that it’s not there.
I’m not sure I fully understand what you’re doing… If we record into the project then offset everything by a specific amount, we still have the original timestamps that must be updated before export to the other platform.
When you export, (if I’m reading you correctly) you are sending BWAV files only ??
Will an OMF or AES export at the new locations not work for you ??
At least then the project is relevant to the new “edit” (??) positions & then any subsequent “new” recordings are in their correct place.
Or have I missed the point re original time stamps ??
Another possible (pain in the arse) workaround…
Lock an X48 to incoming LTC with the offset applied & then chase the time code from it ???
Makes for a really expensive timecode offset though…
It is a major oversight from Steinberg though… even if you & I are the only people in the world still using timecode…
We usually export via AAF so those shifted files will stick. However we often will chase code for playback for a quick rehearsal remix, then continue to record into the project later. Additionally the Avid folks will often request a file to fix something, in the middle of everything else. And my largest concern - making things work for the less-than-stellar operators who are often running the recorders. Telling them that this system doesn’t accurately time stamp files and they have to expend mental energy compensating is the quickest way I know to get our systems tossed out of the facilities.
Initially I thought I was being obtuse. I think the bottom line here is that this most basic synchronizer function, which used to exist, is now gone. Not sure yet where to go with that.
Display Offset does a very smart thing, if you’re running video from within Nuendo and using a PCI card or Firewire to drive an external pix monitor.
It compensates for latency in the video system. Nuendo is kicking out picture to the PCI bus or Firewire exactly in sync with your timeline. But a lot of video devices have anywhere from 1 to 5 frames or so latency to turn that signal into video for the monitor.
So Display Offset applies the offset only when you’re running at play speed.
If you’re manually scrubbing or marking, the latency doesn’t matter - so what if a still picture takes 150ms to appear, you’re going to be looking at it longer than that. So the Display Offset isn’t applied.
It won’t, however, compensate for a TC track that’s constantly off. (Or for the 14-frame difference between front-load and top-load 3/4", if you’re an old-timer.)
Is the offset of the recorded files only a couple of frames ?
Does the offset change or is it always the same value.
We had the same problem over here. Nuendo synced to LTC and when we synced the bwav files in another system they were not in sync though the TC information was correct, but the recorded audio was not in sync.
After a lot of experiments installing the last RME drivers solved the problem and all recordings are in perfect sync, on every system.
Correct it doesn’t work sadly on the entire project and will only update one selected region at a time. The manual says select the clip in the pool and then move the project cursor to the location you want. However you don’t have to select it in the pool and can select it in the project window, you also don’t need to update the cursor position and can run the command, but again it only works (unfortunately) on one audio event at a time.