The Audio SP assumes that a PROXY_MP3 derivative needs to be generated for JWPlayer, but this isn't the case for all repositories. In cases where the original OBJ uploaded to the repository is perfectly fine for playing in the JWPlayer, deriving and storing a PROXY_MP3 represents unnecessary space and computation power being used up server-side.
We should make it so that, optionally, the Audio SP will attempt to load the OBJ into the player if the PROXY_MP3 isn't present.
Addendum: I say 'JWPlayer' a lot here, but realistically, the only important thing is mime type; JWPlayer uses the native abilities of the browser to play audio files, so as long as it can be played in JWPlayer, it should also be able to be played in other players, should one make the switch away from JWPlayer in the future.
Instead of raw, uncompressed archival audio files like WAVs, the audio files an institution wishes to deposit are already compressed MP3s that are suitable for playing by an end user in the JWPlayer.
In this case, compressing a second PROXY_MP3 wastes computation time and energy, and storing it wastes server space and creates unnecessary additional relationships in Fedora.
On the user end, this will involve checking off an option in the admin form to allow fallback to OBJ files.
On the back end, this would involve determining the status of that option, as well as determining whether or not the OBJ is suitable for playback (e.g., looking at the mimetype).
This should be tested against a bunch of differently-constructed MP3 files. Currently, we run all audio through LAME, which means that we kind of curate the makeup of MP3 files that get sent to the player. We should try to make sure that the solution in place to determine whether or not an OBJ is playable is suitable.
This should also be tested across all popular browsers, including mobile.
If what is mentioned in the test case isn't thoroughly tested, we could be sending unsuitable files off to the player, which could result in any number of things ending in a poor user experience.
discoverygarden inc. | Managing Digital Content