TAG review of Audiobooks

[hober]

Hi,

As requested, the TAG took a look at the Audiobooks explainer & discussed it during our telcon this week. We haven't completed our review but we do have a few pieces of preliminary feedback we'd like to share. We'll edit this issue with additional feedback as our review continues.

How It Works

Given that the bulk of the data in an audiobook consists of (already compressed) media files, and that HTTP responses are themselves often compressed, is zipping up the audiobook really necessary? If the purpose of zipping up the contents of the audiobook is solely bundling, and not compression, did you consider using Bundled HTTP Exchanges instead? Or tar even?

We'll comment on the choice to create a new manifest format on w3ctag/design-reviews#344 as it applies to Web Publications as a whole and not just Audiobooks. See also w3ctag/design-principles#95 and w3c/wpub#32 (comment)

Considered Alternatives

In this section, you list several alternative designs that were considered but ultimately rejected. This section lists what alternatives were considered, but not why they were rejected. We'd really like to see some text explaining the rationale for rejecting each alternative. We also thought of a couple additional alternatives that you may or may not have already considered, which we'd like to see your thoughts on:

1. Are your key use cases adequately covered by any existing media specifications, such as RFC 8216?
2. It's not a priori obvious what the difference is between an audiobook and a podcast. (Perhaps it's that you don't know beforehand how many podcast episodes there will be, but Dickens likely didn't know how many installments The Pickwick Papers would end up having either.) Each consists of "audio files, a cover image[,] supplemental material, and some metadata." Did you consider using RSS or Atom instead of a custom JSON manifest format? Does your audiobook format gracefully handle serialized publications when not all installments have been published?

Each of these alternatives are "widely used and implemented technology" that appear (to us, at first blush) to "cover[… your] particular use cases," so you should "consider specifying that technology in preference to inventing something new for the same purpose." (Do not Reinvent the Wheel, one of the HTML Design Principles)

[HadrienGardeur]

Given that the bulk of the data in an audiobook consists of (already compressed) media files, and that HTTP responses are themselves often compressed, is zipping up the audiobook really necessary?

This is necessary for our industry.

Currently, audiobooks are most of the times packaged together as MP3 in a ZIP, then pushed by a publisher to a distributor/aggregator/retailer.

There's no consistency at all for how metadata can be expressed or delivered, reading order is most of the times based on alphabetical order in the ZIP and there's no standard way for expressing a cover or a TOC either.

Having a standard manifest at a well-known location in a ZIP solves most of these problems:

• a standard and extensible way to provide metadata
• the order is explicitly defined instead of implied by a naming convention
• additional resources like a cover or HTML pages can be part of an audiobook as well (and linked from its TOC)
• a TOC can be provided through the use of HTML

While a TAR could be a good alternative to ZIP, it's not as widely used and well-known by this community. Files in a ZIP is the de-facto standard for publications that are not as clearly standardized as EPUB (CBZ for comics, MP3 files in a ZIP for audiobooks).

[llemeurfr]

The comments from the TAG are fair, coming from Web experts who have no real clue about the needs of the publishing industry. They indicate that these needs - especially the need to have not only a Web distribution format but also a B2B interchange format - have not been clearly exposed in the explainer.

Re. http live streaming (esp. DASH), such alternative to mp3 (progressive download) should IMO be explicitly promoted by this WG for Web distribution purpose. The publishing industry does not seem to have any clue about its existence and advantages and some Labs need to prototype on that.

Re. RSS/Atom, it's funny to see XML based structures coming back, where we have witnessed that browsers (and JS) are not big XML fans and we moved from the XML based EPUB to a JSON based manifest explicitly to make browsers happier.

Also, it will become useful to make Web experts aware of the OPDS 2 publishing industry standard, which is a JSON based equivalent of the Atom standard (not for listing audiobook tracks, but for listing audiobook publications).

[TzviyaSiegman]

Thanks @hober for the feedback. Thank you @HadrienGardeur and @llemeurfr for your perspective. We will take time to discuss this feedback in group sessions and our upcoming F2F. Let's keep in mind that there are many audiobook publishers, distributors, and retailers with whom we have not yet spoken and we are trying to make sure that our proposed draft meets many use cases. cc/@wareid

[laudrain]

@TzviyaSiegman I'm sure you meant @llemeurfr

[TzviyaSiegman]

Sorry @laudrain. I should be more discerning with autofill.

[hober]

Here is a strawman example of what flatland.audiopub's manifest might look like if you went with Atom instead of JSON-LD. This sample Atom feed is indistinguishable from an Atom feed that most any podcast player can consume today.

[dauwhe]

@hober wrote:

Here is a strawman example of what flatland.audiopub's manifest might look like if you went with Atom instead of JSON-LD. This sample Atom feed is indistinguishable from an Atom feed that most any podcast player can consume today.

I tweaked a few things to get something that validated and worked in my iTunes. Here's part of what I have right now:

<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en" xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd">
  <link rel="self" href="http://127.0.0.1/acme/audio/atomland.xml" type="application/atom+xml" />
  <id>tag:example.com,2019-04-01:flatland</id>
  <title>Flatland: A Romance of Many Dimensions</title>
  <author><name>Edwin Abbott Abbott</name></author>
  <contributor><name>Ruth Golding</name></contributor>
  <updated>2019-04-01T12:30:02Z</updated>
  <itunes:image href="http://127.0.0.1/acme/audio/cover.jpg" />
  <itunes:category text="Arts"/>
  <itunes:explicit>no</itunes:explicit>
  <itunes:complete>yes</itunes:complete>
  <entry> 
    <title>Part 1, Sections 1–3</title>
    <link href="http://127.0.0.1/acme/audio/flatland_1_abbott.mp3" length="21948718" type="audio/mpeg" rel="enclosure"/>
    <updated>2019-05-01T18:30:02Z</updated>
    <id>http://127.0.0.1/acme/audio/flatland_1_abbott</id>
    <link rel="alternate" type="text/html" href="toc.html" />
  </entry>
  <entry> 
    <title>Part 1, Sections 4–5</title>
    <link href="http://127.0.0.1/acme/audio/flatland_2_abbott.mp3" length="26706222" type="audio/mpeg" rel="enclosure"/>
    <updated>2019-05-02T18:30:02Z</updated>
    <id>http://127.0.0.1/acme/audio/flatland_2_abbott</id>
    <link rel="alternate" type="text/html" href="toc.html" />
  </entry>
  <entry> 
    <title>Part 1, Sections 6–7</title>
    <link href="http://127.0.0.1/acme/audio/flatland_3_abbott.mp3" length="24105262" type="audio/mpeg" rel="enclosure"/>
    <updated>2019-05-03T18:30:02Z</updated>
    <id>http://127.0.0.1/acme/audio/flatland_3_abbott</id>
    <link rel="alternate" type="text/html" href="toc.html" />
  </entry>
</feed> 

I do like this idea in general. Feed validation was a little weird, as it demands the rel=alternate link when there's no content element. I wonder if there's a cleaner way to express this in Atom.

Would RSS be as good as Atom for this use case? It seems rather more common in the podcasting world, at least.

[llemeurfr]

@dauwhe, what is the layout of such an Atom feed in iTunes? Isn't the audio book represented as a Channel, and each track of the feed as an Episode in this Channel, with its own download button, no possibility to have an automatic move from one Episode to the next?
What if audio tracks don't correspond to chapters?
How could such a solution deal with the requirement for modern audiobooks to get a hierarchical ToC?
... Atom / RSS feeds are great for representing series of articles / episodes or collections of books (OPDS). IMHO it's a kind of abuse to use them to stitch together chapters of a single book.

Also, wouldn't such a solution defeat the chance of getting a convergent format for textual-first, audio and visual Web Publications?

And what would be web developers' reaction if client side JS code was asked to process an XML structure in 2019 :-) ? (no pun intended for web developers)

[dauwhe]

@llemeurfr I'm not implying that the existing iTunes interface is adequate. But using a format that already has wide adoption in a very similar space is worth exploring.

Also, wouldn't such a solution defeat the chance of getting a convergent format for textual-first, audio and visual Web Publications?

Convergence is a secondary goal—one that might emerge if we discover commonalities among our use cases—but shouldn't drive our thinking. And it has many dimensions. Convergence between audio books and podcasts seems in some sense more natural than convergence between audio books and reflowable EPUBs, for example. Some of our use cases are very web-centric while others happen mostly apart from the web.

And what would be web developers' reaction if client side JS code was asked to process an XML structure in 2019 :-) ? (no pun intended for web developers)

Web developers already process a SGML-derived markup language every day :)

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

#417: TAG review of Audiobooks, RSS
endyreid: https://github.com/w3c/wpub/issues/417
Wendy Reid: the TAG and Tess was asking about RSS
… it’s a good question… it’s not a bad idea for audiobooks
… it works well for podcasts
… the best argument I have for not including it is that publishers won’t do it
… but that’s not a great answer
… Tess and I are still talking
… but we’re not using it in our spec
… and we’re still talking to the TAG