Ready to improve your sound library metadata for more productive search results? Here is Kai Paquin's 'Metadata Style Guide' which follows the UCS filename format developed by Tim Nielsen!

---

Written by Kai Paquin

---

Please share:

• More

Quick Reference

 
↑ Back to top

Foreword

For those reading, a few things to keep in mind:

This isn’t a best practices guide, this is an explainer of how I like to format metadata currently. I expect these practices to change in the future as I keep learning and coming up with better ideas.

This guide is also written with using Soundminer Pro v5 in mind. A lot of these practices would be less useful to someone using another databasing program or using a file directory to edit.

A lot of what I know was learned from studying other people’s formatting and pulling together what I thought the best ideas were, so hopefully this guide can be a short cut for building your own best practices.

This guide also refers to using a “Music & FX” database within Soundminer. If you see fields you don’t recognise mentioned in this style guide, you may need to create a new database using the “Music & FX” template.

Last Updated (2021/08/20) (SM 5.0v718)

↑ Back to top

Folder Structures

For anyone approaching a SFX collection for the first time, the first piece of advice I’d offer is organizing what’s already there before adding more to the collection. Good organization at a folder directory level helps keep things more organized even when being looked at in a database program like Soundminer where you don’t usually look at the folder structure at all.

I personally break down my collection into the following folder structure:

• Commercial Libraries
  • Commercially purchased libraries from places like ASFX or Pro Sound Effects
• Private Collections
  • This includes things like individual recordists and curated collections like crowdsources or kickstarter libraries
• Shows
  • This is specifically for show libraries ie. TV shows, Movies, Commercials, Games, ect.
• Trademarked
  • These files are restricted use files like Iphone ringtones. These don’t get scanned into the library, but are easily available in the folder structure when the licensed sounds need to be cut in to a project.
• Demos
  • Library demos live here and not in the commercial library folder. It becomes much more difficult to remove a demo library once it’s mixed in with the commercial libraries since the file names are the same. You’re able to discern what files are demos by looking at the filepath this way.
• Raw Files
  • Raw files mirror the structure of the individual recordists folder. I’ll explain that later.

Here’s a link to a template folder structure:
https://drive.google.com/file/d/1Qqd9ASLAOrAWvqo6QtX26DiMNtIzKyEw/view?usp=sharing

As I ingest raw recordings, I’ll create a folder starting with “RAW”, my creator ID, the date structured YYYY.MM.DD and a short description of what the recordings are of.

Once I’ve mastered the files, I’ll create a folder that mirrors the raw file folder and remove the word “RAW” from the name. Because of the formatting of the name being the same, if I’m working on a project where I need more material of the content I’m editing, I can go back to the source material and see if there’s anything I omitted, or if I over-compressed the files while mastering I can access the source and remaster them for the content I’m working on.

Keeping raw files may or may not be in your interest, but as technology keeps advancing, having access to things that could benefit from better denoising might be worth keeping especially if they’d be difficult to recreate or re-record.

Example 1:
As a kid I had recorded several ambiences on my uncle’s farm in Oregon. This was at a time when I didn’t own Izotope and was using denoising with adobe audition and a 200hz high pass.
Further into my career now, I no longer live in Oregon, my Uncle has sold his farm, and I have better tools and a better understanding of how to use the tools.
After remastering the old recording It’s much more usable

Example 2:
A few years ago I spent a day at a horse ranch. While mastering, I focused on archiving the horse vocals and chose not to archive materials that would take a lot of effort to master like horses moving around in the barn. Years later, while working on a project, I realized that discarded material would be useful and I went back to the original recordings to see what I had. 

↑ Back to top

Metadata tutorial – video version:

Kai Paquin has also done a video tutorial on his metadata approaches – check it out below:↑ Back to top

Filenames

Currently I’ve adopted using UCS Filenames.
Tim Nielsen wrote a very detailed document explaining the portions of a UCS compliant file name and how it works as well as several youtube tutorials.

Documentation:
https://drive.google.com/file/d/1iznORG-4a-7sEGRlZRFRk4cCvJrkzd3m/view?usp=sharing

Youtube Tutorial:
https://youtu.be/0s3ioIbNXSM

Additionally you can find a number of resources for building UCS filenames on the UCS website:
https://universalcategorysystem.com/

My reasons for adopting this file naming structure is that all pertinent information about the recording is in the file name. Category, Subcategory, Description, Recordist, Library, and a “Wild Card Field”. Another advantage of the filename structure is that sorting the files in a file browser or DAW is very easy.

Most people use UCS file names with some form of additional flavor formatting

In my case I format files

CatID_ TrackTitle FXName_ CreatorID (short ID) _SourceID (ISWC) _ISRC

DOORWood_ CABIN DOOR Front Door Think Plank Cabin Door Open and Close Skid Across Loose Wood Planks_
KAIB_KPOR_63C3F735

CatID: These are the CatIDs explained in the UCS website

TrackTitle & FXName: The addition of TrackTitle to the FXName keeps the file name legal for UCS standards, and additionally gives you an extra field that can be extracted that wouldn’t be available otherwise. This can be extracted with this Soundminer workflow:

Extract Track Title from FXName
https://drive.google.com/file/d/12z17feprbLZ9_fi4NXPoWHENbs0ryEKZ/view?usp=sharing

You can read more in depth about FXNames in the USC documentation or later in this style guide

CreatorID (short ID): CreatorID is taken from the ShortID field. These codes are proprietary and based on an ongoing list I keep for myself

SourceID (ISWC): SourceID is taken from the ISWC field. These codes are proprietary and based on an ongoing list I keep for myself

ISRC: Commonly people will append their file with the microphone in the UserData chunk of the filename, but I’ve taken to using the ISRC field (which is explained later) to assign a unique code to each file. This allows me to never mix up two files with similar names, and makes it easier to search for in a finder if I have a small region pulled in a Pro Tools session.

↑ Back to top

 

Descriptions

Single Source SFX

 

TITLE (Take#) – subtitle – Prop, Verb, Descriptive Terms

Example:
BLOW TORCH (01A) – Ignite – Propane Blow Torch, Ignite, Steady Blowing then Back and Forth Movement before Turning Off

Single Source SFX include anything like performed props, single objects that emit sound, or groups of objects

Examples of these would be
Prop: A Light Switch (being performed)
Single Object: A Light Bulb (buzzing after being turned on)
Group of Objects: Dominoes (falling down)

TITLE – Name of the prop or sound source in the recording. In the instance of two objects being hit together pick the dominant sound in the recording

Take# (optional) – In the case you have multiple microphone perspectives and master the same recording split into several files often times I’ll add a take number and letter to represent that mic angle ie. 

• Take 01 Close Up MKH416 = (01A)
• Take 01 Distant MKH8060 = (01B)

As the takes progress if you’re looking for the distant perspective of the recordings from that recording session you’ll quickly recognise that the “B” perspectives are always the distant mic in that set of recordings and you know you can skip the “A” perspective recordings.

Subtitle (optional field) – when you have several things sharing the same title ie. BASEBALL BAT, but have several actions associated to that object oftentimes it’s nice to delimit them with a ‘ – ‘ for faster reading purposes.

• BASEBALL BAT – Drop – rest of description
• BASEBALL BAT – Hit – rest of description

Hit, Drop, Scrape ect. I’d put that information in a – delimited space so it’s easy to discern different actions with that prop.

Things like animals, like if you were making a collection of dog barks, it might be nice to label the subtitle the animal’s name: 

• DOG BARK – Spot – rest of description
• DOG BARK – Scooby – rest of description

Prop – Further detail about the prop ie. Wood Baseball Bat vs Metal Baseball Bat. This might be omitted if it’s redundant compared to the title and would skip to verb

Verb – This is the action being performed by the prop or object being recorded

Prop and verb fields might be redundant if covered by title, and could be considered being omitted if they are.

EXTRA tip: It can also be useful to add a unique and easily remembered word to a description. While editing sounds and searching, most editors memorise their favourite sounds by them. It has to be specific to the recording of course.

↑ Back to top
 

Ambience SFX

SETTING – Specific Location, State – Primary Content in Descending Order

Example:
URBAN NEIGHBORHOOD – Echo Park, CA – Moderately Busy Neighborhood, Traffic Wash, (CU) Dog Barking, (MED) House Sparrows, (CU) Occasional Pedestrians, (DST) Car Horns

SETTING – Settings would be between 1-3 words that give you a basic idea where the ambience was recorded ie. Boat Warf, or Elementary School

Specific Location, State/Provence – Between the title and the description is a – delimited space for specific location then state abbreviation ie. Los Angeles, CA. If the ambience was recorded outside of the US, the format of “specific location, country” is used instead ie. Paris, France

Primary Content in Descending Order – Descriptions for Ambiences should be written in order of sonic precedence in the recording. In the example above, we start with “Moderately Busy Neighborhood” to give the editor a quick insight of what the recording is, traffic wash is the next most prominent and consistent feature of the recording. Once the description becomes a list of things in the recording, I’ll sort them from most to least frequent, oftentimes using parentheses with (CU) (MED) (DST) rather than specifying close up, medium, distant because it visually reads quicker.

↑ Back to top
 

Vehicle Driving SFX

CAR MODEL & YEAR (Take#) – Specific Action – MPH if applicable, Order of Actions if Maneuver ||| Car Model & Specific Engine Info  

Example:
TOYOTA COROLLA 2021 – Pass By – 60MPH, Accelerating, Fast Pass By, Pan With |||  2021 Toyota Corolla, 1.8 L 4-cylinder Engine    

Example:
TOYOTA COROLLA 2021 – Maneuver – 10MPH, Slow Pull in, 3 Point Turn, Park, Turn Off Vehicle |||  2021 Toyota Corolla, s1.8 L 4-cylinder Engine    

Vehicle Driving vs Specifics of the car are treated differently for the purposes of descriptions. This is so it’s easier to track down what’s driving vs the car doors, mirrors, ect.

CAR MODEL & YEAR – Vehicle Driving FX start with the Manufacturer, Model, then Model Year as the title

This way, when looking at a flat list of vehicles, you can sort out a 1991 Toyota Corolla from a 2020 Toyota Corolla since the car has been in production for decades, but these two year models are widely different sounding and may as well be different vehicles

(Take#) – If there are multiple recordists recording the pass bys, maneuvers, ect, this can be extremely helpful for discerning the close and distant perspectives or mono vs stereo setups from one another

Specific Action – is handy as a visual delimiter for separating pass bys from parking from complex maneuvers. In the case of a maneuver that involves more than one driving maneuver like a pull in, parallel park, drive away, I would label this a “maneuver” in that space, then list the maneuvers in the descriptions

MPH (if applicable) is a helpful when you’re talking about onboard driving or pass bys, but often times can be skipped for things like parking maneuvers, accel away or decel pull ins

||| Car Model & Specific Engine Info – In this section I’ll often start with the year, make then model. It’s especially important to use a visual delimiter like ||| or /// as a strong visual break between the description and the vehicle details. This section is treated differently for vehicle specifics

↑ Back to top
 

Vehicle Specifics SFX

TITLE (Take#) – Verb, Descriptive Terms ||| Car Model & Year  

Example:

CAR DOOR (01A) – Open and Close, Various Strengths, Creaky Hinge, Ronk, Antique, Jalopy |||  Ford Pinto 1994  

Example:
EMERGENCY BRAKE – Pull and Release, Press Button, Pull with Ratcheting, Release |||  Ford Pinto 1994  

For vehicle “specifics” like car doors, emergency breaks, things that don’t involve driving the car, you’ll treat the TITLE like any other prop, following with a verb and other descriptive terms.

The section for “||| Car Model & Year” is treated differently in that there’s no reason to include the engine details in a recording of a car door, but the make, model and year would be important if you’re talking about a luxury car vs a rusty ford pinto.

Like single source FX, take number and subtitle can be applied optionally as needed

↑ Back to top
 

Synth SFX

TITLE – Style of Synthesis, Descriptive Terms, Pitch

Example:
FLUX MATRIX – Granular Synthesis, Abstract Warping and Fluttering, High Energy Movement, Fluctuating Pitch Between High and Low Frequencies

Example:
DRONE – Subtractive Synthesis, Bassy Flat Tone, Pulsing, Low Energy Movement, Low Frequency Rumble

 

TITLE – I usually try to come up with a descriptive but distinct name for the recording, oftentimes suggesting how the recording might be used.

Style of Synthesis, will usually come first when applicable, things like granular synthesis, additive synthesis, west coast and east coast synthesis can be really helpful for defining the pallet of sound you’re looking at.

Descriptive Terms usually are fairly abstract, but I like to use terms like high and low energy for how much change is happening within the recording

Pitch is often helpful when a sound is consistent, knowing if you’re pulling a high pitched tone vs a low pitched tone

↑ Back to top
 

Other Thoughts and Opinions on Writing Descriptions

To me a good description does three things:
 

• Gives you a quick summary of what you’re going to listen to
• Gives you several searchable terms
• Gives you a more detailed understanding of the recording than the FXName

Here’s some rules of thumb I try to follow:

1. First and most important thing is I try to keep the pertinent descriptive information in the description column. Having information in the filename that isn’t in the description becomes a really frustrating mess in the context of browsing all your libraries in a database.
    
   Having something like the prop and action in the file name, then a description in the description column means you’re reading across two fields. This is fine in a self contained SFX library, but doesn’t work in the context of thousands of files formatted in different formats. Keeping everything in one field means you can reliably find the info you’re looking for. Since description is almost universally plain text of the description, this is one of the best fields to read for understanding what’s happening in the file since filename can be used for multiple purposes.

    

2. Second starting the description with the primary content and action. For props this is pretty easy something like “Catching a VHS Tape, Plastic Impact and Rattle” I’d reformat this so I could quickly read what the prop is, then the action ie. “VHS Tape, Catch, Plastic Impact and Rattle”
    
   Example:
   OLD:  “Catching a VHS Tape, Plastic Impact and Rattle”
   NEW: “VHS Tape, Catch, Plastic Impact and Rattle”

   The reason for this is if I look up something like Plastic Impact, I’m going to pull up thousands of different plastic impact sounds like “hitting plastic tray with hammer” and I might be trying to cut plastic fence impact, so generally knowing what the object being performed helps make informed decisions quickly that a VHS tape is not the same size as the fence and should be skipped while I’m looking at plastic impacts.

   For something like an ambience, I try to put the setting or primary subject matter first like “Wind in Pine Trees” or “Urban Neighborhood”, this helps me if I’m looking for something like “traffic wash” I know “Wind in Pine Trees” might have traffic wash in the background of the recording and is mentioned in the description, but isn’t necessarily the primary subject matter of the recording.

   It’s also worth mentioning some people start descriptions with “This is a recording of…” or “This is a sound effect of…” which means you now are reading about 6 words before you actually have an idea of what the sound is. In that time I probably could have just clicked on the sound and gotten a rough idea of what the recording was before I would have finished reading those words 

    

3. Third formatting text. This is strictly my own personal preference and not something I’d expect other people to follow. If you look at the 2nd and 3rd photos on this post, there are decently written descriptions. One is all in ‘Title Case’, where everything is written like a standard sentence. The next example is one where the prop is in all caps and has a visual divider.
    
   I generally find the all caps and divided text format makes things easier to read, especially when all the files are formatted that way. When you type something like “wind” as a search term you can quickly assess what recordings are “wind” which are “windows” and which are ambiences with the word “wind” in them in this way.

   This mirrors old text binders for tape catalogs, and I believe these were developed for optimal speed reading. 

↑ Back to top
 

Some Additional Considerations when Writing Descriptions

Giving the right amount of information in the description. Too little information like “baseball catch” might not give you much to search in a library or give you a full understanding of the recording. A description like “catching a standard sized baseball in a leather glove being thrown at 40mph. Fastball hits glove and creates a loud thwacking impact on leather” is probably too much information.

A good middle ground is to take that full sentence and arranging it in comma separated “thoughts” ie.

Example:
OLD: catching a standard sized baseball in a leather glove being thrown at 40mph. Fastball hits glove and creates a loud thwacking impact on leather” 

NEW: BASEBALL CATCH – Fastball Caught by Leather Mitt, Glove, Twack, Hit, Impact
 

You can see that I omitted using the word “baseball” in “baseball mitt” because the term “baseball” is searchable and inferred already by the context of “baseball catch”, this keeps the description short and comprehensible.

In the context of ambiences, I think it’s worth mentioning trying not to mention every single “event” in a recording. In a 5 minute recording if there’s a single dog bark at one moment in the recording, it’s probably not worth putting in the description since it’s not a primary characteristic of the recording.

Example:
If there’s a steady bed of traffic wash and some sparse birds consistently through the recording, that’s something that should be mentioned. Some single events like a police siren that spans 30 seconds of the 5 minutes would also be worth mentioning since it takes up a good chunk of the time of the recording. Ambiences can be tricky to write descriptions for, but if you think in terms of “what’s primarily happening?” vs “what are all the things happening?” it helps keep everything in context.
 

 
Try not to use the description field to host multiple chunks of information.

Putting things like microphone info in the description waters down the field in my opinion and would be better served in the filename or more ideally in a microphone field of your library software.

There’s times where this can be appropriate, like if you have multiple mics representing a single recording.Very often though, you can put that in the file name or microphone field and not water down the description field.

 
In the example below of the wine glass, I have several performances of the same action and I have a number signifying the take number then the letter represents the mic setup. This is just a quick short hand so I don’t have to explain at the end of the description “Take 17 Sennheiser MKH416″ or something like that. It just means I can save visual space in the description field when browsing.

Here’s a Soundminer v5 workflow for taking the first couple words, putting them in all caps and separating with a – symbol:
https://drive.google.com/file/d/1hpaYEsIXeexcnc2M3GMWomwZSfSYHtpU/view?usp=sharing

Video of Script in Use:
https://drive.google.com/file/d/1zphILHFXTDex7cAgfsPbbL1AH3S6t0fW/view?usp=sharing

↑ Back to top

Inline Markers

Another helpful way to avoid cluttering the description column is to use inline markers to provide notes for the editor. This is especially helpful for ambiences with one-off moments like a distant siren, dog barks or other things that might not register by looking at the waveform.

Singular moments might not be necessary to include in the description if it’s very brief and is implied by other searchable terms. For instance if you’ve already mentioned traffic, and there’s a single muscle car in a 5-10min recording, it’s probably not worth writing “muscle car” in the description and let that moment fall under the term traffic. You can still point this out with a marker on the waveform to draw attention to it.

Terms written to markers can also be extracted with Soundminer, and later put in the keywords field if that becomes a concern down the road.

As a side note, inline markers can also be used for noting particularly good performances for props, different performances of a single prop, or deviations from the rest of the takes

↑ Back to top

Keywords

This field is where I’d put searchable terms that would take up too much space in a description, or don’t have to do directly with what’s happening in the recording. You can also put synonyms in it or words that describe what the sound could also be used for.

Ie.
Description: Metal Oven Door Shut, Slam, Rattling Metal Impact
Keywords: Robot Footstep, Armor, Thud, Hit, Close, Shut, Open, Clank

By moving extra words to the keywords, I don’t take up visual space in the description or confuse what the content of the recording is. How it could be used is represented in the keywords.  This  keeps redundant wording like “Close” and “Shut” from being side by side in the description making the descriptions easier to read.

I don’t always use keywords in my personal library since it takes extra work, but I will commonly use this trick in my commercial releases where I take extra time and effort into making a product.

↑ Back to top

FX Name

FX Name is usually derivative of the Description. I’ll usually grab the Track Title, and the first 3 comma separated values of the description and copy them to the FXName field.

Here’s a workflow to do this quickly:

FXName Capture Up to 3rd Comma of Description
https://drive.google.com/file/d/1-IaesF9MWGPTx4dHFbAU169x5i__7aO3/view?usp=sharing

In the FXName, I’ll remove any commas, periods, dashes, underscores and illegal characters since this field is used to build out the filenames.

A good FXName shouldn’t exceed 20 words. Beyond that, the filenames get too unwieldy once you add CatID, UserID ect.

Ideally a FXName should sit between 10-15 words

Here’s an example of a description converted to an FXName:

Description:
PLAYGROUND WHEEL – Continuous Turning – Rhythmic Slow Turning, Rusty Metal Playground Structure Steering Wheel, 4 Story Rocket Slide, Reverberant Metal Ronks and Squeaks || LIGHT BG NOISE

FXName:
PLAYGROUND WHEEL Continuous Turning Rhythmic Slow Rusty Metal Playground Structure Steering Wheel

↑ Back to top

Track Title

“Track Title” is a portion of the description I prepend to the files in order to be able to skim over recordings quickly when I’m searching for a file that contains my search term.

Ie. If my search term is “wind” that pulls up: Wind, Window, Ambiences with Wind, Winding up Toys ect.

The content of the track title depends on the type of sound being labeled. You can read more in depth in the Description Section of this document but here’s a short hand list of TrackTitles

Additionally as a separate field, I prepend my descriptions with Track Title
i.e., Track Title – Description

It’s important to separate the Track Title with a “ – “ or another form of a delimiter because this allows you to quickly remove the track title with a workflow, separate it to another field, and otherwise manipulate the text effectively.

↑ Back to top
 

Manufacturer & ShortID

Manufacturer

Commercial Library

Use library name as specified by manufacturer
In my own case since I’m a publisher and have a personal collection, I personally use Kaibrary in both cases, then subdivide personal recordings from commercial releases using the library field.

Personal Collection

In the case of a personal collection like a recordist friend gives me a file from their personal collection, then I use their First and Last name as a substitute for a manufacturer name

Show Library

In the case of a show, I’ll fill the company the show I worked with ie. Lime Studios

↑ Back to top

ShortID

ShortID is a 4 letter code. Usually I’ll try to take the first few letters of the manufacturer name so it’s easy to remember, if the Manufacturer name has two parts to the name like “Sound Ideas” I’ll often abbreviated those names using the first two letters of the first and last name ie. SOID

In the case of personal collections like recordists, I’ll take the first two letters of the First and Last name ie. Kai Paquin = KAPA

↑ Back to top

Library & ISWC

Library

Commercial Library

With a library from a Commercial Library, I’ll assign the library field with whatever the Manufacturer named the library. For the ISWC short code I try to take the first 4 digits of the name of the library or the first 2 letters from the first and second word. This has to be compared against an ongoing list of IDs to make sure there are no duplicates.

Personal Libraries
This depends on the library, but in most cases, if it’s a file or small set of files from someone’s personal library, I’ll use their name in the Library field. In the case it’s a small personal library like a 1969 VW Beetle, I’ll name the collection and assign it to the library field. This way I can recall the entire collection by the library name

Show Library
I usually try to assign the show’s name to the library field. In the case of a tv show or media with multiple seasons, I also include what season the SFX was made for. Ie. “QForce S1”

↑ Back to top

ISWC

ISWC is carried over from an old style I was following. ISWC actually is a field used for International Standard Musical Work Code, but since this isn’t applicable to SFX use, I’ve repurposed the field to host a library code. This follows the same structure as “ShortID” using the library name as the source.

↑ Back to top
 

Mic Perspective

Mic Perspective is a quick way to browse the approximate distance between the source of the recording and the microphone

The mic perspective field uses one of the terms from the first and second table below separated with a delimiting symbol, or a single term taken from table 3.

I’ve settled on “ | “ as my delimiting term

Ie.
CU | INT = Close Up, Interior
D/I = Direct In
 

TABLE 1

TABLE 2

TABLE 3 – Single Use Terms

Besides the benefit of being able to quickly assess the distance of a recording, keeping this info in it’s own column allows you to sort recordings by distance and if the recordings were recorded inside or outside.

Oftentimes knowing if the recording was done indoors or outdoors is unnecessary, but in cases like “dog barks” knowing this can often be critical to the recording. A “DST | INT” vs “DST | EXT” in almost any case sounds widely different, and is nice to be able to discern on a glance.

↑ Back to top

Location

Location Should be Sorted By:

Continent, Country, Provence, Region, Specific Location

Ie: Europe, UK, England, London, Croydon

By organizing your locations with comma separated values, this allows you to browse locations using soundminer’s side panel and allows you to drill into specific locations. The more specific you are, the more you can drill down in this way.

↑ Back to top
 

Category & Subcategory

https://universalcategorysystem.com/
 
Soundminer has integrated support for UCS built into soundminer and can be accessed in a number of ways. Using this system also affect’s the “CatID” section of the filename

I prefer to keep my Category and Subcategory all Caps to match the default setting provided by Soundminer since most other people also do this and it prevents needing to adjust later.

↑ Back to top
 

Recordist

Starting in SM v.5.0.718 the Recordist field has been introduced and should become the primary field for the recordist’s name. Prior to the introduction of the Recordist field, I would use Designer.

Recordist Field should reflect the person holding the microphone in the recording. I don’t usually fill multiple people into this field. If there’s multiple recordists on a single recording session, I’ll keep a folder structure where the parent folder is for the session, then the sub folders reflect the recordists. I might additionally include this in my notes field

If there’s 1 mic and multiple recordists (for some reason) I’ll add that to the notes.

If you’ve installed v5.0.718 and don’t see this option, creating a new database will make this field accessible.
 

Artist

Artist is a good field to additionally mirror the designer field to. This allows you to display the creator’s name in the info panel of mac’s finder under the “authors” section of the browser.

↑ Back to top

Microphone

 
Brand, Microphone Model

Mono

Ie.
Sennheiser MKH 416
 

Stereo & Multi Mic Arrays

Listed in order of channels.
If there’s multiple of a single mic in the array, I’ll show this with (x#)
I’ll usually try to arrange my channel order to start with a stereo pair or stereo mixdown in a multi channel arrangement so that the mics play out of headphones cleanly.

In a situation where I’m doing an LCR instead of LRC setup, I’ll still show arrange the mics like the example below, but also show the mics in IXML Track Layout in the order they appear

Ie. 
DPA 4060 (x2), Sennheiser MKH 416
  Ch1: DPA 4060
  Ch2: DPA 4060
  Ch3: Sennheiser MKH 416

Midside

In a decoded MS array, I still list the microphones separated with a /
Ie.
Sennheiser MKH 40/MKH 30

↑ Back to top

IXML Track Layout

IXMLTrackLayout is used for multi mic files. In circumstances where you want to show a file in LRC but the center is not the same microphone as the L&R, I’d show this in the track layout

The channels in soundminer will show in the comma separated order they appear in the IXMLTrackLayout field.

In the photo below the IXMLTrackLayout is written

Eng Front (1), Eng Rear (2), Eng Turbo (3), Electric Eng Front (4), Intake (5), Tailpipe A (6), Tailpipe B (7), Driver Sound Port (8), Int L (9), Int R (10)

↑ Back to top  

Channel Layout

The Channel Layout field does something similar to IXMLTrackLayout, except only the abbreviations below can be used

The advantages to Channel Layout over IMXLTrackLayout is that if you order files L/R/C/Ls/Rs you can reorder the files in Soundminer for playback on a surround system

You can additionally use M/S on encoded (raw) midside files to decode them on playback in soundminer, but still have access to the mid and sides separately. (Note: I don’t recommend decoding in SM because it causes issues knowing if the file was encoded or decoded in the library. You can adjust this with an MS plugin after decoding, so there’s not a lot of benefit to keeping your files encoded (raw) in the library)

↑ Back to top

Rec Medium

Name of Recorder Used

Manufacturer & Model

Ie. Sound Devices 722T

Rec Type

Separated with commas in this order:

Recording Medium
Digital / Tape / DAT
If another medium is used (ie, wire or something obscure like that note it here)

Recording Space
Studio Recording / Field Recording

Recording Technique
DMS Decoded, AB Spaced 30cm, ect.
You can fill this however you want as long as it makes sense
This is additionally where I’d specify what type of formatting I’m using with ambisonics recordings

Ie. Digital, Studio Recording, DMS Decoded

↑ Back to top

Notes

This is an open field I use for things pertaining to the recording but wouldn’t fit in the description field. I think about this as the “I want to know more about this recording” section of the metadata. So this is a great place to note what version of UCS you’re using v8 or v8.1, things like “watch out for bird chirps” “high pass at 200hz” ect.

Keep in mind User Comments is where I’d put notes about alternate uses for the files. 

↑ Back to top

User Comments

This is where I’d put editor’s notes about the files, for example

“Oven Door Impacts could be used for Large Robot footsteps, Squeaks could be used for small rodents if sped up”

This is also where I’d put any search terms like “favorite” or “WOW!” or something like that if I wanted to find it later

This is the only field in a server setting that any user can edit, so it makes sense in a facility that this is where editors would put these types of notes.

↑ Back to top

Track Year

YYYY.MM.DD

It’s really important to organize files by year/month/day so that in a flat list, everything organizes in descending or ascending order

↑ Back to top

ISRC (Unique Code)

This is a repurposed music field I generate unique file IDs

I use the “Set Unique ID” workflow in SM workflows to generate an 8 digit hexadecimal code based on the filepath of the file including the filename.

The primary benefit is that when you pull a file into a DAW, you can name the files on the transfer, so I’ll tag the ISRC at the end of the file so when I have to back track and find the sound used in the edit, I’ll copy the number in protools and search soundminer for that exact file.

It also gives you a way to let other editors in your facility be able to find an exact file in the server without having to walk them through how to find it.

There’s a 1:4294967296 chance of having a repeat number, and this can be applied to every file in your library cleanly.

There’s little to no reason not to do it since this would be an unused field otherwise and can be done super easily

↑ Back to top

A big thanks to Kai Paquin for sharing this Metadata Style Guide!

Please share this: