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

@daniel, YAML may be great (for config files especially) but I would hate a requirement to transform a YAML manifest (in a package) to a JSON manifest for exposure on the Web. The extra features of YAML aren't enough IMO to accept such burden. 

As for the other comments from Blackstone, they are all going in the same direction we are taking. A simple zipped based packaging for a manifest (representing metadata + reading order) + audio files. 

The presence of "extra" resources (PDF for the booklet, JPEG for the cover) will be explicitly granted via "resources" in the manifest. 

Cordialement, 

Laurent Le Meur
EDRLab

> Le 20 déc. 2018 à 00:37, Daniel Weck <daniel.weck@gmail.com> a écrit :
> 
> Useful feedback.
> YAML is great, I also use CSON in some projects where JSON would otherwise suck as a human-authored format (because of the lack of comments, multiline strings etc.). That being said, this then needs to be converted to JSON so web browsers / JavaScript can consume it directly.
> Daniel 
> 
> On Wed, 19 Dec 2018, 19:32 Reid, Wendy <wendy.reid@rakuten.com <mailto:wendy.reid@rakuten.com> wrote:
> Hi everyone,
> 
>  
> 
> I had the opportunity to speak to someone from Blackstone (for those who are not familiar with the company, they are a producer and distributor of audiobooks). I outlined the work we have done so far and shared links to our GitHub, and in reply he provided some really good feedback I wanted to share with everyone else. There’s a lot, and please remember he is not a member so this is a completely fresh take on our work, but I think his feedback is very interesting and I hope others find it of use. 
> 
>  
> 
> Some thoughts right off the bat are:
> 
>  
> 
> 1.  Audiobooks are VERY simple. Try not to let anyone over-complicate them.
> 
> a.  Audio files
> 
> b.  Maybe a PDF (or other simple file type – jpg, txt etc)
> 
> c.  What order to play/display them
> 
> d.  How to display them
> 
> 2.  Do not mix the packaging of the “book” with the packaging of the “audio”. This is the mistake they made with m4b’s.
> 
> a.  Store files AS files
> 
> b.  AAC audio should be preferred IMO
> 
> c.  Store metadata in a manifest file, not in the audio
> 
> d.  The packaging file defines the contents, not the files it contains.
> 
> 3.  Use a standard format for the container. But don’t let the container drive the specification.
> 
> a.  The topic of DRM (whilst out of scope) gets *much* simpler if it is possible to read the container like a filesystem.
> 
> b.  Zips are universal. So are ISOs
> 
> 4.  Take a look at YAML as the document spec. It is a superset of JSON (and so people can use JSON too) but it is a lot more readable
> 
> a.  YAML is growing rapidly in its popularity
> 
> b.  YAML serializes to/from JSON easily
> 
> c.  It is amazingly human-readable
> 
> 5.  Avoid HTML. Seriously. Same for XML. Let the applications (and there will need to be application support) read and render the JSON data
> 
> a.  If you want formatting, you can add to the spec to add formatting to the nodes
> 
> 6.  User lists/arrays to define the implicit order.
> 
> a.  We made a mistake when we wrote our internal spec, and went with hashes. Those are not guaranteed to be ordered, and we had to rely on an additional ‘order’ datapoint
> 
> b.  Arrays/lists are. The order is implicit, and does not rely on any additional definition
> 
> c.  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)
> 
> 7.  Avoid embedding data (tags, anything display oriented, artwork).
> 
> a.  Again, M4B. Yuck.
> 
> 8.  If you have a container (zip/iso) and files (jpg, pdf, audio) and a single ‘manifest.json’ (or manifest.yaml 😉) then the “specification” comes down to that single JSON/YAML file. Nothing else matters really.
> 
> 9.  If you focus the standard on that Manifest file, then the actual container becomes flexible. As long as an application can read that file. But it would lend itself to a self-contained package (in a Zip/iso) as well as direct filesystem storage (object/POSIX, whatever)
> 
>   
> 
> There is a tendency to over-complicate things – especially when there are lots of opinions involved. I would be a strong advocate for a SIMPLE specification, and preferably one that defines the *contents* of the container, rather than the container itself. Having a single document define the contents, makes it much easier to build applications IMHO.
> 
>  
> 
> If you have any questions of them or comments, let me know and I can pass things along!
> 
>  
> 
> Happy holidays,
> 
> Wendy
> 
>  
> 
>   Wendy Reid
> 
>   Senior Quality Analyst
> 
>   Toronto, Canada (GMT-5)
>  <http://www.kobo.com/>
>    <http://www.facebook.com/Kobo>  
> 
>    <http://www.instagram.com/kobobooks> 
>    <http://twitter.com/kobo> 
>   www.kobo.com <http://www.kobo.com/> 
>  
> 
>  
> 
>  
> 
> <image002.png>