[Tangier Clarke]

Ok, folks I’ve been doing some testing, examining, playing around with these MXF files from the Sony FS7 and looking into the XML files in the card structure. Though DaVinci Resolve is not pertinent for what I am trying to find out, it helped to have another NLE to see how two different systems handled the same content, which in turn helped me verify (or not) certain things about the MXF and MOV files. Here’s what I discovered:

Tools: FCP X 10.4.5 and DaVinci Resolve 15, MediaInfo app
Hardware: 2013 Mac Pro 3.5 GHz 6-Core Intel Xeon E5/ 64 GB RAM /Two AMD FirePro D500/ Thunderbolt 2 connected drives.
OS: mac OS Mojave: 10.14.3

Using FCP X import window rewraps MXF files to .mov with no option (even from hard) drive to “leave in place”. Dragging in MXF files to FCP X event keeps MXF files as MXF and MXF files are allowed to stay in place inside their card structure on the hard drive.

Playback of MXF files in DaVinci Resolve 15 is much choppier than FCP X. Lots of green scrubbing frames as well in DaVinci Resolve. The rewrapped version of these files played back much smoother than their originals.

Using MediaInfo I noticed that the .mov FCP X created (due to using the import window) which was a rewrap it seems and not a transcode of the MXF retained all of the pertinent information and metadata that the MXF had and needed for playback and identifying the camera LUT used; in this case – Sony S-Log3/S-Gamut3.Cine.

I created a new library in FCP X and brought the .mov file in to see if FCP X had and/or would identify the LUT (meaning that it’s truly with the file) and it applied the LUT right away. The LUT info was presented in the inspector in the Camera LUT fields and Color Profile. I didn’t want to give FCP X a chance to use any potential previous database info on how to handle the file. To further confirm the LUT info was there I used DaVinci Resolve 15 and brought the same clip in. It showed flat. I had to apply the LUT manually. Behaviors between the two apps are different, but it seems nothing so far is lost.

The rewrapped MXF to .mov is an mp4 Quicktime inside a .mov. I am thinking that it has to be this way because because perhaps mp4 don’t support PCM audio, but .mov files do. (I could be wrong on this).

The rewrapped .mov from the MXF seems to have all of the pertinent information needed to keep these files instead of the MXF files. I compared information using MediaInfo going line by line to review all of the file structure, metadata, and header information. I recognize this is not scientific.

If money were no object it wouldn’t matter. We’d keep everything. As it stands that’s likely what we’ll do anyway for now, but in the end everything will be edited, archived, referenced, searched, and potentially one day unarchived using the .mov files. So I am keeping these findings in consideration in the case I do have to (dare I say it) ditch the Sony card structure originals.

I know there is no one size fits all solution.

[Tangier Clarke]

Thanks Bouke and Ty. I am not sure Bouke if you’re upset or not and if you’re approachable, but I appreciate the help you’ve given. Via the forum and personal email I’ve gotten “I don’t give a rats ass” comment and in my neck of the woods that’s usually a phrase of contention with the emotion of tension; essentially eluding to not wanting to be bothered further.

In any case, I am not sure if by “samples after midnight”, what is meant is other WAV files or the actual sampling of the audio file itself. That being said, I am not sure what I am supposed to be looking for. The last clip before midnight was at 11:30 pm, then the next was at 3:50 am (after midnight). The recorder was set on a 12 hour time so the timecode wouldn’t go to zero according the the boom operator/recordist.

[Tangier Clarke]

Thanks. I gave it a try and believe it or nor WA was inconsistent. I tired two WAV files, had “preserve TC” unchecked. The first go round the creation date was maintained. The second time I had WA rename all of the WAV files for the shoot day which included copies of the original clips again. This time it did not maintain the same timestamp for same file that it did the first time. Digging a little further on the original files. The accurate created timestamp is the Date Modified timestamp. The Date Created is Dec 31 1969 at 4:00 pm for every single file.

In each test only one WAV was renamed while keeping correct information and it wasn’t the same file.

[Tangier Clarke]

I am on a Mac Pro (2013-Black trashcan with Xeon processors) and a 2016 MacBook Pro. The MP handles all my footage just fine. It’s just horrible when it comes to compressing or transcoding H.264. That’s where my MBP shines and even my old 2012 MBP would run circles around my MP due to Intel QuickSync. The FS7 MXF files at 4K on a 4TB LaCie mobile rugged RAID play incredibly fluidly over 1080p HD from a C100. I can scrub though these MXF files (rewrapped or not) with no lag. Multicam is pretty decent too with two FS7 cams and no proxies yet. I count this to the XAVC-I intraframe codec rather than interframe.

[Tangier Clarke]

Will give it a shot. Though doing some reading and depending on usage of effects, color, just simple edits etc. my understanding is that although FCP X plays the MXF files just fine, that there are circumstances when not to use the raw mxf files. I seldom used the import window either. I always just drag to the event. I need to double check that FCP X behaves differently when using either method in terms of copying or leaving in place. I think it does though.

[Tangier Clarke]

Bret how are you doing this? From the import window when I have an FS7 card ready to bring in, the option to leave in place is not an option; even with the cards are effectively folders on a hard drive where one would think FCP X would allow it. I am forced to copy to library. I’ll be honest that I found this a little strange. If I was importing from the cards then I could understand FCP X behaving this way, but from folders on a drive, FCP X still treated the media like removable cards for me.

FCP X 10.4.5

[Tangier Clarke]

Craig I would only see this as a real issue if when importing or pre-processing clips one picks and chooses the clips to import. I never do that. I always pre-process and or import all of the clips of every shoot. I don’t trust myself nor my associates to keep track of what we did and didn’t import. This way, when we rewrap or transcode clips depending on your process, we know we have it all. If a client want’s something that was left, we’d still have it. It’d simply be in mov form and not camera card original form.

[Tangier Clarke]

Joe, I almost exclusively use EditReady to pre-process all of my media to rewrap it to .mov files and also to create unique nomenclature for the files; at least for AVCHD content coming from a C100. Also, it’s been my routine for many years to archive to to cloned SATA drives and then use NeoFInder to catalogue them. I agree, one will fail at some point.

In the case of the FS7 clips, FCP X actually retains more of the correct metadata importing it directly, rather than through EditReady. They’re close, but FCP X is still a little better. Essentially FCP X is rewrapping it too. I am not having it transcode on import being that FCP X supports MXF anyway. I just pull the clips out of the library package, and can use the Finder to rename them and bring them back in. I really wish FCP X would bring back the FCP 7 feature to rename finder clips based on the names in the NLE since FCP X can do custom naming like EditReady; albeit it’s bound exclusively to the FCP X database.

If there ever was a need to resurrect a project it for sure would be using the rewrapped media, not with the camera original. I am trying to avoid the 2x or 4x penalty too.

I hear what you’re saying though. There really is no perfect answer. It depends on the importance of the content among other things.

[Tangier Clarke]

I guess this begs another question: Is the camera original any more future proof than the rewrapped version of the same file? Granted we’re not talking transcoded files either.

[Tangier Clarke]

Thanks Craig. That is something I was thinking about – the notion of .mov files being supported down the road and/or this FS7 mxf format and folder structure being supported. In general I would agree that one should always keep the camera originals. By the time I start editing, I’ve rewrapped, custom named, and sometimes restripesd the timecode of my video clips based on the LTC audio from lockit boxes. Our editorial and archiving will reference these files. The process to get the clips into this position would never be retained with the original clips and one would have to redo this process to get there. Essentially it boils down to just sucking it up and having the originals backed up, the originals rewrapped and processed for editing backed up. It’d basically be having to accommodate double the storage needs for the same content.