Upfront planning and design considerations can be intimidating to some. It is very difficult to design visuals when you don’t have content, and tough to set the mood for a story that might not exist yet.

The process of planning ahead for design and functionality changes down the road can be intimidating. First you’ll have to come to the realization that there is no way to predict the future. Who could have guessed that by 2010, all computer monitors would be set to 10,000 x 6,000 resolution, and that project you created in 2004 at 640 x 480 is now the size of a postage stamp? Some things just can’t be predicted. Your best bet would be to look one or two years ahead and take a guess, especially with projects you know will be used year after year.

Issues that arise from changes in storyboards, content or anything affecting your project can be infinite. What if in the middle of your 6 month long project you came to realize you needed audio controls, such as play, stop and volume. What would save you time and get the addition completed would be a sloppy hack job. This might take you less than a day to get up and running. You’d be doing this however, with the knowledge that any future projects based on this backend system you’re building will crumble the second any programmer but yourself touches the source files.

An alternative approach is to work within structured guidelines using reasonable timeline goals. This audio fix might now take 2 weeks to do it right as opposed to half a day. What a bummer! The truth is, when you do something wrong or sloppy, the problems you create may take a whole month to fix later on, as other aspects of the code become dependant on your sloppy code. It’s the house of cards effect, where you pull out one part of the structure that all other parts rely on, and the whole thing may come crashing down.

Seeing there’s no right way to plan far in advance, what you have to do is create some sort of constant update timeline. Checkpoints in development where you really focus on debugging code, making everything work together flawlessly, so that in the end you don’t have a hulking mess of jumbled up templates, actionscript files and graphics.

It always happens at the worst possible moment, doesn’t it? You’re booked solid, working 10 hour days, borderline zombie, and the program you use the most starts acting funny for no reason, and apparently no one else in the world has ever shared the same problems (or so Google tells me).

I’ve recently come across a host of Flash audio problems and feel I’ve come up with some fairly straight forward solutions. One side note just FYI is that all audio used was professionally recorded, so none of the issues from what I can tell were caused by the quality of the initial recording.

Problem #1: My audio file sounds slow and drawn out, like a dying record

While adding in .wav audio into a project, it took me a while to realize it, but the VO (Voice Over) actors all sounded a lot deeper voiced that I’d assumed was natural. A few hours into the project I needed to edit a clip of audio and opened it into my favorite editing tool, Adobe Audition (earlier known as Cool Edit Pro before being bought out). Lo and behold the VO actor’s voice sounded clear and natural, the way it should. So what was Flash doing to my file?

Solution #1: Batch process or save your files at a different sampling rate

Now this may be a no brainer for all you audio editing geniuses out there, but for a Flash developer like me who only dabbles in the complexities of professional audio recording, it took a while and some digging to figure this out.
To correct this problem, re-sample your files down to 44100 HZ or a lower quality 22050 HZ. Flash likes these two sampling rates the best which is the important part. You can do 44100 HZ, 16 bit Mono, or 44100 HZ, 32 bit Stereo, it’s the sample rate that matters and will fix the problem.

Problem #2: My audio file appears to randomly skip the first .75 to 1 second of audio in my file

(Oh there is more…)