I’ve written a lot about Premiere Pro and metadata. Surprisingly, almost as an after thought, the solution was shipped in the October 2014 release of Creative Cloud applications. It is hiding in the preference panel under the “Media” tab, and is called “Write clip markers to XMP”. I believe this is one of the most important features that was added to Premiere, because it addresses the issue of backup, archive and project sharing and also helps with on-line/off-line workflows.
For past few weeks I’ve been developing for That Studio a number of scripts for After Effects which are supposed to make one’s life easier, when dealing with an edit in Premiere that requires handling of more than a couple of VFX shots.
One thing that surprised me is that you can’t access layer’s timecode directly using scripting, even though you can do this using expressions. At first I thought that I can use the Time Remap effect to do this, since its values are supposedly shown as a timecode. But a brief experimentation shows that it’s not the case. Time Remap values are given in seconds from the start of the layer regardless of its timecode. Ouch.
Therefore one has to resort to a brutish hack to obtain the layer’s starting timecode: create a text layer, add an expression that reads the layer.sourceTime value and assigns it to the text, and then read the source text in the script. That’s hardly an elegant solution, and it would be so much better, if the layer.sourceTime was supported not only for expressions.
Perhaps I could live with it, but on top of it there is a nasty bug hidden in AE, and it can bite you rather hard, if you’re not careful.
You might be familiar with the fact that when you precompose a single footage layer, and choose to leave the effects in the main composition, the precomp will have the length of the whole footage file, and will inherit the exact timecode… more or less so.
You might not be aware, that if you are using 23.976 fps frame rate, the timecode might be off by a frame or even two when you attempt to render this layer – which you will notice only if you open the file, because even the render queue will show the correct timecode value. You can mitigate this by manually entering the starting timecode in the composition settings window.
The real problem begins when you are trying to set this timecode via scripting. Let’s say you want the composition to start at 20:20:51:22, which at 23.976 fps translates to 73325.2419085752. When you assign it to the desired composition, the internal AE procedure will truncate it to 73325.2421875, which will result in the timecode which is not frame accurate, and even though it is displayed correctly in the composition, it is incorrectly rendered and written to file. You can check it yourself by running the following script on a selected composition (make sure to first enter 20:20:51:22 into the Start Timecode of the Composition Settings dialog):
c = app.project.activeItem; a = c.displayStartTime; alert(a); c.displayStartTime = a; alert(c.displayStartTime);
Note, that the value changes by the sheer fact of assigning the code to the composition start time. My supposition is that the internal workings of AE convert the double value into a float, thereby reducing the precision at higher values. That’s definitely not nice. Depending on how critical the timecode is for your application, it might rule out automation of certain tasks, and make it more troublesome to render – you have to always manually enter the starting timecode, even if you precompose. I have not found a way to reliably code around this bug.
The conclusion so far is: forget about accurate timecode renders from AE, especially if you are using 23.976. 29.97 or higher fps and do not start from a full second. Lower integer frame rates seem not to be affected so much, as are easy dividers (12 for 24 fps, etc.). Unfortunately, even if this is fixed in the future releases, it still means that you can’t use scripts that rely on this feature for earlier versions of AE.
Some time ago, if you ever tried to export XML from Hiero to Premiere, you got a generic importer error message and that was it. This issue – audio related – was thankfully fixed in later versions of Hiero. However, another hydra reared its ugly head, and this time attempted XML interchange resulted in something along these lines: see more
Just a minor maintenance note: the comment sytem on the site has been fixed, so if you wish to share your thoughts, love and grievances, now is the time.
Update: The 7.1 version due out in October is going to fix the issue altogether. Great job, Adobe!
Being the one to spoil the party is no fun, especially if you like the host, or enjoy the meals. But when your favourite dish was rotten and received only a little ketchup treatment, well… sometimes you have to be vocal about it.
Let me at first say that I love the party. To have an update within a month of the release, that fixes a major multicam bug (which for some reason I have not fallen prey to) and adds plethora of new features that will make life and editing easier is awesome. This is the power of Creative Cloud that a lot of people were talking about. There’s no denying, that the party is well deserved.
If you want to learn of all the new features and improvements to Premiere Pro which come with version 7.0.1 update, take a look at the official Premiere Pro blog or reTooled.net tutorial. They will show you the goodies, and these are plenty.
But unfortunately for me, one issue is not completely resolved. And it’s not for the lack of trying.
I wrote before about a nasty curves issue, and for some reason my post was not received with enthusiasm at the home of Premiere Pro. I really, really hoped it would be resolved in this update, and that I will be able to join the happy fest. Well… it is, and it isn’t.
The good news is that the curves no longer clip superwhites and superblacks on input. Depending on how you use the curves it might or it might not be the solution. If you never move the starting and ending points of the curves from their places, you’re good to go. Also, if you only move them up or down, to reduce the dynamic range, you should rejoice, because it works as it used to as well.
But if you ever move these points to the inside, namely the point on the left to the right, or the point on the right to the left, to add contrast, and you hoped to later recover the clipping, your troubles did not go away. Sometimes they might even be compounded.
Unfortunately the curves still do not work as they used to. This example of course is exaggerated to the extreme to make the point.
Because the curves will flatten everything what is beyond the leftmost or the rightmost curve points up until the left or right border. Then they will resume their 45 degree slope. To many it might be a non-issue. To me it is. To me it means that most of my old projects will still have to be rendered out in CS6, and I will have to be careful with the new ones, especially when using Jarle’s grading presets.
I am not happy. Depending on where you sit, this is either a storm in a teacup or a spoonful of tar that spoils the barrel of honey. Unfortunately, I belong to the second group, and it’s no fun at all.
Update: The 7.1 version due out in October is going to fix the issue altogether. Great job, Adobe!
Update: The 7.0.1 patch for Premiere Pro CC fixes some of the below mentioned issues, although unfortunately not all of them.
To my great chagrin Premiere Pro CC changed the way curves operate. Right now the curves, both RGB, and Luma, clip the superwhites and superblacks, and there is no interpolation going on after the curves hit 0 or the white level (255 or 1.0). In CS6, the curves followed the general slope, and it was possible to recover some of the “overshot” material. Right now, if you stick to curves, all clipped data is lost.
 Curve's interpolation in Premiere Pro CS6 allowed to recover superwhites or superblacks, and correct the contrast in the same instance. |
|
|---|---|
 Premiere Pro CC clamps all superwhites and superblacks, and recovering the detail is not possible with the use of RGB or Luma Curves. |
This is completely new, unexpected, and if you ever used curves, it changes your workflow dramatically, even if you don’t know it yet.
It means that you must remove the superwhites and superblacks from the clip before you use RGB curves. It means that if you were like me, using curves to apply the basic correction and contrast in one go, you cannot do it now. You have to first make the signal “legal” – reduce the superwhites and raise the superblacks with for example Fast Color Corrector, so that they fit between the range that curves operate on – RGB scale that is not overshot in either direction, even if you are working in the floating point (max bit depth).
In Premiere Pro CC you need to use Fast Color Corrector or Three-Way Color Corrector to bring the superwhites back into the RGB scale. Only then you can apply curves, and be sure that you are not loosing data.
It also means that there is no real backwards compatibility within the projects that used curves. Your colors will not be the same, if you had any superwhites in the project. I highly advise you to finish your current projects in CS6, and only then create the new ones in CC, being mindful about the necessity to use Fast Color Corrector before applying curves.
Adobe is aware of this issue, and hopefully some fix will come soon, but while using CC 7.0.0 version of Premiere you need to remember about this very real problem.
The very first thing that you should do… no, let me try again. The very first thing that you must do after installing and opening the new Premiere Pro CC is to set a keyboard shortcut for Deselect All. Trust me. This will save you a lot of trouble later.
This is something that you must do as well, if you think that applying transitions in Premiere no longer works.
Open the Edit menu, choose Keyboard Shortcuts…, and in the search box type “deselect”. Fortunately only one option will be visible, the one that appears in the Edit group – “Deselect All”. Assign a shortcut to it which will be easy for you to remember. I sincerely recommend
Set this shortcut right now!
Why?
Premiere Pro CC introduces what is called “the primacy of selection”. Translated to plain English it means, that if you have anything selected in the timeline, Premiere will attempt to use the selection for any operation you choose, disregarding track selections, playhead position, etc. While there is an argument to be made that it’s more effective, more consistent (well, perhaps some day), it is changing the behavior which was long established in Premiere – using the playhead position for applying transitions.
Here’s how the new behavior works: if a clip is selected, and it is between two other clips, nothing happens. If the clip has at least one edit point where it does not touch anything, then the selected transition is applied to the loose ends. And if multiple clips are selected, the transitions are additionally applied between these clips. Not very obvious, right?
The clip on track V2 is selected. You might not even notice it. At least I didn’t!
And here’s the result – instead of applying the transition to the edit point under the playhead, the selected clip receives the transitions on both sides.
If you are like me, and you select and deselect clips all the time, whether to adjust effects or for any other reason, then this new behavior is going to bite your muscle memory hard. Before you learn the
This is the collateral damage or “the primacy of selection”. If you forgot to deselect, and want to use the old way of applying transitions – by the track selection and playhead position – then you are screwed, and need to adjust. It does not help to know that this behavior is the result of Final Cut Pro’s inability to select multiple edit points at once, and was introduced there as a remedy to this limitation. Supposedly a lot of FCP users asked for this functionality in Premiere. They got it, and it came at a cost to established workflows. Like the introduction of patch panels in CS4, only more mischievous, because the results may not be immediately visible.
Here the selection is a bit more obvious. Watch what happens, when the shortcut is pressed now.
The transitions are applied at the end, and in between the clips. Remember to learn the new combination of keys – D, cmd/ctrl+D – if you want to use the playhead to apply the transitions.
To add confusion, there is a keyboard shortcut to “Apply Default Transition to Selection”, which works exactly like Apply Default Transition if clips are selected, although it applies both audio, and video transitions.
My little mind can’t comprehend the idea behind this change, especially since I’m not the only one who was taken aback upon the first encounter with the new behavior. But I know of others who are happy about it, and I found some use of it as well… only to encounter a stray transition during the final viewing of a recent production.
So remember –
Beware of a nasty bug in CS6:
If you import the footage in such a way that a bin or a number of bins is created upon import, and you label your clips on the timeline, you might be in for a nasty surprise at some point.
If you choose to move your files from the bins, or sometimes even simply select them by the innocent “Reveal in Project” command or so much as click on them, you are going to loose labels in the timeline for selected footage in the given folder. *Pooof*, gone. Like this. Without any possibility of undoing it. If you have not saved your project for some time, you face either loosing the labels, or loosing the changes since your last save, because I tell you, these labels are not coming back!
Now, if you are lucky to have a saved project with your labels still applied, don’t breathe with relief yet, because they are not safe! First follow the following steps to the letter:
This bug propagates across projects! If you have Premiere opened in the maximized window – as most of us usually do – then the moment you open your project, the labels will evaporate as well. But if for some reason you do not have your window maximized (it might be larger than one screen, but it must not have the maximized icon turned on), you are safe for the time being. The labels will remain on the timeline until you trigger the bug again by selecting your files or moving them.
I have no idea why, but having your window non-maximized gives you a chance to save your work. This is the weirdest bug I have ever seen, and it is a nasty one.
The solution is to either import media in such a way that no folder is created, or to move them to another folder immediately after import. It does nothing to save your existing projects, but it will protect you in the future.
If you are familiar with my recent complaint about the issues with FCP XML export, let me throw two more problems into the mix. They might not be as important as the drop and non-drop frame issue, because no data is lost in the process, and they are fixable, although they might be quite an annoyance.
After fixing the problem with exporting zero-marker duration, we shall find out two things:
There’s a clip that has 1 marker in it, and 1 subclip. The subclip starts at a frame 228, and ends at the frame 645 of the main clip. The marker starts at frame 355 and ends at 528. After export, you will get:
And what you should get:
I think you have already figured out, what’s going on – the subclip’s offset is not removed from marker’s in point. As I said – hardly a big problem. Merely an annoyance. But it requires a tool to fix it if you are using certain kind of workflow: the subclip-spanned markers should be removed, the real markers’ in points in subclips recalculated.
Depending how you look at it, the fact that the very same errors are present in FCP XML exports from Prelude, can be either disheartening – because you’d think it’s such a basic functionality that somebody should have had noticed in in the production stage – or encouraging – because if they fix it in Premiere, they will also fix it in Prelude.
On a positive note – I’ve been in contact with Jesse Zibble from Adobe about XML export in general, and I know they have been working on these issues. But judging from the release cycle of previous bug fixes, I don’t think this is going to be amended in the current release.
All of us not using Creative Cloud yet, feel free to express your disappointment now. And if any of you needs a tool to fix these markers, drop me an email.
