List of recommended audio formats for audio-only WP

[avneeshsingh]

In EPUB 3 we had notion of core media types. I think that we should not try to restrict audio-only WP in such a way. At the same time it is also true that support for various audio formats vary from browser to browser. So, to help publishers in producing audio publications that work well with popular browsers, we should come up with a list of recommended audio formats for audio-only WP.

[llemeurfr]

Note: a browser compatibility list for audio formats can be found at

https://caniuse.com/#feat=audio (look at sub-features, add https://caniuse.com/#search=webm)

Seems that today, MP3 (low quality), AAC (flexible) and FLAC (lossless) have proper support in most browsers. Not really true for Ogg-vorbis and WebM-vorbis so far.

I also found:

https://developer.mozilla.org/en-US/docs/Web/HTML/Supported_media_formats#Browser_compatibility

https://developer.mozilla.org/en-US/docs/Web/Apps/Fundamentals/Audio_and_video_delivery/Cross-browser_audio_basics#Audio_Codec_Support

[lloydrasmussen]

If you search CanIUse.com for Opus, the support looks a little better. This audio codec is supported by enough web browsers and operating systems that it should be considered, especially in situations where file size and transport/storage requirements are important.

[llemeurfr]

@lloydrasmussen, yes Opus is streamable and supported by Firefox, Chrome, Edge. The missing kid is Safari (I just tried http://opus-codec.org/examples/, see "Example of use in a web page"). But still it can be a recommended format.

I agree that we should not try to keep "core media type", i.e. imposed fallbacks, but rather recommend media types compatible with Web usage. I would prefer if it was expressed via articles (best practices, some evolution of "EPUB Secrets") rather than in the WP spec.

[HadrienGardeur]

Opus is a great fit for voice and audiobooks, it should definitely be on our list.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions
  View the transcript

  Ivan Herman: link: Issue 323
  Wendy Reid: the other issue is bitrate and format
  … there’s a secondary issue, #323, logged by Avneesh
  … there are innumerable ways to encode audio…mp3, flac, opus, etc
  … and many different bitrates
  … in EPUB 3 we had the idea of core media types
  … with WP, do we want to express recommended media types, more best-practices?
  Ivan Herman: what does HTML say about the audio element, in terms of bitrate and format?
  … we should should push the corpse into someone else’s courtyard
  Avneesh Singh: audio element in HTML accepts a broad set of formats
  … but popular browsers may use a smaller set
  … we should not restrict WP in the way we restricted EPUB
  … we should not have core media types
  … but we do need to recommend formats for audio publishers which will actually work
  … the only question is how to present this information? It could be in a non-normative document
  … note I’m not mentioning EPUB4 here
  George Kerscher: there are issues where human audio is in a smaller bandwidth than music
  … so some formats are better for human audio
  … and variable bitrates can make it more difficult to seek to a particular place
  … and the available of time scale modification, to speed up or slow down without changing pitch
  Wendy Reid: by identifiying use cases maybe we can find some recommendations
  Benjamin Young: this is HTML’s section on mime types, which is more generous than what you’d find in EPUB
  … this also allows for innovation and progress, because it is not restrictive
  … let’s keep the web in web publications :)
  Joshua Pyle: looking at George’s use cases for seeking and time scale modification… do we have these use cases? Should we add them to the general use cases doc?
  Wendy Reid: we should have audio-specific use cases
  Ivan Herman: one more source to look at…
  … there are two related groups at W3C
  … there’s the audio working group
  … but what might be more interesting is the media and entertainment interest group
  … it grew out of webtv but went beyond that
  … at the Tokyo workshop the team contact was there, and I tried to convince him to join our F2F meeting
  … so we could talk to him there
  … I think we already discussed that we would not have a restriction on web publications–whatever works on the web works for us
  Wendy Reid: some of these issues could be cleared up by use cases. We’ll discuss in the task force.
  

[geoffjukes]

Blackstone is evaluating Opus for it's lossy archive format (replacing AAC). We use FLAC for the lossless archive format.

[wareid]

PROPOSAL: The Audiobooks profile will not include a recommended list of audio formats for audiobooks. We will leave this in the hands of the content creators.

[geoffjukes]

Ever heard of ALS audio? No? There is exactly ONE implementation for encoding it.... and the Library of Congress chose it as their lossless archive format.

@wareid I agree with not being overly prescriptive here, but my concern is that if it is left too open, a publisher might go nuts. Some guidance could help. Would it be reasonable to "Recommend audio formats supported by HTML5 Audio" or something?

https://en.wikipedia.org/wiki/HTML5_audio

[llemeurfr]

It may be a community best practice document instead of a WG list, if the latter seems too much prescriptive, but there is definitely a need to express that mp3 is not the ultimate audio format, forever.

[avneeshsingh]

There are many audio formats in the world, so I think that providing some guidance is important to help publishers in identification of audio formats that have wider acceptance. I would propose maintaining a non-normative list that can be updated frequently. It may be a separate document referenced by audio pub specs.

[iherman]

I would be wary of setting up our own list... such lists, if not correctly maintained, become a hurdle eventually. Falling back on an existing community effort would be much better imho.

I am not familiar with this world; @geoffjukes is the wikipedia article you referred to (https://en.wikipedia.org/wiki/HTML5_audio) an authoritative source in this community? It was last edited a few weeks ago, which is a good sign. On the other hand, I did not find any reference to it (or to anywhere else) in the html spec (but I may have missed it).

[avneeshsingh]

@iherman , the main objective behind having a non-normative document linked from specs is to ensure its visibility. Separate documents are difficult to find. If we can ensure that one can easily locate best practices document it is fine. May be we should have links to such documents in introduction section of specs, or may be at some other place where these are clearly visible.

[geoffjukes]

@iherman Not my area of expertise either, though I did find this: https://www.w3.org/wiki/Html/Elements/audio#Formats_and_Codecs

Which itself references the Wikipedia page.

[wareid]

I think an accompanying "Best Practices" document is in the works here ;). I agree we should offer some guidelines, maybe that is the best way. It will certainly be a lot easier to keep up to date, and we can work with publishers/distributors to communicate the latest in recommendations or support. I just think for the spec we're being too prescriptive.

[wareid]

RESOLVED: The Audiobooks profile will not include a recommended list of audio formats for audiobooks. We will leave this in the hands of the content creators. We will reference the supported formats from HTML5's

[iherman]

This issue was discussed in a meeting.

• RESOLVED: The Audiobooks profile will not include a recommended list of audio formats for audiobooks. We will leave this in the hands of the content creators. We will recommend the list of supported types under HTML5 <audio> specifications.
  View the transcript

  1.3. Issue #323: List of recommended audio formats for audio-only WP
  Wendy Reid: https://github.com/w3c/wpub/issues/323
  Wendy Reid: this is about recommend formats for audiobooks
  … we plan to leave this in the hands of content creators
  … as discussed in the issue, by making this decisions
  … we also intend to point to something we can keep up to date
  Proposed resolution: The Audiobooks profile will not include a recommended list of audio formats for audiobooks. We will leave this in the hands of the content creators. (Wendy Reid)
  Wendy Reid: but we don’t want to prescribe what the industry is probably already doing for themselves
  Dave Cramer: one of the reasons we have specs at all is to facilitate interoperability
  … if I create something that follows the spec, then I can have some expectation that a supporting client can handle it
  … I fear we’re bypassing interoperability here
  … if I make one using MP3, then do I risk it not being useful in some of the readers?
  … am I then required to read all the docs of all the readers to figure it out?
  Wendy Reid: I think that’s why we’re hoping to have a living list of formats that we keep up to date long term
  … for instance, opus which is widely supported, but not supported by everyone would everywhere
  … but we don’t want to limit it
  Tzviya Siegman: I did like Geoff’s suggestion on github
  … limiting audio (and eventually video) to those things supported by the <audio> (and