Standardize audio file types (extensions)

[obulat]

Based on the discussion in the PR adding Download button to Audio single result page.

We currently don't have a standard for audio file types and extension across the repositories.

The audio database in the catalog includes columns for url[for download and playback on the frontend] and filetype for the main audio file, as well as a JSON alt_files column with an array of different formats available for the same file. The information that is currently saved in the following shape:

alt_files: {
        'url': download_url,
        'format': filetype,
        'filesize': filesize_in_bytes?,
        'bit_rate': bitrate,
        'sample_rate': samplerate,
}

On the front end, we need to join the information for the main file (file type, size, download url) with the information for alternative files (file type, size and download url) to show the Download button. Here, we also need to convert the technical filetype name into a user-friendly label text (eg. mp31 from Jamendo's 96kbs mp3 file becomes MP3 96kbs).

Another point: do we want to display {filetype} {bitrate} for the filetype on the frontend, or something else? What if the bitrate is not available?

For context, here are the file types available for the providers we are currently working on integrating:
Jamendo: mp31 (96kbs), mp32 (VBR, good quality), ogg, flac
Wikimedia: mid, flac, wav, mp3, ogg
Freesound: wav, aif, aiff, mp3, m4a, flac

What is the best way of encoding mp3 format in our database?
Jamendo's distinction between 96kbs mp3 and a VBR mp3 complicates this as we either need to introduce two mp3 formats, and select which of them to apply to the generic mp3 format from other providers, or keep the single mp3, and rely on the bit_rate column to create the distinction on the front end. Which probably means that we need to set the bit_rate column type to string and have VBR as an option there.

[dhruvkb]

Linking the API PR that somewhat relates to this: WordPress/openverse-api#266.

[zackkrida]

My thought is that we come up with a standardized list of formats, skip bitrate, and show people our 'pretty' names and the filesize. I think the fileformat gives enough assurance for most users and is the easiest for us to implement.

We can use the bitrate as an input to determine which pretty name to use, but I don't think we need to display it.

[zackkrida]

oh sorry, i think we could treat mp3 V0 and mp3 320 as two types of mp3. i know that's technically the bitrates displayed, but these are such common bitrates that they've become sort of genericized defacto file names.

[AetherUnbound]

Would mp3 (compressed) (for the 96kbs) and mp3 (high quality) "pretty" names work?

[krysal]

One option could be to only show the highest quality file of each format

[obulat]

Do you mean Varying Bit Rate (VBR) by mp3 V0?

[zackkrida]

yes, V0 is a very common nickname for variable bitrate

[sarayourfriend]

I think a mapping of filetype to human readable that's been suggested would be fine... but we should segment it by provider, which means there will inevitably be a lot of repetition. I think we should do this because Jamendo is likely not the only provider that has multiple MP3 bitrates and if they all used mp31/mp32 but had different bit rates for each one then the keys would clash.

On the other hand, we could do the mapping of { [providerName]: { [filetype]: humanReadableText } } and then if the provider + filetype key doesn't exist we can just do filetype.toUpperCase() as that's what it would be most of the time (flac, ogg, a single mp3 filetype for example)...

[dhruvkb]

👍 for only maintaining the readable mapping in case of overrides. The default should just be to uppercase the extension.