Metadata For SFX Libraries
WHAT IS METADATA & WHY SHOULD I USE IT?
Metadata For Sound Effects Libraries are fields of text attached to the file that can be read by various applications such as Sound Miner, Basshead, Soundly, Sound Q, and other Digital Audio workstations or Video Editing Workstations. The simplest form of metadata is the file name, but files can hold many other fields that are useful for sound editors to have when managing hundreds of thousands and some times millions of files.
Whether you are an independent Sound Effects Editor creating personal libraries for your work, a recordist cataloging nature recordings of different environments, or a sound designer trying to market your creations, metadata will help you. Metadata apps like Sound Miner will allow you to search your database using not only the file name but various other metadata fields like microphone, microphone perspective, description of the sounds, location, rating, artwork, etc. Having good metadata in your libraries will lessen the time needed to find the sounds you are looking for and increase the accuracy in finding the types of sounds you are looking for. If you are selling your sound effects, having detailed and accurate metadata is essential.

NOTES BEFORE WE GET INTO IT
There are lots of ways to use these fields when tagging your libraries, this list is how I like to format metadata currently. There are certain fields that I will be talking about that promote creativity, there are industry standard fields and formatting requirements that should be followed, and some listed might not be useful for the sound effects library you are creating.
This guide is written using Sound Miner V5/V6 Pro as a standard so you may not have access to all of these fields when working in other metadata applications like Soundly, Basehead, Sound Q, etc.
If you are using Sound Miner and you don’t see the fields referenced below you might want to create a new database for “Music & FX”. When I’m building out a new library I import my sounds into a separate database called “Library Creator” with all fields editable and ready to edit.
I’d like to thank Kai Paquin for putting together a wonderful document on Metadata Style Guide, please check out that document here.
I’d also like to thank Tim Nielsen for his courses on Sound Miner & Radium, you can check them out here along with his sound effects libraries.
I’d also like to thank Andy Martin for showing me the power of the Open Tier field.
Now that we’ve gotten all that out of the way, let’s go through all of the metadata fields you have access to, and what they are used for.
Artwork
It can be very useful to embed the library artwork into all of your files. Some users will use the artwork panel when browsing sounds, looking for variations, or looking for similar sounds that they’ve found from a previous search. I tend to rely on the artwork panel to recall memories of sounds that I’ve heard in particular libraries.

AUTO GENERATED TRACK INFORMATION
This is not a complete list as I organized some other autogenerated fields differently but these are noneditable fields that just provide information to the end user.
Duration: This is an auto-generated field that tells the user how long the file is. This field is super useful when trying to find longer ambiance files by sorting them by the longest first.
Total Frames: This field is auto-generated and lets the user know how many total frames the sound takes up.
Sample Rate: This is an auto-generated field that tells the user the sample rate of the file (192khz, 96khz, 48khz, etc).
Bit Depth: This is an auto-generated field that tells the user the bit depth of the file (16 / 24 / 32, etc).
Channels: This is an auto-generated field that tells the user how many channels are included within the file. Stereo Recordings would have 2, 5.1 Recordings would have 6, etc.
Audio File Type: This is an auto-generated field that lets the user know what type of file they are dealing with, wav, aiff, SDII, flac, etc.
UCS (Universal Category System)
The (UCS) Universal Category System is not an embeddable field but rather a system that attempts to standardize the categorization of sound effects for various media such as Television, Film Production, and Video Games.
UCS offers an optional file name structure that various programs can use to automate portions of the metadata embedding process. It is highly recommended that you follow the UCS standards if you are producing sound effects libraries as there are lots of database managers like Sound Miner that have very powerful search features that make it easy to find categories of sounds.
The UCS system takes over a couple of fields including the Filename (Sorta), Category, Category Full, Sub Category, CatID, and Cat Short.
You can access the current UCS system here: https://universalcategorysystem.com/
CatID
The CatID defines the Category and Subcategories of a sound in a single short blurb with the Category in ALL CAPS and the Sub Category using Title Case.
A few examples of this would be AIRBlow (AIR Blow), GUNSCano (GUNS Cannon), RUBRCrsh (RUBBER Crash & Debris), OBJHsehld (OBJECTS Household).
It is important to note, that some sounds can be hard to categorize as some sounds do fit multiple CatIDs. This is a good thing, as it gives you the freedom to use the CatID that best fits the overall theme of the sound effects library you are building.
Category
The Category is the top level category for the sound of which there are currently 82, for example, Alarms, Food & Drink, Geothermal, Voices, & Wings. While the UCS spreadsheet dose get updated from time to time (Currently on 8.2 at the time of this blog post), these categories do a fantastic job at breaking down every type of sound that can exist.
Sub Category
The Sub-Category splits the top-level category into a series of smaller more specific sub-categories. Taking our Alarm Category example from earlier, you can have Bells, Buzzers, Clocks, Electronics, Misc, and Sirens. If you do find that some of the sub-categories don’t exactly fit the very specific niche your sound is, that is okay, pick the closest one that fits your sound as we can use other fields like Vendor Category or User Category to further organize the sound.
Category Full
The Category Full is both the Category and Sub Category spelled our fully in a single field.
So for an alarm your CatID would be ALRMBell, your Category would be ALARMS, your Sub Category would be BELL, and your Category Full would be ALARM BELL.
FX Name
The FX Name is a short name that you give to your effect that is usually derived from the Description. Don’t worry about writing a short novel about all the nuances of the sound you recorded as we do utilize other fields like the Description, Notes, User Category, Vendor Categories, etc to provide more specific information about your sounds.
The FX Name is often confused with the Track Title and Description which often leads to people putting the exact same information in all 3 which is not helpful. The Description is the actual description of the sound and provides lots of information about the sound. The FX Name is a short description of the sound only providing the essential information about the sound. The Track Title is the shortest description possible sometimes only 1-5 words.
GOOD EXAMPLE:
FXName Example: Hotel Late Night Lobby Very Quiet Mostly Air Rumble
Track Title Example: HOTEL LOBBY
Description Example: HOTEL LOBBY – Distant Pov Hotel Lobby From Upstairs Landing, Late Night Quiet, Sparse Voices And Activity, Distant Metal Doors. Mostly Heavy Room Tone, Hvac Air Rumble And Hum
POOR EXAMPLE:
FX Name Example: City Hall Large Quiet Crowd
Track Title Example: CITY HALL LARGE QUIET CROWD
Description Example: City Hall Large Quiet Crowd, Doors Bangs.
When building out your metadata, you are not trying to cram all the information about the sound into every field, instead, you are trying to provide specific information for specific fields so we can automatically generate other fields like file names using workflows.

File Name
We use multiple fields to generate the file names which get separated by underscores or dashes. There are several combinations of fields you can use, but we do recommend at least following the UCS Standards by including the CatID at the start of the file and the FXName.
Official UCS Standard Basic: CatID_FXName_CreatorID_SourceID
Official UCS Standard Advanced: CatID-UserCategory_VendorCategory-FXName_CreatorID_SourceID_Userdata
You can however break away from this standard and use your own organization as long as the CatID comes first. For example, in our Master Gun library, we use the following file name structure.
Other Examples 1: CatID-VendorCategory_FXName_Notes_MicPerspective
We use the Vendor Category to communicate the type of gun (LMG, SMG, Shotgun, etc) and whether the asset is an unprocessed recording (RAW) or if the asset is a Designed asset (DS). We use the Notes field to communicate the caliber of the gun and then we use the microphone perspective to communicate what microphone perspective we are using (AB, MS, ORTF, etc).
As you develop more and more libraries you may find that you want to organize ambient libraries differently from how you want to organize vehicle libraries, or you might want to organize your Foley libraries differently than your weapon libraries. As long as you are using the UCS tags and following good FX Name practices you can add any form of additional flavoring you would like to the file name (within reason).
User Category
The User Category is a definable third category for you to use as you see fit. If you find that the USC system is not granular enough for your library, you can add an additional 3rd layer of organization, for example, in our Master Gun collection, the UCS System does a fantastic job at organizing the types of guns but does not allows us to sort the guns by their names or specific weapon type, so in the user category field, we added the name of the gun.
Vendor Category
The Vendor Category is very similar to the User Category which allows you to expand on the USC system and develop your own style of organization. For example, in our Master Gun Collection, we use the Vendor category field to explain the weapon type (SMG, LMG, HMG, MG, Shotgun, Pistol, Sniper Rifle, Rifle, Anti Tank, etc) and whether the asset is designed or not (RAW or DS).
Track Title
The Track Title is often confused with FX Name or Description which leads to some libraries having the same information in all three categories which is not as helpful to end users.
The Track Title is supposed to be a super short description of the FX Name only 1-5 words and should be all UPPERCASE.
FXName Example: EXT Driving Approach Stop Off 01 Crawl A Tracking
Track Title Example: DRIVING CRAWL
The idea behind the Track Title is to provide a very brief description of the sound that will prepend the description. When working with programs like Sound Miner, it is not common to have all of these fields open to view when browsing sounds, but it is common to have the description field open when searching for sounds. Having the Track Title at the start of the description and in all UPPERCASE is extremely helpful to briefly glance at the description and instantly know what the sound is without having the read the entire description.
Example 1: WEAPON PICKUP – Lightly Throwing The Weapon In The Air And Catching It.
Example 2: LIBRARY – Very Quiet Ambience Paper Movement Typing Science Reading Room British Library
If the track title and description are redundant or identical, you end up with the same information twice, which makes things either look cluttered or can make your sounds harder to find.
Description
The Description is where you can provide a lot more information about what was recorded when compared to the FX Name. A good description should give you a quick summary of the sound, give you several searchable terms, and give you a more detailed understanding of the recording than the FXName or Track Title.
Some rules to follow when writing descriptions:
- Keep the pertinent descriptive information in the description column. Having loads of information in the File Name, Track Title, or FX Name can be quite messy when browsing tens of thousands of sounds.
- Organize the description with the primary content and actions first.
- Format the description to Title Case to make the description easier to read.
- Include the Track Title at the start of your description and make sure it is UPPERCASE.
Goldylocks Description: Finding the right balance on how much information to include in your description can sometimes be a difficult task. Too little information might not provide enough information to give you a full understanding of what the recording is. Too much information might be overwhelming and filled with unnecessary information. A good middle ground is to organize your thoughts into short descriptive phrases and separate them by commas.
Kai gives great examples on writing perfect descriptions for a in their article here, and I highly recommend checking out their article.
Kai’s Too Short Example: Baseball Catch
Kai’s Too Long Example: Catching A Standard-Sized Baseball In A Leather Glove Being Thrown At 40mph. Fastball Hits Glove And Creates A Loud Thwacking Impact On Leather
Kai’s Just Right Example: BASEBALL CATCH – Fastball Caught by Leather Mitt, Glove, Twack, Hit, Impact
You can see that in Kai’s example, they omitted 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.
Inline Markers
To help keep the description from becoming too cluttered with random one-off sounds that are not defining characteristics of the sound that is being recorded we use inline markers which are small markers that we can place on the waveform itself to highlight these moments. Inline markers are an extremely helpful tool for editors to quickly identify one-off moments like distant sirens, dog barks, door closes, or even the last shot of a weapon.
Small singular moments might not be useful to include in the description of the sound as you might find yourself listing off every sound that you hear instead of giving a general overview of what is in the recording. For instance, if you recorded an ambiance of a still forest and a single bird chirps at 3 min in the file, it is not worth including the term “birds” in the description as the majority of the file does not include birds. Instead, we can use Inline Markers to indicate the single events that happen within the sound.
Some sounds might also be difficult to visually see in a waveform as they can be quiet in comparison to the other sounds around it, so using Inline Markers can help identify sounds that are not so visually obvious. 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.


Open Tier
Open Tier is one of the most powerful fields to organize your libraries that often gets overlooked. You can use this field to organize your libraries across your other libraries and create a custom yet powerful folder system.
For this field to work correctly, you can’t use underscores (_) you have to separate the fields using dashes (-)
Open Tier Example 1: Category-SubCategory-VendorCategory-UserCategory
Open Tier Example 2: CategoryFull-VendorCategory-UserCategory
Open Tier Example 3: Library-SubCategory-VendorCategory-Notes-UserCategory
We organized our Master Gun collection using example 3 which allows the user to select “Master Gun” and then the user can select the types of samples they would like (Automatic, Handle, Mechanism, Semi-Automatic, or Suppressed). From there we allow the choice of Designed Or Raw organized by weapon type, then caliber, and then finally the gun name. We decided to use Open Tier so users can quickly a weapon class and find all weapons that utilize the same caliber within that weapon class.
Using a system like this allows for very quick navigation of a larger library or from a larger collection of sounds.
Colors
Using colors is a unique way to organize your libraries to quickly find a broad type of sounds, and it is really up to you how you choose to utilize this field.
As an example we use color field to tag each category of weapons in our Master Gun collection, we use Orange for our LMGs, Yellow for our Pistols, Green for our Rifles, Red for our Shotguns, Blue for our SMGs, and Purple for our Sniper Rifles. As we add more weapon types to the collection, we will add more colors.
LIBRARY & ISWC FIELDS
Library: The Library Field is where you can enter the full name of the library or collection these assets belong to. For our Master Gun Library, we don’t individually list each gun library here as a separate library, we instead just list Master Gun as the individual libraries are just fragments of the bigger vault collection.
ISWC: The ISWC is where you can put an abbreviation for the name of your library. For example, the Master Gun Armoury Bundle would be MGAB.

Keywords
Keywords is a fantastic field to utilize Synonyms or alternate words that may be used to describe and search for your sounds.
For example, if you recorded the sound of searing a steak, you can use keywords like sizzle, cauterize, seer, brand, and searing. As we don’t know how these sounds will be used by the end user, including multiple descriptors will make your sounds easier to find in a wider range of situations
Another example would be if you recorded an oven door, we could use that recording in a large range of sound design situations, some keywords could include Robot Footstep, Armour, Thud, Hit, Close, Shut, Open, and Clank.
The idea behind keywords is to prevent your descriptions from getting too wordy, helps keep the description from being redundant, and make the description easier to read.
MICROPHONE & MICROPHONE PERSPECTIVE FIELDS
Microphone: The Microphone field is where you can place information about what microphone or microphones were used to capture the sound. If you are using multiple microphones in a multi-track format you can list all the microphones used separated by a vertical line (|). The Microphones should be listed as Manufacturer and then model. If you are using multiple microphones that are from the same manufacturer you don’t need to list the manufacturer multiple times.
Example Of 3 Microphones From Two Different Brands: Neumann RSM191 | Sennheiser 50 | 30
Example Of 3 Microphones From The Same Brand: DPA 4060 | 4061 | 4062
Microphone Perspective: The Microphone Perspective can provide some very valuable information on the distance that the microphone was placed in relation to the source as well as if the sound was recorded indoors (INT) or outside (EXT). These fields are usually abbreviated and separated by a vertical line (|).
Examples:
CU | EXT (Close-Up Exterior)
Vari | EXT (Variable Distant Exterior)
MED | INT (Medium Interior)
DST | EXT (Distant Exterior)
OB (Onboard)
D/I (Direct In)
CONTACT (Contact Mic)
HYDRO (Hydrophone)
EMF (EMF)
AMB (Ambience)
OS (Off Stage)


REC MEDIUM & REC TYPE FIELDS
Rec Medium: The Rec Medium is a place for you to include what recorder or interface was used to capture the sounds.
Examples:
Sound Devices 744T
Zoom F6
Sony PCM D100
Zoom F3
Rec Type: The Record Type tells the users what recording technique that was used. These can be written out in long form but should be abbreviated.
Examples:
Mono
Multi-Mic
A/B (Spaced Pair)
MS (Mid-Side)
DMS (Double Mid-Side)
XY (Coincident/Near-Coincident Pair)
ORTF (Office de Radiodiffusion Télévision Française)
ORTF 3D
VR (Virtual Reality)
DATE & TIME FIELDS
Track Year: The Track Year is the date when the track was recorded and is presented as follows YYYY.MM.DD. It is really important to organize files by Year/Month/Day so that in a flat list, everything is organized in descending or ascending order.
Era: The Era could be one of two things, the era could be what era the sounds were recorded in if the object being recorded is not time period specific, or it could be used to identify the era of manufacture like on vehicles or weapons.
Release Date: This is where you can put the information on when the library was released. You should also follow Year/Month/Day.
Shoot Date: This is where you can put the information on when the files were recorded. You should also follow Year/Month/Day.
BW Date: Auto Generated
BW Time: Auto Generated
BW Time Stamp: Auto Generated
Entry Date: Auto Generated
Creation Date: Auto Generated
Modification Date: Auto Generated
Scanned Date: Auto Generated
Touched Date: Auto Generated
LOCATION FIELDS
Location: The location field should be sorted by Continent, Country, Province, Region, and Specific Location. Some projects we work on require specific sounds from specific regions, ambiances would be a big one, and organizing your sounds like this can make finding location-specific sounds or ambiances across multiple libraries very easy. This field could also be where the sounds were recorded or it could be where the object was manufactured, our AK-47 library for example was recorded in Las Vegas but is manufactured in Russia.
Example: Europe, UK, England, London, Croydon.
Organizing your locations with comma-separated values, allows you to browse locations using Sound Miner’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.
GPS Alt/Lat/Lon: Contrary to the general location field, if you are really hardcore in your metadata tagging you can use these fields to put your latitude, longitude, and altitude of where these sounds were recorded. These can be very helpful fields when you are trying to accurately recreate ambiances from specific locations. If you are importing sounds that have been recorded on a device that tracks location data like a cell phone, these fields may already be filled out for you.

CREDIT FIELDS
Below is the list of credit fields that you can use to give credit to individuals who may have contributed to the creation of the library or sounds.
Generally speaking, if I’m the only person working on the library I usually just put my company name and then my name for most of the below fields.
Company Specific Fields:
Manufacturer: This field is used to give credit to the manufacturer of the library. This is usually a company name.
Source: This field is used to give credit to where the sound came from through the use of a URL or company name.
Publisher: This field is used to give credit to the publisher of the library. This is usually a company name or a URL.
URL: The URL is where you can put a link to your website, portfolio, or sound effects store. This is a helpful field to include as you never know who will view these files and want to know where they can get more, or reach out to to you for more information about the files or potential job offers.
Recordist/Artist Specific Fields:
Recordist: This field is used to give credit to the recordist of the sound. If you have multiple recordists involved you can list them all here.
Designer: This field is used to give credit to the designer of the assets.
Performer: This field is usually occupied by music, but you can also use this field to give credit to the performer of the sounds. If you are doing a vehicle library this would be the driver of the car, or if you are doing a fire library this would be the person waving the sticks of fire around.
Music Specific Fields:
Artist: The artist credit is usually filed out when it comes to music samples, but you can also use your company name as the artist for this field.
Arranger: The Arranger field is usually filled out when it comes to music, but you can also use this field to give credit to people who helped arrange recording sessions.
Conductor: The Conductor is used to give credit to the conductor of your musical recording.
Composer: The Composer is used to give credit to the composer of your musical recording.
Notes
This is where you can put any notes about the sound that you would like the end user to know, or you can even use this file to remind yourself of what work still needs to be done on the files while the library is still in production. We use this field internally to remind us that the file might have an unwanted artifact that needs to be removed like a shell drop, and when the library gets released we populate this field with additional information that the user might want to know about the sounds.

ixml Track Layout
Another often overlooked field but a very powerful field is the ixml Track Layout, which allows you to communicate what microphone was used on what track in a multi-track file.
For example, in the 8-channel files we include in our vehicle libraries we have the Mix Left and Mix Right occupying channels 1 and 2, channels 3 and 4 are the Engine Left and Right, channel 5 is the Air Intake, channel 6 is the Exhaust, and channels 7 and 8 are the wheels. (This layout dose change based on the vehicle that is being recorded so it is always helpful to make sure the end user knows which microphone option is on which channel).
This is very helpful if the user only needs to extract one or multiple channels from the file without having to import the entire file into their DAW, and also helps keep the file count down in the library.
Channel Layout
The Channel Layout field does something similar to the ixml Track Layout, except only the abbreviations below can be used. The advantage to Channel Layout over IMXL Track Layout is that if you order files L/R/C/Ls/Rs you can reorder the files in Sound Miner for playback on a surround system.
L – Left
R – Right
C – Center
Ls – Left Surround
Rs – Right Surround
M – Mid
S – Side
BW Description

ISRC
The ISRC (International Standard Recording Code) is the international identification system for sound recordings and music video recordings. Each ISRC is a unique and permanent identifier for a specific recording, independent of the format in which it appears (CD, audio file, etc.) or the rights holders involved.
These can be auto-generated in Sound Miner using the workflow “Set Unique ID” set the 1st field to Append and the 2nd field to ISRC.
The primary benefit is that it 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.
BW Originator
This field is usually automatically generated when exporting your sound from your DAW or other programs. This filed is usually the last program that the sound was exported from which could be iZotope RX, Nuendo, ProTools, Reaper, etc.
LONG ID & SHORT ID
The Long ID is where you can put the name of the manufacturer in my case it is Aftertouch Audio, and the Short ID is where you can add the manufacturer 4 letter Abbreviation, in my case it would be ATAU.
Featured Instrument
While this field is usually utilized by what musical instrument is being recorded, it can also be used to name the object or thing that is being recorded. In our Master Gun library, we list the gun’s name and in our vehicle libraries, we list the name of the car.
Mood
This is a fun field you can use to describe the mood of the recording. Whether the recording is music, tonal, or a gory mess, you can use a mood descriptor to find similar sounds with a similar mood or vibe.
Version
As you release updates for your library, it is a good idea to update the version number so your users know which version of the library they have, and if they need to re-download the library to get the newest version of the library.
Volume
If you are producing a series of libraries like Water Movements and you are releasing them in volumes (Waver Movements Vol: 1, Water Movements Vol: 2, etc). You can enter your volume numbers here.
CD SPECIFIC FIELDS
Sometimes you are delivered a sound effects library on CDs. We use the CD Description, CD Titles, & Index fields to name the CD and Describe the content of the CD.
FILE PATH & PATHNAME
File Path: File Path is an auto-generated field that lets the user know where the file is being stored.
Path Name: File Path is an auto-generated field that lets the user know where the file is being stored. The difference between these fields is that the File Path will include the full file name where as the Path Name will only include the path of the file, I personally find the Path Name easier to read.
Because these fields are embedded into the file when you import the files into your database manager if the files are moved you will need to relink the files again.

POPULARITY & RATING
Popularity: Popularity is an auto-generated field that gets updated every time you import the sound into your DAW. That way you can go back and see what are your most used sounds. You can also reset these values.
Rating: Unlike popularity, this is usually entered manually by the end users and they can provide there own ratings for sounds that they like. By default all sounds will start at a 0 rating.
MUSIC SPECIFIC FIELDS
Tempo & BPM Fields: This field is typically used in musical packs to let users know what tempo the loop was recorded at so they can find similar BPM for their songs or they will know how far they need to warp the sound to make the sound in time with their song.
Key: If your sound or song uses a key signature, it is a good idea to list the key here. Music files or files like ringtones or drones benefit from having their key listed.
Lyrics: If your song has lyrics this is where you can embed your lyrics.
Track: Similar to how albums have track order, this field is used to let users know now only how many files there should be in your library but also in which order those sounds should be in. It is a useful field if a user is missing a file from a library they can quickly figure out which sound they are missing.
Examples:
1/91
2/91
3/91
4/91
etc.
Usage
The usage field is a unique field where you can input how your sounds should be used or what type of license the sounds are under.
Single User Licence Agreement
Multi-User Licence Agreement
All sounds are copyright (Company Name Here) – All Rights Reserved.
Etc.
User Comments
This field is usually left empty for the end user to make any comments they would like about the sound.
SHOW SPECIFIC FIELDS (IXML)
The iXML specification is designed to provide an unambiguous communication of file and project-based metadata between various stages of workflow in production, telecine, picture editorial, and audio post-production. iXML is primarily designed to be used as a RIFF (embedded tagged data) chunk inside a Broadcast Wave file (although it can be optionally included in other file types), to supersede the metadata currently written in the standard Broadcast Wave ‘bext’ chunk description field in a non-standardized way by several manufacturers. iXML is intended to offer a standardized specification to communicate all information currently in use, to provide an extensible framework for manufacturers to add new private, or public data, and for the specification to expand in a completely forward and backwards-compatible manner.
Show: If you recorded sounds specifically for a show it can be a good idea to tag the show’s name into the file. Shows often get sequels and it can be useful to search for the name of the show and have all of the sounds that you recorded for the show come up. Similarly, if you are working on a show that is similar to a show you’ve worked on in the past it can also be good to be able to search the name of the other show to pull effects, ambiance, or designed assets from.
Show Category: The Show Category can be what is the genre of the show you are working on, Documentary, Horror, SciFi, etc.
Show Sub Category: The Shows Sub Category is another field you can use to expand upon the shows category. Documentary (Nature), Documentary (History), Horror (Slasher) Horror (psychological), etc.
Scene: The name of the scene/slate being recorded. For the US system, this might typically be 32, 32A, 32B, A32B, 32AB etc. For the UK system, this might typically be an incrementing number with no letters.
Take: The number of the take in the current scene or slate. Usually, this will be a simple number, although variations for things like wild tracks may yield takes like 1, 2, 3, WT1, WT2, etc.
Tape: The SoundRoll which identifies a group of recordings. Normally, the SoundRoll is a vital component of workflow to differentiate audio recorded with time of day on different days. In other words for 2 (completely different) recordings each covering a period around 11 am, the soundroll would differentiate them by (typically) telling you which shooting day this recording applies to. Some projects may turnover sound more than once per day and increment the sound at this point. In any event, the soundroll should change at least once in any 24 hour period. Some systems change the soundroll for every recording which is also a valid option, in effect using the sound roll as a unique file identifier (although this function is explicitly provided with the iXML FILE_UID parameter).
ixml Master Speed: The MASTER_SPEED parameter would typically be X/Y, eg 24/1, 25/1, 30000/1001 (NTSC) – this determines the DEFAULT speed of the project, or the speed at which the material will be replayed.
ixml Current Speed: The CURRENT_SPEED parameter identifies the speed of this recording which is different to the MASTER_SPEED. So in the slow motion example, MASTER_SPEED would be 24/1, and CURRENT_SPEED would be 48/1. We use a ratio in each in order to easily accommodate accurate representations of NTSC and HD frame rates. The NOTE parameter allows the user to explain any details about the change.
ixml File UID: A unique number which identifies this physical FILE, regardless of the number of channels etc. If your system employs a unique SoundRoll per recording, your FILE_UID and TAPE parameters should be the same.
ixml Note: A free text note to add user metadata to the recording. This might typically used to communicate information such as TAIL SLATE, NO SLATE, or to warn of noise interruptions – PLANE OVERHEAD etc.
ixml Original File Name: The ORIGINAL_FILENAME allows a permanent record of the name given to this file when it was created. If the file is subsequently renamed by the user, this may cause problems in the workflow. Using the ORIGINAL_FILENAME metadata would allows systems to track back to the original given name.
ixml Parent File Name: PARENT_FILENAME is equivalent to Avid’s TAPEID parameter.Multiple mono second generation files may be associated with one another using a common PARENT_UID. Alternatively they could also be associated using a common FAMILY_UID given to the set of files when a polyphonic file was split.
ixml Parent UID: The PARENT_FILENAME and PARENT_UID allow identification of the source of a derived file.
ixml Speed Note: The NOTE parameter allows the user to explain any details about the change.
ixml Time Code Flag: The TIMECODE_FLAG parameter can be NDF or DF for non drop or drop timecode (defaults to non-drop).
ixml Time Code Rate: The TIMECODE_RATE tag should be included and set to 24/1, 25/1, 30000/1001, 24000/1001, 30/1 etc as appropriate
ixml Project: The name of the project to which this file belongs. This might typically be the name of the motion picture or program which is in production.
ixml Track Layout: We covered this field earlier in the list as it was a big one to cover.
If you would like to know more about ixml formats, please visit the ixml site and melt your mind with numbers and jibberjabber (http://www.gallery.co.uk/ixml/).