Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Migration of unmigrated content due to installation of a new plugin

One Binary for each Resource Composite

To indicate that a binary (a.k.a. Resource file such as an AAC-encoded sound recording) is being communicated as part of a Release delivery, the Message Sender needs to provide a TechnicalSoundRecordingDetails composite for the relevant Resource. Conversely, the absence of a TechnicalSoundRecordingDetails composite for a specific Resource indicates to the recipient, that no binary is being delivered at this stage. The most typical case for this is an update to a previously sent NewReleaseMessage.

Float
border0
sideright
width33%
Excerpt
Info
titlePrimary and Secondary Resources

DDEX distinguishes between "primary" and "secondary" Resources.

The former are  "Resources that are a main Resource of a Release" whereas the latter are "Resources that are not a main Resource of a Release supporting the Primary Resources (examples are lyrics, cover art etc)". Whether a Resource is deemed to be primary or secondary for a given Release is communicated in the ResourceGroup with the appropriate flag.

However, to simplify the processing, DDEX has agreed rules as to what binaries can be communicated and/or omitted under which circumstances. These rules are as follows:

  • Typically, a first NewReleaseMessage about a new Release would contain all primary and secondary binaries. Therefore all Resource composites would contain one TechnicalSoundRecordingDetails composite each;
  • It is permissible that a Release delivery does not contain any binaries; in that case, the NewReleaseMessage must not contain any TechnicalSoundRecordingDetails composites either;
  • If, however, a binary for a primary Resource needs communicating (e.g. because it was corrupt in an earlier delivery), binaries for all primary Resources must be be communicated; it is not necessary to also communicate binaries for secondary resources in this case; and
  • If a binary for a secondary Resource needs communicating, binaries for all secondary Resources must also be communicated; it is not necessary to communicate binaries for primary resources in this case.

This approach has been chosen to simplify implementations – it is acknowledged that this approach may lead to an increased amount of  data to be transferred.

Multiple Resource Files for each Resource Composite

It is possible, that more than one binary needs providing for a single Resource composite. This allows offerings with different sound quality levels or with DRM-protected and unprotected files for a single Release.

To indicate that multiple binaries are communicated for for a single Resource, the Message Sender must provide  one TechnicalSoundRecordingDetails composite for each binary. Thus a delivery of a Release with ten sound recordings plus one image, where all sound recordings are provided in (lossy compressed) MP3 and (losslessly compressed) FLAC, would contain of 2*10+1 = 21 binaries.

The above rules about sending binaries to all primary Resources when one primary Resource needs to be communicated is still in force and needs extending:

  • If a binary for a primary Resource needs communicating, all binaries for all primary Resources must be be communicated; it is not necessary to also communicate binaries for secondary resources in this case; and
  • If a binary for a secondary Resource needs communicating, all binaries for all secondary Resources must also be communicated; it is not necessary to communicate binaries for primary resources in this case.

The same rule applies to secondary Resources.