[Joe Marler]

[Michael Paul] “So why do you use FCPX? What are your reasons? What’s great about it? I have started to use it now so of course I am lacking experience in it. So far it doesn’t make any sense to me since I come from programs like Avid or Premiere. “

The reason you have to ask questions like this is partially due to the lack of authoritative conceptual and philosophical background on FCPX. See my reply to you in the other forum: https://forums.creativecow.net/thread/344/44094

Re your question it is probably easier to show you than tell you. See this presentation by Thomas Grove Carter on editing high-end commercials using FCPX: https://vimeo.com/158641571

Provided you accept the implied workflow and work *with* FCPX, it is especially strong at documentary or anything with a high shooting ratio. The skimmer is incredibly fast and tagging, rating and keywording content can greatly expedite post-production. See MacBreak Studio’s “Warp Speed Keywording: https://www.youtube.com/watch?v=azJ4J41JaZk

Last weekend I had a conversation with several well-respected Indie filmmakers (who don’t use FCPX). I asked them as quality cameras become ever more affordable, multicam more common and shooting ratios skyrocket, do they use a Digital Asset Manager or what? The answer was “we just use bins”. They admitted it was such a problem they try to ingest only the good takes and rely heavily on notes from their script supervisor. There are add-on solutions to this like CatDV: https://www.squarebox.com/ but it seems lower end productions usually don’t use them and high-end productions often have a custom system.

One advantage of FCPX is media management is built in, and not just a toy. It is scalable from low end single-camera vlogger-type productions up to feature films.

The 3rd-party plugin market for FCPX is very active, so if you need specific features not in the core product by all means investigate this. FxFactory is kind of like the App Store for plugins: https://fxfactory.com/download/

FCPX is not perfect and there are several things I wish they’d fix. However it is very fast and uses available machine resources efficiently. The problem is to fully utilize FCPX you must learn to think a little differently, and work with it, not against it. This can take some mental reorientation, and IMO there is a deficiency in tutorial information which elaborates on the conceptual and philosophical differences which led to FCPX and the workflow changes this implies.

Some contents or functionalities here are not available due to your cookie preferences!

This happens because the functionality/content marked as “Vimeo framework” uses cookies that you choosed to keep disabled. In order to view this content or use this functionality, please enable cookies: click here to open your cookie preferences.

[Joe Marler]

[Michael Paul] “I am an Adobe Premiere editor and I have switched to FCPX/a job requires me to use this software I have no clue about.”

I also came to FCPX from Premiere and it was a difficult transition for me. FCPX is a fresh re-think about how an editor works and trying to use it like a conventional track-oriented editor will lead to frustration.

FCPX embodies several concepts which ideally should be accepted and used. These include (but aren’t limited to):

– Storage management
– Media management database
– Super-fast skimmer
– Initial workflow focused on the Event Browser, not on the timeline
– Magnetic timeline
– Storyline concept of embedded or collapsed content rather than stacked up timelines

A major problem is people have different styles of learning. Some just say “tell me what button to press”. There is lots of good FCPX tutorial info about this. But just as *design* of FCPX required a profound re-think, the optimal *use* of FCPX requires a re-think of workflow and UI concepts. There is unfortunately limited quality information which addresses the underlying reason for the changes. Without this information it is easy for transitioning editors to get confused, try to jam FCPX into a track-oriented mold, or just give up.

For many people the optimal learning style is first understanding why — the philosophical and conceptual framework underpinning the new knowledge. The best quality tutorial content begins with a conceptual and philosophical outline of the new material to be learned. Not a summary — but the thinking and reasoning that led to the new thing.

When Apple popularized the then-novel GUI, there was lots background info about how this evolved and why it was needed. Unfortunately there is a deficiency of formal content on this for FCPX. This lack results in editors from track-oriented systems complaining about or struggling with FCPX concepts.

Because of this deficiency in background explanatory content, people learning FCPX are often simply told “you have to approach it differently” but without any structured authoritative basis for this. In turn volunteer helpers on discusion forums must repeatedly try to explain this ad-hoc, based on their best guess.

Information on the reasoning and philosophy leading to FCPX is largely heresay, supposition, paraphrases of something that was said at some symposium, even 3rd hand stories about Premiere/FCP7/FCPX designer Randy Ubillios struggling to edit his vacation video and finally realizing something new was needed.

If someone would write a book or even a white paper on this, then transitioning editors could be pointed to that. It would reduce a lot of the confusion and irritation when confronted with the new paradigm of FCPX. It would help defuse the impression that FCPX is different for the sake of being different. It would help motivate transitioning editors to invest the time in deeply learning the new underlying philosophy with FCPX, rather than the fastest minimal route of what button to press for the immediate task at hand.

[Joe Marler]

[Jeremy Garchow] “This is with a DF source? I don’t know what you mean, exactly. Fcpx will add auto speed adjustments to keep whole frames, you can reset these auto speed changes. Is that what you mean?
“

It’s possible I looked at it wrong. Unfortunately I have to go out of town a few days and can’t pursue it until I get back. Thanks for the discussion and I’d like to continue this later.

[Joe Marler]

[Jeremy Garchow] “you have to separate real time from NDF timecode. NDF tc, while expressed in hours/minutes/seconds, does not equal real time.”

Yes I agree with this. In fact the Apple page on timecode stresses this, and the confusion which can occur by referring to timecode values as elapsed recording time or “length”: https://bit.ly/1BlCL49

“Remember that these numbers don’t reflect time; they are simply unique identifiers. The first frame of NTSC video is labeled 00:00:00:00. The 29th frame is labeled 00:00:00:29, and the 30th frame is labeled 00:00:01:00. Again, just because a frame is labeled 00:00:01:00 does not mean that 1 second has passed. The frame could just as easily have been named AAABD, in which case there would be no temptation to read the label as a time value. Only the frame rate of the video can determine how much time has passed by the 30th frame.”

“Timecode is merely a method of labeling frames with unique identifiers to easily find them again later. It is a convenient way of giving each frame a name that can be referred to later without having to verbally describe and visually search for it. Even though frame rate and timecode are independent, people commonly confuse the two, which can lead to frustrating problems in post-production.”

Re measuring by elapsed recording time (not indicated time code) and equating this to frame count, both DF and NDF material with the same elapsed recording time will have the same frame count. This can easily be inspected with QT7 Pro, Invisor or other tools.

I still think there is a bug in how FCPX displays NDF 29.97 material. Even though the project and TC display format are set to NDF, it displays a shorter clip length in the timeline, as if it were 30 fps. Premiere CC does not do that. This is just another example of how you can’t trust TC readouts and referring to TC duration as program length can be misleading. It’s OK to refer to it as length for loose purposes but someone in the production — the DIT or 1st AE, etc — must know the nitty-gritty details.

[Joe Marler]

The OP asked a simple question but this can be a confusing area. Here are several key concepts:

– 30 min of video recording time (by the wall clock) will always equal 30 min of playback time (by the wall clock), whether using DF or NDF timecode — unless that material is somehow manipulated. In these cases timecode means SMPTE timecode, an 80-bit number which is encoded as metadata with each frame, in the format HH:MM:SS:FF (hours:minutes:seconds:frames).

– No matter what frame rate you record at (whether a fractional or integer frame rate), if the material is played back at the same rate, the elapsed real-world recording time will equal the playback time.

– No frames are ever dropped during DF recording or playback — only timecode values are adjusted. Quicktime Player 7 Pro will show the timecode values jump during playback at the minute boundary. There is no visible glitch due to lost frames, because only timecode is adjusted. Likewise pressing the pop-up menu on the QT7 timecode and selecting “frames” will show the same number of frames in 30 elapsed minutes of DF *and* 30 elapsed minutes of NDF material. FCPX can also show DF or NDF TC on a per-clip basis by selecting the clip, then Inspector>Info>Timecode Display = DF or NDF. The project’s TC format can be examined or changed by selecting the project, then Inspector>Info>Modify Settings

– Although we often refer to the TC values as if they were elapsed time (e.g, “minutes of video”), in fact the TC values do not reflect time per se — they are merely identifiers which are *similar* to time. This is made clear in Apple’s informative page about TC: https://bit.ly/1BlCL49 This is also obvious since the TC display format can be changed (as above) for a clip loaded in the editor. Obviously the true elapsed time of the video material is not changing when we change the TC display format, no more than the true length of an object changes when we measure in centimeters vs. inches.

– Similarly some audio material (such as that recorded by a Zoom H4 or lower-end Tascam field recorders) does not contain SMPTE timecode, even though the device may display a pseudo-timecode. When this material is imported into an editor it has a true duration based on the real-world recording time. Various editors may display a timecode-like number, but the file has no timecode in it. But we don’t call the duration zero just because there is no SMPTE timecode data. This illustrates how the program length is not determined by the encoded SMPTE timecode or by how the editing software displays it. Rather it is determined by the real-world recording time, or the frame count divided by the frame rate. In the case of audio I suppose you could divide the sample count by the sample rate. Why not just trust what the editing software tells you? See below.

– What IS different in DF recording is the TC rate (NOT the actual video frame rate) is effectively 0.1% faster than NDF. However some cameras when shooting DF material will display elapsed recording time not the actual SMPTE timecode.

So if someone tells you go shoot exactly 10.00 hr of 29.97 material, when the camera “HH:MM:SS” display (not necessarily the TC display) says 10:00:00, you have exactly 10 hr — despite shooting DF. Inside the video file the SMPTE TC value will be (I think) 10:00:36:01, but there will be exactly 1078920 frames in that file, exactly 10.00 elapsed hours. Had 29.97 NDF been used there would also be 1078920 frames in the file, also covering exactly 10.00 hr of elapsed time. The frame count can be confirmed by viewing the file with QT7 or tools like Invisor: https://itunes.apple.com/us/app/invisor-media-file-inspector/id442947586?mt=12

– When you *import* that 10 hr of DF material into an editor, the software has a decision to make when representing TC. It could show actual DF timecode which would mean the TC values would jump two frame numbers at the top of each minute. Both QT7 Player and FCPX will show that if configured. Or it could show a “fixed up” version of the TC so frame numbers don’t jump. The software must also decide how to graphically represent the material on the timeline. IOW does the timeline length and x-axis marks end at the real-world program duration? What about when conforming two different formats? Regardless, these are simply changes to the *displayed* TC representation. The underlying TC data and frame count in the files do not change.

– There may be a bug in how FCPX displays TC for NDF 29.97 material. When I import a clip with a known frame count to a 1080p/29.97 NDF project with NDF display format, the timeline nonetheless displays a slightly shorter length. The length is shortened by exactly the amount as if the timeline display logic was hard-coded to 30 fps, IOW it shortens the displayed timeline length by 0.1%. This display anomaly makes it hard to figure out what is going on — especially in a project where you’re mixing DF and NDF material. IOW are changed timeline lengths the result of a conforming algorithm, is it an intentional display simplification or is it a display bug? I don’t know.

[Joe Marler]

[Herb Sevush] “Need to put together another editing station by first week in October. Just for the convenience of Thunderbolt I’m thinking about going nMpro. But who wants to buy a 3 year old machine when Apple is supposedly upgrading the line in the fall.”

I have 64 terabytes of Thunderbolt RAID on my 2015 iMac 27, split between a couple of RAID-5 boxes and three RAID-0 boxes. It works OK but I’m not sure the iMac is a better choice at this point. If you are doing any 4k and especially if using Premiere you really need all the CPU and GPU horsepower available. Even a three-year-old nMP if properly configured delivers more of that than a top-spec new iMac.

There’s a good chance the iMac update will probably have a significantly improved GPU due to the new 14nm products from AMD. The nMP refresh (assuming that happens) will probably be an even greater jump because it’s been three years.

OTOH if you are on Premiere and intend to stay there, a Windows machine might be a better option. You have a lot more configuration and upgrade options and can get a higher-performance machine for a given price.

I don’t know what I’d do in your situation. I suppose you could just get any of these options then plan to resell it.

[Joe Marler]

[Jeremy Garchow] “You should produce a drop frame master if your timing has to be exact to real time (45 minutes of video runtime equals 45 minutes of real time). Otherwise, you don’t need drop frame.”

By “video runtime” if you mean literal playback time as measured by the wall clock, I don’t think this is correct. Using the NTSC/ATSC fractional frame rate of 29.97, 45 min of video runtime will equal exactly 45 min of real world playback time. This is because it is both recorded and played back at 29.97 fps. Provided you play back at the speed it was recorded, any frame rate (fractional or otherwise) will have the same playback time as record time.

Drop frame timecode is only needed to ensure the recorded timecode consistently matches up with actual program duration. Without this, by the end of an hour-long program the time code would be 3.6 seconds behind the actual elapsed time. If the playback system has “time to go” or “time from start” counters derived from the recorded timecode, these would gradually become inaccurate unless drop frame timecode is used. It would be impossible to FF or REV to a specific timecode value and have that match the elapsed program time to that point. However the actual real-world elapsed time remains accurate between playback and record of 29.97 material.

So it’s not the video frames that are dropped, but timecode values are periodically dropped to keep them in sync with real-world elapsed time. The only purpose of this is to keep the timecode (or HH:MM:SS:frame addressing system) in sync with elapsed program time.

There is a good explanation here: https://documentation.apple.com/en/finalcutpro/usermanual/index.html#chapter=D%26section=6%26tasks=true

SMPTE timecode is true metadata in HH:MM:SS:frame format recorded in a standardized format. Some devices like Zoom H4 and certain Tascam audio recorders show a “pseudo timecode” but this is not SMPTE and cannot be used by editing software to sync based on timecode.

[Joe Marler]

For comparison, below are some benchmarks I ran on a 2013 and 2015 iMac 27, comparing to an older 4Ghz Windows PC with a GTX-660. I can’t explain why the BruceX test was so fast on the 2015 iMac (about 19 sec). I re-ran it many times. It shows the danger of relying on a single benchmark which for various (and often unknown) reasons may run abnormally slow or fast on certain platforms.

https://photos.smugmug.com/photos/i-gRvVr9h/0/O/i-gRvVr9h.jpg

[Joe Marler]

[Harry Katz] “different locations with different accoustics and mikes so each clip has a different audio quality. Is there any way to achieve more audio consistency so that they don’t sound so different from one another”

It is expensive but iZotope RX5 Advanced can match ambience and EQ between different clips, especially useful in ADR:

https://www.izotope.com/en/community/blog/tips-tutorials/2015/10/room-tone-matching-with-rx-5-advanced-and-pro-tools.html
https://www.izotope.com/en/community/blog/tips-tutorials/2015/02/how-to-match-audio-from-different-sound-sources.html

[Joe Marler]

[Bret Williams] “When you mention the thumbnail issue, are you talking about thumbnails (one single frame to represent the entire clip) or filmstrips? I don’t see any bog down in thumbnails, but I only use a single thumbnail”

I’m talking about single-frame thumbnails. While it generally works very well there is some internal inefficiency which rears its head on very large events. The thumbnails become very slow to fill in and sometimes it gets stuck for 30 sec. During those periods Activity Monitor indicates extremely high I/O rate — 15,000 I/Os per sec on my 16TB RAID. That must be from caching at either the file system or SoftRAID level, since a four-drive array can’t do that many. There’s nothing wrong with my RAID array, as I have several different ones (some hardware and some software) and FCPX exhibits this behavior on them all.

Eventually the thumbnails are generated (for that page) and then everything is fast. However as I scroll down further it gets bogged down until they generate.

Unfortunately there is no way to tell FCPX to proactively generate them — you have to scroll down. The UI is somehow sending messages to the thumbnail generation thread. This is probably an optimization to avoid a lengthy thumbnail/preview generation period as with LightRoom, etc. But unfortunately there is no way to override the automatic algorithm and tell it “go ahead and generate them, I’ll wait”.