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

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 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)
>
> [image: signature_614067523] <http://www.kobo.com/>
>
>   [image: signature_421441780] <http://www.facebook.com/Kobo>
>
>   [image: signature_767639743] <http://www.instagram.com/kobobooks>
>
>   [image: signature_578962038] <http://twitter.com/kobo>
>
>   *www.kobo.com <http://www.kobo.com/>*
>
>
>
>
>
>
>