-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft.yaml
214 lines (208 loc) · 9.25 KB
/
draft.yaml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
---
# General Notes
# This document is a very rough, first draft of what I was thinking of.
# Written in YAML, so that I can use Anchors and write comments. It is serializable to JSON.
#
# I have included comments/notes on the specific key/value pairs. Most of them are self-explanatory.
#
# All `source` nodes should use URIs. Any non-URI, is considered 'internal'
# `resource` and `audio` keys are treated as 'internal' resources, and are fetched to that location from the `source`
#
# For example, `/cover.jpg` would mean 'inside the container, filename cover.jpg'
# Whereas `file://users/desktop/cover.jpg` would mean 'outside the container, in the users filesystem
# and `http://somewhere.com/cover.jpg` would be a HTTP resource
# I don't know how feasible it is, but an option to 'fetch' the resources would be nice.
#
# I have honestly over-complicated this example to show its flexibility. In point of fact, only a tiny handful
# of the 150,000+ audiobooks I have processed *ever* reach this level of complexity.
# The average book is 10 hours long, with a number of audio files, and maybe a single PDF.
#
# In the Audiobook industry, complexity on the side of the Author is usually normalized in the contact
# negotiation stage. Audiobooks are a very 'flat' structure product.
#
# I have included one option for handling a complex playlist structure.
#
# I have to warn you though - NO publisher currently produces audiobooks with *any* kind of structure. Even getting
# publishers to agree to "One File per logical unit of audio" is basically impossible.
#
# You have my permission to redistribute this file in any format, including posting to public forums.
# It is not necessary to credit me for the work
# `book` covers the simplified book-level metadata for display. Additional keys can be added as appropriate
# This hash represents the common fields we use at Blackstone
# `cover` is a resource reference. The key is resolvable in the `resources` hash
# This is the information that is displayed before any audio is downloaded i.e. in the users 'library'
book:
title: "The Story of a Specification" # Book Title to display
subtitle: "From nothing, to something" # Book Subtitle
abridgement: "Unabridged" # Book Abridgement
author: "Geoff Jukes and Others" # Author String
narrator: "Geoff Jukes" # Narrator String
copyright: "Blackstone Publishing, Inc." # Copyright
isbn13: "9781234567890" # Product ISBN 13
cover: '/cover.jpg' # Cover Image from resources
version: "a02291caf068b252c6ba899cf6f13cf3" # Arbitrary version string. For us it's a 'hash of hashes'
modified: "2012-08-14T16:49:59+00:00" # Arbitrary version timestamp in ISO format
license: # If you use book-level encryption
credits:
authors: # List of Authors
- "Geoff Jukes"
narrators: # List of Narrators
- "Geoff Jukes"
publishers: # List of Publishers
- "Blackstone Publishing, Inc."
contributors:
- "The World"
# `resources` covers the non-audio assets that are available.
# The key is the relative path, which the App will deal with as appropriate
# `source` defines where to 'get' them from if they are not available.
# Downloading/caching can be disabled with `cache: false
resources:
/cover.jpg:
source: "http://example.org/cover.jpg"
label: "The Story of a Specification (Unabridged)"
md5: "06f33a03629a38129cfdfc46be2256c5"
mimetype: "image/jpeg"
modified: "2012-08-10T15:39:57+00:00"
size: 345645
/target.jpg:
source: "http://example.org/target.jpg"
label: "The Target"
md5: "f69a7bd55507cb41161f452777701109"
mimetype: "image/jpeg"
modified: "2012-08-10T15:39:57+00:00"
size: 345645
/battle-plans.pdf:
source: "http://example.com/battle-plans.pdf"
label: "Top Secret Battle Plans"
md5: "2971819be3990807db172ee7079cf907"
mimetype: "application/pdf"
modified: "2012-08-10T12:23:55+00:00"
size: 1524554
# `audio` covers the audio file resources.
# same as `resources`, the key is the container-relative path. If it is not available at that location
# it can be 'fetched' from the `source`
# Basically an extension of the `resources` hashes, adding length and license values.
audio:
/6729-001.m4a: # Key is a relative filepath
source: "http://example.org/audio/6729-001.m4a" # Optional: source of audio file resource
length: 3336.3330416666668 # Required: Track runtime in seconds
md5: "c45c8f927f93f474074c5641f205349c" # Optional: Track data hash
modified: "2012-08-14T16:49:50+00:00" # Modified Timestamp of file in ISO format
size: 80072018 # Size in bytes
license: # If you use file-level encryption
/6729-002.m4a:
source: "http://example.org/audio/6729-002.m4a"
length: 2446.1845
md5: "857ce612dc13b3446a8b728286843274"
modified: "2012-08-14T16:49:52+00:00"
size: 58708453
license:
/6729-003.m4a:
source: "http://example.org/audio/6729-003.m4a"
length: 2543.1249166666666
md5: "00408f65e855ccfced068fe7a3a201f5"
modified: "2012-08-14T16:49:55+00:00"
size: 61035023
license:
/6729-004.m4a:
source: "http://example.org/audio/6729-004.m4a"
length: 3364.022875
md5: "15e9654a94eaa16484d8d94a3f4356f8"
modified: "2012-08-14T16:49:59+00:00"
size: 80736574
license:
/6729-005.m4a:
source: "http://example.org/audio/6729-005.m4a"
length: 3364.022875
md5: "1425374a94eaa16484d8783950-34g93"
modified: "2012-08-14T16:49:59+00:00"
size: 80736574
license:
# Now some will argue that "Audiobooks Need Structure". I say that is not true, Print books need structure.
#
# There are *never* any contractual obligations regarding how track lists appear. This is because
# it is not something that we have ever (or will ever) have universal control over.
# Should that ever change, the most that could be asked for would be "best efforts" - which this allows.
#
# Oh, and *no* publisher captures this level of structure for audio.
#
# Below is a deliberately complex example, just to demonstrate the idea
# The nominal idea here, is a Publisher can communicate the desired format/layout of the tracks
#
# So we can hint at a layout/style/structure, but there is no obligation on the part of the developer
# beyond displaying the 'label''
playlist:
- label: "Part One" # Label for the group. 'null' would display no label.
style: "book-section" # Default CSS Style for Playlist entries
indent: 0 # Offset from left
stylesheet: "default.css" # Stylesheet for this list
contents: # Audio Files to include in this group
- label: "In the Beginning" # Display Label
audio: "/6729-001.m4a" # audio resource key
indent: 1 # Additional offset from left (in addition to group offset)
style: "track"
- label: "An Idea Forms"
audio: "/6729-002.m4a"
indent: 1
style: 'track'
resources:
- "target.jpg" # Array of resources associated with this audio
- label: "The Journey"
style: "subsection-red"
indent: 1
stylesheet: "default.css"
contents:
- label: "A First Draft!"
audio: "/6729-003.m4a"
indent: 1
style: "blood-red"
resources:
- "/battle-plans.pdf"
- label: "Part Two"
indent: 0
stype: "book-section"
contents:
- label: "Winners"
audio: "/6729-004.m4a"
indent: 1
style: "track"
- label: "Losers"
audio: "/6729-005.m4a"
indent: 1
style: "track"
# The example above would display similar to this:
# [* means it would play a track]
# ---
# Part One
# In The Beginning *
# An Idea Forms *
# The Journey
# A First Draft! *
# Part Two
# Winners *
# Losers *
# ---
#
# I like this layout because it allows for complex groups of audio, without being difficult to read or parse.
# It also allows the much simpler (and more common) 'track list' (see below)
# Each 'list' can represent a main section or a book (part one, part 2 etc).
# The top-level `label` is optional, and would be omitted from display if `null`
# Aesthetic sections would have no `audio` item, and would display just as a label for formatting.
# Functional sections would have an `audio` and/or `resources` element
#
# Honestly, what you will probably see most often is this:
# ---
# playlist:
# - contents:
# - label: "Track 1"
# audio: "/6729-001.m4a"
# - label: "Track 2"
# audio: "/6729-002.m4a"
# - label: "Track 3"
# audio: "/6729-003.m4a"
# - label: "Track 4"
# audio: "/6729-004.m4a"
# - label: "Track 5"
# audio: "/6729-005.m4a"
# ---
#