Lately I ran into some problems because of the lack of metadata. I guess sometimes we all inherit files that contain less than satisfactory, descriptive metadata. While the first reaction might be anger, if we dig deeper, we would encounter a much bigger problem. In an ideal dream world there would be clear, concise standards that kept by all the manufacturers. Even more ideally, we would have one perfect standard. But we don’t live in a dream world like this, hence problems arise. One major disaster can be an operator who doesn’t pay attention to metadata. But that’s a simple user error. The other big thing is compatibility or rather, incompatibility. We have so many software that we can hardly enumerate all of them. These comes from different developers, have different feature sets, and use different implementation regarding metadata. And this is the main point. Not all of these otherwise useful tools handle our precious metadata with care. There are two possibilities.

1. (this is the worst of all) The implementation is flimsy or buggy:

We are lost, because the so important metadata might be truncated, or even worse, deleted. Now thanks to some very clever individuals and companies this happens very seldom, but I urge everyone to make preventive tests before the production. This is especially important with new software, or with new iteration of a certain software. Seeing is believing. Don’t forget that the developers are human beings too, and even though their intentions are the best, they might ruin something deep in the code. And just one tiny hiccup can ruin all your data.

2. Different implementations:

We have some very good standards, but the implementation of these are always up to the developer. They decide what is important and what is not. If we focus on metadata, we’ll soon realize that different apps treats metadata differently. Let’s take a brief look at some well known applications.

Example:

One fx library, enriched with descriptive metadata. If we use soundminer than there’s a great chance that we’ll able to see and use all metadata. But if we use some other application like snapper, or audiofinder, we might miss some fields as their handling of this data is different. And from this point on, it is not about bad coding. It’s about different implementation of the same standard.

We have a very good “specification” called iXML. In my opinion it is a very clever thing as the whole structure of the iXML metadata is simple, yet clever enough to contain every important information. Essentially it’s a chunk of metadata embedded within a broadcast wave file. It can be short or long, depending on the recorder or operator who type in the information. The best thing is our software doesn’t need to know every field. If something is not yet implemented, it can be skipped without any problem. Here’s Pro Tools’ iXML implementation:

If you want to know more about iXML, you can get all the details here.

So, then what is the problem? The problem is diversity. In one software I’m able to see and use all the metadata, but in others I might see only a part of the whole. And while I’m pretty sure about that I will use Pro Tools for the next couple of years, I’m absolutely not sure about that I will use the same sound library app. For years I had been using only the workspace in Pro Tools to input metadata. Now, as my time allows, I try to test many sound library apps to find out which is the best for me. Obviously soundminer is a safe bet, and it has probably the most advanced metadata handling, but it’s pricey. And there are many solutions on the market.

Currently on my radar:

• Soundminer
• Audiofinder
• Basehead
• And to be honest, Pro Tools’ workspace

I know there are many others, but I tried to do my homework, and these are the solutions that might likely work for me. While contemplating, head over to other very useful info on metadata at musicofsound.co.nz. There are a couple of very informative articles about this. And while I’m searching, any suggestion would be nice.