I highlighted in http://blog.davidesp.com/archives/598 (10 months ago) that Adobe Premiere etc. can adulterate media files, in terms of metadata and/or sidecar-files (depending on user-configurations of these applications. I indicated that, regardless of the reasonableness of at least some of these actions, this could potentially cause problems to other applications.
Validating that concern, I note a post (2012-06-12) by Matt Davis on Philip Bloom’s website, stating (my italics):
- …if sharing assets with FCPX and Adobe Premiere, Adobe ‘touches’ (resets the modification date) of each file without doing anything else to it, but also sprinkles sidecar files into directories of transcodable files for metadata, thus sending any returning FCPX activity into a tailspin, requiring a re-linking session. It’s oddities like these which haunt the implementation of FCPX in a wider system and make system managers wonder if FCPX is actually worth implementing in its current state.
That was over a year ago, and so the issue may or may not exist for the current version of FCPX.
As users, whether or not the actions of one application adhere to standards and another don’t, what we as users ultimately care about is workflow, which in this case translates to “does it connect up with my other tools/processes?”. So we have to maintain a “situational awareness” of potential interoperability pitfalls.
Incidentally, I recall that FCPX’s predecessor (in history at least, if not development-line) FCP7 could adulterate source directories with its own sidecar files, produced by its SmoothCam effect. Not knowing anything further for sure, I nevertheless wondered (at that time) what it might be doing “under the hood” of the QuickTime [.mov] wrapper.