I have been working at the Church for about three and a half months. During that time, my primary focus has been accessibility; making our sites more accessible, and improving our services to persons with disabilities, especially the print-disabled. One particular technology I have encouraged the Church to adopt is the Digital Accessible Information System, or DAISY for short.
DAISY is an XML based open ANSI approved standard for creating digital talking books. It has gained broad support in the print disabled communities and most agencies that produce books for the Blind have either already switched to the format or are in the process of doing so.
Currently, the Church records the Ensign, New Era, Friend, as well as most of our other major publications for the blind. These recordings are currently being distributed on cassette, but they are recorded at half-speed and we utilize all four tracks of the cassette separatly. This results in being able to fit about 6 hours on a single 90 minute cassette.
The reasons I believe that DAISY would be a good move for the Church are many. First, as mentioned above, it is for all intents and purposes an industry standard. On the other hand, the 4-track format is being supported less and less. Because it is based upon cassettes, and since cassettes are becoming rather scarce in general, the cost of the players and media continues to rise.
Another reason is that the DAISY format is much more flexible than the old 4-track standard. Properly created DAISY books allow the reader to quickly and easily jump from section to section, chapter to chapter, page to page, and even paragraph to paragraph. (As you might imagine, this especially makes a huge difference for the scriptures.) The user can either listen to the book being read by a human reader, or read the text on the screen. The user can add book marks, tell the player to automatically read or skip footnotes, and search for text, among other things. In comparison to cassettes, where the only navigation available was rewind and fast-forward, the increase in functionality is huge. In fact, many books which would not have been practical to produce on cassette, like the Topical Guide or Bible Dictionary, can now be made available Through DAISY
Finally, because the format is open, it doesn't require too much alteration to our existing processes to implement. The audio portion of the book is typically encoded in the MP3 format, which we are already producing for lds.org, and we use XML in our publication process, so the text can be easily incorporated.
So far, I have received an enormous amount of support for this proposal, but we still have a ways to go before we can begin to make a public release. Still, I am very optimistic.
The only area about which I have some concern regards the availability of playback devices. The least expensive hardware player sells for about $200, and a software player can be had for $50. Unfortunately, at this time, no good freeware players exist. However, the news in this regard is not all bad. The National Library Service for the Blind and Physically Handicapped, a division of the Library of Congress, has adopted DAISY, and so all eligible persons in the United States will soon be able to borrow a DAISY player at no cost. Also, because the format is based on mp3 files, the books will be able to be played in a standard MP3 player, although they will lack many advanced features when played in this manner.
However, this is not really a new issue. The 4-track format also requires a special player, and unlike Daisy, there is no less functional alternative. So, I believe that over all, more people will have access to DAISY than had access to the 4-track standard. Still, the accessibility to DAISY could be better, which brings me to my reason for posting.
I am wondering if there is anyone who would be interested in working on an open source DAISY player? I think it would be nice if we could have a solid freeware player to distribute with our DAISY titles. This is how I envision such a player working:
After the application was installed on the users machine, it would check to see if an internet connection was available. If one was, it would display to the user a library of content. This would include all the books, magazines, pamphlets, ETC. that we make available in DAISY. They could pick the titles they were interested in and they would be automagically downloaded, unzipped, and installed in their local library by the program in the background. If they chose a magazine, the
program would give them the choice of downloading just that issue, or subscribing to that publication. If they subscribed, new issues would be automatically downloaded on program startup, or optionally, we could have the program check in the background on system startup.
If the user did not have an internet connection, they could still load books from CD or their local hard drive.
Once the book was downloaded from the internet or otherwise loaded, the user could browse the table of contents, jump from paragraph to paragraph, and everything
else a good Daisy player supports. It would also show the text of the book in sync with the audio. There would be controls for enlarging the text, changing the color and contrast, and anything else that might help a partially sighted user. For the totally blind person with no screenreader, the application
under windows could easily be made self voicing with the Microsoft Speech Engine. It may also be possible to do something similar under the Mac as well.
Other possible features could include:
Ability to slow down or speed up the audio (a commonly requested feature in DAISY players).
Ability to begin listening to books as they are being downloaded.
Support for skippable content
advanced text searching
ETC.
I thought that the best language for this project would probably be Python. Python generally requires less development time than some other languages, it has broad cross-platform support, and although it is an interpreted language, there are ways to create native windows executables that are not too large. Also, I happen to know Python, so that is also a plus.
I considered Java, like the Family History Dept. uses for the Family Search Indexing app, but that requires either the user to have the right JRE installed, or that they have an internet connection. Neither is a supposition I feel we can safely make. Java also has a bad record when it comes to playing nice with screen readers, although that can usually be alleviated by some smart programming.
Anyway, those are my thoughts. I'm very much interested in people's feedback on this, and in finding out how many folks would be interested in helping out with development.
Thanks
Aaron Cannon
