Quick navigation:
– click below to jump straight to your chosen topic:
Quick Reference • Foreword • Folder Structures • Filenames • Descriptions • Single Source SFX • Ambience SFX • Vehicle Driving SFX • Vehicle Specifics SFX • Synth SFX • Other Thoughts and Opinions on Writing Descriptions • Some Additional Considerations when Writing Descriptions • Inline Markers • Keywords • FX Name • Track Title • Manufacturer & ShortID • Manufacturer • ShortID • Library & ISWC • Library • ISWC • Mic Perspective • Location • Category & Subcategory • Recordist • Artist • Microphone • Mono • Stereo & Multi Mic Arrays • Midside • IXML Track Layout • Channel Layout • Rec Medium • Rec Type • Notes • User Comments • Track Year • ISRC (Unique Code)
Quick Reference
| Filename | Catch all field used in folder structure |
| Description | Primary field for key description of the recording |
| Keywords | Additional search terms to support description |
| Track Title | Short 1-5 word description that names the sound source and sometimes action. |
| Manufacturer | Name of Creator/Company |
| FX Name | Short Description used for Filename |
| Library | Library Name |
| Mic Perspective | Approximately how far the mic is from source and if it was indoors or outdoors in the recording |
| Location | Where the recording took place |
| Category Subcategory | UCS Categories |
| Designer | Name of Recordist |
| Microphone | Model of Microphone(s) Used |
| Rec Medium | Name of Recorder Used |
| Rec Type | Recording Technique Used |
| Notes | Additional info about the recording |
| User Comments | Additional comments for editors using |
| Track Year | YYYY.MM.DD |
| ISRC | Unique “serial number” for the file |
| ISWC | Library Abbreviation |
| Short ID | Manufacturer Abbreviation |
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)
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
Individual Recordists and Raw Files
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.
Metadata tutorial – video version:
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.
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.
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.
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
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
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
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:
- 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. - 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
- 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.
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
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
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.
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
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
| Single Source SFX | Title | Ie. Prop or Prop & Action |
| Ambiences | Setting | Ie. Park |
| Vehicle Driving SFX | Car Model & Year | Ie. Toyota Camry 2019 |
| Vehicle Specifics | Title | Ie. Prop or Prop & Action |
| Synth SFX | Title | Ie. Title Evocative to what the Content is |
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.
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
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
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”
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.
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
| Term | Meaning | Description |
| CU | Close Up | You hear almost all source and little to none of the space |
| MED | Medium Distance | You hear about equal parts source and space |
| DST | Distant | You hear more space than source |
| VARI | Various | Multiple Mic Perspectives in a Single File (specifically multitrack files) |
TABLE 2
| Term | Meaning | Description |
| INT | Interior | Recordings in an Enclosed Space |
| EXT | Exterior | Recordings in an Outdoor Space |
TABLE 3 – Single Use Terms
| Term | Meaning | Description |
| D/I | Direct In | Synths, Instrument Direct In |
| CONTACT | Contact Mic | Contact Mic recordings |
| HYDRO | Hydrophone | Hydrophone recordings |
| OB | Onboard | Recordings attached to a moving source (ie. a car) |
| EMF | EMF | Recordings using Electro-Magnetic Fields & Induction |
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.
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.
Location should also be written in a short form of the description (follow link for more info). This allows you to quickly assess on an ambience critical location information without having to trail through a long description.
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.
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.
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
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)
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)
| L | Left |
| R | Right |
| C | Center |
| Ls | Left Surround |
| Rs | Right Surround |
| M | Mid |
| S | Side |
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
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.
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.
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
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
A big thanks to Kai Paquin for sharing this Metadata Style Guide!