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
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:
NewReleaseMessageabout a new Release would contain all primary and secondary binaries. Therefore all
Resourcecomposites would contain one
NewReleaseMessagemust not contain any
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.
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:
The same rule applies to secondary Resources.