Re: [AudioTF] Some helpful comments from an audio publisher

> It may be true for audio books, but the examples I have seen at the Manga workshop in Tokyo does suggest that a Web deployment of manga is certainly of a great interest.
Sure, I'm not meaning to suggest web pubs can't work, only that we've seen what happens in epub when there are fundamental requirements that are intractable to each format (e.g., the long and contentious arguments we've had over images in spine without fallbacks in epub).
If the audio format has to be lightweight for distribution (html is out), forcing a compromise to make it a web pub likely doesn't lead to the intended outcome of widespread adoption (or that's how I've seen this play out before). It would be better, imho, to develop the format as it needs to be for its intended use and then determine if complete compatibility remains or is possible.
But that's just my observation, so I'll leave it to those more invested in realizing this format to decide what compromises they can and can't live with.
 Matt

Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Ivan Herman <ivan@w3.org> Date: 2018-12-28  5:04 AM  (GMT-05:00) To: Matt Garrish <matt.garrish@gmail.com> Cc: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>, Wendy Reid <wendy.reid@rakuten.com>, W3C Publishing Working Group <public-publ-wg@w3.org> Subject: Re: [AudioTF] Some helpful comments from an audio publisher 


On 22 Dec 2018, at 11:20, Matt Garrish <matt.garrish@gmail.com> wrote:
> I should be allowed to create a Web Audio Publication, using a HTML PEP with the ToC in it, package it, and call it a bona fide audio book. Call me jaded, but we’ve gone down this road before with EPUB trying to make it the format for manga/comics and magazines (that immediately spring to mind), and it didn’t succeed. I’m not getting the impression that web deployment of audiobooks as web publications is a primary concern, so forcing compromises that makes them conforming may not be the best way to tackle the problem for either format.
It may be true for audio books, but the examples I have seen at the Manga workshop in Tokyo does suggest that a Web deployment of manga is certainly of a great interest. One the other hand, we did agree (and Lauren's submission goes in this direction[1]) that the packaging solution we would use should be general and not restricted to audio books.
Ivan

[1] https://github.com/w3c/pwpub/pulls

 I’d only aim for easy translation if it better meets the needs of the people who will actually be deploying/consuming the audiobooks, otherwise we’re likely just going to walk the same path again. Matt From: Ivan Herman <ivan@w3.org> 
Sent: December 22, 2018 04:18
To: Matt Garrish <matt.garrish@gmail.com>
Cc: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>; Wendy Reid <wendy.reid@rakuten.com>; W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: [AudioTF] Some helpful comments from an audio publisher If we go down that line, we should somehow (not sure exactly how) make a very strict separation in this respect between a packaged and non-packaged version of the book. I would hate to then go the next step to essentially introduce these into a non-packaged, Web version of an audiobook, ie, that the Web URI of the audio book would then lead to… I guess the manifest as a separate JSON file, with no HTML entry page at all. We would open up a can of worm if we did so (origin, vanilla browser, Web architecture, etc, etc). Also: this should be optional. I should be allowed to create a Web Audio Publication, using a HTML PEP with the ToC in it, package it, and call it a bona fide audio book. In other words, audio user agents should be capable of processing both forms, and it would be _possible_ for a publisher/author to go the simpler way.

On 21 Dec 2018, at 21:40, Matt Garrish <matt.garrish@gmail.com> wrote: > I've seen discussions about forcing an audiobook to have an entry page (even if it doesn't need one) and the issue about the ToC in JSON is still open. It does beg the question whether we keep trying too hard to make one format to rule them all, at the expense of simplicity where it’s needed? Would an audiobook format that is the same as a WPUB in all aspects except the address/entry page/toc be such a bad thing, if those who want it to be capable of being both can just add in the optional pieces? With the exception of the address, it also seems pretty simple to write a program that could process such audiobook to add an html page with an embedded toc. Matt From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com> 
Sent: December 20, 2018 09:48
To: Reid, Wendy <wendy.reid@rakuten.com>
Cc: W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: [AudioTF] Some helpful comments from an audio publisher Well, this feedback is almost completely aligned with what was proposed in the first comment of the issue: https://github.com/w3c/wpub/issues/352 There's a very strong anti-M4B feeling, which I'm not really surprised about. Some additional feedback though: Avoid HTML. Seriously. Same for XML. Let the applications (and there will need to be application support) read and render the JSON data I don't think we've solved this issue entirely. I've seen discussions about forcing an audiobook to have an entry page (even if it doesn't need one) and the issue about the ToC in JSON is still open. Store metadata in a manifest file, not in the audio I'm not entirely sure what that means. In our case, metadata about the publication are in the manifest but metadata about audio resources are in the resource. This potentially goes back to https://github.com/w3c/wpub/issues/229 Array items can be hashes, containing *anything*. This is where I would include file hashes, runtimes, and anything specific to the display of the file (font, format, label, etc etc) We don't have a way to indicate the hash of a resource currently. Is it worth considering?  
----
Ivan Herman, W3C 
Publishing@W3C Technical LeadHome: http://www.w3.org/People/Ivan/
mobile: +31-641044153ORCID ID: https://orcid.org/0000-0003-0782-2704


----
Ivan Herman, W3C 
Publishing@W3C Technical LeadHome: http://www.w3.org/People/Ivan/
mobile: +31-641044153ORCID ID: https://orcid.org/0000-0003-0782-2704