Describing our Bicycle library

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: 

1. Sort files in a sensible order when viewed in a list.
2. Help the user memorize the sonic character of your sound objects by using short but descriptive main names (Bike04 is not very memorable).
3. Make it possible to quickly identify sounds in a DAW-track by putting the most important information in the beginning of the filename (the user often only sees the first few words in a clip/region-name).
4. Make finding sounds in a database as easy as possible.

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: 

1. Use abbreviations or codes to shorten much-used phrases, but don't make them cryptic. 'XYMic' is a lot more intelligible to a sound person than 'XYM' for example (we needed that term in the name to differentiate between mono and stereo mics).
2. Make finding sounds easier by using standardized terms for often used phrases, for example: 'PassBy' instead of 'passes by' or 'passing by'. This also makes it possible for users to change our phrases to their own using batch-renaming: Some people might prefer "Passing" over "PassBy" for example. 
3. Try to avoid words that obviously overlap with common search-terms or often used phrases, for example: 'shotgun-mic' - overlaps with 'shotgun' (the weapon), 'close perspective' - overlaps with 'close door'… use something like ClsPersp or ClsUp instead.
4. Be frugal. In the filename especially, use 'character-saving' ways of writing. Filenames should be as short as possible without losing the most important information - we need concise names to increase readability and avoid truncation/compacting in some applications. We chose to use blocks of words separated by spaces, without any commas (MediumSpeed Start-ride-stop etc). 
5. Automate the process as much as possible, this limits the risk of typos and inconsistencies in the metadata (more on this in another post).
   
   

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'