MOTUnation.com

The move to original time stamp feature seems to be broken for me or maybe I am doing something wrong. when I am recording vocals, and my session crashes, I used to never worry... all I had to do is bring the clips back to DP and click on move to original time stamp and they would just pop back to the location I recorded them at...

This no longer works... DP either tells me there is no timestamp associated with the clips or moves them to measure 1 for me...

any ideas why this no longer works for me or what conditions would make clips not have an original time stamp?

thanks in advance...

I've found the same thing unless I saved before the crash. I don't know if this was always the case prior to 5.13, was it?

This is a problem that started occuring from 5.12 onwards.

What happens is that DP doesn't write a timestamp to the audio file till you create a region within the audio file. One thing you can do (until they fix it, which I hope will be soon), is once you've created a soundbite by recording, edge edit it - even just by trimming the end of the soundbite by a fraction of a second, it will force a 'region' to be created and the audio file will now have a timestamp. That's the best I've been able to come up with. Also, try and record exactly from a bar boundary - this makes it heaps easier to line it up again if you do get the awful crash just after that perfect take (not always feasible, i realise).

Mr_Clifford wrote:This is a problem that started occuring from 5.12 onwards.

What happens is that DP doesn't write a timestamp to the audio file till you create a region within the audio file. One thing you can do (until they fix it, which I hope will be soon), is once you've created a soundbite by recording, edge edit it - even just by trimming the end of the soundbite by a fraction of a second, it will force a 'region' to be created and the audio file will now have a timestamp. That's the best I've been able to come up with. Also, try and record exactly from a bar boundary - this makes it heaps easier to line it up again if you do get the awful crash just after that perfect take (not always feasible, i realise).

Whoa I didn't know this. I rely on time stamping quite a lot but havn't been affected because i decided to stay on 4.61 till 6 comes out but I hope they fix it because if time stamping is not fixed I may not be able to use it.

Now you got me a little worried

kassonica wrote: Whoa I didn't know this. I rely on time stamping quite a lot but havn't been affected because i decided to stay on 4.61 till 6 comes out but I hope they fix it because if time stamping is not fixed I may not be able to use it.

Now you got me a little worried

I'll keep you posted. It will be one of the first things I test once I get DP6 as I also rely on timestamping a lot. Funny thing is that the timestamp still works within DP immediately after recording. It's just if you get a crash before you save, or try to export it to another program (eg. Pro Tools) that it's mysteriously not there.

It works exactly how it should in DP 5.11 - I did toy with going back to 5.11 at one stage, probably should have - all up the best version of DP5 to date IMO.

Mr_Clifford wrote:

kassonica wrote: Whoa I didn't know this. I rely on time stamping quite a lot but havn't been affected because i decided to stay on 4.61 till 6 comes out but I hope they fix it because if time stamping is not fixed I may not be able to use it.

Now you got me a little worried

I'll keep you posted. It will be one of the first things I test once I get DP6 as I also rely on timestamping a lot. Funny thing is that the timestamp still works within DP immediately after recording. It's just if you get a crash before you save, or try to export it to another program (eg. Pro Tools) that it's mysteriously not there.

It works exactly how it should in DP 5.11 - I did toy with going back to 5.11 at one stage, probably should have - all up the best version of DP5 to date IMO.

Much thanks.

So if you save or don't have a crash it works.

Still if the system crashes even after a save is the TS data is lost then?

I bet this has something to do with running 16 and 24 bit files at the same time.

I'll be keeping my eye on this and thanks for doing the same.

kassonica wrote: So if you save or don't have a crash it works.

Still if the system crashes even after a save is the TS data is lost then?

Well if you've saved then the soundbite is still sitting on your timeline so you'll be fine. The only problem then is exporting to another DAW, in which case you have to select the soundbites and trim the edge a bit to get it to 'write' the timestamp into the audio file with the new region that it's created.

Try recording some audio, then open the 'import audio dialog box' and select the file - you'll notice that there's the audiofile icon listed, but not the second 'region' listed underneath (the one with the 'wave' symbol). I think that the timestamp is saved in the region definition, and so, without one, you don't get a timestamp.

I bet this has something to do with running 16 and 24 bit files at the same time.

I suspect more to do with the way that, since 5.12, there's now a different naming scheme for SDII files. Although I can't see how that would have affected it. Either way, you can bet that while they were 'under the hood' changing things, something got broken.

BTW - I suspect that once we go to Broadcast Wave in DP6, this problem will just go away, as the timestamp of a B-Cast wave file is saved in the file header, and therefore should get saved as soon as we record.

+1+1 For broadcast wave. Can't wait till that day.

it's going to be months I bet....

martian wrote:it's going to be months I bet....

God I hope not.

But i have to admit the longer it is you got to wonder what it is thats holding them up.

this comes under the header of "intersting/valuable things I wish I'd have known a couple of weeks ago!"
Reason is that I was doing a film score (23 cues) that would wind up in ProTools. PTools has a "spot to OriginalTimeStamp (OTS)" feature that makes it a breeze to drop DP recorded 2-mixes in to a PTools session at the correct places. It makes it a breeze, that is, *IF* DP is creating a correct/readable OTS in to every 2-mix. Of the 23 cues, a little over 1/3 of them showed up as "out-of-range" when we tried to drop them in to a PTools session, then went back to discover that they had OTS's of 0:00:00.00, despite when they were actually recorded!
A bit of a pain. Hope the BWAV thing will sort this out....

Posted: 26 May 2008 10:34 pm Post subject:
This is a problem that started occuring from 5.12 onwards.

What happens is that DP doesn't write a timestamp to the audio file till you create a region within the audio file. One thing you can do (until they fix it, which I hope will be soon), is once you've created a soundbite by recording, edge edit it - even just by trimming the end of the soundbite by a fraction of a second, it will force a 'region' to be created and the audio file will now have a timestamp. That's the best I've been able to come up with. Also, try and record exactly from a bar boundary - this makes it heaps easier to line it up again if you do get the awful crash just after that perfect take (not always feasible, i realise).

not sure i understand this? i'm working in 5.13 at the moment, and after recording a q, i import it into another "chunk" (ugh) which has all the q's for the film in. i just drag it from the soundbites window and select "move to original timestamp."


works a treat - or am i missing something?

but also can't wait for broadcast wav so i can export for the dubbing suites.

doodles wrote: not sure i understand this? i'm working in 5.13 at the moment, and after recording a q, i import it into another "chunk" (ugh) which has all the q's for the film in. i just drag it from the soundbites window and select "move to original timestamp."

works a treat - or am i missing something?

Yeah, that's how it happens. After you record the audio it looks like it's all fine. The timestamp will be listed in the soundbites window and you can copy it to another sequence no problem. The problem is if DP crashes before you have saved, you'll import the audiofile back into your project and there's no timestamp - because it never got saved into the audiofile.

You have to use 5.1.1 to get TStamps without incident. I found out the hard way too.

williemyers wrote:this comes under the header of "intersting/valuable things I wish I'd have known a couple of weeks ago!"
Reason is that I was doing a film score (23 cues) that would wind up in ProTools. PTools has a "spot to OriginalTimeStamp (OTS)" feature that makes it a breeze to drop DP recorded 2-mixes in to a PTools session at the correct places. It makes it a breeze, that is, *IF* DP is creating a correct/readable OTS in to every 2-mix. Of the 23 cues, a little over 1/3 of them showed up as "out-of-range" when we tried to drop them in to a PTools session, then went back to discover that they had OTS's of 0:00:00.00, despite when they were actually recorded!
A bit of a pain. Hope the BWAV thing will sort this out....

I've seen this problem for years. At least 1/3 of audio files imported into Pro Tools from DP are "out of range". Also, on occasion, the timestamp wouldn't be accurate. Sometimes the imported file would be 1 frame, 8 subframes late in Pro Tools. For example, a cue recorded in DP at 10:00:00:00.00 would sometimes appear in PT at 10:00:00:01.08. There seemed to be no rhyme or reason as to when that would happen. Sometimes the timestamp was right on.

I now create a chunk in DP that incorporates all the final mixed cues in the film. That sometimes means creating two stereo audio tracks if there are overlaps. Within DP, timestamps seem to work flawlessly (provided you haven't crashed before the timestamp is written to the file). I then create an OMF of that sequence and import that into Pro Tools. Since I've started doing things this way, I've had no problems with flaky timestamps. Of course, you need DigiTranslator to make this fly.