Frame Rate Mess Up

Fun story:

Editing a movie in Premiere with a 23.976 frame rate and exported the XML to DaVinci. Made all the grades in 23.976 only to discover that the original clips were 29.97 and the Timeline was created wrong. So I got flicker everywhere and bad pulldown when exporting the files.

So I reexported the XML in premiere with the correct 29.97 but I can´t import it to the project in 29.97, since it was already set to 23.976.

So:

1) I searched around and saw that I can´t change the project settings to this new framerate.. Is this true?
2) I don´t want to start another project and lose all the grading I did previously. Is there a way for it? Either importing the grade to a new project or something like it?

Exporting as a single clip in 23.976 removed the flickering but made an awful pulldown problem.

Thanks in Advance!

[Dwaine Maggart]

It's true that you can only change the project frame rate before there is a timeline created, and before there is any media in the Media Pool. You can't change the project frame rate of an existing project.

You can create a new project at the proper frame rate and use Colortrace or Stills to bring the corrections from the original project into the new project. Colortrace details are in the Colorist manual.

Yeah but good God man. Can that be the #1 flaw to fix in the next release? I can't believe that's still a thing. That's crazy.

The inability to change frame rates after a project has started exists in quite a few different color-correction programs. This is one of those database structure things that's etched in stone.

The ColorTrace solution is livable and does not take long to do. The key is always to know what you're doing when the session is initially set up, check everything twice, and use caution. It's the little details that will kill you in sessions like this.

[Dwaine Maggart]

Any given colorist generally only runs into this issue once, if at all.

Any given colorist generally only runs into this issue once, if at all.

Understood but still. Thats a catastrophic problem and just because other software may a similar handicap doesn't make it acceptable. If there's a way to have that not be, they should.

Any given colorist generally only runs into this issue once, if at all.

This is sadly true. Good lesson to learn, though. It'll give them good practice with ColorTrace.

Understood but still. Thats a catastrophic problem and just because other software may a similar handicap doesn't make it acceptable. If there's a way to have that not be, they should.

I'd call it a catastrophic user problem. You gotta read the manual. There are certain setup parameter for this and many other kinds of software that are absolutely mission critical. Change your way of thinking and you'll see this is true.

Try to change the framerate in Avid Media Composer and let me know how well it works.

Whilst i respect the seasoned a list pro colourists who are used to these kind of things being non changeable since the dawn of times, surely software needs to change and become more comfortable and logical. Surely you would like to not read about it in the manual but for it just to work so you can get on with colouring rather than fishing out silly things like that in the manual?

Surely you would like to not read about it in the manual but for it just to work so you can get on with colouring rather than fishing out silly things like that in the manual?

I would get nowhere near color-correcting or editing or mixing anything unless and until I read the manual first. I think this is a basic rule of life: patience and knowledge.

[Peter Chamberlain]

There is solid technical reason for calculating the timecodes, length of clips, audio sync, re-time events and how these items are placed in the edit timeline and then re-timed again etc. etc.

This is all based on the timeline frame rate you set when you start the project. We are not ignoring the requests to make this more flexible, but be assured if it was easy and didn't have ramifications to all the other timelines you might have in your project, key framing etc, we probably would have changed this some time ago.

In the meantime gents, please set the project frame rate first.

I would get nowhere near color-correcting or editing or mixing anything unless and until I read the manual first. I think this is a basic rule of life: patience and knowledge.

Yes this is ultimately absolutely true, however certain things can be automated and made logical. For example If I go into nuke (and nuke is a huge huge program packed with complicated functionality) and decide to copy a bazier curve shape from one keyframe and paste it onto another keyframe I don't need to read the manual. I need common sense. And common sense states that If i select the bazier click cmd+copy go to the destination keyframe and click cmd+paste it will paste it there. I don't think anyone would argue that this kind of logical program behavior saves shedloads of time. Just like you would save time by being able to have several timelines with different frame rates like you can in Premiere (surely they have all the same problems with timecodes audio retimes and all that? But it just works there).

you would save time by being able to have several timelines with different frame rates like you can in Premiere (surely they have all the same problems with timecodes audio retimes and all that? But it just works there).

I would disagree.

While it is true that many NLEs allow multiple frame bases within a project for separate sequences, changing the base frame rate is also frozen once you add media to any timeline and for the same technical reasons that BMD have structured their platform.

When you are operating in many compositing applications, they are essentially operating outside of a rate-based sequence and merely dealing with one frame after another as if they were sequential images, which explains why in many you have to specify what your target export frame rate is... was it 23.98 or 29.97 progressive or interlaced or segmented...??? It doesn't actually know unless you tell it, and lord help you if you performed any operations that should have been de-interlaced because what you are going to get is a steaming hot mess.

Frankly many of the sequences that allow mixed framerate sources don't work all that well because nearly none of them are field-aware and their version of frame-rate conversion is "best guess", but mostly just "guess."

jPo

Fair enough i might be wrong then...


Sent from my iPhone using Tapatalk