Transfer of content between companies remains a time consuming and costly process. In a lot of cases it is not the time taken to get the file from A to B which is the time consuming aspect, it is the interpretation of what exactly has arrived when it gets there:

We all know that Metadata is the answer, but what is metadata? How should it be stored? And how can it be made easier? In this blog post I will look at 5 secrets to make Metadata easy…

When I say easier, should it be easier for the content creator to generate the Metadata, or easier for the content recipient to interpret the information contained? Can it not be both?

One

Initial consideration is what data should be captured or in other words the Metadata Schema, should it be video codec, resolution, and frame rate along with the same information about the audio? The metadata schema depicts all the information which should be included in the metadata and should cover all aspects of video and audio so that downstream processing decisions can be made based solely on the metadata, no asset analyses should be required.

Two 

Next, how should the metadata be carried? When creating the metadata for a particular asset you may not know who is going to receive it. Is it going to be supplied to a multinational broadcast facility where it will be imported into a MAM and processed along with the hundreds of titles received on a daily bases? Or is it going to a small post production house where it is to be put back on tape so it can be supplied to meet a particular customer requirement?

Either way it is probably best to choose a language which tailored to both. XML, a language designed to store and transfer data with the benefit of being both human and machine readable. It therefore doesn’t matter which of the above facilities receives the content, the metadata contains usable information.

An additional benefit of using XML is the addition of a Style Sheet, formatting like data in a nested structure and presenting the metadata in a more readable way. While this addition would probably not assist the larger organisation above, it will help the individual who has to read and extract key information when making downstream processing decisions.

Three 

What if the schema you decide upon uses a similar naming convention as someone else? You supply the content to the broadcaster who attempts import into their MAM, the MAM rejects the files based on the contents of the XML due to a conflict with a previously used naming convention. Creation of a namespace in your XML allows for similar tags to be used within differing schemas, therefore removing the likelihood of conflicts between differing XML Metadata files.

Four 

You now have decided on the metadata you plan to supply with your asset, you know how it is going to be carried and how it will be presented. You have ensured there will be no conflict between metadata carried in your XML and that of other suppliers.

What about confidence in your metadata? Can you be sure it is all present and correct? Depending on how the metadata is created, is there a potential for incorrect values being entered? Validation of the metadata prior to submission is good practice, ensuring the information is present and complete therefore removing the potential for follow-ups on previously supplied content.

Five 

Finally, the easiest way to make metadata is to employ one of the previously defined standards, AS-11, AS-12, DPP… While each of these standards specifies the metadata will be carried in the MXF wrapper, the same information can be supplied as an XML side car, using a pre-defined schema and already has validation tools available.

AmberFin iCR provides support for both embedded and side car metadata though a simple plug-in, allowing data capture during content creation, the generation of a side car XML and the embedding of metadata in the file wrapper.

The Real Secret 

The real secret to making metadata easy is to not re-invent the wheel, use predefined standards and greatly reduce the cost of content transfer.