Having the project hosted here would bring more attention to the Church's contribution to the project. Each time someone has to type in "tech.lds.org" they are reminded who is hosting the site. However others may be confused why a "church" is hosting this project. I was on the fence before but I'm starting to lean towards SourceForge. Regardless, we need more of a specification before we can begin.
Tom
Open Source Digital Talking Book Player
-
WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
- Contact:
-
cannona-p40
- Member
- Posts: 79
- Joined: Sat May 19, 2007 2:32 pm
- Location: Iowa City, IA
Hi all.tomw wrote:Having the project hosted here would bring more attention to the Church's contribution to the project. Each time someone has to type in "tech.lds.org" they are reminded who is hosting the site. However others may be confused why a "church" is hosting this project. I was on the fence before but I'm starting to lean towards SourceForge. Regardless, we need more of a specification before we can begin.
Tom
Just a quick update. I haven't been able to work on this for the last couple of weeks due to some organizational decisions needing to be made concerning exactly who will be taking this project going forward.
I'll post more when I know more.
Thanks all for your interest and offers of help.
Sincerely
Aaron
-
thedqs
- Community Moderators
- Posts: 1042
- Joined: Wed Jan 24, 2007 8:53 am
- Location: Redmond, WA
- Contact:
-
gkearney-p40
- New Member
- Posts: 15
- Joined: Tue Aug 28, 2007 5:18 pm
Here are some goals which I think we should have for this project:
1. Core is cross platform that is Windows, Macintosh, Linux. I'm not particular to any language but I might suggest Perl. i'm not a big fan of Java. Seems to make a great deal of claims it never delivers on. Accessibility is hard to implement in it too. That said the Java app that the church did for census entry works well with Mac VoiceOver.
2. It should support Daisy 2.02 DIASY/INSO 2002 and DAISY/NISO 2005
3. Should support both text only, via TTS and text/audio books.
4. Should support RFB&D Audio+ format DAISY books
5. Should be able to access books stored on Web servers.
6. Should support display of and syncing to text/image when offered by the book by using system HTML/XML rendering.
7. Support for bookmarking, page number navigation and retaining a place in a book from one session to another.
That's all I can think of at the moment.
1. Core is cross platform that is Windows, Macintosh, Linux. I'm not particular to any language but I might suggest Perl. i'm not a big fan of Java. Seems to make a great deal of claims it never delivers on. Accessibility is hard to implement in it too. That said the Java app that the church did for census entry works well with Mac VoiceOver.
2. It should support Daisy 2.02 DIASY/INSO 2002 and DAISY/NISO 2005
3. Should support both text only, via TTS and text/audio books.
4. Should support RFB&D Audio+ format DAISY books
5. Should be able to access books stored on Web servers.
6. Should support display of and syncing to text/image when offered by the book by using system HTML/XML rendering.
7. Support for bookmarking, page number navigation and retaining a place in a book from one session to another.
That's all I can think of at the moment.
-
thedqs
- Community Moderators
- Posts: 1042
- Joined: Wed Jan 24, 2007 8:53 am
- Location: Redmond, WA
- Contact:
-
cannona-p40
- Member
- Posts: 79
- Joined: Sat May 19, 2007 2:32 pm
- Location: Iowa City, IA
Here are my responses to the proposed functionality.
1. I believe the consensis is that it will be written in Python, which is cross platform.
2. Daisy 2002 will be supported for sure because that's what we will be releasing. The other standards would be nice, but probably shouldn't be an immediate priority.
3. I agree. It is possible that we may at some point release a book that is audio or text only, and the player should support either.
4. Nice, but not a priority. Also, I don't think they would appreciate having source code distributed which allows one to crack their DRM.
5. This is probably not a top priority, but I do agree that it is important. I think it is something that should be implemented shortly after we get the basic player built.
6. For sure. The more work we can pass off to the OS, the better.
7. See 5.
8. See 5.
On the other hand, this is open source, so ultimately what gets implemented will be up to the contributors.
I have been given the go-ahead to continue work on this project, so I will be posting more shortly.
Thanks!
Aaron
1. I believe the consensis is that it will be written in Python, which is cross platform.
2. Daisy 2002 will be supported for sure because that's what we will be releasing. The other standards would be nice, but probably shouldn't be an immediate priority.
3. I agree. It is possible that we may at some point release a book that is audio or text only, and the player should support either.
4. Nice, but not a priority. Also, I don't think they would appreciate having source code distributed which allows one to crack their DRM.
5. This is probably not a top priority, but I do agree that it is important. I think it is something that should be implemented shortly after we get the basic player built.
6. For sure. The more work we can pass off to the OS, the better.
7. See 5.
8. See 5.
On the other hand, this is open source, so ultimately what gets implemented will be up to the contributors.
I have been given the go-ahead to continue work on this project, so I will be posting more shortly.
Thanks!
Aaron
-
WelchTC
- Senior Member
- Posts: 2085
- Joined: Wed Sep 06, 2006 8:51 am
- Location: Kaysville, UT, USA
- Contact:
-
cannona-p40
- Member
- Posts: 79
- Joined: Sat May 19, 2007 2:32 pm
- Location: Iowa City, IA
-
cannona-p40
- Member
- Posts: 79
- Joined: Sat May 19, 2007 2:32 pm
- Location: Iowa City, IA
What follows is a start at putting down some formal guidelines for the application. Input is of course welcome.
The following guidelines are just that, guidelines. They should not be considered unchangeable or complete. They are simply meant to get everyone on the same page, and jumpstart the discussion and coding.
Objective:
The overall goal of this project is to produce a cross platform open source application capable of playing the Daisy/Niso 2002 Digital Talking Books produced by the Church of Jesus Christ of Latter-Day Saints.
Specific goals:
The application should be accessible to users of screen reader or screen magnification software. It should also have the simplest and most intuitive interface possible while not sacrificing important functionality. The source code should be well documented and be written in such a way as to make the addition of functionality as simple as possible. The application should be self-voicing so that it may be used by individuals without screen readers. It should automate the locating and downloading of content as much as possible. Finally, the interface should be written in such a way as to support translation.
Sample application walk-through:
The typical user would either download this application from the Church's web site or receive it bundled on a CD with a Daisy book purchased from the Church Distribution Center. It would be packaged as a single executable for Windows, and in whatever format is the most intuitive for the other operating systems. The installation would be as brief and as painless as possible.
Once the application was opened, it would attempt to detect an internet connection. If one was available, it would automatically connect to the Church's server and download an XML file. This XML file would contain a list of all Daisy publications currently available. This list would be used to populate the library view.
The library view would contain at least two lists. The first would be a list of all the books currently on the users hard drive. (All books would be stored in a particular folder, with a subfolder for each book.) The other list would contain books that were available for download, and/or if a Daisy CD was inserted, from that CD. From the local list, the user would be able to select books to open or delete. From the external list, the user could select books to download. All downloads would take place in the background, but the user could view their status from the download status view.
The subscription view would show a list (also populated from the XML downloaded) of Magazines, general conference, First Presidency Messages, ETC. that the user could subscribe to. Each time the application started, it would check to see if the users subscriptions had been updated with new content. If they had been, it would add those items to the download queue.
(It might make more sense to combine the subscription and library views, as they are related.)
The player view would have standard controls such as play, pause, stop, skip back, skip forward, next section, previous section, next paragraph, previous paragraph, next sentence, previous sentence, next page, previous page, ETC. It would have a frame that would display the text and images from the book, assuming that the book included those. Finally, the frame would have the ability to scroll.
The contents view would show the table of contents of the book as a tree-view. The user could click on an entry to jump directly to that part of the book.
Naturally, all buttons, views, and features would be available from either the mouse or the keyboard, so that a person who is strictly limited to one or the other could still use the program.
Font color, style, and size, as well as background color would be fully customizable.
Finally, the application should optionally support the following features:
Playback of OGG, SPEEX, and any other audio format which is open and might be used in an audio book.
The ability to retrieve content feeds from other sources in addition to the Church.
A commandline interface.
Support for other Daisy standards, specifically Daisy 2.02 and Daisy/NISO 2005.
Ability to begin listening to books before they have completely downloaded.
Place restoration, bookmarking, annotation, ETC. (By place restoration, I mean that the player would remember where you left off reading, even if you haven't read that book for several weeks.)
Ability to speed up and slow down audio without changing the pitch.
Ability to skip certain types of content, such as footnotes and the like.
Ability to copy portions of text to the clipboard.
Brief explanation of Daisy:
A Daisy book consists of at least three XML files and 1 or more audio or image files. The .OPF file (an XML file) contains the metadata of the book and a manifest of all of the files that make up the book. The .NCX file contains the table of contents data stored as XML. Each element in the contents is linked to a specific part of the SMIL file. The .SMIL file (another XML based file) is really what ties it all together. It contains links to sections of mp3 files, portions of the text, and images. It tells the player in what order to play each and which items get played together. The .XML file contains the text of the book. This file is optional. It is referenced by the SMIL file.
The daisy standard supports synchronizing text down to the word level, but we will likely only be producing markup down to the paragraph level. It also supports skippable content. This allows users to optionally skip things they may not wish to hear, such as footnotes.
The following guidelines are just that, guidelines. They should not be considered unchangeable or complete. They are simply meant to get everyone on the same page, and jumpstart the discussion and coding.
Objective:
The overall goal of this project is to produce a cross platform open source application capable of playing the Daisy/Niso 2002 Digital Talking Books produced by the Church of Jesus Christ of Latter-Day Saints.
Specific goals:
The application should be accessible to users of screen reader or screen magnification software. It should also have the simplest and most intuitive interface possible while not sacrificing important functionality. The source code should be well documented and be written in such a way as to make the addition of functionality as simple as possible. The application should be self-voicing so that it may be used by individuals without screen readers. It should automate the locating and downloading of content as much as possible. Finally, the interface should be written in such a way as to support translation.
Sample application walk-through:
The typical user would either download this application from the Church's web site or receive it bundled on a CD with a Daisy book purchased from the Church Distribution Center. It would be packaged as a single executable for Windows, and in whatever format is the most intuitive for the other operating systems. The installation would be as brief and as painless as possible.
Once the application was opened, it would attempt to detect an internet connection. If one was available, it would automatically connect to the Church's server and download an XML file. This XML file would contain a list of all Daisy publications currently available. This list would be used to populate the library view.
The library view would contain at least two lists. The first would be a list of all the books currently on the users hard drive. (All books would be stored in a particular folder, with a subfolder for each book.) The other list would contain books that were available for download, and/or if a Daisy CD was inserted, from that CD. From the local list, the user would be able to select books to open or delete. From the external list, the user could select books to download. All downloads would take place in the background, but the user could view their status from the download status view.
The subscription view would show a list (also populated from the XML downloaded) of Magazines, general conference, First Presidency Messages, ETC. that the user could subscribe to. Each time the application started, it would check to see if the users subscriptions had been updated with new content. If they had been, it would add those items to the download queue.
(It might make more sense to combine the subscription and library views, as they are related.)
The player view would have standard controls such as play, pause, stop, skip back, skip forward, next section, previous section, next paragraph, previous paragraph, next sentence, previous sentence, next page, previous page, ETC. It would have a frame that would display the text and images from the book, assuming that the book included those. Finally, the frame would have the ability to scroll.
The contents view would show the table of contents of the book as a tree-view. The user could click on an entry to jump directly to that part of the book.
Naturally, all buttons, views, and features would be available from either the mouse or the keyboard, so that a person who is strictly limited to one or the other could still use the program.
Font color, style, and size, as well as background color would be fully customizable.
Finally, the application should optionally support the following features:
Playback of OGG, SPEEX, and any other audio format which is open and might be used in an audio book.
The ability to retrieve content feeds from other sources in addition to the Church.
A commandline interface.
Support for other Daisy standards, specifically Daisy 2.02 and Daisy/NISO 2005.
Ability to begin listening to books before they have completely downloaded.
Place restoration, bookmarking, annotation, ETC. (By place restoration, I mean that the player would remember where you left off reading, even if you haven't read that book for several weeks.)
Ability to speed up and slow down audio without changing the pitch.
Ability to skip certain types of content, such as footnotes and the like.
Ability to copy portions of text to the clipboard.
Brief explanation of Daisy:
A Daisy book consists of at least three XML files and 1 or more audio or image files. The .OPF file (an XML file) contains the metadata of the book and a manifest of all of the files that make up the book. The .NCX file contains the table of contents data stored as XML. Each element in the contents is linked to a specific part of the SMIL file. The .SMIL file (another XML based file) is really what ties it all together. It contains links to sections of mp3 files, portions of the text, and images. It tells the player in what order to play each and which items get played together. The .XML file contains the text of the book. This file is optional. It is referenced by the SMIL file.
The daisy standard supports synchronizing text down to the word level, but we will likely only be producing markup down to the paragraph level. It also supports skippable content. This allows users to optionally skip things they may not wish to hear, such as footnotes.
-
thedqs
- Community Moderators
- Posts: 1042
- Joined: Wed Jan 24, 2007 8:53 am
- Location: Redmond, WA
- Contact: