Hi there.

A small number of the many thousands of AAFs which I've exported using GetLatest have no network locators. Consequently if you export the AAF from Interplay, delete the asset metadata from the database, then import the AAF back, the File Locations tab in the Object Inspector is blank, and if you use GetFileDetails nothing is returned.

The network locator is usually found inside the source package for each media file - the attached screenshot shows a bad AAF on the left and a normal one on the right (text dumps created by mxfdump).

All my clips have been created by Media Composer - I'm trying to put my finger on what's different between the bad clips and the good clips.

Confusingly, if I try to go to the filemobs for the bad clips, Interplay Access complains that there are no filemobs. However, you can see them there in the file, as the SourcePackageID for each track.

This is happening with my Interplay 2.3 but has also been seen to happen occasionally with a customer's Interplay 3.0.

Help appreciated!

Geoff.

Don't suppose there's any news on this fellers? It's a real problem for me, to the extent that I've written some code to fix up the bad AAFs. I attach an example of an asset before exporting its AAF and after re-importing it. This seems to mainly affect clips which are produced by AMA linking, though I haven't pinned down the exact cause yet.

The "before" screenshot didn't make it, so here it is again...

I'll check with our developer support team...

omsupport,

We are trying to understand the steps needed to reproduce this problem.

From your posts above, it seems to be:

1. In Media Composer, AMA link to a masterclip
2. Use Media Composer to check the clip into Interplay
3. Use the IPWS call GetLatest() to export the AAF
4. Use mxfdump to get a listing

That's it. The bad part happens when you then delete the clip from Interplay and check the AAF back in (using either the WS or Interplay Access).

Unfortunately I've not managed to reproduce it to order yet - I only found it by chance, when I was testing my code to parse AAF files. I looked through a stock of 1700 AAFs that had been exported from Interplay and found the problem with 8 of them (one is attached).

All the clips are a couple of years old and look like they were produced by Media Composer 5.5.2, so maybe the problem lay there. And maybe the Media Indexer had something to do with it.

I've never quite understood how Interplay creates these AAFs. I heard tell that it just makes them on the fly when you want to export one, which makes sense - I've noticed that if you export an AAF twice the second one isn't quite the same as the first, though the difference just seems to be in timestamps and UIDs.

And one final oddity is that while the binary format of 99% of the AAFs is straightforward KLV, every now and then I get one in Microsoft Structured Storage (AAF-SS) format. Is there any rhyme or reason to this discrepancy?

Cheers, Geoff.

Small correction - these clips weren't made by AMA linking, they were made by importing XDCAM OP1a MXF files into Media Composer.

I found one problematic clip (produced by Media Composer 6.5.2) which has the additional curious problem that all audio tracks show up as A0 in Interplay Access (see screenshot)! I found the original camera file and created a new clip from it - the new clip is completely normal.

The AAF for the bad clip mentioned above...