Start to Finish in Premiere CS6

Question

I'm freelancing as a finishing artist and offline assistant at a commercial shop in LA that switched from FCP to Premiere a few months back and wanted to share some of the workflow notes we've accumulated over that time.  Please feel free to contribute anything or point out things that we might be doing wrong. 
First off, the work here is mostly comedy/dialog driven, so lots of long takes, improv from talent, and multicam shoots.  The footage we get is more often than not Alexa, and the dailies are, more often than not, generated out of Resolve.  Our offline clips are in ProRes Proxy for the moment, because we still need to use FCP for some finishing prep (more on that later).
One note for anyone working with Alexa footage out there:  when you are making dailies, or sending specs of dailies out to DITs or facilities to transcode your raw dailies into offline proxies, be sure that the Alexa reel names are getting embedded in the transcode.  In Resolve, for example, there's a setting (not on by default), to "use reel name embedded in Source metadata" or something to that effect.  This absolutely needs to be in place, regardless of which NLE you're using.  EDLs are primarly reel name and timecode driven.  Clip names can be squirrely.  Be sure your reel names match your source files and you'll save time in color and finishing.
Footage comes in extremely fast and we make heavy use of markers for jotting down notes on lines and transcribing improv takes.  The marker list is a really good tool.  We've used Prelude on single camera shoots to make subclips with comment markers for general notes and Speech markers for transcription.  It works really well, but it would be even better if it integrated multicam since we don't want to mark two cameras separately.  So for multicam breakdown and marking, we work in Premiere.
Editing is great.  Once the editors got used to the GUI and keyboard, they didn't look back.  Playback, trimming and versioning is faster and smoother than FCP7 by a longshot.  Sequence-to-sequence editing is missed heavily, as is match frame detection and healing.  But overall there's nothing that gets in the way.  Playing back audio in the viewer for clients is a bit laggy, but it's a Blackmagic issue.  Blackmagic output is sequence based, meaning clips in the viewer can be problematic for client playback since they aren't embedded in a sequence.  Audio defaults to SD output, so your monitor will need to toggle between settings if you play back video in the timeline and then audio in the viewer.  AJA overcomes this by having a global output that's independent of your sequence setting.  We've stuck with Blackmagic though and it's otherwise been great.
Multicam works very well although we've noticed that, when you want to play back a multicam clip in the viewer, it will only display the single cam view in the client monitor.  If we want to show the client a contact sheet view, as you can in Avid or FCP, we can't.  In the viewer, if you want to view in single camera mode, you have to disable multicam in the viewer.  If you try to switch cameras or re-enable multicam viewing in the viewer, it won't work.  We have to restart Premiere for that clip to be able to be viewed in multicam mode again.  I've submitted a feature request and bug report to allow 1-up viewing of multicam clips in the source monitor that still lets you toggle between cameras, ala Avid. 
Adobe Media Encoder is a great utility for postings.  For large batches of files to compress, we save a copy of the project in the directory where we want the compressed spots to live, then import the sequences from that project copy into Media Encoder.  ME saves the files to the project directory by default, so this is our way of influencing the destination of the batch encode without clicking on every file name.
The only drag with using Premiere right now, relative to working in Avid or FCP, is prepping for finish.  The process is pretty rough around the edges and there are some missing utilities that would be great to see in a future release.  Here are the issues we've encountered and how we work around them:
- there's no matching back to a source clip from a multicam clip.  Nor is there a way to collapse that clip.  When Premiere syncs cameras to make a multicam clip, the new clip is self-contained and has its own timecode (starts at 00:00:00:00) and filename that doesn't change regardless of which camera is active.  When you dis-enable multicam, nothing changes.  If you need to prep an EDL, you have to manually find the source clip and overcut it into the sequence.  Premiere won't help with this, so you need to be organized and know where to look to speed the process up.  It's a major drag, maybe, for us, the biggest drag in the whole app.
- there's no duplicate frame detection or match frame notifiers.  For match frames, it's just a matter of skimming through the sequence to find them.  For duplicate frames, it's the same deal.  In both cases, exporting an XML of your sequence (no multiclips - those can be erratic when translating into FCP) and bringing it into FCP is the fastest way to get your EDL prepped without duplicate frames or match frame edits.
- EDL export is quirky.  It gets the job done, but there are a couple things to be wary of.  Most significantly, any time remapping or reverse speed effects should be removed prior to making the EDL.  As a finishing artist, I'd rather get all the media in, with handles, and a reference quicktime with text overlays or a standalone document telling me what my speed changes should be than have an incorrect EDL.  Unforunately, Premiere's EDL generator will give you incorrect source timecode on reverse speed effects and won't reflect time remapping effects at all (the latter isn't surprising, although it would be nice if it picked the slowest speed and used that as the M2 qualifier so you at least would be guaranteed to have all the media you'd need to recreate the effect).  So, remove all reverse speed effects and time remapping and you have no problems.  A second quirk, though, is that when exporting video layer 1, any media living on video layer 2 will also show up in the EDL as a key clip.  The workaround here is, if you have multiple layers, just keep video 2 empty when generating the EDL.  I thought it would be a big issue that there's no way to specify whether the EDL is referencing clip names or file names, but as long as your reel names and timecode are good, accurate clip names aren't necessary for conforming for color or finish.
- OMF and AAF export seems to work fine.  No issues to report there.
A couple final notes:
We usually have a few people working on the same project, with one user having read/write access to the SAN directory where the media lives and everyone else having read only access.  On all of our systems, we've gone into the Media Preferences and turned off "write XMP ID to files on import." We leave on the "Enable Clip and XMP Metadata Linking" option.  This lets the write access user make metadata changes that will then ripple out to other users when they refresh their mounted SAN volumes.  Without this option selected, we've had markers, comments, and revised reel names get messed up.  I highly recommend these settings for anyone working on a project with common media shared by several users.
We've been hit by project bloating a couple times.  It appears to be caused by duplicate links to preview files being added to the code within the project file.  These erroneous links can get created when exporting with Media Encoder and selecting the "use Previews" option (a bummer because that can save a lot of time).  They can also appear when click-dragging a Premiere project file into Media Encoder, which unfortunately is the fastest way to load a project sequence into ME.  You can rescue your bloated project by importing it into a new project, but keep a watchful eye on your project size.  I'd recommend a daily import into a new project just to make sure you're safe.  It gets big exponentially when it does start bloating, and before long you can have a multigig project file that can't open or be imported. 
Overall we love the application and haven't looked back (except to prep) since switching.  I've recently worked at other shops using either FCP or Avid and, for loading, breakdown and editing, Premiere feels faster than either one.  I'm anxious to see where Adobe takes it in the next release.
Hope this is helpful and I look forward to your thoughts and questions. 
Jon

Answer 1

Hi there David,
Thanks very much for getting in touch and hopefully I can give you some useful info to help in your decision making process.  I haven't encountered your specific issue and workflow, so take everything I have to say with a grain or three of salt.  Specifically, I haven't trid to do final color for a project using either Premiere or SpeedGrade.  I've used MB Looks in After Effects on some personal projects and was happy with the results I got given the short turnaround time.  That said, the projects I'm most familiar with are colored by a vendor and then conformed on my end in Premiere.  I've done minor color tweaks in Premiere, AE and Resolve, but haven't gotten too much into SpeedGrade other than just playing around in it.
With that in mind, I have a couple considerations based on your e-mail.
You have adjustment layers in Premiere and could use your MB Looks and/or Colorista directly in PP the same as you'd do in AE, so I don't see the point in using AE here unless there are significant differences in the performance of the apps.  The tech in Looks and Colorista is very cool and will take advantage of the data you've collected in the .R3D files.  If you're comfortable in that software and are happy with your results, I'd stop right there.  What looks good looks good, no matter how you got there.
One of the limitations you've imposed on yourself seems to be using the .R3D files at all times and making sure all that data is in play at every stage of post.  Do you have an anticipated final format?  Do you expect to be scanning to film and projecting in a movie theater?  Even if that's your expected output format, don't worry about data loss going to DPX.  That's an industry standard format for the highest of the high end feature film work.  Most of the VFX you see on features shot on RED Epics are not using the .R3D files.  They're using DPX files generated from the .R3Ds.  Ditto for nearly every commercial you see on the Super Bowl and all your favorite TV shows.  So if you want to get into Speedgrade and have it generate the DPXs that may (I haven't done it so I'm not sure) bake in your effects, don't sweat it.  Those DPXs will give you plenty of range to work with in color.  They chose that as the format to bake to for a very good reason.
You'd need to look at the files with a vectorscope to notice any difference.  Also, keep in mind that when RED first came out, professional grading software didn't work with it natively and everything that was shot with that camera and finished for broadcast or cinema required that the .R3Ds be transcoded to something else prior to grading.  You really don't lose anything by going to DPX is basically my point here.  Tons of data is tons of data, no matter what the file extension is.  Purists will crucify me for this, but I've been next to top shelf directors looking at ARRI RAW from an Alexa on set on one $30k calibrated monitor and the ProRes 4444 output from the same camera on another, and they've forgotten which was which.  It's easy to go down a rabbit hole with all the file types and codecs and so forth and completely forget about using the single most important tool in the entire business - your eyes.  There are specific tasks where that stuff can wind up mattering quite a lot, but for most projects it's overkill.
Lastly, the workflow I'm accustomed to in commercials involves getting the footage graded prior to final VFX being added in.  If you're happy with where all your VFX are at, you could duplicate your hero edit, pull out all the effects work so you only have the ungraded plates to work with and send that as an EDL over to Speedgrade if you'd rather use that than the Magic Bullet products.  Once that work is done, render out DPXs or Quicktimes of your graded selects and conform with Josh's reLink application (for movie files) or by manually overcutting your footage (for image sequences) and re-applying your effects work.  The advantage this workflow gives you is that your effects are still "live" so to speak.  Once your footage is graded, it's not unusual for details to emerge that effect your comps.  Having the base plates, not the VFX work, graded will give you the flexibility of making tweaks without having to go back to color.
Hope there's something useful in all of this.  Congrats on the project and I wish you loads of success with it! 
Best,
Jon