In Flash Player 9, the Sound.id3 property is unavailable when you use Sound.loadSound (or its ActionScript 3.0 equivalent, Sound.load) to load an external MP3 file from a different domain than the SWF file. This issue occurs when thre is no policy file on the MP3 file's server. The policy file permits access by the domain of the SWF file that is attempting to read ID3 tag information from the MP3 file. This issue can cause some MP3 files to appear as though they don't contain any ID3 tag information.


The following example illustrates the possible workarounds. If you maintain a SWF file at that loads an MP3 file from, and you want to extract ID3 tag information from a Sound.mp3, there are several workarounds.

Create a default-location policy file

The easiest fix is to create a policy file in the default location on, as in the following example:

<!-- Cross-domain policy file at -->
   <allow-access-from domain=""/>

Don't create a policy file on unless you are sure that all SWF files that might originate from are trustworthy;that is, you control, or you trust the person or people that do. Creating a policy file has additional effects beyond permitting cross-domain ID3 tag access. For example, a SWF file from is also permitted to read the contents of any text files on, and send those contents anywhere it chooses.

In particular, it is never advisable to create a policy file on a server on a private network that is not accessible from the Internet.

By using the default policy file location, which is a file called "crossdomain.xml" in the root directory of the web server at, you permit cross-domain ID3 access without having to inform Flash Player of the policy file's location. However, the default location speaks for the entire web server. Therefore, only use the default location if you want to permit access to the entire contents of the web server by SWFs from the domains you name in your policy file.

Even if you use the default policy file location, there is one modification that required in your SWF file. Set theSound.checkPolicyFile flag before callingSound.loadSound. This setting instructs Flash Player not to begin downloading the MP3 file until after attempting to download a policy file. The advantage of this method is that you can be assured that, once MP3 data begins downloading, it is safe to refer toSound.id3. If you do not specifySound.checkPolicyFile, Flash Player isn't aware that you intend to refer to Sound.id3, and doesn't preload a policy file. Also, because Sound.id3 is a synchronous API, Flash Player cannot retrieve a policy file at that moment.

Here is an example (in ActionScript 2.0) of usingSound.checkPolicyFile with a default policy file:

var mySound : Sound = new Sound(); 
mySound.checkPolicyFile = true; 

Create a custom-location policy file

If you don't have access to the root directory of the web server at, or you don't want to permit access to all of, but only a part of it, then you can create a policy file in any location that you want on The location of the policy file determines its scope. For example, if you create a policy file in a subdirectory, that policy file applies to media located in the subdirectory at and below. The contents of the policy file are the same as in part (1) above.

When you use a non-default location, inform Flash Player of the non-default location, by (or, in ActionScript 3.0, Security.loadPolicyFile). In addition, you should set the Sound.checkPolicyFile flag, to request that Flash Player finish the policy file download attempt before beginning the MP3 download. Here is an example (in ActionScript 2.0):""); 
var mySound : Sound = new Sound();    
mySound.checkPolicyFile = true; 

Proxy the MP3 download through the SWF file's own server

If you do not have control over the server from which you are loading an MP3 file, but you need to extract ID3 tag information from the MP3 file, you can proxy the MP3 download through the server from which your SWF file is served. You might do this with a CGI script on your own server, invoking the script like this:

mySound.loadSound("" + "?");

This is always permitted, since a SWF file may always access data from its own server. However, this requires some server-side scripting, using CGI, perl, PHP, ColdFusion, ASP, or any server scripting technology.

Be careful when you set up a proxying script like this, as there are many other security considerations for proxies. You will probably want to take at least some basic steps to ensure that the proxy is only used for the purposes for which you intend it. These could include checking HTTP "Referer" headers, hard-coding a limited range of URLs that the script will retrieve, etc.


Flash Player enforces security sandbox boundaries between media loaded from different domains. These boundaries typically permit media to be played from other domains, but generally prevent data from being extracted from that media into ActionScript. For example, Flash Player permits SWF files to load and display SWF files from other domains, but does not permit a SWF file to inspect the variables of a SWF file from a different domain unless the SWF file being accessed has (or, in ActionScript 3.0,Security.allowDomain) to permit the access.

Starting in Flash Player 9, Sound.id3 is recognized as an operation that extracts data from MP3 media, and thus is prohibited for MP3 files from different domains, except where a policy file on an MP3 file's server permits the operation.

This is a new behavior introduced in Flash Player 9 to comply with the security model and affects all SWF versions. Adobe is aware that this may change the behavior of some SWF media deployed before the release of Flash Player 9, and we apologize for any inconvenience this may cause.

Keywords: 50c96388

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Twitter™ and Facebook posts are not covered under the terms of Creative Commons.

Legal Notices   |   Online Privacy Policy