Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sync media file should declare which HTML document it goes with #26

Closed
marisademeglio opened this issue Oct 11, 2019 · 3 comments
Closed
Labels
synchronized-narration Applies to the archived sync narration draft but not the new sync media work

Comments

@marisademeglio
Copy link
Collaborator

The text property is the only point of reference from sync media to HTML. It is currently defined as a URL fragment, e.g. #id1234

This fragment-only definition makes sense when the sync media file is discovered from within an HTML file. It can also make sense if the sync media file is discovered from data in a publication manifest, but only if the reading order item that it appears on is an HTML file.

If however it appears on an audio file item, we have no way of knowing the corresponding HTML document.

An Audiobooks processor encounters the following:

"readingOrder" : [{
		"type"	: "LinkedResource",
		"url"   : "audio/part001.wav#0",
		"encodingFormat" : "audio/vnd-wav",
		"name"  : "Chapter 1",
		"duration" : "457.931",
		"alternate" : "sync-media/part001-1.json"
},
...
]

But according to the current text definition, the text property would not say which file to open:

sync-media/part001-1.json:

...
{
 "text": "#id21",
 "audio": "file.mp3#t=23,45"
}
...

Ideas to fix this:

  1. Require* the filename on text
{
 "text": "content.html#id21",
 "audio": "file.mp3#t=23,45"
}

* - : it would probably be "technically optional" but given that Audiobooks is our most likely real-world use case, then we should be sure to write our examples in a way that will copy/paste well for that context.

  1. Add a property to the sync media file, at the root level, giving the filename. E.g.
{
 htmlDoc: "content.html",
 narration: [
  {
   "text": "#id21",
   "audio": "file.mp3#t=23,45"
  },
  ...
 ]
}

and so the sync media file must say what HTML document it is using to synchronize with this audio file.

  1. (I don't really like this option but for completeness, here it is:)

Audiobooks should instead directly refer to the HTML document, which in turn refers to the sync media file from its <head>.

If we went this way, it would suggest that we could skip packaging sync media entirely and just always have the HTML refer to it. This to me feels like the easiest to specify and also the most cumbersome to author and maintain and process because 1. It increases the destructive editing burden on the HTML document, which I think we should be increasingly moving away from; and 2. Having to open an HTML document before you decide to fire up your sync media player is also additional processing burden.

@marisademeglio
Copy link
Collaborator Author

@danielweck thoughts?

@danielweck
Copy link
Member

danielweck commented Jan 29, 2020

This fragment-only definition makes sense when the sync media file is discovered from within an HTML file. It can also make sense if the sync media file is discovered from data in a publication manifest, but only if the reading order item that it appears on is an HTML file.

See my thoughts / remarks on the "base URL" of the JSON document:
#28

@marisademeglio
Copy link
Collaborator Author

The new draft is moving away from being so lightweight as to have this problem, so it may not be an issue in the end.

@marisademeglio marisademeglio added the synchronized-narration Applies to the archived sync narration draft but not the new sync media work label Dec 19, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
synchronized-narration Applies to the archived sync narration draft but not the new sync media work
Projects
None yet
Development

No branches or pull requests

2 participants