14:41:29 RRSAgent has joined #pwg-audio 14:41:29 logging to https://www.w3.org/2018/12/14-pwg-audio-irc 14:41:47 rrsagent, set log public 14:42:08 Meeting: Audio TF Meeting #6 14:42:11 Chair: wendyreid 14:42:29 Date: 14 December 2018 14:46:25 ivan has joined #pwg-audio 14:59:27 Avneesh has joined #pwg-audio 15:00:21 present+ 15:01:19 Regrets: danielweck, Garth 15:01:45 present+ 15:01:49 present+ 15:01:53 laurent_ has joined #pwg-audio 15:02:06 dauwhe has joined #pwg-audio 15:02:07 present+ 15:02:07 gpellegrino has joined #pwg-audio 15:02:11 zheng_xu has joined #pwg-audio 15:02:11 present+ 15:02:14 Zakim, who is here? 15:02:14 Present: tzviya, bigbluehat, ivan, laurent_, dauwhe 15:02:15 present+ 15:02:15 present+ 15:02:16 On IRC I see zheng_xu, gpellegrino, dauwhe, laurent_, Avneesh, ivan, RRSAgent, Zakim, tzviya, wendyreid, bigbluehat 15:02:22 present+ 15:02:28 George has joined #pwg-audio 15:02:38 scribenick: dauwhe 15:02:59 present+ George 15:03:01 present+ 15:03:05 wendyreid: howdy 15:04:05 ... thanks for coming on short notice. We've had a lot of conversations on email and github 15:04:09 https://github.com/w3c/wpub/wiki/Packaging-for-WP-Audiobooks 15:04:14 ... I created a wiki page for packaging 15:05:01 dkaplan3 has joined #pwg-audio 15:05:10 present+ 15:05:12 duga has joined #pwg-audio 15:05:33 q+ 15:06:19 dauwhe: 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 15:06:21 laudrain has joined #pwg-audio 15:06:25 ack dauwhe 15:06:27 q+ 15:06:29 present+ 15:06:35 ack ivan 15:06:41 ivan: there should be one more row 15:07:12 ... how difficult would it be for a community to transition to a particular format? 15:08:15 present+ 15:08:17 wendyreid: perhaps today we can discuss this, as we are still fresh from Monday's meeting? 15:08:39 laurent_: I did a summary of OCF solution, dividing into the 3 15:09:18 ... we could take OCF 3.2, and remove everything in it that has to do with EPUB, META-INF, file extension, and mime-type 15:09:29 ... the end result is that there would be almost nothing left 15:09:42 ... we'd need another doc for the well-known locations for index and manifest 15:09:52 ... a second choice would be to extend OCF 3.2 15:10:11 ... and to extend it for audio pub, we would have to segment it 15:10:24 ... we use zip, we are careful about some constraints 15:10:32 ... 2nd part would be about epub features 15:10:43 ... 3rd part would be about audio features--well-known locations 15:10:56 q+ 15:10:59 ... a common part about zip, and then a choice: EPUB or audio 15:11:21 ... third solution is to take OCF 3.2, copy it, and in this new doc remove EPUB stuff and add Audio stuff 15:11:29 ... a clean doc that is only for audio 15:11:35 ack ivan 15:12:03 ivan: I am for option 3, and the reason is that we should keep away from the impression that we redefine anything for EPUB 3 15:12:11 ... but it will confuse a lot of people 15:12:22 ... OCF 3.2 is part of the CG output, and we should not change it 15:12:35 ... if we do option 3, we are clean 15:12:43 +1,keep away from perception of touching EPUB 3.2 15:12:48 laurent_: I agree 15:12:48 +1 ivan 15:12:55 wendyreid: it's important to keep it separate 15:13:40 laurent_: 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 15:13:57 ... but we have to study the difference between OCF wording and the ISO wording 15:13:58 q? 15:14:27 ivan: let's stay on stable ground and look to EPUB's version 15:14:34 wendyreid: +1 15:14:40 laurent_: this would be easier to edit 15:15:07 q+ 15:15:13 q+ 15:15:15 ack dauwhe 15:15:36 dauwhe: It seems like what we are calling OCF lite has very little OCF in it 15:16:10 ... 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) 15:16:25 ... if we do this we have a very light implementation 15:16:48 ... every reading system is dependent on the mimetype 15:17:08 wendyreid: I do have an answer on mimetype for Kobo 15:17:18 ... I talked to our ingestion team 15:17:59 ... from the app and ingestion perspective, it would be possible to not use these 15:18:06 ... we just use it for validation 15:18:10 q+ 15:18:15 ack ivan 15:18:29 ivan: dauwhe is correct on the technical content 15:18:41 ... I had a discussion Ralph yesterday about the admin side 15:19:09 ... 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 15:19:23 ... we could say we try to use OCF for now and we need a deployment strategy 15:19:35 ... and we could publish something as a note 15:19:53 ... and when Web packaging comes into the picture, we'd revisit 15:20:02 ... so we have to be careful what we call it 15:20:24 ... using OCF-lite reminds the community we are reusing something that exist 15:20:29 ... let sleeping dogs lie 15:20:41 ack laurent_ 15:20:43 laurent_: two things 15:20:59 ... re: charter, I see that this group has to create a packaged web pub and EPUB 4 15:21:07 ... which means choosing a packaging mechanism 15:21:18 ... I don't see anything that forbids choosing a packaging mechanism 15:21:27 ivan: choosing is different than defining 15:21:39 ... and this came up during chartering. There be dragons. 15:21:45 laurent_: the other was about mimetype 15:21:52 ... dauwhe, you tried removing 15:22:00 q+ 15:22:05 ... did you try moving the mimetype? 15:22:17 ivan: and uncompressed 15:22:37 dauwhe: I haven't done a test with the mimetpye in a different position, but I can 15:22:47 ... also the restriction of it being uncompressed 15:22:52 laurent_: we know the only issue for zipper is that you don't know where this files go 15:22:54 q+ 15:23:07 ivan: the uncompressing means you to run things twice 15:23:08 ack laudrain 15:23:21 laudrain: it's not exactly the same when we sideload vs when we ingest 15:23:28 ... and distribute 15:23:37 ... I'm not sure that it's exactly the same 15:23:51 ... so the Q of mimetype is probably important for ingestion 15:24:02 q- 15:24:11 q+ 15:24:30 ack laurent_ 15:24:59 laurent_: Luc, when you say mimetype is important for ingestion, what do you mean? is it because of epubcheck, or is intrinsic? 15:25:14 q+ 15:25:18 laudrain: if I remember the email from Brady, it said the program would not find the real EPUBs 15:25:45 laurent_: 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 15:25:46 ack duga 15:25:57 duga: the purpose of the mimetype is not for people in this room 15:26:10 ... we may find it useless, but it wasn't designed for us. 15:26:35 ... 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. 15:26:51 ... it's nice to identify a file, and most files have a trivial way of recognizing them. 15:27:07 ... zip does have the PK sig, so anything will recognize zip 15:27:19 ... it just makes it easier for apps 15:27:33 ... moving it doesn't make the mime type file easier 15:27:47 ... today you have to add it first with uncompressed flag, then add everything else 15:27:56 ... changing the order doesn't make things easier 15:28:06 ... it's still two commands 15:28:21 q? 15:28:30 q+ 15:28:31 q+ 15:28:38 ack dauwhe 15:29:17 dauwhe: 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 15:29:30 ... without exploring what our alternatives are 15:29:32 ack duga 15:29:40 duga: in general I'm leaning towards option 3 15:29:47 ... I think that's what Garth wanted 15:30:01 ... it would be ideal if we could just reference OCF, but we can't 15:30:15 ... it sounds like option 3 is make our own spec, taking what we want 15:30:20 ... the biggest problem is political 15:30:26 ... clever names might help 15:30:31 ... like OCF-audio 15:30:55 q+ 15:31:00 ... the real issue is the politics and the paperwork 15:31:04 ack ivan 15:31:26 ivan: what would be the difference between OCF-audio and OCF for web publications 15:31:33 ... would the difference be zero? 15:31:38 q+ 15:31:52 ... there are a number of properties that audio needs, but it's not dependent on packaging 15:32:07 q+ 15:32:08 ... is there anything special about audio that's not true for edu? 15:32:08 ack laurent_ 15:32:11 q+ 15:32:22 laurent_: we should first make a note, and then later see if we push it to rec 15:32:38 ... for politics it would be better to make a note for audio and not for web pub 15:32:50 ... we have a short-term use case. If we want to extend it, we can 15:32:53 ivan: I understand 15:33:02 ack duga 15:33:03 ... what we put in the note should not be audio-dependent 15:33:14 duga: the difference to me is whether we reference audiobooks 15:33:31 ... we can make a generic version, that includes a mimetype for the content 15:33:44 ... we'd be making a generic zip-based packaging format 15:33:57 ... if we want an audio-specific format, we could include an audiobook mime type 15:34:13 ... my understanding is that that is easier politically 15:34:22 ... than a generic zip-based packaging format 15:34:22 ack dauwhe 15:34:56 dauwhe: One of my foundational concerns is that whatever solution we adopt for audio will by default become the solution for WP 15:35:12 ... I think there is a significant difference between the audio case and the general WP case 15:35:25 ... roughly encapsulates ideas of security and origin 15:35:51 ... a ZIP-based WP format is going to be challenging from a security POV and gets us no further than EPUB 15:36:03 ... and possibly worse off if we remove the proposed items from OCF 15:36:27 ... 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 15:36:28 q+ 15:36:29 q+ 15:36:33 ack ivan 15:36:36 +1 Dave 15:36:43 +1 dauwhe 15:36:46 q+ 15:36:50 ivan: I understand what Dave is saying 15:36:59 ... for the time being, we work as if we are working on audio 15:37:07 ... knowing in our hearts this could be reused 15:37:16 ... but we know this is not an ideal solution 15:37:26 ... then we hope we have a genuine choice in a few years 15:37:39 q- 15:38:02 +1 as we need something now for the industry 15:38:04 ack George 15:38:06 ... the approach of laurent and brady is probably politically our best choice, even if not optimal 15:38:45 George: 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 15:39:11 ivan: if we have the definition of audio and media overlays for web publications, there's no reason we can't use it 15:39:12 q+ 15:39:21 ... marisa and friends are working on 15:39:27 ... I don't think it won't work 15:39:29 q+ 15:39:35 George: I mean the packaging aspect 15:39:56 wendyreid: you're talking about the DAISY (and Apple) implemenation of audio books in EPUB 3 15:40:09 ... I do have this listed as an avenue in the explainer 15:40:23 ... I don't think it is the way it was going to work 15:40:39 ... the companies making audio could have been doing it 15:41:04 George: in the context of this discussion, it's just about the packaging? Is it about baggage? 15:41:06 q? 15:41:20 wendyreid: we're changing a lot 15:41:47 George: that helps me understand, if we're just trying to get rid of the complexity associated with EPUB and media overlays 15:41:56 ack dauwhe 15:42:16 dauwhe: I think George brings up several possible things, audiobooks could happen in EPUB today with media overlays 15:42:26 ... they could happen in EPUB with a small change adding media to spine 15:42:43 ... we could use OCF and have the container.xml point to the manifest file, we can do all of these things 15:43:05 ... the major objection to all of those things is that there are simpler options 15:43:30 ... 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 15:43:35 ack duga 15:43:38 duga: my answer was, square peg, round hole 15:43:46 ... trying to do this with EPUB today would be a pain 15:44:07 ... we'd create baggage around something that wasn't designed for audio-only 15:44:18 ... and existing reading systems wouldn't recognize audio-only EPUBs 15:44:31 ... it would be a pain for both content creators and reading systems 15:44:39 George: I'm happy now 15:44:57 dkaplan3: I'm grateful to george for the clarifying questions 15:45:06 wendyreid: this is hard stuff. ask lots of questions! 15:45:07 q+ 15:45:11 ack ivan 15:45:38 ivan: the question of george also is relevant in one other aspect 15:45:46 ... as dave said, there are other options 15:46:00 ... what was the name of dsinger's latest stuff? HEIF? 15:46:18 q+ 15:46:28 laurent_: it's a high-fidelity image format 15:46:34 ... it's a format for one type of media only 15:46:48 ack dauwhe 15:47:11 dauwhe: I think dsinger's point is the technology of HEIF could be used to package any sort of resource including audio, video, HTML 15:47:41 ... it's basically an ISO -based media format that underlies the various MPEG things, we could do everything we envision with it 15:48:02 ... I've been trying to learn about it and it has been difficult 15:48:19 wendyreid: I've reached out to dsinger to come to a WG meeting 15:48:47 ... so hopefully he can provide an overview on this topic, because the rest of us are (cough) less than expert 15:48:54 ... I want a resolution of some sort 15:49:14 ... I'm not against exploring other options. OCF-audio sounds like what we're working for 15:49:24 ... but we can keep looking. We don't have enough information. 15:49:37 ... does anyone want to take on the task of defining what OCF-audio would look like? 15:49:44 ... it would require a new issue 15:50:03 ... clearly defining what we need for OCF-audio, so we can come back in a couple weeks with a proposal 15:50:21 ... any volunteers? 15:50:28 laurent_: I ccan make a draft of ocf-audio 15:50:32 q+ 15:50:34 ... with OCF 3.2 as base 15:50:39 q+ 15:50:39 ack tzviya 15:50:48 tzviya: I will work on organizing things with dsinger 15:50:51 ack dauwhe 15:51:14 dauwhe: I think we have a multiplicity of options, even without making a final decision it sounds like we have rejected some options 15:51:20 ... like OCF 3.2 15:51:40 ... I think it's critical that we document our decisions and explain why we're rejecting certain approaches 15:52:04 ... like m4b, which is an already existing format for audiobooks 15:52:15 wendyreid: I don't think we've rejected m4b 15:52:58 ... based on my limited understanding there might be issues with audio codecs 15:53:04 q+ 15:53:17 q+ 15:53:35 ack Avneesh 15:53:38 wendyreid: let's document stuff in the wiki 15:53:57 Avneesh: people do want to know why decisions are made 15:54:15 ... we need requirements, success criteria. that should be the starting point. 15:54:23 wendyreid: excellent point. I'll add to wiki 15:54:23 ack laurent_ 15:54:27 laurent_: I want to say exactly that. 15:54:39 ... maybe one issue per potential format, one entry in the wiki 15:54:49 ... the issue means that everyone can provide their comments 15:55:18 wendyreid: we can have issues for each format, and then decisions can go in wiki 15:55:34 Avneesh: sounds good 15:55:52 dkaplan3 has left #pwg-audio 15:56:02 wendyreid: we'll end a few minutes early. We've made progress on a difficult issue. Thanks everyone! 15:56:12 rrsagent, draft minutes 15:56:12 I have made the request to generate https://www.w3.org/2018/12/14-pwg-audio-minutes.html ivan