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

Hi,
 
I believe in the very old CEA audio book spec, there was embedding of metadata in the headers MP3 file. Certainly there were markers indicating transitions.
 
I think this approach is now outdated, and the affermation from Blackstone is good.
 
Best
George
 
From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com> 
Sent: Thursday, December 20, 2018 6:48 AM
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?