Audio TF Meeting #6 — Minutes
Date: 14 December 2018
See also the IRC Log
Attendees
Present: Tzviya Siegman, Benjamin Young, Ivan Herman, Laurent Le Meur, Dave Cramer, Zheng Xu (Jeff), Gregorio Pellegrino, Wendy Reid, George Kerscher, Avneesh Singh, Deborah Kaplan, Luc Audrain, Brady Duga
Regrets: Daniel Weck, Garth Conboy
Guests:
Chair: Wendy Reid
Scribe(s): Dave Cramer
Content:
1. Packaging format
Wendy Reid: howdy
… thanks for coming on short notice. We’ve had a lot of conversations on email and github
Wendy Reid: https://github.com/w3c/wpub/wiki/Packaging-for-WP-Audiobooks
Wendy Reid: I created a wiki page for packaging
Dave Cramer: A lot of this was thrown together quickly and I would encourage others to edit and provide suggestions for how to make it more helpful. This is the 5 parsec view
Ivan Herman: there should be one more row
… how difficult would it be for a community to transition to a particular format?
Wendy Reid: perhaps today we can discuss this, as we are still fresh from Monday’s meeting?
Laurent Le Meur: I did a summary of OCF solution, dividing into the 3
… we could take OCF 3.2, and remove everything in it that has to do with EPUB, META-INF, file extension, and mime-type
… the end result is that there would be almost nothing left
… we’d need another doc for the well-known locations for index and manifest
… a second choice would be to extend OCF 3.2
… and to extend it for audio pub, we would have to segment it
… we use zip, we are careful about some constraints
… 2nd part would be about epub features
… 3rd part would be about audio features–well-known locations
… a common part about zip, and then a choice: EPUB or audio
… third solution is to take OCF 3.2, copy it, and in this new doc remove EPUB stuff and add Audio stuff
… a clean doc that is only for audio
Ivan Herman: I am for option 3, and the reason is that we should keep away from the impression that we redefine anything for EPUB 3
… but it will confuse a lot of people
… OCF 3.2 is part of the CG output, and we should not change it
… if we do option 3, we are clean
Avneesh Singh: +1,keep away from perception of touching EPUB 3.2
Laurent Le Meur: I agree
Tzviya Siegman: +1 ivan
Wendy Reid: it’s important to keep it separate
Laurent Le Meur: if we choose option 3, we can either replicate all the information in OCF about Unicode, or make reference to the ISO standard that adds the same constraints
… but we have to study the difference between OCF wording and the ISO wording
Ivan Herman: let’s stay on stable ground and look to EPUB’s version
Wendy Reid: +1
Laurent Le Meur: this would be easier to edit
Dave Cramer: It seems like what we are calling OCF lite has very little OCF in it
… in the days of OEB you would put the package file and content in a zip, OCF came about because of all of the other things you would want to do (encryption, obfuscation, etc)
… if we do this we have a very light implementation
… every reading system is dependent on the mimetype
Wendy Reid: I do have an answer on mimetype for Kobo
… I talked to our ingestion team
… from the app and ingestion perspective, it would be possible to not use these
… we just use it for validation
Ivan Herman: dauwhe is correct on the technical content
… I had a discussion Ralph yesterday about the admin side
… we have to be careful, in the charter of the WG it says we don’t define a packaging format, because such work is happening elsewhere
… we could say we try to use OCF for now and we need a deployment strategy
… and we could publish something as a note
… and when Web packaging comes into the picture, we’d revisit
… so we have to be careful what we call it
… using OCF-lite reminds the community we are reusing something that exist
… let sleeping dogs lie
Laurent Le Meur: two things
… re: charter, I see that this group has to create a packaged web pub and EPUB 4
… which means choosing a packaging mechanism
… I don’t see anything that forbids choosing a packaging mechanism
Ivan Herman: choosing is different than defining
… and this came up during chartering. There be dragons.
Laurent Le Meur: the other was about mimetype
… dauwhe, you tried removing
… did you try moving the mimetype?
Ivan Herman: and uncompressed
Dave Cramer: I haven’t done a test with the mimetpye in a different position, but I can … also the restriction of it being uncompressed
Laurent Le Meur: we know the only issue for zipper is that you don’t know where this files go
Ivan Herman: the uncompressing means you to run things twice
Luc Audrain: it’s not exactly the same when we sideload vs when we ingest
… and distribute
… I’m not sure that it’s exactly the same
… so the Q of mimetype is probably important for ingestion
Laurent Le Meur: Luc, when you say mimetype is important for ingestion, what do you mean? is it because of epubcheck, or is intrinsic?
Luc Audrain: if I remember the email from Brady, it said the program would not find the real EPUBs
Laurent Le Meur: if any generic ingestion mechanism takes a file, and doesn’t look at file extension, and wants to check what kind of file by introspection, then magic numbers are useful
Brady Duga: the purpose of the mimetype is not for people in this room
… we may find it useless, but it wasn’t designed for us.
… will the world end if there’s a zip without a mimetype, so that your email won’t open an audio book? No. It will just be messy.
… it’s nice to identify a file, and most files have a trivial way of recognizing them.
… zip does have the PK sig, so anything will recognize zip
… it just makes it easier for apps
… moving it doesn’t make the mime type file easier
… today you have to add it first with uncompressed flag, then add everything else
… changing the order doesn’t make things easier
… it’s still two commands
Dave Cramer: Almost all of the discussion here and in email/github has been about what we call OCF lite, but we seem to be mostly discussing it without deciding that this is the direction we are going in
… without exploring what our alternatives are
Brady Duga: in general I’m leaning towards option 3
… I think that’s what Garth wanted
… it would be ideal if we could just reference OCF, but we can’t
… it sounds like option 3 is make our own spec, taking what we want
… the biggest problem is political
… clever names might help
… like OCF-audio
… the real issue is the politics and the paperwork
Ivan Herman: what would be the difference between OCF-audio and OCF for web publications
… would the difference be zero?
… there are a number of properties that audio needs, but it’s not dependent on packaging
… is there anything special about audio that’s not true for edu?
Laurent Le Meur: we should first make a note, and then later see if we push it to rec
… for politics it would be better to make a note for audio and not for web pub
… we have a short-term use case. If we want to extend it, we can
Ivan Herman: I understand
… what we put in the note should not be audio-dependent
Brady Duga: the difference to me is whether we reference audiobooks
… we can make a generic version, that includes a mimetype for the content
… we’d be making a generic zip-based packaging format
… if we want an audio-specific format, we could include an audiobook mime type
… my understanding is that that is easier politically
… than a generic zip-based packaging format
Dave Cramer: One of my foundational concerns is that whatever solution we adopt for audio will by default become the solution for WP
… I think there is a significant difference between the audio case and the general WP case
… roughly encapsulates ideas of security and origin
… a ZIP-based WP format is going to be challenging from a security POV and gets us no further than EPUB
… and possibly worse off if we remove the proposed items from OCF
… we are in a tough position, we want something soon for audiobooks and we’re stuck waiting for the better thing that may never come
Brady Duga: +1 Dave
Tzviya Siegman: +1 dauwhe
Ivan Herman: I understand what Dave is saying
… for the time being, we work as if we are working on audio
… knowing in our hearts this could be reused
… but we know this is not an ideal solution
… then we hope we have a genuine choice in a few years
Luc Audrain: +1 as we need something now for the industry
Ivan Herman: the approach of laurent and brady is probably politically our best choice, even if not optimal
George Kerscher: how is it that we are able to do media overlays in EPUB 3, which are a combo of text and audio, but if you don’t have text why isn’t this appropriate
Ivan Herman: if we have the definition of audio and media overlays for web publications, there’s no reason we can’t use it
… marisa and friends are working on
… I don’t think it won’t work
George Kerscher: I mean the packaging aspect
Wendy Reid: you’re talking about the DAISY (and Apple) implementation of audio books in EPUB 3
… I do have this listed as an avenue in the explainer
… I don’t think it is the way it was going to work
… the companies making audio could have been doing it
George Kerscher: in the context of this discussion, it’s just about the packaging? Is it about baggage?
Wendy Reid: we’re changing a lot
George Kerscher: that helps me understand, if we’re just trying to get rid of the complexity associated with EPUB and media overlays
Dave Cramer: I think George brings up several possible things, audiobooks could happen in EPUB today with media overlays
… they could happen in EPUB with a small change adding media to spine
… we could use OCF and have the container.xml point to the manifest file, we can do all of these things
… the major objection to all of those things is that there are simpler options
… when I try to convince the audio people at Hachette to use all of these XML files they’ll look at me like I’m crazy
Brady Duga: my answer was, square peg, round hole
… trying to do this with EPUB today would be a pain
… we’d create baggage around something that wasn’t designed for audio-only
… and existing reading systems wouldn’t recognize audio-only EPUBs
… it would be a pain for both content creators and reading systems
George Kerscher: I’m happy now
Deborah Kaplan: I’m grateful to george for the clarifying questions
Wendy Reid: this is hard stuff. ask lots of questions!
Ivan Herman: the question of george also is relevant in one other aspect
… as dave said, there are other options
… what was the name of dsinger’s latest stuff? HEIF?
Laurent Le Meur: it’s a high-fidelity image format
… it’s a format for one type of media only
Dave Cramer: I think dsinger’s point is the technology of HEIF could be used to package any sort of resource including audio, video, HTML
… it’s basically an ISO -based media format that underlies the various MPEG things, we could do everything we envision with it
… I’ve been trying to learn about it and it has been difficult
Wendy Reid: I’ve reached out to dsinger to come to a WG meeting
… so hopefully he can provide an overview on this topic, because the rest of us are (cough) less than expert
… I want a resolution of some sort
… I’m not against exploring other options. OCF-audio sounds like what we’re working for
… but we can keep looking. We don’t have enough information.
… does anyone want to take on the task of defining what OCF-audio would look like?
… it would require a new issue
… clearly defining what we need for OCF-audio, so we can come back in a couple weeks with a proposal
… any volunteers?
Laurent Le Meur: I ccan make a draft of ocf-audio
… with OCF 3.2 as base
Tzviya Siegman: I will work on organizing things with dsinger
Dave Cramer: I think we have a multiplicity of options, even without making a final decision it sounds like we have rejected some options
… like OCF 3.2
… I think it’s critical that we document our decisions and explain why we’re rejecting certain approaches
… like m4b, which is an already existing format for audiobooks
Wendy Reid: I don’t think we’ve rejected m4b
… based on my limited understanding there might be issues with audio codecs
Wendy Reid: let’s document stuff in the wiki
Avneesh Singh: people do want to know why decisions are made
… we need requirements, success criteria. that should be the starting point.
Wendy Reid: excellent point. I’ll add to wiki
Laurent Le Meur: I want to say exactly that.
… maybe one issue per potential format, one entry in the wiki
… the issue means that everyone can provide their comments
Wendy Reid: we can have issues for each format, and then decisions can go in wiki
Avneesh Singh: sounds good
Wendy Reid: we’ll end a few minutes early. We’ve made progress on a difficult issue. Thanks everyone!