Metadata practices
If you look at how Metadata is applied in sound effects libraries, from old to new, there is a considerable amount of variation to be found. Well, to be fairly honest... it’s all over the place :) For example in the formatting: some people use ALL CAPS in descriptions, while_others_ separate_every_word with an underscore. Or in the length: there are descriptions with only cryptic abbreviations, descriptions that are far too long and detailed, but you also find informative and concise sentences. So in general: 'metadata practices' vary widely.
'Metadata Club'
The first rule of 'Metadata Club’ is: there are no rules! We have to make those up ourselves and share them with the community. Our golden rule is to think like a sound editor/designer. It's too easy to think from just your perspective as a creator of the library. When you do that, you might create filenames/descriptions like these:
Sound A: 'Bike04 passes by fast on asphalt, XY-stereo-microphone at roadside'
Sound B: 'Chain comes off while passing by fast on asphalt, Bicycle 4, Shotgun-microphone tracking the source from roadside'
This might be enough to distinguish the files within your library from one another and provide the required information. What it doesn't take into account is that filenames and metadata ideally do more than that. We wanted them to realize these additional goals:
When you start thinking about how to realize these goals, you might notice that there's a potential clash between points one and three: You might want to serve goal number one and make the filename sort as perfectly systematic as you can, so you could be tempted to put some main category terms in the beginning of the filename - some people like to do that. But this creates an issue. If you take this to the extreme you might end up with something like this:
'FX-EXT-TRANSPORTATION-BICYCLES, Bike04 passes by fast on asphalt, XY-stereo-microphone at roadside'.
For the task of browsing sounds this might make sense, but note that it does shift some of the vital information quite far away from the beginning of the filename, which is the opposite of what you'd want in goal number three. When you are editing sound in a DAW you're probably more interested in the terms 'Bike04 passes by fast on asphalt' then 'TRANSPORTATION' or 'FX'. In an ideal world the exact terms that you need to know would appear at the very beginning of the name as you are editing, but unfortunately it varies which words are the most relevant to you - sometimes you want to know which clip is the bicycle, another time you're interested in the surface-type or the speed, depending on the context. Maybe we'll someday have telepathic computers or something like that… until then we'll have to compromise. Following the above reasoning we chose to put the most vital information first and still make it sort in a logical order for this library (more on that below).
To realize goal number two (memorable names) we borrowed from Sergio Leone: Our main bikes are called Good Bike, Bad Bike, Ugly Bike and Racer Bike… that should be colorful enough to remember! Watch the teaser if you haven't seen it yet: Teaser City Bicycles
Finding treasures
The last goal (make finding sounds easy) seems simple but can actually be very complex if you are prepared to dive deep… We won't go into the big issues here, concerning categories, language problems and such. But a few simple and useful rules on our way were these:
Following all these ideas we ended up with this as the fundamental building blocks for our two example files:
Sound A: 'BadBike PassBy Asphalt Fast XYMic'
Sound B: 'BadBike PassBy Asphalt Fast ChainOff MonoMic'
We then added the most important category-names at the end of the filename (bicycle and exterior), plus the short version of our company-name (Frick & Traa) and the number of takes in the file. And voila! - we have compact yet informative well-searchable filenames, that sort files by type of bike, perspective, surface and speed:
Sound A: 'BadBike PassBy Asphalt Fast XYMic F&T Bicycle EXT 3x'
Sound B: 'BadBike PassBy Asphalt Fast ChainOff MonoMic F&T Bicycle EXT 2x'
In some cases this still didn't serve goal number one (sorting files), for example in the case of our single-take pass bys: It's a collection of 21 different bikes passing by, from very smooth sounding to very broken. These give the user even more colors on their palette, in addition to the Good/Bad/Ugly/Racer bicycles, which is nice, but the (hopefully memorable) main names of these single-take bikes are all over the place, in terms of sorting alphabetically: 'CleanBike', 'OldBike', 'RattleBike' etc. So in order to bundle those together when viewing the files as a list we used a short prefix - 'VAR' for 'various' in this case.
Hierarchies
As for the use of the descriptive metadata-fields we decided to implement a three-step hierarchy: We put the most vital information in short form in the filename, a more extended version of the same plus some additional information in the field 'Description' and finally, the information that is least important, but which we still wanted to include for some reason, into 'Notes'. So for example in the case of the compact terms 'ChainOff' and 'MonoMic' (in the filename of our example Sound B) you'll find a more detailed explanation in its Description-field:
'Chain comes off, emergency brake using feet on the road, Mono mic tracking source, hypercardioid'
In this case the ‘Notes'-field just contains a summary on the type of bicycle ('Severely damaged bike, old, worn, rattling, chain comes off regularly, trashy'), but in other cases you might also find extra information like this: 'Take 2 and 3 with short skid’ or '1 long take 1 short take both with roll out'.
Keywords
As sound designers we enjoy stumbling upon a great sound, that we wouldn’t have thought of searching for. You might call this serendipity, but you could also say it’s the result of rich metadata. Keywords are a good place to support these little unintended discoveries.
We decided that the keywords should contain, well… 'key'-words from the description, their synonyms (if applicable), onomatopoeia (ie: squeak!) and brand names. This is an example of a set of keywords for the Racer Bike:
'bicycle, koga miyata, cycling, riding, ride, wheels, tires, stop, brake, stutter, skid, squeak’
The terms ‘ride, wheels, tires, brake’ are used for a lot of vehicles and moving objects. This helps using the sounds from our library for other sound objects. We used a gravel layer for a 'car arrival' scene to give it that extra bit of gravity and grit, for example.
Unique libraries > Unique Metadata
The sounds in our library are performed, recorded and edited in such a way that they ‘ask’ for a certain approach to metadata. During the creation of the metadata we tried to listen just like the first time in the field: We listened to the ‘voice' of our character-bicycles.
The resulting naming schemes and general approach all are a result of long sessions and conversations about what is optimal for the user. We would like to see more public discussion on metadata and are thinking about ways to do that. We think that this article can contribute to the field of other sound effects recordists and we hope to learn from their feedback.
Acknowledgements
We want to thank some people for their contribution to the field concerning 'metadata practices’.
Paul Virostek, his articles on metadata are very informative. Let’s hope people read his work and take it to heart, we certainly did.
Paul Col from CrowdsourceSFX libraries had the excellent idea to include a 'Metadata Reference Guide' in the upcoming ‘Walla’ library, to which we contributed.
Marco Vermaas for beta testing our metadata and sharing his professional experience regarding metadata and database management.
Discussion
If you're eager to discuss metadata practices, here are some places to go:
https://www.facebook.com/groups/independentsoundeffects/
Or become a member of the Facebook group: 'Sounds Effects Mastering and Curation'
© 2023 www.frickandtraa.com - Powered by Shoppagina.nl