The Annotated Music File (AMF) standard is designed to allow the distribution of audio files (music, etc.) with additional media types embedded in the package. Particularly, the goal is to allow artists to distribute their works works in such a way that consumers who wish to compensate said artists will have an easy venue for doing so. AMF does not concern itself with copy protection or Digital Rights Management; rather, it is designed so that downloaders who wish to become customers have a minimal number of barriers to overcome.
The secondary goal is to allow content creators to enhance the presentation of their audio; it is assumed that the proper use of this capacity will encourage listeners to become customers.
The third goal is to make the system simple enough that playback software can easily support it, and artists can easily make content for it.
An AMF file consists of a .ZIP file with the .AMF extension, which includes the following files:
|audio[00..N].ext||Required: The audio portion of the file; may consist of multiple files numbered sequentially, as in audio00.mp3, audio01.mp3, etc. The format of the audio file is up to the artist(MP3, OGG, etc); but if the playback software does not support the format no playback will be possible.|
|amf/lyrics.html||Optional: a file containing lyrics or transcription of spoken material.|
|amf/about.html||Optional: a file with content intended to be shown when the AMF file is being played. This might include a picture, or song notes, or anything which doesn't fall into the category of lyrics or ordering information.|
|amf/order.html||Optional: a file which should specify how to buy this music, or other artist compensation instructions.|
|amf/creator.html||Optional: information about the person or group which created the file, including info on where to obtain a catalog of their work.|
The audio files should be stored as uncompressed data in the .ZIP so that music players with a simple translation layer can treat them as normal input and perform functions such as seeking without dealing with uncompressing .ZIP bitstreams. Since all annotation files are html, they may contain references to any sorts of additional media the creator whishes to include; those media may be included in the archive (pictures, etc.) or on the internet.
If multiple audio files are stored in the AMF, the annotation files may optionally include anchor tags who's target corresponds to the number of the audio file. In this way, multiple sets of lyrics or order forms can be included for each piece of audio data, if necessary. The format of the anchor is audio[00.N], such as #audio00. The player will jump to that tag when it starts playing back that file.
It would be advantageous to provide creators a way to sign the content digitally (say, with RSA), so that the downloader knows it is unmodified. For instance, if the creator has an audio file which the user is asked to pay for, the .AMF file could specify that, any anybody who wished to intentionally avoid piracy could do so. Particularly, if P2P technology was used to share AMF files, then an AMF aware program could chose to not share "paid content" (files would be marked with a 0-length file called paid content.tag in the AMF folder). Of course, the end user could easily remove that file, however, they would not be able to resign the AMF file with the creator's signature. Any AMF file which truthfully reports its creator could be checked independently to assure it was legal to share.
The goal here is not to prevent illegal sharing, but to allow AMF aware software to intelligently select what should be shared. Fair use is important, and users should be allowed to use what they have purchased. Any limits on the technology should be designed only to help users who wish to adhere to fair use standards without any extra effort. The emphasis with AMF is trusting consumers to do the right thing when it's made easy for them. It is, then, perhaps questionable whether any restrictions should be placed on the format, hence this section being labeled "speculative".
Currently, all the software needed to create AMF files exists in the form of HTML editors, audio compression software, and .ZIP file tools. Playback software has not yet been implemented, but would not require that much new code. At the minimum the requirements are:
Ideally, all of these features would be integrated into the player's UI, which would require an additional amount of effort, but would still not be that hard if 3rd party .ZIP and .HTML libraries are leveraged.
©2004 Alan Robinson (arobinsonhampshire.edu)