As mentioned in a previous blog about metadata, Pole has decided not to fully use the UCS standard for various reasons, you can read about it here. But we thought it would be interesting to hear UCS initiator Tim Nielsen’s story on what sparked the idea of UCS and what lies ahead in the future.
Tim, you’re supervising sound editor, sound designer and re-recording mixer at legendary Skywalker Ranch north of San Francisco. Tell us a bit about what lead you to your current position.
I grew up in the Midwest, and knew I wanted to work in movies, but had no idea how. So, I applied and was accepted to the graduate program in Cinema at USC. While there I was honored to be Skywalker’s first official intern and, in the summer of 1996, I spent the summer at Skywalker working with Gary Rydstrom. This led to a job shortly after graduating, and Skywalker has been home now for more than 20 years.
You are also one of the key initiators of The Universal Category System (UCS) – a set category list for the classification of sounds effects. What sparked that idea?
I was teaching a class in Germany about 5 years ago, and many of the students brought up the fact that they really had no idea how to organize a sound library. When I got home, I spent some time looking over what category lists existed at the time. There had been a few attempts, but I found they were all really lacking in certain areas or missing quite a few categories outright. I took a bit of time and generated what I felt a ‘decent’ list and that has been available for a number of years. When covid happened and some of my projects got pushed, I had some time and thought I would revisit the idea. Justin Drury from Soundminer got excited about the possibility of really integrating it into the program, and I gathered about 10 or 12 of the brightest people I knew doing this type of work. For a month we spent many hours each weekend working together trying to hone the list to what it ultimately became.
The main problem UCS was intended to solve was fairly simple. Anyone buying sound effects, anyone having to organize a library knows the pain all too well of getting sounds coming in with lacking, or inconsistent metadata, or inconsistent categorization. You might see something as simple as a prop airplane categorized as AIRPLANE, AIRCRAFT, PROP AIRCRAFT, AEROPLANE, PLANE, PROP PLANE…. so, if you wanted to call up, say all prop airplanes in your library, it would be nearly impossible. You’d have to have gone and ‘adjusted’ every incoming category one by one to match a system you’d have to come up with on your own.
The idea is simply if we would all agree to call them by one category and one subcategory, we’d have that consistency of sound categories.
How are the different sound effects categorized in UCS and how do users navigate and find the effects they are looking for?
The categories and subcategories are normally assigned into Metadata in the various database programs. At the moment, Soundminer, Soundly and Basehead all have UCS implementations, and I believe Search from PSE is in the works still.
But for programs that might not use metadata, we implemented something we called CatID. This is a simple abbreviation of the Category / SubCategory pair, and we recommended putting that always at the head of a filename, followed by an _. While some people quite disklike this idea, if done, ANY program could use a simple lookup table, take that CatID from the filename and fill in Category or SubCategory information. UCS has a whole filename structure, that is of course entirely optional. The CatID in the filename is also optional but has proven very useful for example programs like Soundminer, Soundly, etc., to see a filename, and instantly know the Category and Subcategory to assign based on that CatID.
The second benefit that many people like is that it forces like files to sort together. All metal doors would sort together in a folder list, in ProTools region bin, etc.
One of the areas that people react strongest to is the filename structure. But I fear they’re really missing the point of it. My argument is that a ‘consistent’ filename, with structure, can very easily be shaped and changed by the end user. Right now, when files come in from 15 vendors in 15 formats, and even worse sadly most vendors don’t even have a consistent filename from library to library, it changes over the years… but as a librarian, it becomes quite a chore to one by one have to go through and reshape those filenames. One thing I’m doing these days is to offer multiple filename options in Metadata. We’ve written a small app that can actually take a list of files and with a click, swap them out to an alternate set based simply on a .csv list. So even if some vendors feel strongly against our filename structure, which is fine, they could offer up a USC filename simply in Metadata, so that a user who does want to use our filename system, could easily do so. For the recent My Home crowd source I ran, I built three complete filename options, one USC structured one, and two more that were more ‘readable’.
Or if Vendors have released a library, they could simply supply a new .csv that would allow any of their customers to swap out to various filename structures.
Would you describe UCS as a work in progress and that new features will be implemented along the way?
The core of UCS is the list itself, and while it may change over time, it will only ‘grow’. We will never take existing categories away. We have a list of around a dozen new categories and/or subcategories that are under considering for a next revision, but we certainly wouldn’t update the list maybe more than once a year. But the list we have now is quite stable and anyone using it, they will never find a situation where we have taken categories away.
Certainly, there is more talk of ‘what else’ we could achieve. One thing we’ve talked about is something like Universal Metadata, so one set of metadata of the common fields, that all programs could use. iXML fields offer this as a possibility. Right now, a user using one program to create the metadata, it may not load completely in another program. Different programs use different names for basically the same piece of information. I’ve thought it could someday be useful to define a standard set of UCS Metadata Fields, that could be stored in iXML and be available to any program.
There are more and more tools being conceived and written that take use of the system, to make if friendly and easier to use. The Renamer app will be released soon, there are some quite clever programs and scripts written already, but I think we’ll see more as people find interesting ways to integrate the idea into different programs.
More from Pole:
