Cutting and Cutting Backwards on the Timeline

[student101]

sorry, yes, 3sec 00 frames, 300

my mind was on frames, so 3 sec would be 75 when frame rate is 25

Still having the same issues with Anton's new way and using the number pad.

Today I did a test involving clips from 29.97 fps and 59.94 fps. When ever I do 3 second cut segments involving both mentioned methods at 29.97fps the outcome is always accurate and without fail.

When ever I do 3 second cut segments using 59.94fps there is always a fault usually around the third consecutive cut.

Needless to say since this thread started I've been working with clips at 59.94 fps.

[BernH]

Still having the same issues with Anton's new way and using the number pad.

Today I did a test involving clips from 29.97 fps and 59.94 fps. When ever I do 3 second cut segments involving both mentioned methods at 29.97fps the outcome is always accurate and without fail.

When ever I do 3 second cut segments using 59.94fps there is always a fault usually around the third consecutive cut.

Needless to say since this thread started I've been working with clips at 59.94 fps.

29.97 and 59.94i are the same framerate. 29.97 refers to frames per second and 59.94i refers to fields per second with 2 fields making a frame just like in 29.97. If however you have filmed at 59.94p that is a referring to progressive frames per second and is actually double the framerate.

I work strictly in 23.98, 29.97i and 59.94i, so I have nothing in the 59.94p variety to test with, but if it is progressive material that you have I can generate some and test it.

If I may ask, what are the framerate and codec specs of your material?

All that said, technically the frame rate or codec of the media shouldn't matter, as entering the timecode is only telling Edius to move the play head a defined amount relative to it's current position on the timeline. You can do this on a timeline with no media on it.

[student101]

29.97 and 59.94i are the same framerate. 29.97 refers to frames per second and 59.94i refers to fields per second with 2 fields making a frame just like in 29.97. If however you have filmed at 59.94p that is a referring to progressive frames per second and is actually double the framerate.

I work strictly in 23.98, 29.97i and 59.94i, so I have nothing in the 59.94p variety to test with, but if it is progressive material that you have I can generate some and test it.

If I may ask, what are the framerate and codec specs of your material?

All that said, technically the frame rate or codec of the media shouldn't matter, as entering the timecode is only telling Edius to move the play head a defined amount relative to it's current position on the timeline. You can do this on a timeline with no media on it.

Sorry about that Bern, I should've mentioned that I only shoot in progressive. My codec is AVCHD and the material that working with is 59.94P. A matter of fact I always shoot in 59.94P because I do a lot of equestrian shoots where I'm always panning, zooming and following targets.

Yes if you could be so kind to work up a test on your end concerning 59.94P that would be greatly appreciated. I would really like to find a fix for this.

Thank you!!

[BernH]

OK. I took 5 minute piece of my 59.94i material, deinterlaced it and exported it as 59.94p AVCHD. I then took that material and placed it on a 59.94p drop frame timeline and tried the numeric time code movements, starting at 26:15 on my timeline. I marked an in point at the start and then repeatedly typed +300 <enter> c o to move 3 seconds, cut the timeline and then mark an out so I could see if the duration from in to out had increased by 3 seconds. I repeated this 12 times until I crossed the 1 minute mark. each cut was exactly 3 seconds long, with the exception of the the one that spanned the 1 minute mark. This one was 2 frames short. Subsequent cuts returned to the 3 second duration.

In short, the only time I am seeing and slippage in the time movement, is when we cross the 1 minute mark, which is standard when dealing with drop frame timecode.

[student101]

OK. I took 5 minute piece of my 59.94i material, deinterlaced it and exported it as 59.94p AVCHD. I then took that material and placed it on a 59.94p drop frame timeline and tried the numeric time code movements, starting at 26:15 on my timeline. I marked an in point at the start and then repeatedly typed +300 <enter> c o to move 3 seconds, cut the timeline and then mark an out so I could see if the duration from in to out had increased by 3 seconds. I repeated this 12 times until I crossed the 1 minute mark. each cut was exactly 3 seconds long, with the exception of the the one that spanned the 1 minute mark. This one was 2 frames short. Subsequent cuts returned to the 3 second duration.

In short, the only time I am seeing and slippage in the time movement, is when we cross the 1 minute mark, which is standard when dealing with drop frame timecode.

I would agree that the same problem is happening with me when I cross the one minute mark. I will do some testing on it tomorrow morning when I have time. I noticed before when I was doing it my old way I've always noticed that when I crossed the one minute mark there was a shortage in time even though I was doing exactly 3 seconds. But yesterday when I was testing with 29.97P all tests came out perfect but I'm not sure if I ever crossed one minute mark. Very interesting work on your part, Bern. Right now it is 5:45 AM and I have to leave for a shoot in New Jersey. I'm going to run some clips in 29.97P today along with my usual 59.94P for testing tomorrow morning. After my testing I'm sure I'll have the same results as you but will know we accomplished our points through testing.

Thank you so very much!!!

[BernH]

If you are using drop frame times code, you will always be 2 frames short when you cross a minute mark, with the exception of the of the 10 minute marks, which will not be short 2 frames. This is not a problem, it is the way that drop frame time code works. If you don't use drop frame time code you will not see any of these 2 frame shortages.

Unless you are delivering for NTSC broadcast, you don't need to use drop frame timecode, but your runtime accuracy will be off.

Drop frame times code was implemented to try to make our 29.97fps video rate "clock" its time code off closer to the "clock on the wall" time Because our frame rate is not a whole number, the 0.03fps will cumulatively cause the time code to drift from "clock on the wall" time. The math works like this:

29.97fps is 0.03fps short of 30fps (30 would not require this drop frame calculation)

0.03fps x 60 seconds = 1.8fpm (that is 1.8 frames per minute slower playback than 30 fps)

after 10 minutes that would mean we are 18 frames short of what the evenly divisible 30 would have given us. (1.8 frames per minute x 10 minutes)

Since we can divide 18 by 2 (18/2=9) that says we can can skip 2 frames on our time code clock every minute for 9 minutes to get us back on the equivalent 30fps clock count, but since the 18 frame number is based on 10 minutes of time, if we skipped 2 frames on the 10 minute mark, our time code clock would now be 2 frames off in the other direction, so we just forgo making the adjustment at the 10 minute marks.

[student101]

If you are using drop frame times code, you will always be 2 frames short when you cross a minute mark, with the exception of the of the 10 minute marks, which will not be short 2 frames. This is not a problem, it is the way that drop frame time code works. If you don't use drop frame time code you will not see any of these 2 frame shortages.

Unless you are delivering for NTSC broadcast, you don't need to use drop frame timecode, but tour runtime accuracy will be off.

Drop frame times code was implemented to try to make our 29.97fps video rate "clock" its time code off closer to the "clock on the wall" time Because our frame rate is not a whole number, the 0.03fps will cumulatively cause the time code to drift from "clock on the wall" time the math works like this:
29.97fps is 0.03fps short of 30fps (30 would not require this drop frame calculation)

0.03fps x 60 seconds = 1.8fpm that is 1.8 frames per minute slower playback that 30 fps)

after 10 minutes that would mean we are 18 frames short of what the evenly divisible 30 would have given us. (1.8 frames per minute x 10 minutes)

Since we can divide 18 by 2 (18/2=9) that says we can can skip 2 frames on our time code clock every minute for 9 minutes to get us back on the equivalent 30fps clock count, but since the 18 frame number is based on 10 minutes of time, if we skipped 2 frames on the 10 minute mark, our time code clock would now be 2 frames off in the other direction, so we just forgo making the adjustment at the 10 minute marks.

Bern, I tried the non-frame but now it's working in reverse. Meaning I'm getting more under 3 second segments. When I work with drop frame I get more consistent 3 second values. But still not anything I would trust without checking the duration.

Thanks for the drop frame time code lesson. It's always nice to be re-familiarized and why they came up with it especially the forgo part.

I'm including a screenshot of my project settings.

http://forum.grassvalley.com/forum/attachment.php?attachmentid=15572&stc=1&d=1465727658

[BernH]

Using no-drop timecode, my movements are always consistently 3 seconds when replicating the test, which is exactly as I expected.

Like I said before, the media itself should actually have no bearing on this, as the the numeric entry is strictly moving the play head in relation to the timecode "ruler" on the top of the timeline.

To me, it sounds like you either have an unknown bug in your version of Edius or a corrupted/broken install. You could try a reinstall to see if it fixes the problem.

Also, as I said before, I am on Edius 8.2, but I can't recall having any problems when I was in the Edius 7 builds either. That said, since you are on Edius 7, you are entitled to update it to the latest version which was 7.52. It might fix your issue if you have encountered some kind of unknown bug.

[student101]

Using no-drop timecode, my movements are always consistently 3 seconds when replicating the test, which is exactly as I expected.

Like I said before, the media itself should actually have no bearing on this, as the the numeric entry is strictly moving the play head in relation to the timecode "ruler" on the top of the timeline.

To me, it sounds like you either have an unknown bug in your version of Edius or a corrupted/broken install. You could try a reinstall to see if it fixes the problem.

Also, as I said before, I am on Edius 8.2, but I can't recall having any problems when I was in the Edius 7 builds either. That said, since you are on Edius 7, you are entitled to update it to the latest version which was 7.52. It might fix your issue if you have encountered some kind of unknown bug.

I may very well consider updating to 7.52.

[student101]

Bern, I was looking at my user settings under source and wondering if any of the following screenshots have anything to do with my timing problem. To tell you the truth I'm not sure if the source has anything to do with what we have been discussing.

Please check your automatic corrections, duration, partial transfer and restore offline clips in the source and let me know if you think I should make any adjustments.

Thank you

http://forum.grassvalley.com/forum/attachment.php?attachmentid=15606&stc=1&d=1466165485

http://forum.grassvalley.com/forum/attachment.php?attachmentid=15607&stc=1&d=1466165497

http://forum.grassvalley.com/forum/attachment.php?attachmentid=15608&stc=1&d=1466165505

http://forum.grassvalley.com/forum/attachment.php?attachmentid=15609&stc=1&d=1466165514

[BernH]

Bern, I was looking at my user settings under source and wondering if any of the following screenshots have anything to do with my timing problem. To tell you the truth I'm not sure if the source has anything to do with what we have been discussing.

Please check your automatic corrections, duration, partial transfer and restore offline clips in the source and let me know if you think I should make any adjustments.

Thank you

http://forum.grassvalley.com/forum/attachment.php?attachmentid=15606&stc=1&d=1466165485

http://forum.grassvalley.com/forum/attachment.php?attachmentid=15607&stc=1&d=1466165497

http://forum.grassvalley.com/forum/attachment.php?attachmentid=15608&stc=1&d=1466165505

http://forum.grassvalley.com/forum/a...1&d=1466165514

The only setting there that would really effect how a source video file is temporally interpereted is the "Adjust Framerate...." option under the auto correction settings. If you have this unchecked, as your image suggests, that means Edius will not try to automatically make a file with a different framerate conform to your projects framerate when you import the file. All the other settings in the screenshots you sent are related to stills, audio, missing clip restoration, and transferring files to the project folders.

But once again, as I said before, the actual media should have no effect on numeric timecode entry for the timeline "play head." This numeric entry is related to the timeline timecode "ruler", not the media.

[student101]

The only setting there that would really effect how a source video file is temporally interpereted is the "Adjust Framerate...." option under the auto correction settings. If you have this unchecked, as your image suggests, that means Edius will not try to automatically make a file with a different framerate conform to your projects framerate when you import the file. All the other settings in the screenshots you sent are related to stills, audio, missing clip restoration, and transferring files to the project folders.

But once again, as I said before, the actual media should have no effect on numeric timecode entry for the timeline "play head." This numeric entry is related to the timeline timecode "ruler", not the media.

Yes I knew I was shooting in the dark but I just had to ask.

This coming week I'm going to install 7.52.

Thanks for checking in with me Bern!!