Skip to main content
MediaBeacon University


XMP Accelerator

MediaBeacon servers need to manage huge numbers of files. To allow this, MediaBeacon has developed a unique method of accelerating the write of the metadata for each file into the file system. This acceleration works outside of the standard XMP specification, but is crucial for reasonable response times on larger databases. MediaBeacon allows administrators to select the proper mode for their environment. In all cases, the users will download a completely compatible file. This setting affects ONLY the way the files are stored on the server. Downloaded files are ALWAYS downloaded in a completely compatible format.


Resource forks are an old Macintosh technology that allows a second stream of data to be attached to a file. Windows has a similar concept for NTFS, called Alternate Data Streams. Generally speaking, neither is maintained when transferred over standard protocols, such as HTTP. Additionally, some file systems (like NFS) don’t have native support for forks/streams. As a result forks/streams can be lost if care isn’t taken to preserve them when transferring them between systems.

MediaBeacon caches a variety of data in the resource fork / alternate data stream, including:

  • Thumbnails and previews
  • XMP Metadata for file types that don’t support XMP embedding
  • Legacy XML metadata

MediaBeacon has a proprietary, pure Java library, mb-finfo which preserves and converts various resource fork formats, including support for HFS, NTFS, MacBinary, AppleDouble and maczip. The zip format (which we generally refer to as maczip) used by MediaBeacon and Mac OS 10.4 and later preserves resource forks for the files it contains, when downloading to a Macintosh. On Windows, it acts like a regular zip with some extra files, and will not preserve resource forks.

The following file formats can have embedded (not resource fork) XMP in MediaBeacon. They will not lose metadata when transferred between systems, regardless of the care taken to preserve resource forks:

  • JPEG
  • JPEG2
  • PSD
  • TIFF
  • PDF
  • InDesign
  • EPS
  • XMP and files that are actually just XMP (like .xmpb, etc.)

We can write to the data fork for the following formats, but choose not to, for various reasons:

  • PNG: By default, we put metadata in the resource fork, since this matches Adobe’s behavior.
  • GIF: By default, we put metadata in the resource fork, since this matches Adobe’s behavior.
  • AVI: By default, we put metadata in the resource fork, since writing to the data fork is very slow for big files.
  • MOV:By default, we put metadata in the resource fork, since writing to the data fork is very slow for big files.

All other formats will have their metadata placed in the resource fork, meaning that if the resource fork isn’t preserved, neither is the metadata.

XMP Acceleration allows the user to choose a “Compatible”, “Balanced” or “Accelerated” strategy for XMP storage. “Compatible” complies to the rules described above. “Balanced” writes a few complex / large file types to the resource fork (e.g. INDD). “Accelerated” always writes metadata to the resource fork. When files are downloaded through the MediaBeacon web interface, data will always be in the data fork, for embeddable file types, regardless of the acceleration setting.



MediaBeacon will follow the XMP specification in its entirety, even for very large files, which will be slow. Use this option if you are planning to use tools on the server that depend on the metadata present in the files. (For example, if you are writing Photoshop droplets that use metadata triggers on the server.)


MediaBeacon will follow the XMP specification for most files, but for large formats, such as InDesign, PDF, and EPS, metadata will be accelerated. Use this option in most cases. Balanced will provide compatibility in most cases while delivering the highest performance.


MediaBeacon will use accelerated mode for all files. Use this option if you want speed above all.

Note: Changing from one option to another is possible, but will require a rewrite of all affected files. This can by VERY slow. Plan ahead for the time to change this option if you have a database of more than a few hundred thousand files.


MediaBeacon has a unique ability to encrypt certain metadata into virtually any type of files. Either individual fields or entire blocks of data (schemas) can be encrypted using a variety of keys. XMP encryption tab presents you with a list of available keys and allows you to configure the data encryption functionality.



Keys window displays all currently available keys. The list can be sorted on a per-column basis.

To create a new key, click on New Key. Now you should be able to enter a key name, select a type of cipher, and input a pass phrase.


This key will be added to the list of keys under the XMP Encryption tab. Now you can select how this new key will be applied. You can either encrypt all metadata or individual data blocks and fields.


To encrypt a certain metadata schema or a field, select the Configure Fields button. MediaBeacon will open a new window displaying available data schemas and their fields. You can select any number of schemas and any number of fields within those schemas and apply a different set of keys to any of them.

To encrypt an entire schema, select a schema name and then select a key right next to it. To encrypt an individual field in one of schemas, click on a desired schema without selecting it, then select a desired field, and then select a key from the pull-down menu. Selecting a schema encrypts the entire data block.


Ignore External Changes to Encrypted Fields

Selecting this option will ignore any data changes to the encrypted fields.

  • Was this article helpful?