[sword-devel] Linked in audio files

[DM Smith]

  On 08/26/2010 02:51 PM, Matthew Talbert wrote:
> On Thu, Aug 26, 2010 at 12:25 PM, David Haslam<d.haslam at ukonline.co.uk>  wrote:
>> Hi everyone,
>>
>> I think we got hung up by thinking that everything has to be done within the
>> module.
>>
>> Why are we focusing on the OSIS files? Is there any real need to define a
>> new marker tag for audio in the OSIS? I very much doubt that it's necessary.
>> As far as I can tell, the OSIS files used by John Austin's xulsword (MK)
>> application did not contain any such extra tag. I just examined the UZVL.xml
>> file which he kindly let me have access to in 2008. (This is for Uzbek
>> Latin).  I could not find any object that has a connotation of audio.
>>
>> This implies that everything is done by the front-end itself. After all, the
>> application knows which chapter and verse is currently being displayed as
>> text, so all that is needed in addition to the audio (MP3 or whatever) file,
>> is a means to synchronize the current location (e.g chapter) with the start
>> time for the respective audio file. And to stop somewhere suitable.
>>
>> This throws the challenge back to the front-end application, and makes the
>> option to install an audio file as an ancillary media object something that
>> can be independent of how the text is displayed and how the module is
>> parsed.
>>
> Sorry to put this bluntly, but are you basically saying that instead
> of all of us collaborating and getting this done right in sword, all
> of the front ends should re-implement the same thing? Essentially 5x
> the work?

That's not how I read it. I thought he was saying that audio would be a 
companion to a module. Perhaps he meant that the effort was on each 
front-end, but I gave him the benefit of the doubt and understood him to 
say that front-ends would need to support the new module type to get 
sound to the user.

I imagine it would be like a dictionary, with an index and a dat file. 
The index, keyed by whatever is an appropriate lookup for the module, 
would hold offset and length and the dat file would be the audio file, 
perhaps individual ones concatenated.

This would allow for any module to have a corresponding audio file.

In Him,
     DM