scribe+
wendyreid: background of
audiobooks spec
... audiobooks were historically rooted in accessibility c.
1930s
... 70s and 80s saw mainstream adoption - e.g. listen to books
on tape in the car
... today it's a $3B industry
... use cases: continuous listening, portability, navigation,
accessibility
... current digital audio book space does not cover this
well
... there is currently no standard 😱
... what are the components? cover image, audio files, track
list, supplemental content (e.g. graphs, charts, images)
... distributors may or may not have individual content
standards. retailers also have differing requirements.
... divergence causes many problems
... from bad UX to software bugs
... small publishers shut out by proprietary channels
... indie creators need to distribute broadly
... to stay afloat
<dauwhe> repo: https://github.com/w3c/audiobooks/
<dauwhe> spec: https://w3c.github.io/audiobooks/
wendyreid: having a single
audiobooks format based on the modern web platform would solve
many of these issues
... including a better user experience
<scribe> ... new use cases: variety of non-audio supplemental content, table of contents, synchronized media (text + audio rendered simultaneously), packaging for file exchange and download
UNKNOWN_SPEAKER: we have 2 specs:
pub-manifest and audiobooks profile
... pub-manifest contains resource list and reading order and
metadata
... pub-manifest format is JSON-LD
... metadata comes from schema.org
... publishing industry has strong feelings about existing
metadata standards that they use - we are not interfering with
that
... packaging comes from LPF community group
... sync media comes from sync media in publications community
group
https://github.com/w3c/sync-media-pub/
scribe: feedback welcome
... CR coming at the end of this month
... audiobooks uses the same structural format as pub-manifest
and adding audiobook specific needs
... an audiobook is a pub-manifest but not necessarily vice
versa
<Zakim> Alan, you wanted to ask about the ecosystem
Alan: business perspective - who do we need to involve in the convo who's not here
wendyreid: we are looking at both
UAs that want to support that; also looking at content creators
who want to create in this format and who can put pressure on
distribution channels
... has to come from both directions
duga: audiobook publishers have
tables of contents that are rich and stored in excel files; not
delivered or used by anyone
... it represents a lot of work to create this sort of
file
... a format that is better for exchange and distribution
should be attractive to them
dauwhe: complex business
situation - the costs of the lack of standards are often not
borne by the publishers themselves
... e.g. publisher may send raw materials to intermediary who
does all the work
... but the publisher may not feel the pain; also, the
intermediary is benefitting monetarily from this flow
james: portability across
platforms is interesting
... can you read a book on one platform and then find your
place in the same book on a different one?
wendyreid: this falls under
addressability
... bookmarking is one of our more complicated issues
dauwhe_: this is a very
complicated problem across the web
... e.g. sync desktop and mobile versions of apps
... privacy considerations
... (do i want the different platforms to know that i'm the
same person?)
james: store user info in manifest? UAs would have to have write access
wendyreid: schema.org might have a property that could represent this
james: is anything editable by UAs?
duga: we don't include user data in the file
wendyreid: this is v1.0 - want to keep simple and extensible - leaving room for future versions
Alan: any pushback that 1.0 is not a good starting point?
wendyreid: no pushback re
starting point
... we are adding some features already (supplemental content,
sync media)
... we had to find a balance between what is acceptable for a
change-resistant industry and ease of understanding
Markus: who are the interested implementors
wendyreid: collibrio reader in europe is implementing, some publishers are showing interest
Markus: any validator?
wendyreid: no but we have epubcheck
laurent: audio studios would
benefit from a single format
... table of contents is a new idea for audio studios
... so they will save some time with a single format but
covering new concepts will cost some time
... readium foundation is also implementing on all our
toolkits
... so there will be an open source toolkit for UAs
dauwhe_: this was largely
designed to meet a use case of b2b exchange
... publishers providing audio books to distributors +
retailers
... not really a web use case
laurent: disagree; librivox as
25000 audio books
... free of use, on the web
... uses a JSON manifest
... issue on the web is that the main distributors (e.g. apple,
kobo) is that it's vertical / walled garden
... indie publishers will benefit from this standard
wendyreid: we could use more browser attention. no indication that what we're doing is web-incompatible. dream: open an audiobook directly in a browser.
dauwhe_: bundled exchanges may mean that we're closer than we think to browser adoption
wendyreid: being super cutting
edge can scare off publishers
... publishing industry is 100s of years old and rather slow
moving
... we are incrementally pushing them towards the future
james: making this more webby -
new APIs could help - such as the one that opens a file
extension in an associated app - what's it called -
FileHandlingApi
... lots of tech coming out that will be of use when it's
ready
... as a user i prefer an app to entering a URL and logging
in
wendyreid: content licensing can
be an issue, e.g. audible are the only ones who has handmaid's
tale; kobo has the sequel
... bad portability between services
laurent: DRM
room: shh!
sander: any barriers to including certain things in the book?
wendyreid: we've left it flexible
james: what about podcasts?
wendyreid: this has come up as a
use case
... similar to audiobook use case
... could bring many improvements to podcasts (lang, narrators,
structure)
... we have not found a good standard format for podcasts. most
use RSS.
... no podcasters have joined us ðŸ˜
<wendyreid> marisa: I think that that would be a great audiobook creation tool
<wendyreid> ... translating a list of audio clips into the profile would not be rocket science, speaking as a developer
dauwhe_: is the mapping relatively simple between RSS and audiobook profile?
wendyreid: suspect so but more research is required
Bert: what would be the mime type?
wendyreid: lives in pub-manifest. audiobooks uses this plus has type: AudioBook
Markus: if I did want to link to an audio book, would i link to the zip package or the manifest? can it live on its own (not in a zip package)?
wendyreid: yes it does not have
to be in a package
... manifest JSON is the starting point for the publication
laurent: primary entry page can be HTML, can be helpful as a starting point
<wendyreid> https://www.w3.org/TR/pub-manifest/
<wendyreid> https://www.w3.org/TR/audiobooks/
<dauwhe_> dauwhe: i just built an experimental audiobook, using the x-playlist custom element in an html file that also has an embedded publication manifest. It was turned into a bundled exchange. Theoretically, a future version of chrome would allow you to double-click this and open the audio book
wendyreid: please check out our work, we welcome feedback!
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/???/Markus/g Succeeded: s/standar/standard/ Succeeded: s/develoepr/developer/ Present: AlanB toshiakikoike Yanni jkamata Bert Bos JohnRochford No ScribeNick specified. Guessing ScribeNick: marisa Inferring Scribes: marisa WARNING: No "Topic:" lines found. WARNING: Could not parse date. Unknown month name "09": 2019-09-18 Format should be like "Date: 31 Jan 2004" WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: WARNING: No "Topic: ..." lines found! Resulting HTML may have an empty (invalid) <ol>...</ol>. Explanation: "Topic: ..." lines are used to indicate the start of new discussion topics or agenda items, such as: <dbooth> Topic: Review of Amy's report WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]