Closed HadrienGardeur closed 5 years ago
(First off: Congrats on the new job!)
I think the current draft of the spec and the requirements you list above are close. I agree we should include the abridged/unabridged and explicit content options, which I am happy to discuss in the meeting next week, I don't think they'll be contentious.
I have been thinking about the TOC question again. I'm reluctant to open that particular pandora's box but I see both sides of the argument and I've talked to people here about it too. Both options are possible and I would be open to discussing the pros/cons in a world of publication manifest. I'll add it to the agenda as well.
Would like to hear options about samples, I think we have covered supplemental material as best we will manage. I don't want to be prescriptive about it in version 1.
Would like to hear options about samples [...]
I've seen the following use cases in the various retailer requirements:
It's worth pointing that what Apple does (pointing to the beginning of a sample) and what Google does (define the length of the sample) would work better together than separately.
This could be handled through a reference in either links
or resources
that would be properly identified (using a specific rel
value).
"resources": [
{
"rel": "preview",
"url": "sample.mp3",
"encordingFormat": "audio/mpeg"
}
]
This could be handled through a reference in either links
or resources
and re-use the start
rel
value or define our own.
"links": [
{
"rel": "start",
"url": "chapter1.mp3#t=78",
"encordingFormat": "audio/mpeg"
}
]
I think this has been suggested by Google before (ping @GarthConboy) as additional metadata
but I can't find back where this was suggested (I remember a separate Google Presentation for example).
The Preview PR has been relocated to the Publishing Manifest document here
@HadrienGardeur It is important to bear in mind that the term 'sample' is used to describe 2 different things, with 2 different purposes.
The first (most commonly supplied as a separate file) is a marketing resource, effectively unrelated to the audiobook as it ships. Samples are often created before the audio is available i.e. it is more akin to a movie trailer than a sample of the book. This sample may change over the lifetime of the book, at the whims of the marketing department.
The second is a snippet of audio extracted directly from the book. This is more akin to a preview.
Both of these can be subject to strict contractual obligations from the author or publisher, and both can exist simultaneously.
It is my understanding that Google use the 'sample' (more appropriately a 'preview') to facilitate contextual audio samples based on search results - leveraging the publishers 'you can play X seconds of this book as a sample'. It is worth emphasizing that not all publisher/author contracts allow for this type of sample (but it is becoming more common)
The term 'sample' has an established meaning in the industry as the marketing resource, and it is already managed via ONIX deliveries (along with the cover image) and I do not think it appropriate to embed it in the distribution package at all.
If we focus on the term preview
(and Google's use of it) then I think that it is perfectly appropriate to embed it into the distribution.
Both of these can be subject to strict contractual obligations from the author or publisher, and both can exist simultaneously.
@geoffjukes could you explain their respective use cases when they both exist simultaneously?
I get your point about "trailer" (basically replaces the description or a back cover) vs "preview" (which lets me sample what the experience will be) but I would imagine that most of the time they're used the same way by a retailer.
In previous discussions, we've talked about "authored samples" vs "generated samples". My guess is that a retailer should prioritize an "authored sample" over a generated one, but it doesn't hurt to offer at least some controls about the way these "generated samples" are calculated.
The term 'sample' has an established meaning in the industry as the marketing resource, and it is already managed via ONIX deliveries (along with the cover image) and I do not think it appropriate to embed it in the distribution package at all.
"Authored samples" and covers can definitely be delivered using ONIX, but it's still common to have file naming conventions for covers (this is true for both EPUB and audiobooks). It's worth discussing whether this is truly redundant with ONIX or if it serves a purpose.
"Generated samples" are usually created based on a default setting per retailer and/or contractual obligations (I've seen a lot of contracts with either 5%/10% or the first chapter, whichever is the smallest). If fine-grained controls over the way they're generated (like Apple or Google) is useful, then ONIX can't easily fulfill that role.
@geoffjukes could you explain their respective use cases when they both exist simultaneously?
Using your terms @HadrienGardeur - Prior to publishing, the "Authored Sample" will be the only one that exists, and is used to promote the book. After publishing, the "Authored sample" may (or may not) be updated any number of times (in practice, it is rarely updated after publication, unless the book is optioned for a movie or similar).
It is true to say that the "Authored Samples" are most often "generated", but it is not true to say that they are always generated, and that is the distinction. I find it useful to think of "Authored Samples" as "highly-abridged versions of the book, used for marketing and promotion only".
This issue was discussed in a meeting.
Just an update here, I've added abridged
and preview
to the specification.
We are still discussing isFamilyFriendly
for publication manifest as there is some implications on interpretation there, so I think it's worth including but not required right away, and we should look at options for how best to include it.
This issue was discussed in a meeting.
RESOLVED: Close Audiobooks Issue #12, abridged and preview have been added to the specification, and isFamilyFriendly be moved to Publication Manifest
Context
I’ve recently started a new position as Director of R&D at De Marque, an aggregator and digital distributor connected to major ebook and audiobook retailers.
Since we’re receiving audiobooks from major publishers in Canada, France, Spain and Italy, the audiobook spec is very relevant for us as it might become the standard format that we request from them.
Given the lack of a standard format for distributing audiobooks, it felt relevant to explore what various retailers expect to receive when we deliver them an audiobook and figure out what might be different and/or missing for the proposed spec.
Documentation
Manifest Examples
Apple (XML)
```Kobo (JSON)
``` { "manifest_version": 1, "file_list": [ { "duration": 15, "media_type": "audio/mpeg", "file_name": "01-somefilename.mp3", "file_order_id": 0 }, { "duration": 60, "media_type": "audio/mpeg", "file_name": "02-anotherfilename.mp3", "file_order_id": 1 }, { "duration": 200, "media_type": "audio/mpeg", "file_name": "doesnt need-to-be-in-filename-order.mp3", "file_order_id": 2 }, { "duration": 30, "media_type": "audio/mpeg", "file_name": "lastchapter.mp3", "file_order_id": 3 } ], "table_of_contents": [ { "title": "Introduction", "file_order_id": 0, "offset": 0 }, { "title": "1. We hear you", "file_order_id": 1, "offset": 0 }, { "title": "2. Another chapter", "file_order_id": 2, "offset": 0 }, { "title": "3. The End", "file_order_id": 3, "offset": 0 } ] } ```Notes
Closing Remarks