Audio

From 2009 48 Hour Film Project

Jump to: navigation, search

Most important thing at this moment is finding a local sound editor. We don't have one. We need one badly. Althea is covering early voice recording, Thomas is going to be doing sound effects when he's not occupied with the opera, and Derek will be kicking out a score like a mad man. However, we need someone in Richmond to help coordinate this group and produce the final edited mix. We'd prefer to work with someone who know Ardour, but at this point we'll take what we can get. Recommendations welcome.


Of course, there are other issues. For instance, what form of version control system do we want to use for audio. We definitely cannot use the same subversion tree for both audio and animation. The prospect of using a distributed RCS like Bazaar is tempting, but more research needs to be done. And we need to know what data (just animatics?) need to be synced from the 3D tree.

Contents

Version Control and Asset Management for Audio

Introduction

At the moment this is the plan.

We are going to test bzr for feasibility for a dvcs solution next week with Thomas and Derek. With bzr we can push and pull directly between each other as needed, and skip the checkin/wait/checkout/wait process we had last year that slowed us down.

Along with this however, we are going to continue to utilize a SVN server to push to for a centralized place for work to end up in the end. We are going to be utilizing the bzr-svn plugin to allow us to interface with it natively, and maintain all the benefits of dvcs.

The address for the sound SVN server is http://svn.handturkeystudios.com/rva48hr-snd. Basic information on how to access it can be found on the Help page.

SVN Structure

The SVN server will have the following structure, which should be maintained throughout bzr.

  • rva48hr-snd
    • music - Under this directory will be the final music files from Derek. At the top level of the directory should be a text file that defines the SMPTE timecode that each piece music should be played during.
    • effects - Under this directory will be the final effect sequences. Like the music there needs to be a text file that describes when each file will be played in video timecode. Effects should be broken up as possible into seperate files for background ambience and localized sound effects.
    • dialog - Under this directory will be the exported Dialog track for timing. If the final mix is not happening on site, then the source sound files will also need to be in the folder for whoever is doing the final mix, and preferably a text file with timecode ranges again, but that may not be possible.
    • video (as needed) - This is an optional directory that may not be needed. If preview renders of the videos or animatics cannot be rendered by the entire sound team, then the renders that are created for other memebers of the team should go here. If the renders can be done by the entire sound team then this directory can be safely ommitted as they should not need to be in version control.
    • previews (as needed) - Another optional directory. If preview renders of the audio are needed for other members of the team, then they should go here. These should only be lossy format files, AAC files, 192kbps at most(128 should be fine for our purposes to be honest). Again a text file describing the audio file would be preferred, but may not be possible in a rush.

VCS Notes:

The structure of all directories under version control should follow this.  However this structure was specifically chosen so that we could check out a directory as needed, and with the knowledge that most people would not need to be worried about more than one directory, so to save bandwidth we can only check out a single directory, or push to a single directory as needed.  I believe this even holds true for pushes and pulles directly between peers, though I have not checked this yet and it will be on the test list for next week.  The end goal of this is that all work happens locally on each person's machine, with only the finished product being pushed elsewhere, or previews as needed.  Hopefully between this and switching to DVCS we can drastically lower bandwidth requirements and time spent waiting for checkins and updates.

Due to the possible necessity to push and pull directly between peers, a method for communicating IP information will be needed.  Obviously your current IP can be found by utilizing the site www.whatismyip.com however some of us are on Dynamic IPs from our provider and this my shift during the 48 hours.  One possible solution is to utilize DYNDNS or something similar to map an IP address to a hostname and update it often.  Another lower tech solution is to ask and announce on IRC as needed, this may be sufficient but more thought needs to be given to it.

Since both Derek and Thomas are on Mac OS X, probably the easiest way to enable direct transfers between them is to utilize the HTTP functionality of OS X, and keep the bzr branches accessible form the ~/Sites directory.  We would enable web sharing then, and only pull form each other, we wouldn't be able to push to each other with this setup, but that should be fine for what we need.  We could always checkin to svn as needed as well under this setup.  Or at least that is the hope.

Personal tools