[RNLD] Links between publication and sound corpus
doug.cooper.thailand at GMAIL.COM
Fri Mar 8 02:25:58 UTC 2013
Yes, this states the server solution exactly. This does not pose any
technical barrier (it's just a matter of providing a wrapper for
something like sox or mp3splt). It just needs an archive that sees
providing a service like this to be part of its long-term role.
Although html5 does allow a start/finish time to be specified, the last
time I checked the complete underlying file is downloaded. I'd be happy
to be wrong about this, or to hear that there's an (Apache) server add-on
that handles this in a more intelligent way.
On 3/8/2013 2:20 AM, John Hatton 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
> (That last bit after the '?' is called a URL Query string.)
> http://snippetServer. org/?url=paradisec.org.au/someinternalpathat
> 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:
> 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
More information about the Resource-network-linguistic-diversity