Multiple Choice of Audio Formats in a Single View (Canvas)

Use Case

You have an audio resource in multiple file formats and/or sound qualities and you want to allow viewers or other software components the ability to present the appropriate files to a listener.

Implementation Notes

This recipe is structurally very similar to the Image Choice recipe, though with a different rationale and different expected outcomes. Where that recipe presented multiple images of the same object, registered against each other, audio choice emerges more frequently from accommodating format compatibility issues in web software. Therefore, there is also a conceptual difference between these two recipes in the notion of choice. In the Image Choice recipe, as there are no format differences in the images, the viewer will not encounter handling capability differences. The choice belongs only to the manifest creator and the user. In this recipe, on the other hand, the resources vary in format, which can affect the viewer’s ability to play a resource. Consequently, the choice is shared among the viewer, the manifest creator, and the user.

In the manifest, the central Annotation’s body is a resource with a type of choice. Each resource in the items property is instead the media to be presented. This structure is defined in the W3C Web Annotation Data Model:

“A Choice has an ordered list of resources from which an application should select only one to process or display. The order is given from the most preferable to least preferable, according to the Annotation’s creator or publisher.” — from Choice Between Bodies

Understanding that not all file formats are playable in all viewers or, as relevant, all browsers, the viewer is expected to present for playing the first audio file it is capable of playing. Viewers should use the format property of each resource option to determine which option to present to start or as a default.

Developers of viewers or other consuming clients need to understand that the intent is to offer the user a choice between 2 or more sound formats, which the user may switch between at will. Publishers can order the audio files by preference, but the file with which a viewer starts cannot be assured.

Restrictions

No known restrictions.

Example

This manifest uses a short excerpt from a 14-minute reel-to-reel recording of music from Kabba Division, Kwara State, Nigeria in the 1980s. From the web version in UCLA’s digital library, it was transcoded into 6 different containers and codecs of varying commonness. The first option is highly unlikely to play in any web browser and the second is highly likely to play in any web browser, so it is expected that viewers will select the second option by default. Other options are provided for cookbook readers to see how viewers handle further options and other formats. Since the sound content is the same for each file, a computer-voiced format tag has been added to the start of each file for differentiation. This would not be included in a real-world implementation.

In practice, current viewers react with the manifest in a range of ways, with some failing more gracefully than others when they encounter a format they cannot play. Some only try to play the first one or two choices, while others will try to play or offer the visitor to try to play any of the resources in the manifest.

Sound recorded by Institute of African Studies of the University of Ibadan, at Kabba Division, Kwara State between 1980 and 1990. The archival version is at the Archive of Sound and Vision at the IAS. For more information, contact unibadanias60@gmail.com.

Soundfile from UCLA Library Archives of Sound and Vision, Institute of African Studies, University of Ibadan

JSON-LD | View in Mirador | View in Universal Viewer | View in Clover | View in Ramp | View in Theseus




The direct link to the fixture is a useful convenience.