User stamp vs Timecode stamp... WHAT?

[Eric Seaberg]

We've been doing the same thing for YEARS... and now, all of a sudden, when we export clips as files the TIMECODE STAMP changes. The difference is almost random, but when I go to import the file into another PT session, I'm given the option of spotting to USER stamp, or TC stamp and the USER location is correct.

How could this have changed? I can't find any option to do this and sessions that were mixed a few months ago all have the proper TC stamp.

BTW, this has magically shown up on two of our systems, both running 2019.6 on High Sierra. I even back-rev'd to 2019.5 and deleted ALL prefs... no difference.

Anyone else seen this? Our Avid guys are able to spot our audio by slipping it comparing the audio, but TC is now unusable.

Thanks for the help!

[Eric Seaberg]

Let me explain a little better what we're doing...

We're playing back a 75 to 85 track session, mixing it through our SSL C200 console, and recording back into 5.1 and Stereo tracks in the same session. All timecode and sync is ref'd to our house master and is correct... placement of the mix files in the session is at the correct TC, 09:00:49;18 for example.

We highlight the 5.1 and Stereo mixes we just recorded and hit Command-Shift-K to export the new clips as files, saving them to a specific place on our facility SAN.

When the files are selected and imported into an Avid session by one of our video editors, the timestamp of the files is no longer 09:00:29;18 but 09:04:55;25. If I try to import the same file into a separate Pro Tools session and spot it to TC, the window shows the timecode stamp at the new 09:04:55;25, but with a user position of the original 09:00:29;18.

This has NEVER happened before, and is now happening on two separate systems. Odd thing is, going back to the original session the real-time bounce was done in... if we select the mixes in the clip list and spot it to a new track, it drops at the correct, original TC stamp. As soon as I import it back into the session after the export is done, it's dropped at the newer, later spot.

Like I said, we've been working this way for over 10-years on the SSL without ever having this happen. Even importing files that were only mixed a couple of months ago, places them at the correct spot... but these newer exports aren't right.

Again, any help or insight would be appreciated. Thanks...

[Led]

Something to do with session start time in the session settings of the 85 track session maybe? Just a guess..

[Frank Kruse]

TC rate mismatch in the session setup maybe? As you probably know there is no actual TC rate info in the BWAV (at least not from PT) just a "samples after midnight" stamp. The actual TC is calculated by the program that opens the file so if your DAW is set to a different TC rate than the creating session the TC stamp will be shown differently even though inside the file meta-data is still the same.

Not saying it's not a bug. Just to rule out the above. It's probably the wrong idea if you've tried to re-import the exported file into the same session already and it was wrong. I've just done this on my system and it was correct and user stamp was the same as the original TC.

[BScout]

What Frank said.

TC stamp is based on samples after midnight. There is no SMPTE information (feet, frames, actual hours:minutes:seconds) in a timestamp.

An incorrect timestamp is probably about the session it is being imported into since timestamp is recalculated based on those settings.

[Eric Seaberg]

Thanks for the replies... odd thing is, all of the sessions we do with the SSL are created with a template that has a start time of 07:00:30;00 and it never changes. I will confirm that again when I get in, but the fact that older mix files from May are fine, and these last ones aren't... real head scratcher.

I'll keep looking. I have some other theories about the 2nd system that's wrong.


Thanks!

[Eric Seaberg]

Originally Posted by BScout

What Frank said.

TC stamp is based on samples after midnight. There is no SMPTE information (feet, frames, actual hours:minutes:seconds) in a timestamp.

An incorrect timestamp is probably about the session it is being imported into since timestamp is recalculated based on those settings.

I can kinda believe that when importing back into a ProTools session, but we've been pulling files into Avid for years and the time-stamp of the file has never been an issue.

I'll keep looking.

[Eric Seaberg]

Originally Posted by Frank Kruse

TC rate mismatch in the session setup maybe?

The SSL would warn us if that were the case. Everything is ref'd to video and house TC. Good idea, though.

[Frank Kruse]

Originally Posted by Eric Seaberg

The SSL would warn us if that were the case. Everything is ref'd to video and house TC. Good idea, though.

Yeah but the SSL has nothing to do with your session, no? Try to re-import the exact same file you exported into that same session that you exported from and see what happens. Also make sure you're not exporting with a different sample rate setting in the command-shift-k menu.
Just to rule out any odd settings on the AVID side or the other session you are importing into earlier.

If that file comes in fine it must be some odd setting on one of the other systems PT or AVID.

Just to find the cause step my step. Maybe it is in fact a bug.

[Frank Kruse]

Originally Posted by Eric Seaberg

Thanks for the replies... odd thing is, all of the sessions we do with the SSL are created with a template that has a start time of 07:00:30;00 and it never changes. I will confirm that again when I get in, but the fact that older mix files from May are fine, and these last ones aren't... real head scratcher.

I'll keep looking. I have some other theories about the 2nd system that's wrong.


Thanks!

"07:00:30;00" means you're running drop frame? 30drop or 29.97drop? could be something there especially on the AVID side. Depending on the AVID project settings.