# Naming convention...



## rhd1607 (Nov 20, 2019)

Hey guys,

Wanted to bring up a topic I seem to be struggling with. I know, it's kind of dumb but could use some insight from you fine composers. 

How are you guys naming your compositions? I'm trying to figure out the best way to name 30 second/60 second songs for work/reels. Right now I'm all over the place with how I name them and I seem to be losing a lot of time looking for the right songs. 

Again, stupid topic but can use some insight for organizational purposes. Thanks a bunch!!!


----------



## Snarf (Nov 20, 2019)

Do you mean names for personal organization or also for other people to see?


----------



## Fredeke (Nov 24, 2019)

I number projects sequentially and keep a draft render of every project along it, which I can quickly play (just press space on a mac for preview) to remember what the project is.

As I approach a hundred, I realize maybe I should have used starting dates instead of sequential numbers. But anyway.

My folder structure is this:
"FSC0001"
"FSC0002"
"FSC0003"
etc.
And inside folder "0001" you have:
"takes" (folder containing wavs)
"FSC0001.txt" (text file containing anything I want to write down about this project)
"FSC0001.mp3" (short render - doesn't need to be up-to-date)
"FSC0001 v001.RPP" (Reaper project file)
"FSC0001 v002.RPP"
"FSC0001 v003 (drums trigged).RPP" (indicates that from now on, drums are triggered)
"FSC0001 v004.RPP"
etc.

Alternatively, I could just store the renders all together, outside the project folders, so I wouldn't have to enter folder after folder just to look for a song.

'FSC' is just me, Fred Scalliet. If you're making different kinds of job, like, say, orchestral soundtracks and experimental albums, you could use different prefixes, like SNDT and XPR, each starting counting from 0001. Just a thought.

Sometimes I have more folders along "takes": a folder for presets (which sometimes are photos from unautomatable hardware's panels), for example.

You get the idea.

I settled for this scheme because I would want the change a song's name several times between start and finish 
It's still not the best but it's better than the kind of mess you're describing. I've been there too.


----------



## charlieclouser (Nov 24, 2019)

I use pretty verbose names to avoid confusion, but I'm only doing scores for tv series and features, not production music or any other purposes. Still, in 15 years I've done around 10,000 cues but I can still find things pretty quickly. Some of this might apply to your situation. Although I don't completely obey all of my own rules all the time, the ideal way I format the names is:

*[project group][project number][season number][episode number]*

- hyphen -

*[act/reel number][m for score cues, s for source cues, etc.][cue number from cue sheet][version number of performance]*

- hyphen -

*[unique cue title]*

- hyphen -

*[length modifier]*

- hyphen -

*[stem or mix type]*

- hyphen -

*[version number of mix]*

- hyphen -

*[mastered/unmastered descriptor]*

So that results in file names like:

*Ns312-2m12v2-Code Book-030-MIX-v3-oz3*

or

*Saw7-4m36v1-Needle Pit-full-DRM-v2-unm*

In these examples:

- In the *[project group][project number][season number][episode number]* fields, *Ns312 *decodes as the tv series Numb3rs season 3 episode 12, and *Saw7* decodes as the seventh film in the Saw franchise. I use a two or three letter abbreviation to denote the global title of that project, and the digits following to denote the season, episode number, etc. If there is an already-agreed-upon nomenclature for this that the production company or post production team is already using, I'll make mine the same as theirs if possible. So that's already a lot of info in five characters or so, and the resulting files will sort in a meaningful order if they're all dumped into a single folder.

- In the *[act/reel number][m for score cues, s for source cues. etc.][cue number from cue sheet][version number of performance]* fields. *2m12v2* decodes as the 12th cue in the episode, which happens in act two, and it's the second version of the underlying performance - meaning some changes were made to the music contained within but not necessarily to the mix itself (which gets its own, separate version numbering elsewhere in the file names). The *4m36v1* decodes as the 36th cue in the film, which happens in reel four, and it's the first version of the underlying performance. For films, the cues are grouped by *reel*, while on tv series they're grouped by *acts* (acts are typically divided at the commercial breaks). Some folks like to start the cue numbers over again at each act / reel break, meaning that if the last cue in act 1 is 1m07, the first cue in act 2 would be 2m01. I hate this as things get messy. So I number the cues continuously from the start of the film, meaning that after 1m07 would come 2m08. The final two characters represent the version number of the music contained within; if I made changes to the mix but not to the music, this number would not change - only the mix version number later in the name would change. This helps to sort the various mix versions of a single music version from the more major changes made to the music contained in them.

- In the *[unique cue title]* field in the above examples, *Code Book* and *Needle Pit* are the actual titles of the compositions. This is what will appear on the BMI repertoire, all cue sheets, etc. This is "the name of the song" and will never change once the piece has been started. My music editor uses a database format when making spotting notes to insure that this field has a unique value. Some music editors use a spreadsheet or dedicated spotting notes program to generate spotting notes from the rough notes taken during the spotting sessions, but my guy has always used a database instead - this means that his database contains the records for ALL of the projects we've done together in a single file, and allows this field to be set to "force unique values" so that the program will check all other shows / films we've done to see if we've used that title before, and will reject any attempts to do so. I learned this on my first tv series, where ever episode would have a cue titled "Car Chase" or something generic like that. Having unique cue titles is, for me, absolutely and completely mandatory. It's not too hard to do - we'd usually grab the cue title from a phrase of dialog or a place name that relates to the scene in question, so we'd have titles like "Stygian Street" or "Wrong Baptism" or "Fake Chinese" - things that only made sense in one context and immediately called to mind the scene in question. I try to keep these titles short, ideally no more than two words, so that I don't wind up with titles like, "Second Avenue Bank Robbery Car Chase Shootout" or something. Having very unique, idiosyncratic names make things easier when making reels or collections that include cues from a bunch of different projects - I can have a collection called "Action Cues" that has cues named "Bear Trap", "Charm Boys", and "Dock Heist" and both me and my agents will probably remember what project they were from because the names are so descriptive - and I'll never again have a cue called something generic like "Car Chase". Down the road, when my agents are making reels or I'm making compilations, I'll extract the mixes I want to use and then rename them with names like "Numb3rs - Dock Heist" or "Saw7 - Bear Trap" and these names are just the project name and cue title minus all the stuff relating to which mix, which reel, etc. - but they still make sense and searching by their title will locate all of the original files.

- In the *[length modifier]* field, the *030* and *full* denote any cut-downs or changes made to the length of the cue. So a five-second cut-down would have 005 here, a ten-second would have 010, etc., and full denotes the un-cut-down version with whatever length it had to match picture. I use three digits with leading zeroes to accommodate lengths like 1:30, which would be written as 130, and the leading zeroes keeps everything sorting nice and tidy in lists.

- In the *[stem or mix type]* field I denote whether the file is a complete mix or a stem. Depending on how many stems you have you may need to use longer or shorter terms here. On my early projects I just named my stems DRMS / KEYS / ORKS / MIX, but as my stem count went up I started using a lower-case letter or a number before the stem name to keep things sorting in the same order they should appear on the faders on the console or ProTools mix sessions. So that results in names like aDRMS / bPERC / cKEYS and zMIX or something like that.

- In the *[version number of mix]* field I'll apply version numbering to describe which mix of the underlying musical material that file represents. This lets me accurately sort and group various versions of the composition separately from the various versions of mixes of that material.

- In the *[mastered/unmastered descriptor] *field I'll use a three-letter code to indicate what device I used to master or compress the files, and hopefully some info about the settings. So, *oz3* would indicate to me that I used iZotope Ozone for about 3db of peak limiting. I might also have a set of files with oz6 or oz9 or even more, and back when I used MasterX5 to do stem limiting I abbreviated those files with a prefix of "mx". In this case, *unm* denotes "unmastered".

Note that I use hyphens instead of underscore characters to separate the terms within the names, and I freely use spaces within the cue title fields. On MacOS, spaces and hyphens within file names are not a problem, but Windows users seem to avoid using them for some OS-related reason. Use at your own risk!

Since all of my files are formatted this way, I can easily do a search for a unique cue title (if I can remember it!) or do searches for "Ns3" which would return all cues from season three of the series Numb3rs, etc., and when making collections or reels, the files will sort in a meaningful manner when a lot of them get dumped into a folder together.

- edit to add - For the files inside the DAW, I'd name the Logic Project "*Ns312-2m12v2-Code Book" *minus all the other faff. For versions of the music, I'll usually just create a whole duplicate of the Logic Project folder so that I can destructively mess with the audio - disc space be damned! For the corresponding Ableton Live Project (if there is one) I give it the exact same name, and it goes inside its own sub-folder inside the Logic Project folder so that it doesn't get lost. Since the Logic Project has a suffix (which may or may not be visible depending on OS settings) the Logic Project file and the Ableton sub-folder can coexist inside the Logic Project folder without conflicting. For all of the audio files that the Logic Project uses (like raw audio recordings, not mixes or printed stems) I use only the front half of the name, so they'll have names like "*Ns312-2m12v2-Guitar Raw-1*" or "*Ns312-2m12v2-Waterphone-2 normalized*" etc. Also I never store the bounced stems or mixes inside the individual Logic Project files; they go up one folder inside the per-episode or per-film folder, in their own set of sub folders called *Ns312-Bounced Stems *or *Ns312-Stereo Mixes* etc.


----------



## rhd1607 (Nov 27, 2019)

Sorry guys. Was away from the forum but wow, thank you so much for the insight. This is very helpful and it reminds me how much one can learn from this board. You guys seriously rock!

Happy Holidays!!!


----------

