AVCHD File Structure problem

[awelgraven]

I have a friend who didn't know how to import hmc footage into FCP, so she ended up watching all the raw AVCHD video files in VLC, then renaming them in the Finder like you would normally do in Log and Transfer.

Now FCP crashes when trying to import that card. Is there any way to recover those files via FCP? Or will I have to convert them for her in Toast?

I've never used an HMC (i have an HVX) so I'm not sure what's possible.

 

[Superfresa66]

i think you have to go with the toast method, haven't heard of anyone fixing a broken file structure... but if i was to try and fix it, i would name them the same before she change them. I would just go with toast!

 

[Cranky]

It is not the file structure that is broken, it is FCP that insists on full PRIVATE directory. FCP is as user-friendly as a rope to rope-dancer.

 

[Superfresa66]

The structure is broken when you rename the files, even if you have the entire Private directory if you mess with the files you get this kind of problems... Not a big deal, I'm sure is a mistake she won't make twice!

 

[pailes]

It is not the file structure that is broken, it is FCP that insists on full PRIVATE directory. FCP is as user-friendly as a rope to rope-dancer.

How would you know that it's not broken? As soon as you start renaming the files you're breaking the link between the streams and the clip information files which indeed breaks the AVCHD file structure.

@Superfresa66:
Actually, it would be possible to recreate an entire AVCHD structure from scratch having only the stream files left. The HMC will not necessarily read it that way but FCP will most probably accept it.

 

[Cranky]

How would you know that it's not broken? As soon as you start renaming the files you're breaking the link between the streams and the clip information files which indeed breaks the AVCHD file structure.

I meant to say, that who cares about these links. It is FCP which is badly broken by design, because it insists on having the whole PRIVATE directory and is unable to work with bare MTS files.

MultiAVCHD can recreate PRIVATE folder that FCP should be able to ingest.

 

[pailes]

I meant to say, that who cares about these links.

Well the AVCHD specification requires these files and their clip information files otherwise it's non-compliant and thus not compatible.

It is FCP which is badly broken by design, because it insists on having the whole PRIVATE directory and is unable to work with bare MTS files.

FCP was designed to support AVCHD by log & transfer and it's not meant to deal with broken or corrupt data correctly. I think it behaves as it should and it's definitely not a design flaw or anything.

I could very well imagine that FCP requires the files for a reason, it's not that the AVCHD clip metadata is some redundant garbage. A lot of useful information can be retrieved from those files.

 

[Cranky]

it's not that the AVCHD clip metadata is some redundant garbage. A lot of useful information can be retrieved from those files.

FCP could provide ADDITIONAL features when the full directory structure is present, but should allow working with bare media files if a user wanted so. FCP is written in traditional Apple's way "do like we say".

 

[Superfresa66]

I kind of like the "do like we say" workflow, if you take the time to know what you're doing it becomes ultra stable... witch is why the entire "mac" mentality works as it should.

at the end of the day all i have to say is, It just works! no guesswork for me!

 

[pailes]

FCP could provide ADDITIONAL features when the full directory structure is present, but should allow working with bare media files if a user wanted so. FCP is written in traditional Apple's way "do like we say".

Is my standalone hardware Blu-Ray/AVCHD player broken by design because it can't deal with bare transport streams? I really don't think so.

Final Cut Pro is hell of a program and if there is one thing about Apple I really like it's the fact that they do think carefully about the things they do.