John Seguin

Techy | Musician | Info Geek

Organizing your sound files: a strategy

Organizing your project
Putting together a sound library for a large game project is complicated, time consuming and (sometimes) very frustrating. To try to combat this, I have developed my own little system that seems to work for me and keep things relatively organized, so I thought I'd share it with all of you in hopes that you don't have to endure the frustration that I sometimes go through. Perhaps, however, you are working on your first game so you're not really sure what needs to be organized? Or perhaps you are simply thinking -- "what's wrong with CVS?"

The obstacles
There are a few inherent problems that come along with setting up a workspace for all of your sound files:

1) Consistent Naming is important - Obviously, if the game makes a call for dudeJumps.ogg and you have a file instead called dudeJumps2.ogg, its not going to work. Naming iterations for newer versions of files is not practical as it is far too tedious to continue to rename the file write after you copy it into the appropriate directory. I tried this when I first started out. Trust me. You don't want to!

2) Most files will be in a compressed format - Most game engines (including torque of course) work with a compressed audio format, like ogg or mp3 or even wav using certain compression schemes. In addition, the final footprint of the game may be up in the air till the last minute and re-compression may be necessary for all files. So, even though you may be putting compressed files in the game, you STILL need to a logical place to hold onto your UNCOMPRESSED AIFF or WAV files.

3) Previous version access - And of course, you need to have backups of all the versions you have sent to the developer (if its not yourself) so that at any time when they say "you know what? Last weeks one was better..." you have access to that and can immediately respond.

The solution
The solution to all of these problems involved two pieces: a handy-dandy batch converter and a logical file structure.

For the first-part, I use a converter for the Mac called "Sound Grinder". Not only is it a wonderful time saver, its also fairly cheap and easy to use. For each of my projects I work on, I create a preset in Sound Grinder and a destination directory. In this way, any new files are dropped in, processed and then put in a directory of my choosing. Options as specific as "make all sounds mono, 128 kbps ogg" can be selected and processed in seconds. It's also reasonably priced at around $40. I'm sure there are other tools out there that do similar tricks, but this one has worked VERY well for me.

The second step, as I mentioned, is in the logical file structure.


Every project is given a folder (one that is backed up nightly!):

Within that project, I usually separate it into sub-folders depending on what "kind" of sound it is, for example, for a recent project I had:


Source Directory
... and so on. When your projects start using well over 60-70 sfx/music tracks this organization comes in handy later on! The last one, "source" references source files that I've either recorded myself or have bought from some place like Since when I buy these source files they are essentially "mine", royalty-free as long as I use them in a project. Well, certain "source" purchased sounds have been used in multiple projects with various edits, recombinations or alterations made to the original source. So, keeping these in an easy-to-remember spot has proven handy.

Final Sounds Directory
Additionally, note the "finalAllSounds" directory. This is my "secret weapon". [b]All sounds, in their current "approved version" get copied here as uncompressed files.[/b] This is great, because then when I'm working on a project, and the dev says, "can we try 64kbps instead of 128kbps? I want to see if the quality is okay at that smaller size". I can then say "no problem!", and I just fire up my batch converter and send them over. Additionally, after the project is over, I can send the dev uncompressed masters for everything just in case down the road they make a GBA version of the title or something where things need to be re-encoded again.

Below that, I'll name individual folders with the actual name of the sfx, as used in-game. Sometime, I won't know what this name will be because the developer hasn't gotten there yet. Often, I'll simply suggest logical, short names that the dev might find handy and will give them these names to use. Inside these folders, I'll have the source I've used (meaning its located in this sound folder as WELL as the /source folder discussed above) and any program files, such as a Reason file or a Logic Pro file. Within here then I'll have a "bounces file" which will be a "final version" of that sound, named appropriately, within a folder giving the DATE of the bounce. For example:

.../.../.../buttonRollOver (logic file)
.../.../.../click.aif (source)
.../.../.../.../.../buttonRollOver.aif (bounced file)
So, you see in the above example, that there are quite a few directories that are involved with the production of a single file. Additionally, remember that this buttonRollOver.aif will be copied to the "finalAllSounds" directory as marked above. One final note about that "finals" directory.

Because Torque is fairly finicky (as are other engines) about what sounds are stereo and what is mono, I'll often create that breakdown as well to make it easier to batch convert. Hence:

Wrap-up and the digital studio log text file
I've found that this system works well for me -- especially since I often bounce between multiple projects at once. Just looking at the file structure then gives me an idea of what needs to be done, etc. I'll often also keep a digital log within the master file if it looks like a project is getting "shelved" for a while, to help jog my memory when I pick things back up again.