AF100 .MTS files returned by client - Mac/FCP import issues?

Creatively Bankrupt

Creatively Bankrupt

Member
I shot the LA Marathon for an east coast client last Sunday and I got a call today saying they have been unable to import or view the MTS files and want me to convert them to mov to mp4. They are on Macs using Final Cut.

My workflow has been all Adobe CS5 so far with this camera and I haven't had any issues. What are Mac AF100 owners doing to work with their MTS footage?

I should also note that I only uploaded the mts files themselves - could that be part of the issue? Are the folder structures or other files required?

Thanks in advance for any advice!
 
Yep -- FCP on the Mac cannot import the MTS files by themselves. It requires the whole folder structure, the whole PRIVATE directory.

Every other NLE can work with just the MTS files, but FCP can't, you have to give them the whole thing.
 
Barry maybe you should put the file structure chain in the "AF100 tips, tricks, and FAQ's" thread. I'm sure a lot of people have done this and will continue to do this.
 
If you need to send files to a client with the card structure, have you considered using Disk Utilities to make a "disk image" of the card?

That's how we archive all cards (be it AVCCAM or P2 or even SXS) from production media to active storage. Subsequently a second copy will be created in the backup arrays for redundancy. Once completed, the disk images can be used in our NLEs as if they were the originals - even restored to SD cards if required.

For us it works for a few reasons:
a) speeds up transcoding since we're not limited by the card's read speed (and can therefore be completed on other workstations/computers or even on laptops in the field)
b) we can transfer cards to clients if needed with the original card structure intact without having to hand them a card... most will fit on average USB flash drives.
c) if there's some kind of an issue (especially with footage on rented P2 cards) we have the original structure to work with
c) when doing documentary work with lots of long interviews and lots of b-roll, we can import all footage in a proxy format and then we have an easy time of re-transcoding the fine cut to a higher quality format for further work down the post pipeline.

Because the footage balloons in size when moved to an edit-ready codec like ProRes 422 (HQ, LT), keeping an extra 50-100GB of data around with disk images isn't such a big deal when you consider the added benefits. This is of course, just, like, my opinion, man. ;)
 
Petros Kolyvas said:
If you need to send files to a client with the card structure, have you considered using Disk Utilities to make a "disk image" of the card?
Click to expand...

If you use "Archive as disk image" in the "Log and Transfer" window in FCP, it does the same thing, but you get the added benefit of the disk image being verified which Disk Utilities doesn't.
 
ClipWrap2 will transcode the bare mts files. Just convert to an editing codec that FCP supports, not mp4.

AVCHD workflow for the AF100 is no different than the AVCHD workflow for Final Cut Pro since version 6.0.x.

It certainly something that you should review with your client in anticipation of sending the files. FCP 6.0.x comversions are to pro res 422, and for FCP 7, use log and transfer to encode to pro res LT.

Your client's suggestion to go to mp4 is ill advised. That codec is not an editing codec support under FCP in any version. Pro Res LT for FCP7 and Pro Res 422 for earlier versions.

Keep the AVCHD file structure intact.

For whatever reason, Apple requires a transcode to a native QT file. It just works differently than other NLEs, and some prefer the transcode for editing ease.

Others don't, but that isn't the business of this thread.
 
Brian@202020 said:
If you use "Archive as disk image" in the "Log and Transfer" window in FCP, it does the same thing, but you get the added benefit of the disk image being verified which Disk Utilities doesn't.
Click to expand...

I'm suggesting making disk images before you even open Log and Transfer. Disk images are verified upon their completion in our workflow. This way, data wrangling like this can be completed on machines that don't have a seat of FCP installed.
 
Petros Kolyvas said:
...Disk images are verified upon their completion in our workflow.
Click to expand...

Are you verifying the data in a different program? As far as I know Disk Utility does not verify the transfer. I had an AC on a job a few years back create a P2 disk image using Disk Utility that ended up being corrupt. I've also heard of several other horror stories of corrupt disk images being created by Disk Utility because it doesn't verify. I know FCP verifies disk images as well as Shot Put Pro.
 
Brian@202020 said:
Are you verifying the data in a different program? As far as I know Disk Utility does not verify the transfer. I had an AC on a job a few years back create a P2 disk image using Disk Utility that ended up being corrupt. I've also heard of several other horror stories of corrupt disk images being created by Disk Utility because it doesn't verify. I know FCP verifies disk images as well as Shot Put Pro.
Click to expand...

Yes when disk images are created with Disk Utility they can be verified immediately afterward by mounting them - as the utility which does so will attempt to verify them at that time.

But you are absolutely correct that they are not explicitly verified by Disk Utility upon creation. The data transfer and disk image creation (which is actually handled by the hdituil command) however must have some type of error checking and correction (CRC or something like that) during data transfer/creation of the image.

The nice thing about these OS tools (outside of FCP) is that much of this can be easily scripted on the command line in OSX such that you can get a report afterwards in a text file and have the mounting, disk image creation, verification and un-mounting all happen with with a single command.

I have not heard of Shot Put Pro but I'll look into it - it's nice to know there are so many ways of doing all this stuff and I'm always excited to hear how others are doing it.

Also thanks for the questions - I think data integrity in this day and age of limited physical media (if any after production finishes) - is important to keep in mind; and there are probably even better ways of doing it than I am at this point in time.
 
Petros Kolyvas said:
Yes when disk images are created with Disk Utility they can be verified immediately afterward by mounting them...
Click to expand...

In my case and the others I heard about the corrupt disk images mounted but some/all/part of the clip wouldn't play or import. So opening the image doesn't necessarily verify everything.

Petros Kolyvas said:
Also thanks for the questions - I think data integrity in this day and age of limited physical media (if any after production finishes) - is important to keep in mind; and there are probably even better ways of doing it than I am at this point in time.
Click to expand...

Your welcome and I completely agree. Data integrity is more important than ever, and anytime I see something in question on here regarding this I either help out or ask questions so I learn. I never want to be the one who loses footage and or clients and I cringe at the thought of others being that person as well.
 
Last edited:
You must log in or register to reply here.
Back
Top