[RNLD] Links between publication and sound corpus

[Andrew Cunningham]

Actually the way to do that is via JavaScript using the HTML5 Audio API
where the start and end time are data attributes of the audio element.

Although the event listerners only fire of five times a second, so will not
be millisecond accurate.

A.
On Mar 8, 2013 6:21 AM, "John Hatton" <john_hatton at sil.org> wrote:

> > That was some time ago and now I think I would use an archival version
> of the media as the streaming source and have HTML5 calls to the timecodes.
> ****
>
> ** **
>
> Am I understanding the problem correctly?****
>
> ** **
>
> 1) We want URLs which act just like a pointer to a static wav somewhere on
> the internet. These can then be embedded in anything.****
>
> 2) But because we don't want to actually carve up each file into little
> files, we need the URL to specify a time range rather than just a filename.
> ****
>
> 3) We want to point to an archived version, not some special vers****
>
> ** **
>
> ion hosted for the purpose of these embedded links.****
>
> ** **
>
> If I understand the problem, then the solution is a URL like****
>
> ** **
>
> http://<some snippet service>.org/<address of the archived
> version>?start=<starttime>&end=<endtime>****
>
> ** **
>
> (That last bit after the '?' is called a URL Query string.)****
>
> ** **
>
> E.g.****
>
> http://snippetServer. org/?url=paradisec.org.au/someinternalpathat
> paradisec/KovaiCanoeStory.wav?start=02:20:10&end=02:22:10****
>
> ** **
>
> When it receives this query, the server would get ahold of the full audio
> file declared in the query string, and then stream out just the section
> that was called for. The experience to the user would be the same as if
> they had clicked on a url of a pre-prepared, stand-alone file containing
> just that snippet.****
>
> ** **
>
> Now, because the audio itself is served by an archive, it will have a long
> lifetime. The snippet server itself need not be related to the archive; a
> single instance could serve everyone. But if the snippet server itself goes
> away in the future, the URL is still human readable, and can be changed via
> search/replace to some new snippet server. ****
>
> ** **
>
> To avoid the links going bad, it seems the snippet server should be run by
> something prepared to be around for a long time, like an MPI or an ****
>
> ** **
>
> archive itself:****
>
> ** **
>
> http://paradisec.org.au/snippetserver/...****
>
> ** **
>
> Practically, such a server could limit its services to files in its own
> repository or some set of other domains, if it didn’t want to end up
> providing this snippet service for just any content on the web.****
>
> ** **
>
> I googled a bit, didn't come up with anything, but I wouldn't be surprised
> if such a service already existed. If not, well clearly this would be cheap
> to do.****
>
> ** **
>
> John Hatton****
>
> SIL International Language Software Develoment****
>
> ** **
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.linguistlist.org/pipermail/resource-network-linguistic-diversity/attachments/20130309/3a9db376/attachment.html>