[Joe Marler]

[Kevin McKeever] “I sent the card to Sony data recovery in Laredo, TX. They were unable to retrieve any footage. Then to make matters worse, they made the horribly stupid mistake of writing some data files ONTO the card, which permanently wrote over some of the footage files. The tech apologized profusely and admitted he should have contacted me first to ask permission, but too late now.”

Yes that technician was irresponsible. The first step in data recovery is you make a block-for-block safety copy of whatever is on the media. The original media is always suspect — it’s usually impossible to tell whether the problem was caused by the app, the OS, a card reader or the card itself. You definitely don’t copy files to the original media. If the allocation table is messed up that could physically overwrite otherwise-recoverable data.

The file system on the card is probably exFAT, so it’s not highly complex. A recovery technician can normally use various tools to examine this at a low level and assess the situation.

It is still unknown how this happened but FCPX would not be my first suspicion. If there was an FCPX bug whereby it could erase data on SD cards, this would probably be eventually encountered by other users. I have never heard of that but I have heard of and infrequently experienced data loss from OSX file system bugs and physical card failures.

Re importing directly into FCPX, that is commonly done however I always copy and verify at the Finder level, then import from disk. However if the card is flaky this same situation could have happened doing a Finder copy.

[Joe Marler]

What is the native camera frame rate, what is your FCPX project frame rate, and what is the export frame rate? Are you exporting straight from FCPX or through Compressor? Have you tried optical flow smoothing? Does it look different if exported as ProRes vs H264? ProRes doesn’t use cross-frame compression so that would be an interesting test. If it doesn’t happen on a ProRes export, what bit rate is your H264 export?

[Joe Marler]

Kevin thanks for that info. Normally FCPX should not do anything to the card data (whether it crashes or not) because the files are probably opened in read only mode. With Windows if the OpenFile() API is called with an OF_READ parameter the app simply cannot do anything to the data. It is probably the same with OS X.

The OS X file system code is not perfect and might infrequently under rare conditions cause data corruption. I had a reproducible scenario a few years ago using high I/O stress with the DiskTestR utility. I discussed with the developer who said he’d reported it to Apple as a known bug but it wasn’t yet fixed (back then). FCPX exists at the application layer so it’s possible it did the right thing and the fault is with OS X.

Another possibility is the card itself had a failure. Anytime I encounter something like this I am leery about ever using that card in a production environment again — even if I’m not sure it was the card’s fault.

I know lots of people import from cards but out of conservatism and due to our policy of backing up in the field, I rarely import data from camera cards into FCPX. Rather I copy and verify the data with Finder, and Beyond Compare https://www.scootersoftware.com/.

I should probably use ShotPut Pro which is designed for this but so far have not: https://www.imagineproducts.com/index.php?main_page=index&cPath=5

Anyone who deals with large amounts of production video data has probably seen (or will see) some anomalies. Over the years my documentary group has had a few SanDisk and Lexar SD cards fail in the field, and we’ve had to do data recovery but usually retrieved most of it. This is very rare but I’m talking about 100+ terabytes of data over five years. In the few failures we’ve had, the card was never touched by FCPX it was apparently a camera issue or card failure.

It is tempting to say use only dual-card cameras but this greatly restricts camera choice and if the camera itself fails or crashes it could possibly mess up both cards. Likewise if one card fails then the camera OS became unstable and doesn’t flush and close the other card it could also be jeopardized. It is relatively common in operating systems (whether computer or camera) that unpredictable “async” events are not handled well. This is largely due to the difficulty of realistically testing these in a multithreaded concurrent environment.

[Joe Marler]

In my above post, I meant re-wrapping AVHCD externally should *not* be necessary, but doing so might help understand the problem provide a workaround.

[Joe Marler]

Obviously it should not be crashing. It’s good to look at the stack trace but it’s often of limited benefit without source code access. That is a common camera and codec so nothing unique there.

Are these 300 clips each in a separate project or are they sparse selected clips from a big timeline? Can you describe in more detail the exact sharing procedure, and what export parameters you’re using?

Is it reproducible in any way or is it random? E.g, when it crashed when sharing only two files, if you re-try that will it always crash on those? What if you re-try those two files 5 or 10 times?

Can you pre-render the entire timeline(s) before sharing sharing those? Sharing (exporting) is actually two discrete phases: rendering then exporting (ie encoding). Knowing whether it crashes in the rendering phase vs encoding phase could be useful.

In software support, anything which has a tidy replication scenario tends to get fixed quickly. Also efforts to narrow narrow down the scenario often lead to a better understanding of the problem bounds, and a viable workaround until the code is fixed.

Another possible step is re-wrapping externally the AVCHD files to .mov before importing them. This should be be necessary but it might help isolate the problem. E.g, if the re-wrap utility errors out on certain files, they might be corrupted. I usually use ClipWrap: https://www.divergentmedia.com/clipwrap

ReWrapAVCHD is free and supposedly does the same thing but I have not tested it: https://www.macupdate.com/app/mac/39800/rewrapavchd

[Joe Marler]

[Robert Rinkewich] “I got another crash and I had only shared two files 1 minute each”

The fact it crashed when sharing only two small files is suspicious. What camera and codec are you using, and does your project contain any 3rd party plugins? If 3rd party plugins, can you temporarily remove those on a few clips and try to export without them?

Another standard FCPX troubleshooting procedure is to reset your preferences. This this article for more info: https://support.apple.com/en-us/HT203477

I saw a recommendation to check your fonts when experiencing problems like this. The procedure is:
Font Book > All Fonts > select ALL File menu > Validate Fonts. Any hint of a problem, deactivate or remove the font. I don’t have any direct experience with this, just passing it along.

[Joe Marler]

[John Rofrano] “All of the iMac are just laptops with laptop grade “mobile” GPU’s. The AMD Radeon R9 M395X in the highest end 27″ iMac has only 1/2 the power and bandwidth of the minimum requirement for Oculus Rift which is the AMD Radeon R9 290…So I would have to agree that, for the most part, Apple is only building glorified laptops with fixed GPU’s which is one reason why I’m still using a 2010 Mac Pro with an AMD Radeon HD 7950 and could probably put a GPU in it that could handle the requirements of Oculus Rift… but Apple doesn’t make boxes like these anymore. :(..

The “mobile” M395X is probably faster overall than the HD 7950 in your Mac Pro. But as you said it cannot be upgraded. However it provides good performance in FCPX. From iStat Menus, it appears most of my 1080p and 4k H264 editing on a 2015 iMac 27 is CPU limited not GPU or I/O limited.

I have upgraded the GPU in my Windows machine several times, so it would be nice to stretch an iMac’s lifetime with a field-upgradeable GPU.

This issue is constantly debated on various Mac forums — a small subset of users who are mostly avid gamers want faster GPUs or upgradeable GPUs in the iMac. For the vast majority of the user base the available GPU options are fine.

The problem is adding a more power-hungry upgradeable GPU has various design knock-on effects. They typically pull much more power — in fact the R9 290 mentioned as a *minimum* requirement for Oculus Rift pulls 250 watts average, 365 watts peak — all by itself: https://www.tomshardware.com/reviews/radeon-r9-290-and-290x,3728-4.html

My entire top-spec 2015 iMac 27 with two Thunderbolt drive arrays only pulls 95 watts idle and 150 watts peak. So to support the Oculus-mandated minimum GPU requirement would require a vastly upgraded power supply and cooling system, different physical design, higher cost for all iMac 27 customers or a splintering of the iMac product line.

The Oculus CEO said “if they [Apple] ever release a good computer we will do it [support Macs]”. The Rift has not even shipped yet, although they plans to *start* shipping it this year. So Apple would have had to design the “big GPU” iMac over a year ago with all the concomitant costs to support this one narrow product niche.

Unlike the CPU side, the GPU industry has been stuck at 28nm fabrication for a long time. This year they are finally moving to 14nm fabrication. This will yield at least a 2x improvement in performance per watt, and AMD claims Polaris samples already have achieved this:

https://www.zdnet.com/article/can-amd-outperform-nvidia-with-14nm-polaris-gpu-tech/
https://wccftech.com/amd-unveils-polaris-11-10-gpu/

A 2x performance improvement at the same power budget is huge. This would enable Apple to retain the same thin iMac 27 design yet greatly improve GPU performance. Even that may not be enough to produce what Oculus calls a “good computer” but I think most iMac users think they are pretty good now and will be better when these GPU upgrades are rolled in, probably in late 2016.

[Joe Marler]

[Rob Katz] “i’m ready to move to my next edit machine, a 2015 apple 27″ i7 retina imac/4.0/4gb graphics card….barefeats has suggested these imacs are as fast as several versions of mac pro for many edit tasks…i’m looking to use as fcpx workstation…it also must be able to handle the occasional premiere pro project….
i am also hoping it will work well enough for basic color correction using resolve.”

I have both 2013 and 2015 iMac 27s, both top-spec except the 2013 is 3TB FD and the 2015 is 1TB SSD. I use various Thunderbolt RAID arrays inc’l the 8TB Pegasus R4 and 8TB G-Raid.

I use both FCPX and Premiere CC 2015.2, although most of my work is in FCPX.

A top-spec 2015 iMac 27 is a great editing machine, and due to Quick Sync (which the Mac Pro does not have) is faster on several key areas such as export to H.264. I frequently edit three-camera 4k H264 multicam and it does OK, however you get smoothest performance by using a 1080p project and/or proxy mode.

The Mac Pro does have more CPU cores (some configurations) and can be quieter under sustained rendering but IMO the iMac 27 is not bad acoustically if you have several RAID arrays in the same room.

Premiere struggles on 4k H.264 on the same hardware — the frame update rate and JKL input lag when fast forwarding on the timeline are vastly slower. This is exacerbated by Premiere having no built-in proxy mode, so transcoding to a lower-compression codec to obtain better performance must be done externally. It’s a good product but Adobe really needs to rework their playback engine for the 4k era.

With external Thunderbolt media, there isn’t much performance difference between 3TB Fusion Drive vs SSD. That said it’s easy to run out of space with 512GB, especially if you’re using things like Boot Camp or Parallels. I’ve done many FD vs SSD tests, and SSD always wins on synthetic benchmarks but in most real world workflows I don’t see that much difference. SSD is mentally comforting, knowing it’s the fastest possible I/O so any slowdown is elsewhere.

I can’t comment on Resolve since I use Color Finale. I use Color Munki Photo screen calibration, and there was an issue with older versions on the new iMac 27 LED screen if upgraded to OSX 10.10 or higher. Contact X-Rite support for a manual workaround.

[Joe Marler]

[Boe Beito] “My arsenal includes a GH3, 12-35, 1 wireless LAV mic, and a pretty nice ARRI tungsten light kit…We make it work and my bosses are happy with the product I’m putting out but I know I can do better with the resources I have and if we ever get approval for more budget, I want to show a marked return on their investment.”

These are quite good by the standards of this type of material. You have already done many things right: they are brief (most similar ones are too long), you summarize the tools at the beginning and give an annotated close up, and your audio, video quality and lighting are good.

This really demonstrates how you don’t need highly expensive equipment to make a good quality instructional video.

Considering these are done in a one-week turnaround, if I was the customer I’d be very satisfied.

Here are a few things you could consider, but keep in mind they are pretty good as is. Every additional production step takes more time so this is a trade off.

– You only have one camera but you can shoot multiple takes and cut to another angle in post, say when the speaker turns his head. Anything which introduces visual variety is good.

– Consider using a “call out” plug-in to further highlight and visually specify items: https://www.rippletraining.com/plugin/callouts-3-0/

– For some items such as the Upper Chaincase video, consider cutting to a macro shot of the item. You’ll have to experiment to see how close you can get with the 12-35mm lens. Alternatively you can take a still, blow that up in post and do a Ken Burns zoom/pan on it. Don’t overdo this but it can throw in some visual variety.

– For table top objects, consider using an inexpensive “roller skate” camera dolly. This adds motion to the shot which is visually more interesting: https://amzn.com/B00FHTT8EI

– On some shots of close-up small items, it might help clarity to start wide to show context, then zoom in to show detail. Again, don’t over-do the zooming which also gets tedious.

– At the end consider summarizing with bullet points. Obviously that would have to be scripted so you have covering dialog. These videos are very short so you could get by without it but it’s just one more little flourish.

[Joe Marler]

[Scott Witthaus] “article from 2014 linked in the Boston Globe piece that stated Avid was being forced to the “top of the pyramid” catering to a small group of high-level professionals in film or aspiring to be there.”

The problem is despite all the “street cred”, there’s not much money at the top from NLE software sales. Avid’s total annual revenue from all video and related products and solutions is only $233 million. That is the total from their Hollywood monopoly, broadcast news, independent film, documentary — everything.

As the first linked article states, Avid exists in a totally different situation than when they could sell $100k workstations in 1990 ($182k current dollars). It is interesting that Avid’s roots included the former workstation vendor Apollo Technology. Every RISC workstation vendor is now out of business or long acquired by someone else.

When a high margin product becomes a commodity it is difficult to stay in business. Avid has actually done very well to survive this long.