Fuga Delivery 1.7

This page describes the technical interface between the FUGA platform and the platform of a consumer DSP (Digital Service Provider) to provide content delivery.

Overview

There are two kinds of products: audio and mobile. Audio product is a music album, mobile a collection of ringtones.

After a DSP makes a deal with a supplier, FUGA delivers to the DSP the media files and metadata associated with the products in the deal. Delivery is initiated by the content owner (label). The delivery for a single audio product consists of:

The delivery for a single mobile product consists of:

When FUGA encodes audio tracks it will add (depending on the encoding format), ID3v2 tags to the audio file unless explicitly requested not to by the DSP.

Before a file is sent to the DSP a checksum is generated and added to the metadata. This checksum can be used by the DSP to verify that the audio, video, or image file has not been damaged during network transit.

Once the delivery is completed the DSP will get a delivery notification by email. FUGA currently supports the following protocols for content delivery:

Connecting you to Fuga

Before we can connect you to Fuga and start sending you content, we need some questions to be answered first:

  1. Who is the technical contact on your side we should contact about reviewing the XML requirements and setting up the interface? (name and email address)
  2. Who is the commercial contact on your side we should put in touch with the content providers using FUGA? (name and email address)
  3. How do you want the content delivered to you? (FTP or SFTP)
  4. What are the credentials to login to a folder on your server where we can drop content?
  5. Do you want to deliver content from different providers to separate content directories named after the provider name?
  6. What is your preferred transcoding format? (FLAC,WAV, MP3, AAC, AAC+)
    1. If you request MP3 or AAC+ what bitrate would you prefer? (128kbps, 192 kbps, 320 kbps, etc.)
    2. If you request MP3 what should the MP3 type be? (eg ABR, CBR, VBR)
  7. Should FUGA create audio previews?: (Y/N)
    1. If yes what format should the previews be?
    2. If yes what duration should the previews be?
  8. Will you be able to process:
    1. meta-data XML only re-deliveries?
    2. takedowns in XML?
    3. Can you process H.264 video? (Y/N) If so, what is the prefered bitrate (300kbps, 500kbps, 800kbps, 1500kbps, 6000kbps)?
    4. mobile ring-tone products?(Y/N)
  9. Would you like to receive cover art in JPG or PNG?
    1. What dimensions should the cover art have?
    2. If cover art is larger should it be scaled down?
  10. Notifications: (note that delivery notification emails and take-down notifications can be sent to seperate email addresses)
    1. What is the provider email address where FUGA delivery notification emails should be sent to?
    2. What is the provider email address where FUGA take-down notification emails should be sent to?

After we receive this information, we will be able to you send you a test delivery.

Delivery structure

The files for a single audio product (audio, video, cover art, metadata, attachments) or a single mobile product (audio, cover art, metadata, attachments) are delivered together in a directory. The directory is named after the product's UPC and FUGA's internal delivery ID in the format of [Delivery ID]-[UPC]. The directory contains the cover art file named [UPC code].jpg, the metadata file named [UPC code].xml, the track files named [UPC code]_[disc number]_[sequence number]_[encoding format].[ext] or the ringtone files named [UPC code]_[sequence number]_[encoding format].[ext], the video files named [UPC code]_[sequence number]_[video configuration counter].m4v (not available in mobile product delivery), and the confirmation file [UPC code].complete.

If there are any attachments belonging to the product, they will be placed in a subdirectory called attachments. The attachment files are named in sequence [upc]_01.jpg, [upc]_02.doc and so on. The extension designates the file type. If no attachments were delivered, the attachments directory is not present.

For example, if the Delivery ID of the product was 63119, the UPC code 723456789013, the files were encoded in MP3@320, and the DSP would support videos, the directory structure of the delivery would be:

Example of mobile product delivery:

If requested, FUGA can be configured to deliver to separate directories for separate content providers. It means the product directories will be created as subdirectories of a directory reserved for a specific label:

The confirmation file has zero byte size and is uploaded as the last one. That means once the file is found on the DSP's server, the delivery has been fully completed and the can be ingested.

Metadata format

Metadata is delivered in the XML format for each product. An example of a FUGA metadata document instance can be found here (for audio product) or here (for mobile product). Note that this examples reflects only a subset of the full FUGA metadata set. For a complete listing, refer to the audio product XSD or mobile product XSD.

Product updates

Products are subject to change, even after they have been distributed. The labels can (and will) push these updates to the DSPs.

There are two kinds of update deliveries. A full one consisting of a redelivery of all the delivery content - the metadata file, cover art file, and media files. Second option is metadata only update delivery where only metadata has changed and thus only the XML (and the .complete file) is sent. There is neither cover art nor any tracks or videos in a metadata only delivery.

When FUGA sends an update, it sets the action element in the metadata file to either "update" or "metadata_only" depending on the update type.

Product takedowns

Labels have the right to request you take a product down from your system. In that case FUGA sends you a delivery consisting of only the metadata file and the .complete file. There is neither cover art nor any tracks or videos in the delete request delivery. The structure is the same as for metadata only delivery, only the XML contains "delete" in the action element.

Changelog

1.7.2

1.7.1

1.7.0

1.6.7

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.0

1.5.1

1.5.0

1.4.4

1.4.2

1.4.1

1.4.0

1.3.2

1.3.1

1.3.0

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

Upgrading from 1.1 to 1.2

Why upgrade? All the files among all deliveries have now unique names which allow you to easily ingest them in one big batch. The file names also can't contain any special characters anymore and thus you will have no more problems with character sets configurations. The newly added confirmation file helps you ensure that the delivery you want to start ingesting has been fully completed. The XML is more readable and the content of important elements (genres, contributor roles) is restricted to a list of fixed values.

Upgrading from 1.0.1 to 1.2

Why upgrade? If you still use 1.0.1, you'll benefit from upgrading 1.2 a lot. Crucial territory information in the metadata, unique file names, checksum of the track files, extended ID3 tags, more information about the cover art are just a few.