In order to get the best quality sound for the smallest file size and performance hit, you must consider what the content of the sound is. Too often, movies use a blanket 8-bit 22kHz sound format when that may not be appropriate. But first, you must realize what each factor means when recording sound.

First, sound recorded in a computer is digital. This means that a replica of the sound is being recorded as opposed to analog which makes an actul copy of the sound wave. As a developer, you need to be aware of two crucial elements and how they affect your piece.

Bit depth - This is the detail of any particular sample. The higher the bit depth, the more detail each sample has of the sound. This gives greater accuracy and, more importantly, less noise.
Sampling rate - The number is measured in kHz, but is actually the number of times per second that the sound is sampled. At each of those intervals, that particular place in the sound is recorded. A sample is taken
So a sound recorded at 16 bits and 44.1 kHz is actually a sound that has been sampled 44,100 times per second and each sample has a bit depth of 16 bits.

Bit Depth
Bit depth is the detail of the sound samples. The higher bit depth, the more detail and less room for noise or muddiness. Sounds recorded at 8 bit typically have more noise (hiss) than sounds recorded at 16 bit. If you are recording voice alone, there will be gaps and pauses between words and sentences which can accentuate any noise in your sound. Generally, a higher bit depth is recommended for voice in order to keep your sound "clean".

Sampling Rate
Sampling rate is a bit more complex. You need to consider what your needs are. Keep in mind that the human ear can hear things in a range of approximately 20-20,000Hz. Anything above 20,000kHz cannot be heard by humans (while sounds below 20Hz cannot be heard per se, they can be felt assuming that your sound system can output at that frequency). A range of 20 - 20,000Hz is the general rule of thumb although this can vary somewhat among individuals.

Nyquist's Theorem says that you need to record your sound at a sampling rate of double that of the dynamic range you are trying to achieve. If you want your sound to have a range of 20 - 20,000kHz, then you need to record it with a sampling rate of at least 40,000Hz. A sampling rate of 44.1kHz is commonly used to achieve a full dynamic range - CD audio quailty.

What it all means
Now that you've had a crash course in digital audio, you need to apply it to your piece. File size and quality are important. While it is easy to assign a blanket bit depth and sampling rate to all of your sounds, your sound quality might not benefit from this strategy. Instead, weigh the differences each provides.

Voice - For voice, a higher bit depth to eliminate hiss and muddiness is preferable to achieve a clean sound. But 16-bit audio files are twice as large as comparable 8-bit sound files. You can usually make the tradeoff in sampling rate, by cutting it down. Recording voice does not require the same frequency range as music. There is no booming bass or higher highs. The human voice is pretty much mid-range. So if you establish that the frequency range does not need to go any higher than 5,000Hz, Nyquist's Theorem says to record the sound with a sampling rate of 11kHz. If your talent has a deeper voice or tends to fluctuate in range, then a range of 11kHz can be achieved by recording at 22kHz. Keep in mind that this will double your file size.

Music - For better sounding music, the bit depth is not as important as the sampling rate. Since music is continuous with no noticeable pauses or gaps similar to what you'd find in voice, hiss and muddiness can often be masked by the nature of the sound. So a lower depth of 8 bit can sound nearly as good as 16 bit, but without the doubled file size. Since most music has a wide dynamic range, then the sound needs to be recorded with this in mind. A lower bit depth such as 11kHz will produce a very flat, undynamic sound, not unlike that coming out of a transistor radio. The highs will be cut off and the bass will be nonexistant or even distorted. 44kHz is CD audio quality and sounds quite good on a good system. But the file size is quadruple that of a sound recorded at 11kHz and most computer systems have small speakers that can't generate the quality you are looiking for. So a happy medium is 22kHz. This is radio quality which is good for applications most of the time.

Summary
For voice, focus on bit depth to reduce noise, hiss, and muddiness. Sampling rate is usually a secondary concern. For music, focus on sampling rate since the nature of music can mask the degradation of a lower bit depth.

Things to Consider
File size is always halved if you cut the bit depth or sampling rate in half. In other words, you won't get a smaller file by cutting the bit depth in half than you would if you cut the sampling rate in half. You will get the half the size of the original regardless of which one you cut.
An 8-bit 44.1kHz sound is the same size as a 16-bit 22.050kHz sound.
A 16-bit 11.025 kHz sound is the same size as an 8-bit 44.1kHz sound.

Most people don't have sound systems on their computers that can pump out a 16-bit 44kHz sound the way you want them to hear it. Unless you know your target audience has this capability, there is no sense in doing it.
File size is not the only thing to consider when chopping sounds. Performance is also affected by bit depth and sampling rate. As expected, higher bit depths and sampling rates require more system resources to process, possibly degrading the performance of other elements in the piece. So if your animation speed is crucial at that moment, consider dropping the sound quality.

Director for windows has one sound channel. We employ macromix.dll to mix Director's 8 sound channels into one. But if you try to mix sounds of different bit depths, two performance hits can result:
The sounds will be resampled to match each other. A 44kHz sound may suddenly have the same range as the 11kHx sound you are trying to play at the same time.

Due to the time it takes to mix the sounds, there can be a noticeable delay bertween the time the command to play the sound is issued and when it actually begins to play.

For more information specifically regarding this issue, please see TechNote 3191, Windows and Multichannel Sound.
For purposes of simplicity, sampling rates in this techNote are referred to in their simplest values such as 44kHz. This is not entirely accurate and to keep things standard for the widest compatibility across different sound cards, you should limit yourself to the following sample rates:

It used to be that to store such an enormous amount of information, you'd need the long spiral of a vinyl disk (raise your hand if you remember LPs) or miles upon miles of magnetic tape. Such a recording method is called analog, because the LP turns under the needle (or the tape moves past the head) at a rate analogous, or equal to, the sampling rate. If you've ever slowed down or sped up a tape player, you've experienced analog sound out of synch with the sampling rate.

As technology advanced enough to make storing large amounts of data economical, it became practical to record sound digitally. Every sampling of sound is attributed a digital value. If the range from quiet to loud was divvied-up into 16 levels, for instance, you would have 4-bit sound (each sampling would have one of the 16 binary values from 0000 to 1111. Think "walkie-talkie").

As digital data goes, digital sound is very much like digital imagery. Sampling rate is very much like pixel resolution. As a denser array of pixels can increase the clarity of a digital image, so too can a denser sampling rate increase the fidelity of digital sound. Imagine a 300 dots-per-inch (DPI) image and how much more information it provides relative to a 72 DPI image. The same goes for sampling rate. While a music CD reproduces sound with a resolution of 44.1 kHz, the standard computer sound is produced with a density of only one-fourth that (11.025 kHz).

The sophistication, or depth, of each byte of digital information is relevant as well. GIFs possess the 256 values of 8-bit data, but often JPEGs have the color depth of 24-bit data (224 or "millions" of colors). Likewise, digital audio can have the refined tone of 16-bit data or the more bland, "greyscale" tone of 8-bit data. (Human ears, by the way, hear the equivalent of 24-bit sound).

As you may already know, with digital bitmap imagery, more and deeper pixels make for bigger and fatter files. Once again, the same goes for digital sound. Sound, however, has the unique predicament of having to be delivered at a sustained rate because it eventually has to go analog again when it hits the speakers. While a 300 DPI, 24-bit JPEG just takes longer for a computer to buffer and then display to the screen, full-fledged sound taxes the very infrastructure of computer networks with its constant, streaming delivery from disk driveto speaker. If you have ever had occasion to watch the painfully slow draw of a large JPEG, then just imagine if it were an orchestral maneuver.

Note: The compromise of digital quality for file size is as true for sound as it is for imagery. Sometimes an 8-bit GIF is an acceptable alternative to a 24-bit JPEG. For the same reason, it just makes sense to use 8-bit, 11.025 kHz mono sound for a button click. Always determine the minimum amount of quality acceptable for every instance of sound, but do yourself a favor: when capturing or altering sound, work at the maximum resolution and depth possible and then desample to lower rates on export. Robust original sound data has more latitude and fidelity and is therefore more tolerant to the ravages of editing and compression. However, as with digital imagery, it is never necessary to "scale-up" the data to a higher sampling or bit-depth - the file will be larger but not better, just laden with more of what you don't have.

If you need to capture visual motion for reproduction, you take a lot of pictures with a movie camera and then play them back to see the motion. Sound is motion too, just like the ripples in the water. To capture sound for reproduction, you have to take a lot of little samplings of the motion and then drum them over a speaker to reproduce the sound. The number of samplings captured per second is called the sampling rate and is measured in hertz. These "sound bites" are like the frames of a movie. The sampling rate of pulses per second (Hz) is similar to a movie's frame rate of frames per second (FPS).

Light moves fast — faster than sound. However, when you make a movie, you're not capturing light waves, you are capturing a sequence of static images. The light waves take care of themselves getting from the projector to the screen to our eyes. A process called persistence of vision helps the brain fill in the blanks between all those flickering frames.

To reproduce sound, however, there is no such convenience. Recorded sound must duplicate the waves themselves, and sound waves can't be faked with a mere 24 samplings per second. Even a sampling rate of 5564 pulses per second is rather crude - kind of what you'd hear over a walkie-talkie. To get acceptable results for reproduction, like a good FM radio broadcast, 22050 pulses are produced every single second.

Sound synching strategies
There are different approaches to synching audio and visual content. The method used should be chosen on a case by case basis, depending on the content and scope of the project.

The easiest way is to use short sounds that are triggered when the playback head reaches a certain frame. If a long narrative track is being used, break up the sounds into sentences or paragraphs that describe a certain section of the movie. Make sure the playback head stays in this area long enough to play the entire sound. It's much easier to tie specific sounds to specific frames, than it is to play very long sounds.

If a longer sound file must be used, consider using the "stream" synch method, available in the Sound Panel of the Frame Properties dialog box. This will force Flash to drop frames (if necessary) in order to keep up with the audio.

If the project demands that each and every frame of the animation is seen, then try setting a slower frame rate. Unlike QuickTime, Flash and Shockwave both use the frame rate as a top gate: the playback will try to meet that rate, but will not exceed it. By controlling the playback dimensions of the movie and by testing on a slower machine, constant playback rate across different machines can be achieved.

Synchronize audio in the destination environment
If this Flash movie will be playing in another environment, such as QuickTime or Director, then it is often more efficient to synchronize audio in the destination environment. This is particularly true with time-based QuickTime files: instead of combining an event-based Flash animation and a time-based audio file in Flash, and then converting both to a time-based QuickTime stream, it is usually easier to first convert the event-based Flash animation to a time-based QuickTime stream and then to strip in a time-based audio track. (Rephrased, the synch process is facilitated if all the elements are already time-based, rather than attempting to match time-based and event-based streams and then converting everything to another time-based stream.)

When working in Director, it is usually best to use simpler Flash movies... instead of building all the interactivity and audio into a nested Flash file, keep the control at the top level so it will be easier to edit later. The Flash movies can send frame events out to the Director host, letting Director know when it should play certain files. By sending messages out to Director, audio cue points can be used for synching, and the "lock step" option can keep Flash frames in synch with Director frames.

Summary
There are many delivery paths where audio synchronization might be desired. Because of this, one approach doesn't work for all cases. Try experimenting with different methods to find the way that suits a specific project. Smaller sound files will make the process easier and testing on slower machines can ensure consistent playback. Also remember that delaying the synchronization procedure until the project is in the final delivery environment can improve workflow and efficiency.

Sound is data intensive. The quality of the sound output and length of playback factor prominently into the amount of data required. Sounds with higher sample rates (22.5Khz and above) retain a greater degree of quality, but almost always require too much data to realistically stream sound to the Flash player on time over a 28.8Kbps modem. Flash utilizes compression to help reduce the size of the data - but even the maximum compression allowed in Flash may not be sufficient to deliver high quality audio over longer periods of time. Here are some tips to use sound more efficiently:

Use the lowest bit-depth and sample rate acceptable to achieve the smallest data size.
Sound quality deteriorates as the sample rate declines, so you may find lower sample rates yield more even playback but also poorer quality audio. Try to find a happy medium between quality and data size.

Keep sounds short.
Flash doesn't have the same type of compression capabilities as Shockwave streaming audio, so it is ill suited as a means to deliver longer audio programs. You may use smaller sounds looped to achieve longer audio playback because a smaller amount of sound data is downloaded once and used repeatedly.

Watch the size report closely for clogging of data near keyframes.
The Event synch option delivers the sound data all at once when needed for playback; Stream synch delivers the sound data over the specified series of frames. Watch the size report closely for clogging of data near keyframes and use the "preloading" techniques to trim down the amount of data needed per frame or per second.

How then do we synchronize animation and sound; two process operating on such different principles? Unfortunately, we don't - at least, not really. All we can do is plant sounds where they need to occur and hope for the best.

Hope and play. And work smart. Realize that sound requires thousands of samplings each second and is therefore likely to be the bulkiest addition to any Flash animation. If sound is optimized, and then used and placed properly, it can be a wonderful thing. Use sound improperly and the results can be painful to watch (and excruciating to listen to).

Flash provides two methods for incorporating sound into an animation, and while neither will guarantee seamless synchronization, they can both contribute to a better experience:

Event sounds function very much like automatons (animated symbols) in that they are placed at key frames and then run their course when triggered. In fact, the only functional difference between event sounds and automatons is the sound's ability to be placed into any of the states of a button. Whatever the use, event sounds are slaves to the animation.
Streaming sounds work like a sound track to the animation. Upon export, all sounds designated to stream are merged into a single sound track which then plays the entire length of the animation. This method gives precedence to the sound and drops animation frames accordingly to maintain synchronization.

The obvious advantage of using streaming sound is the ability to synchronize sound with animation. Unfortunately, if the forum is the Internet, the unpredictable delivery to unpredictable computers will produce unpredictable results. When a Flash movie is intended to be played directly, such as in video format (QuickTime or Windows AVI) or via the Flash Player, a much more successful synchronization can be expected.

Note: Don't think only Flash movies with streaming sound will stream upon playback. Actually, all Flash movies, regardless of the sound method, will stream if they are accessed prior to being completely cached. Lengthy or complex event sounds may behave sporadically if data is still catching up, but chances are this is no more annoying than having frames drop due to the streaming sound method. You decide.

The term streaming, as it relates to Flash Player, refers to the normal flow of data from a server over a network connection to the client machine that has requested it. The fastest speed at which data moves is limited to the slowest connection through which that data travels.

Often, the slowest point in the connection is a user's modem (running at 28.8Kbps per second or slower). Since all data streams over a connection to the users machine, what makes a Flash Player movie's stream different from a big GIF or JPEG file's stream?

The difference is that the data in a Flash Player movie is stored sequentially by frame. When the Flash Player (plug-in or ActiveX control) receives all of the data for a single frame, it may then immediately render it to the screen without waiting for any more of the data to arrive. A Flash Player movie will play smoothly only if Flash Player is able to receive the data over the net connection at about the rate that the Flash Player movie is set to play in frames per second.

Flash Player movies, just like any other data, always stream. However, how well a Flash Player movie plays when streamed depends on how much data is required for each frame in order for a Flash Player movie to play.

Often, the slowest point in the connection is a user's modem (running at 28.8Kbps per second or slower).To play smoothly from start to finish, the following must be given consideration:
- The size of the data required to display each frame should be as small as possible.
- The size of the data required to display a series of frames should take no longer to download than it takes to play the series of frames.
- To play any frame, Flash Player requires all elements of the frame to be downloaded in their entirety: event sounds, bitmaps, vector shapes and so on.

If the movie reaches a frame that cannot be rendered because all of the data hasn't downloaded yet, playback will stop until the needed data has finished downloading. Therefore, if your movie has complex items or a large number of items in the first frame, it may take awhile to download all those items before the first frame can be displayed. If other frames are also large or complex, your movie may play in spurts slowing down to wait for data and then speeding up when it has enough data to play the frames faster.

First a little tip about bitrates and Mp3´s:
My new rule of thumb is to use 24 bit mono sound almost exclusively for 56.6 modems and 64 bit mono for broadband.
These ratios will stream without worry. I mention mono because there's something interesting to note about mp3 stereo.
A 64 bit stereo mp3 file is roughly equvilent to two 32 bit channeles. When compared to a mono 64 bit instead of one channel that sounds pretty good, you get lower quality playback at the same file size.

Another thing I have been looking into is streamline site downloads by loading different sounds according to a bandwidth check. The largest portion of most flash applications is the sound To do this all sounds must be in their own swf's and each sound should be encoded at two different bitrates for modem and broadband usage.

Instead of embedding the application swf into the html, the application will end up being loaded into a level and run inside another swf file. The swf file embeded in the html is only a small space holder to check the bandwidth. This is done to ensure that there is no collateral bandwidthusage.

The logic order is this:
- Html page loads with a small 2kb swf space holder that is the same dimensions as the application which is intended to be loaded. The file starts with a loop to check if its last frame is loaded (again minimizing collateral bandwidth).
- Once the last frame is loaded the loop breaks and a load movie command is executed. The movie loads in another swf that must be created. This swf is only to serve as data to be timed by the space holder swf. The contents of the swf are 9 blank key frames and a 5kb bitmap on frame 10 followed by an additional frame. The frame spacing isn't important, but the size of the bitmap is. I choose 5 because it won't bog down the loading time too much and it is enough data to gage the connection speed.
- To check the speed use the _framesloaded property on the target where the data swf is loaded. First check to see if the last blank keyframe before the kayframe with the bitmap is loaded. If it is start a clock or a frame counter to time how long it takes the frame with 5kb to load. Stop the counter when the frame with the bitmap has loaded and calculate the connection speed. (filesize of bitmap=5kb)/counter converted to seconds.
- This will give a rough connection speed. If this speed is less than 5kb/s the user has a modem connection speed. If greater than 6 broadband. Set a variable refering to sound quality according to the connection speed. quality="lo" or quality="high" The target can then be unloaded.

The next step is to load your application swf into a level and then set the quality variable in that level according to the check. Now for the tricky part. The application should have no sound, except for the seperate swf's encoded at two different mp3 bitrates: soundlo.swf soundhi.swf as an example.
As the application goes through its preloading process it needs to load in the sound swfs using the quality variable calculated by the bandwidth check. The url loaded should use the variable to determine which sound file to load.
"http://www.mydomain.com/sound"&quality&".swf"

The real tricky part is creating the preloading processes and setting up your applicationwith blank targets to load the sound into. The advantage is having an optimized download time while delivering the best sound quality as determined by connection speed.

The following tips are general advice for achieving small file sizes and optimum playback performance:

1. Simplify elements drawn in Flash or imported from other drawing applications.
   Under the Modify menu, the Curves pop-up menu contains the Smooth, Straighten and Optimize commands. The Smooth and Straighten commands will automatically smooth or straighten the currently selected lines and curves. Optimize allows you to control the amount of smoothing and straightening of lines and curves, whether multiple passes are used to accomplish the optimization and also reports the amount of optimization that has occurred with each pass. Use Optimize when you want to preserve as much of the original appearance of the lines and curves as possible. The goal is to strip away unneeded point and path information to reduce the amount of stored data to the minimum required to render your object on the screen. Because screen resolution is substantially lower than common print resolutions, minute details can often be eliminated from the drawing without compromising the overall appearance.
   
2. Use symbols instead of groups when you repeat elements.
   Symbols are stored once in the file and may be referenced many times, adding very little data to the file for each reference to the original symbol. Groups are stored in the file every time they are used. So, if you have a group of items that is used three times, you store the same data in the file three times. If you use a symbol in this instance instead of a group, then you are storing the data once and adding three very small references to that data in the file. Ultimately, the advantage of using symbols instead of groups can reduce the size of your movie file significantly.
   
3. "Preload" symbols when too much data is needed all at once.
   As mentioned above, Flash Player must have a symbol fully downloaded before it can render a frame that contains it. Use the size report and a visual inspection of the movie to pinpoint areas where performance begins to suffer because too much data is suddenly needed for a frame. If your movie has smaller symbols, you can preload them by placing them on a layer beneath an item that hides them from view. This technique can be used to load some symbols ahead of time (while hiding them from view) so they are ready for use later in the timeline when downloading them might cause a delay in playback.
   
4. You can also force Flash Player to "preload" all the symbols for the entire movie by placing them on a layer beneath an item that hides them from view in the first frame. This technique forces Flash Player to wait for all of the symbols in Frame 1 to download before playback can begin and may cause a significant delay before a viewer sees any activity on the screen. This technique is useful though when any delay or pause in playback would be undesirable (e.g. sound data).
   
5. Another technique involves using one of the Goto frame actions with the Wait for Frame check box to prevent Flash Player from playing a series of frames until all of the series has downloaded. To utilize this technique, place a Goto frame action on a keyframe and specify the next frame in the Frame field. Count the number of frames forward in the timeline that should be downloaded before the Goto frame action should be executed. Check the Wait for Frame check box and supply the number of frames to wait for in the field provided below it. Flash will pause playback at the frame containing the Goto action until all of the specified frame data has downloaded. Use this technique early in the timeline for best results. A temporary loading message can be displayed - or a more elaborate status bar can be created with this technique - to hold the viewers attention until the needed data arrives.
   
6. Avoid using too many CPU intensive features at the same time.
   Flash's vector based animation system differs from raster (bitmap) animation systems in that the host CPU is required to perform calculations with the vector data before rendering the images on the screen. Tweening multiple symbols in a frame, tweening color effects, changing large areas of the screen between frames, and using gradient fills are all CPU intensive operations requiring further calculations on top of the normal load Flash places on the processor. Playback may slow down when too many CPU intensive features are in use. Although some improvement in speed may occur when the file is exported to Shockwave Flash format, results may vary with your design.
   Test early, test often.
   
7. Test on all browsers that you anticipate will be used to view your site and test on the lowest connection speed that you think should be necessary to view your movies online (a 28.8 connection for example.)
   

Flash relies on vector based rendering for efficient storage and delivery. Raster (or bitmap) based rendering systems store information about individual pixels to be presented on the screen. The amount of information required to render a raster image is based on the size of the image (or the number of pixels that image contains). Vector based rendering requires far less information, storing only the mathematical data needed to calculate and render the image. For these reasons, raster images can drastically reduce the efficiency of Flash when used excessively.

Here are some tips for using bitmap images effectively:
Take advantage of compression to reduce the total file space occupied by bitmap images.
Flash supports two methods of compression for bitmap images: JPEG and Lossless. JPEG compression is the default compression for all bitmap images exported to Flash Player format. The value in the JPEG Quality field in the Flash Player export dialog box can be adjusted from 1 (most compression, lowest quality) to 100 (least compression, highest quality). Because JPEG compression can result in a loss of image data, you should test images with different JPEG quality values to achieve the best level of compression and image quality according to your preferences. Bitmap images may also be exported with lossless compression to retain image quality. Lossless compression, however, cannot achieve as great a reduction in data size as JPEG compression. To specify lossless compression, open the Library and select the desired bitmap. Choose properties from the Library pop-up menu and then choose Lossless in the Export As pop-up menu.

Use bitmap images sparingly.
Even though Flash will allow you to create a frame by frame movie with one bitmap image in each key frame, the resulting file will still be too large to deliver quickly over a 28.8Kbps modem. For smaller file sizes and faster playback, use bitmap images as accents or backgrounds.

Avoid animating bitmap images.
Bitmap images, unlike vector images, do not scale or rotate well on the screen. Also, Flash Player must render bitmap images again each time they change positions on the screen - often changing large areas and slowing down playback as these areas are continually redrawn.

To retain definition and clarity in the original bitmap, disable smoothing for that image only.
Open the Library, select the desired image and choose Properties from the Library pop-up menu. In the Bitmap Properties dialog box uncheck the Allow Smoothing check box. This will disable anti-aliasing (or smoothing) for this image only. Repeat for each image desired.

There are a few things that can be done to improve the image quality of bitmaps before and after importing them to Flash.

To improve bitmap quality in Flash: Don't scale imported bitmaps within Flash, which can greatly reduce image quality in published SWFs. Rather, use an external image editor such as Macromedia Fireworks to scale the image to the desired pixel dimensions before import.

After importing the image into Flash, break it apart and convert it to a graphic symbol. To do this, first select the image and choose Modify > Break Apart. Then, with the image still selected, choose Insert > Convert to Symbol and select the Graphic option for the behavior.

In the HTML tab of the Publish Settings (File menu > Publish Settings > HTML tab) set the Quality to Best.

Disable the Allow Smoothing option for the bitmap. In the Library window, right-click (Windows) or control-click (Macintosh) on the bitmap and select Properties. Un-check Allow smoothing in the Properties dialog and click OK.
Use lossless compression for the bitmap. In the Library window, right-click (Windows) or control-click (Macintosh) on the bitmap and select Properties. Choose Lossless from the Compression pop-up menu and click OK. This will cause Flash to render the image at the original imported quality and will probably cause the SWF file size to increase considerably.

Although Flash 5 offers flexibility in naming objects and freedom in coding practices, following some basic naming conventions will help ensure proper playback. The use of naming conventions when coding also helps make scripts easier to understand, troubleshoot, and share with others. This document lists some common naming conventions when programming in ActionScript and other languages.

Naming strategies:

- Avoid spaces or special characters. Spaces, periods, or special characters often have special meaning to the Flash Player, signifying the end of a statement or part of an expression, for example. Names can include underscores, letters, and numbers. Punctuation or other special characters should be avoided.

Note: For an example list of special characters, refer to the TechNote URL Encoding: Reading special characters from a text file (TechNote 14143).

- Start with a letter. Using a variable or object name that starts with a number can cause confusion. For example, instead of using the expression '3frame' to identify a frame label, use 'frame3'. Variable, function, and object names can contain numerals, however the first character should be a letter.

- Use unique names. Avoid giving two different objects the same variable name. For example, if a movie clip instance and a text field both have the same name, problems may arise when changing properties of one or the other. Giving each object a unique name can help avoid this issue.

- Use a system for identifying type and scope of variables. For example, use 'mc' as a prefix for movie clip instance name, or 'txt' as a prefix to a variable name given to dynamic text field. In a movie with both local and global variables you might use the word "global" or the letter "g" to prefix global variables that you intend to use throughout the movie, and the word "local" or the letter "l" for local variables that cannot be accessed later in the movie. What is referred to as Hungarian notation is widely used across scripting languages.

Here are some more examples :
The left column contains the data or symbol type and the right column contains an example of a variable or instance name for that type:

Array: myArray_array
Number: myNumber_num
Movie Clip: myMovie_mc
Button: myButton_btn
Graphic: myGraphic_gr
Date: myDate_date
Sound: mySound_sound
String: myString_str
Textfield: myText_txt
Color: myColour_color
XML: myXML_xml

- Use multi-word descriptive names. For example:
firstNumber, myDate, timeCounter, lastName. This naming practice is useful when troubleshooting or sharing scripts with others. Generically named variables such as x, i or j don't give much information as to their use and can be difficult to keep track of when troubleshooting. The variable lastName, however, instantly gives clues as to what the variable is for.

- Capitalize the first letter of subsequent words. When using multi-word names for variables, capitalize the first letter of all words but the first. Some examples of this are: lastAddress, currentAddress, and lastFrameVisited. This practice can make code easier to read. If you share code or collaborate on projects, others will benefit from the readability..
Match cases. Be sure to be consistent with capital and lower case letters. If an object is named myTextFader, be sure to refer to it throughout the movie as myTextFader, and not 'mytextfader' or 'MYTEXTFADER'.

- Avoid reserved words. Words like 'date', 'this', and 'goto' have special meaning for the Flash Player. Using these words as variables may cause problems when the script is executed. One way to avoid this is by using multi-word descriptive names for variables, as suggested above. For example, use birthDate as the name for a variable holding a date. In addition to avoiding conflicts with the reserved word 'date', the result is a more descriptive variable name.

Note: This issue is more thoroughly explained in the TechNote Variable names conflicting with object names (TechNote 14677).

- Declare variables with var or set variable. Although Flash does not require using var or set variable to assign a value to a variable, it's a good practice. For example, it's perfectly acceptable to declare a variable and assign it a value in one step, as in the following:
userName ="Mary";
However, the code is more readable if the variable is declared before being assigned a value:
var userName ="Mary";
This clearly identifies the statement as a variable assignment.

- Include a legend. This is especially helpful in complex projects.
For example, if you use certain prefixes to identify different types of variables and objects, it is helpful to define your naming system. Use the comment statement in ActionScript, or create a "ReadMe" or "legend" symbol in the library with text that explains what each prefix means.

Flash stores the outline data for all characters used from a particular font. This technique allows you to use custom fonts in Flash without converting them to outlines in another drawing program or breaking them apart in Flash. If you wish to animate changes to the outline of a font, use the Modify > Break Apart command to convert them to outlines. Here are some tips on using fonts:

Do not break apart fonts unless you really need to edit the paths of the characters.
Fonts that are broken apart or imported as outlines from other drawing programs generally add more to the overall file size if any of the characters appear more than once. Leave text intact for optimum results.

Avoid using multiple fonts if possible.
If file size takes priority in the design process, limiting the number of fonts used in a Flash Player movie can significantly reduce the file space taken up with font information. Every character that is used from a font is stored once in the file and the data is reused every time it is needed. If you use multiple fonts, each character used from each font is stored, increasing the amount of file space needed for font outlines.