A thread a few days ago we talked about linking to audio files.
The suggestion made was to use start and end times for each verse, add this
information into the module and let the application advise an associated media
player to play verses or passages.
I also understand that at least Nic from
"Peter von Kaehne" writes:
> largest image module from Karl's repo is IIRC about 70mb.
-rw-r--r-- 1 gnomesword vuser 156327891 Apr 9 15:35 bibleartbw.zip
Users have picked up 186 copies of it this month.
___
sword-devel mailing list: sword-devel@cr
On 08/24/2010 10:27 AM, Peter von Kaehne wrote:
> A thread a few days ago we talked about linking to audio files.
> ...
> Any opinions on this? Any better suggestions? I really would like to go ahead
> and encode such a module, even on an experimental base.
>
> Peter
>
I'd like to see this a
Peter,
If you look at the mailing list archives for April 2010, you will find John
Austin's message that announced xulsword.
Subject: Announcing a new SWORD front end called Xulsword
On the Nabble mirror of this list, you can read this thread
http://sword-dev.350566.n4.nabble.com/Announcing-a-
On Tue, Aug 24, 2010 at 11:15 AM, David Haslam wrote:
>
> Peter,
>
> If you look at the mailing list archives for April 2010, you will find John
> Austin's message that announced xulsword.
>
> Subject: Announcing a new SWORD front end called Xulsword
>
> On the Nabble mirror of this list, you can
> I have not found any appropriate separate tags for this and think that teh
> best place to encode this is probably in the verse tags themselves as an
> x-attribute.
>
> The main immediate concern I would have, would such x-attributes survive
> engine filtering or would we require a new release
On 24/08/10 20:02, Greg Hellings wrote:
> Off hand I don't know of any other formats which might be a candidate
> for your work. Support of various front ends might also be worth
> considering.
I never thought about that aspect. Would the easiest not simply be to
push it off onto an external h
> I never thought about that aspect. Would the easiest not simply be to
> push it off onto an external handler?
>
> I just experimented with mplayer (which is capable of playing a
> multitude of formats). It accepts nicely start and end times for playing.
>
> Peter
It will probably be difficult to
On 24/08/10 21:01, Matthew Talbert wrote:
> I think you ought to look closely at how images are handled.
I thought of that. But images have a separate tag (figure, I think)
which is not really suitable for sound. And a generic does not
exist, does it? Finally it is not just about simply linking
On Tue, Aug 24, 2010 at 4:28 PM, Peter von Kaehne wrote:
>
> On 24/08/10 21:01, Matthew Talbert wrote:
>
> > I think you ought to look closely at how images are handled.
>
> I thought of that. But images have a separate tag (figure, I think)
> which is not really suitable for sound. And a generic
Matthew Talbert writes:
>> I thought of that. But images have a separate tag (figure, I think)
OSIS , ThML .
>> a generic does not exist, does it?
Only in ThML, I'm pretty sure.
> I do think you would be better off splitting it into per-verse files.
Ow.
31,102 verses in KJV. At the very le
On 8/24/2010 2:10 PM, Karl Kleinpaste wrote:
Matthew Talbert writes:
I thought of that. But images have a separate tag (figure, I think)
OSIS, ThML.
If you mean to embed the audio in-line, I would recommend using the
element. There's nothing specifically image-oriented about the
elemen
> Von: Chris Little
> OSIS does have , with more or less standard semantics. (It supports
> the href attribute, but not name). But I'd recommend using only if
> you want to link to an external page/object (e.g. you want to force
> front ends to launch an external player). I think front ends ou
> So, anyway, I would suggest that we allow - just as with images - a variety
> of file types and just hope for (gradual) expansion of any deficient media
> players (here mp3, ogg and aac) - and steer confused souls towards ogg.
I ask that we don't favour (or even use) ogg vorbis (FYI, "ogg" is
Chris Little writes:
> If you mean to embed the audio in-line, I would recommend using the
> element. There's nothing specifically image-oriented about the
> element, aside from implications made by its name.
Yes, there is: The XXXhtmlhref filters wrap the resulting HTML
element in for the sak
On Wed, Aug 25, 2010 at 8:20 AM, Karl Kleinpaste wrote:
>
> Chris Little writes:
> > If you mean to embed the audio in-line, I would recommend using the
> > element. There's nothing specifically image-oriented about the
> > element, aside from implications made by its name.
>
> Yes, there is: Th
Karl Kleinpaste writes:
> the application probably has to hack the filter output to spackle in a
> standard miniature image to indicate it, to go along with the intended
> pseudo-picture actually-audio reference
It occurs to me as well that simply adding a standard "there's audio
here" image fil
Am 25.08.10 13:41, schrieb Karl Kleinpaste:
> Karl Kleinpaste writes:
>> the application probably has to hack the filter output to spackle in a
>> standard miniature image to indicate it, to go along with the intended
>> pseudo-picture actually-audio reference
>
> It occurs to me as well that si
On 26/08/10 01:00, Manfred Bergmann wrote:
Creating a new tag (or something similar) that gets wrapped in
something like would let
this happen in much more consistent, standard, and reliable ways.
I don't have the full overview of what the filters do or render exactly
but I generally agree h
Indeed, for example, Bible translations done for deaf people in sign
language are done in video as the primary medium.
On Wed, Aug 25, 2010 at 1:02 PM, Robert Hunt wrote:
> On 26/08/10 01:00, Manfred Bergmann wrote:
>
>>
>> Creating a new tag (or something similar) that gets wrapped in
>>> som
On 8/25/2010 5:20 AM, Karl Kleinpaste wrote:
Chris Little writes:
If you mean to embed the audio in-line, I would recommend using the
element. There's nothing specifically image-oriented about the
element, aside from implications made by its name.
Yes, there is: The XXXhtmlhref filters wr
Am 26.08.10 06:19, schrieb Chris Little:
>
>
> On 8/25/2010 5:20 AM, Karl Kleinpaste wrote:
>> Chris Little writes:
>>> If you mean to embed the audio in-line, I would recommend using the
>>> element. There's nothing specifically image-oriented about the
>>> element, aside from implications ma
> Von: Manfred Bergmann
> However, the HTML5 audio tag doesn't define attributes like for example
> start/stop time for playing fragments within a large audio file.
> How could this be handled?
I think there is an standard attribute which allows for "home made" extensions
"data-"
http://www.w3
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 Jo
Corrigendum: It was 2009 (not 2008) when JA kindly let me have access to his
files.
--
View this message in context:
http://sword-dev.350566.n4.nabble.com/Linked-in-audio-files-tp2336755p2340019.html
Sent from the SWORD Dev mailing list archive at Nabble.com.
___
On Thu, Aug 26, 2010 at 12:25 PM, David Haslam 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
On 08/26/2010 02:51 PM, Matthew Talbert wrote:
On Thu, Aug 26, 2010 at 12:25 PM, David Haslam 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
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.
The total amount of work may turn out to be less, especially if the OSIS
files do not have to be changed
Thanks DM.
Here's a link to the MK program and the text and audio downloads.
Those of you who have Windows might just like to take the opportunity to see
it in action.
http://www.ibt.org.ru/english/bible/info_bible_en.htm
We already know that MK is not backwards compatible with our software in
I should have mentioned that the reason for the backwards incomaptibility was
unrelated to audio support.
It was due to the separate IBT requirement to support v11ns for both KJV and
RST (Russian Synodal Translation) for the 66 book protestant canon.
cf. Their project began considerably before
David Haslam writes:
> Well that's going to be the case anyway. Each SWORD (or JSword)
> front-end application would need to implement a media player
No, not at all.
If the resulting HTML returned by the filters is any sort of typical
"passagestudy.jsp?action=playMultiMedia" link, then Xiphos w
On Thu, Aug 26, 2010 at 2:13 PM, David Haslam 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.
On 27/08/10 08:23, Greg Hellings wrote:
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{file: "sounds/Genesis/1.aac", start_time: "0:0:15",
end_time: "0:0:23"}.
O
On Thu, Aug 26, 2010 at 4:15 PM, Robert Hunt wrote:
> On 27/08/10 08:23, Greg Hellings wrote:
>>
>> 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> osisID="
On 27/08/10 09:38, Greg Hellings wrote:
As you see, I'm not suggesting that the data going into the original
KJV module and thus tying it to a single audio recording's time starts
and stops.
Sorry, I misunderstood your previous email. (When you said OSIS file, I
originally misunderstood that t
Greg,
MK ("Holy Bible") is the same as the open source xulsword project, so anyone
can study how it is programmed. Here's the project URL
http://code.google.com/p/xulsword/
When I met the programmer face to face in 2009 Q1, he hadn't got round to
putting the source code online. However, thi
On Thu, Aug 26, 2010 at 12:19 AM, Chris Little wrote:
> No, there is nothing specifically image-oriented about the element.
> That Sword filters always interpret it as an image is irrelevant to my
> point.
>
> Moving forward, we can mandate that (for Sword) non-image data embedded with
> be tagg
On Wednesday, August 25, 2010 07:29:28 am Nic Carter wrote:
> I ask that we don't favour (or even use) ogg vorbis (FYI, "ogg" is a
> container format, "vorbis" is the audio format codec). I'm going to
> completely ignore any arguments that could be made for or against the idea
> that it is patent
38 matches
Mail list logo
