[Craig Seeman]

[Mitchell Huie] “they aren’t accepting them”

You may want to explain what’s not accepting them.
AVI is a container that contain any number of codecs.
If they have a specific program or a specific codec, they should provide that info.

There’s a True audio codec.

[Craig Seeman]

I reported it as well. I reported the extent of the fix too. It’s still not working for Archives created around June 2014 and earlier.

[Craig Seeman]

[Robin S. Kurz] “Well, I’m not sure which part of “a camera archive is the exact same thing as if you were to simply drag the contents of a card to a random folder in the Finder, only with a suffix” you’re not getting your head around, but the conversation has clearly become nonsensically circular. “

The Archive contains a .plist that is written by FCPX.

[Robin S. Kurz] “And the issue with the BMPCC was in fact an error that THE CAMERA was writing into the metadata file and how FCP was reading it. “

The fix was retroactive. There’s nothing in a BMPCC firmware update that would impact archives created the previous year. A change in approximately May 2015 suddenly made my Camera Archives going back to 2014 readable in FCPX.

You’re assume only the suffix of the folder is at issue. Given the issues FCPX had reading it’s own archives, one can’t assume the suffix will be the only problem. Of course the MAM can ignore the .plist file. FCPX certainly needs that info to read its own Archives properly so I wouldn’t make such assumption.

[Craig Seeman]

If there’s a MAM that can read Apple’s Camera Archives please do mention it.

FCPXML is widely supported even though there may be exceptions. On the other hand Camera Archives, as simple as the folder structure is, apparently isn’t.

[Robin S. Kurz] “But then you could always simply open the “folder” and import everything manually as any other media that you have copied from a camera to wherever, without any issues whatsoever”

Except the time it would take to do that for scores if not hundreds of Camera Archives. That FCPX can’t read its own Camera Archives from Blackmagic Camera preceding a certain date is a serous concern. If FCPX can have such issues then certainly that may be a problem MAMs don’t want to deal with.

[Robin S. Kurz] “Nope. It’s simply because they don’t recognize the suffix! Simply teach it that “.fcarch” means “folder”… BINGO.”

If it were that simple then why the issue with FCPX and the early BMPCC Camera Archives. The Archives contain a .plist file and apparently reading that isn’t so simple… short of ignoring it.

[Robin S. Kurz] “[Craig Seeman] “Perhaps FPCX Camera Archives is a proprietary can of worms.”

That being where you’re sorely mistaken, as I’ve demonstrated above.
“

Non Proprietary then why can’t FCPX read its own archives under circumstances noted previously. The .plist in the archive is likely the issue and FCPX can have problems with it.

[Robin S. Kurz] “No. Just your fault that you don’t understand what a FCP X archive in fact IS “

What it IS is something that FCPX can have problems reading in some cases and MAMx may not read as well.

If it were so simple….
It isn’t unless you think MAM developers have motives

[Craig Seeman]

[Robin S. Kurz] “Sorry, but I don’t see how it’s in any way Apple’s responsibility to work their development around the abilities of others.”

While some features (most features) can be entirely internal, outside of FCPXML use, I think an archival feature should be accessible to other software.

I’m not sure it’s Apple’s responsibility but if you have “two sides’ each ignorant of the other, it is not good for the end user. Saying it’s no one’s responsibility doesn’t solve the problem.

So it’s my fault that I have four years of Camera Archives because Camera Archives seemed like a sensible way to back up Camera Master files ensuring their integrity?

I’ll add that even FCPX can’t read any of my BMPCC camera archive masters predating about May 2014. At some point FCPX stopped reading them, possibly through a change in FCPX. That was partially fixed in a recent FCPX update as I can now read my current BMPCC archives going back to May 2014.

Given these archives are simply ProRes files with FCPX’s added .plist, it would seem Apple changed something. BTW this has only impacted archives from BMPCC (possibly other BMD cameras?) but not my other camera archives.

If Apple can change something that impacts the ability to read its own archives that can certainly pose a probably for any MAM attempting compatibility.

[Robin S. Kurz] “In fact I don’t see why MAMs shouldn’t be able to access/read FCP archives,”

I’d agree but given the issues I had with BMPCC I don’t doubt there could be some potential pitfalls attempted compatibility. Perhaps this is why MAMs don’t attempt this. Perhaps FPCX Camera Archives is a proprietary can of worms.

So is this Apple’s fault? Is it the fault of MAMs for choosing not to go there. Is it my fault for Foolishly believe FCPX Camera Archives were an intended feature that would be useful?

Regardless of blame I have years of Camera Archives and if it means I have do “undo” or avoid and FCPX feature for outside world compatibility there’s a very serious problem with this picture.

Personally if the “recommendation” is to avoid using FCPX Camera Archives then I’d have to say that Apple “walked me into a problem.” If it’s a hinderance to MAM compatibility then perhaps the feature should be pulled or, there should be a recommendation against using it.

[Craig Seeman]

Otherwise I’d have to abandon using Camera Archives and pull apart all the “packages” I have.

There’s something incongruous to me about Apple implementing a feature that’s fundamentally not supported in MAM software (I don’t think this is specific to KeyFlow Pro). It’s almost as if the User Guide should carry a warning about Camera Archives and MAM. One can dig oneself into a very deep hole with it.

[Craig Seeman]

It doesn’t support Camera Archives. While it’ll see the archive in won’t see the contents.

Given that, for me, Camera Archives are Camera Masters, that’s a serious problem.

It’s not clear at all if it’ll handle camera formats in which folder structure must be maintained in order for the metadata to be read properly. One example might be XDCAM EX recorded on Fat32 formatted SxS cards. Which, for me, the integrity is maintained through the use of Camera Archives.

[Craig Seeman]

Could that be an SLV file?

See this old post in NXCAM forum.
https://forums.creativecow.net/thread/298/1999

[Craig Seeman]

Issue in 6.0.4 where video without audio would cause discconects due to the way the encoder was handling it. 6.0.5 fixed the issue.

[Craig Seeman]

It’s always hard to make suggestion when someone says “various settings’ since we have no idea what you tried, what you actually missed if anything so, we end up making suggestions that you’ve already tried.

With that I’ll simply post what YouTube recommends and you can try them or confirm that you’ve tried them. BTW, simply stating “I tried that” often isn’t enough information. You should confirm the settings specifically because we have no idea whether you actually understood the settings you’ve tried.

Stating that you’ve tried a preset in an app without a version number, isn’t enough either since the preset may have changed through different versions. Additionally you eliminate the possibility of help from compressionists who don’t have the app at all so wouldn’t know the specifics of a preset unless you provide them.

https://support.google.com/youtube/answer/1722171?hl=en