[sword-devel] Linked in audio files

[Greg Hellings]

On Thu, Aug 26, 2010 at 2:13 PM, David Haslam <d.haslam at ukonline.co.uk> wrote:
>
> Matthew,
>
> Well that's going to be the case anyway.  Each SWORD (or JSword) front-end
> application would need to implement a media player for playing the ancillary
> resource when the user wishes.

I think this is pretty well understood.  Playing audio isn't really
something that the SWORD library ought to handle.  There are other
libraries for that, leave it to them, and let each front end that
wants to support this type of module use a method that works on their
target platforms.  So long as we settle on an audio format and
encoding that is relatively well supported (AAC is probably the best
judging by its lack of patent issues and its extremely wide support),
the player details can be left to the front end developers.  Some may
opt to include built-in functionality, others might use their HTML
viewers with JavaScript or other bridges to control them and some
might be forced to use built-in libraries like on iPhone.

>
> The total amount of work may turn out to be less, especially if the OSIS
> files do not have to be changed for the modules. Ancillary resources can
> then be developed independently, and added as and when they become ready to
> release.

I don't think anyone was suggesting going and changing existing
modules like our KJV or WEB or anything else like that to include the
data necessary to play audio files.  Doing so would basically limit
them to only working with a single audio module - which is almost
certainly not desirable.  However, unless you were suggesting that
every front end need to acquire the data itself, we still need to
agree on a way to represent that in a module.  The general consensus
around Crosswire is that OSIS is our format of choice - so it makes
sense to talk about how it can be represented in the current OSIS
specification or how OSIS can be altered to include support for this
data.  DM's suggestion would have the module encoded in TEI and
Chris's module would have it encoded in OSIS.  Both of them would be
encoded in a new module which front ends might include within other
modules, in parallel with them, as a module interface unto themselves
or almost anything in between.

The fact that someone else has done it doesn't help us if we don't
know how they did it.  I don't know anything about this MK program
except I remember hearing about it when it first appeared.  Their
method of support might be totally unavailable to us because they
might use a SQLite database of start and stop times or something else
entirely.  Additionally they are a single program that supports
itself, and not a library trying to support may applications on many
platforms.  They can do anything they want internally to their own
program - we need to accommodate many applications and programs.

The first step is deciding on a markup method.  I like the sound of
DM's, but I don't see why it couldn't be handled in OSIS already?  A
verse could have something along the lines of <verse
osisID="Gen.1.1">{file: "sounds/Genesis/1.aac", start_time: "0:0:15",
end_time: "0:0:23"}</verse>.  A flag in the conf module of supported
features could say GlobalOptionsFilter=OSISAudioData or whatever (I
encoded the data as JSON because it's the easiest, compact notation I
know off-hand - one could also have additional OSIS elements or even
have them on the verse object as attributes).  A front-end can then
pull out that data and convert it into any format it wants: external
audio player, built-in audio player, system audio player, embedded
audio in HTML, etc.  Since what we're talking about is a Bible,
through and through, there seems to be no reason we can't represent it
in our normal Bible ways and have it categorized as a Bible.  David
might want it to be a supplement to a text Bible, but I might just
want to listen to it as my main Bible while I'm at the gym with my
Android phone and have it on continuous play.

The general plan is to leave the presentation in the front end's
hands, but the encoding and storing needs to be done by the module and
engine.  I like the idea of keeping it in a Bible module, since that
is what this represents to many of the world's languages.  A general
enough solution like this, though, allows us to extend the definition
almost seamlessly to video presentations from the point of view for
module encoding and storage.

--Greg