Open MEAdams opened 7 years ago
Hi Michael, Thanks! I just took a brief look at your BibleVox project and it looks interesting. It looks like you are using Festival, correct? I actually already have text narration support in my KJPBS app and fully working. I just haven't done an official version release with it in there.
I'm using Festival on Linux and the SAPI ActiveX/COM object on Windows and the system Speech Synthesis Manager part of ApplicationServices on the MAC. All three were doing an OK job, depending on which voice training files you selected, but it could certainly be improved.
It looked like you had pronunciation rules for all of the words in the Bible. That part might come in handy for training the KJPBS speech, at least on Linux where I'm using Festival. I haven't done much on KJPBS lately, but I will certainly look closer at that in the future.
Thanks for letting me know about your BibleVox project! Donna
Donna,
Thank you for responding. The primary product of the BibleVox project is to develop a Bible proper names pronunciation lexicon. The lexicon source file (i.e. BibleVox/Tools/Lexes/BibleVoxLex.menu) is a flat-file that my tools software (i.e. BibleVox/Tools/Lexes/SSdict2CMUaddenda.bash - which calls a FLEX application) converts into speech engine specific syntax. Festival is the one I support now (i.e. a BibleVoxLex.scm SCHEME language file is created). I believe speech engines other than Festival can be targeted. I will look into the engines you have noted here (I am not now familiar with them) to get an idea of what might be needed (since I am sure you decided on those engines for good reasons).
I have tools to search Bible texts for all the words in my master lexicon so that I can pick out only those needed to support a text of interest. For example, I can find only those words needed for the KJV 1769 text for KJVBS. My major work has been to make pronunciation entries for the proper names of the Bible. However, I am adding common words that I find the speech engine mispronounces, also. Additional work is needed for the KJV text since I have spent most of my time on the ESV up to now. My Tools software makes this a less tedious task. However, I like listening to God's Word, anyway! I chose to process the ESV text because I was initially concerned about the sometimes more complex sentence structures of the KJV. I am finding that this doesn't seem to be a problem for Festival and am now working to verify that the all KJV proper names are in my lexicon (since the different translations spell some differently).
The Festival speech engine analyzes the Parts-Of-Speech (POS) of words occurring in sentences in order to resolve pronunciation discrepancies. For example, A cat does not have nine "lives". Michael "lives" in Maryland. The noun and verb form of "lives" are pronounced differently. This processing in necessary for Text-To-Speech (TTS) accuracy. The BibleVox lexicon provides the necessary POS tags. A target speech engine should be able to make use of them.
I hope you don't mind my long e-mail. I am glad to hear from you and I truly enjoy using your KJVBS application. The addition of the SoundEx algorithm is really a nice touch.
I'll post to your "issues" board again once I have finished verifying the KJV proper names entries. Whenever you get a break in your schedule, I'd love, if you agree, to get a KJVBS build with text narration support to work with and test. I run Ubuntu Linux with Festival.
P.S. Your software cross-platform installation method is really nice, too!
In Him, Michael
The "good reasons" for picking the speech engines that I did for Windows and Mac was because that's what comes already installed on those operating systems, making it easy for the average user to get running. I do all of my actual development work on Linux (it's essentially the only OS I use at home), so most of my work on it has actually been with Festival.
To keep the Linux version of KJPBS (and yes, it's a "P", for "pure", instead of a "V" in the "acronym") distro-independent, I built it in LSB (Linux Standard Base) which means it will work on all Linux versions that support LSB, which nearly all of them do right out of the box. However, I've found so far that it's been impossible to compile Festival for LSB. What that means is that users doing speech on Linux will have to install the Festival package themselves (rather than being bundled in the KJPBS installer) and they'll have to run it as a server. I have KJPBS set up to use Festival either as a direct library or as a client/server, so it can work either way.
As for trying it, you actually can already do so now, even before I do an "official" release. There are two ways we could do it. I run Kubuntu (I can't stand the Unity desktop with Ubuntu) -- 14.04 on my laptop and 16.04 on my desktop machine. Though 16.04 has proven to be a train wreck so far and I'm presently regretting having upgraded my desktop to 16.04. I'm on the verge of jumping ships to Xubuntu, with Xfce instead of KDE. Though KDE is Qt based, which is what I used for KJPBS (which is why it's so platform independent).
Anyway... If you are running the same distro as I am (specifically 14.04 or 16.04 -- it won't matter much if you are on Ubuntu or Kubuntu or Xubuntu, etc), I could send you the version compiled natively for the Ubuntu world and it should work until you upgrade some dependent system package that breaks it. Or, I could walk you through the process of compiling it yourself. It's somewhat involved, but not too difficult. Most of the steps can be seen in the Travis script file in the root folder of my repository. That script builds the Webchannel variation of KJPBS, but the GUI version is just a minor variation -- the core steps are the same.
The most flexible would be for you to compile it yourself, then you can easily recompile it whenever you upgrade something that breaks it.
KJPBS is really more of a "filter" than a "search engine". It doesn't really have to search for anything, as it already knows where all of the words are located. In fact, it doesn't have the actual text, in text form, anywhere. It generates it all on-the-fly from the word count/position and its list of words. That's how it can do proper counting and real-time searching in the search phrase windows with the drop lists and such.
It's simply filtering the word list. To find the next possible words, it just adds one to the position indexes of the first word you type and takes all of the words they point to to find the possible "second words" list. Then when you've picked your second word, it does it again by adding one to the indexes of that second word prefiltered with the indexes of the first word, and so on.
I was just thinking through how your pronunciation lists could be added and I think the most viable would be to simply add them to the main word list. Then all that remains is the part of speech, and it's possible I could derive that from the original OSIS (open-scripture information standard) database that I build the KJPBS database from, as that database also contains Strong's numbers and word lemma morphology from the original texts that might can be cross-referenced back to a part-of-speech easily.
So perhaps the extension to KJPBS would be the part-of-speech detail for the verse mapping and pronunciation rules for the word list from your project. Hmmm...
It must be time for me to start looking closer at the text-to-speech logic for KJPBS, as every time God has had a new part for me to work on, I start having people, such as yourself, start sending me things related to it. For example, the next text version in KJPBS will most likely be Latvian, believe it or not.
God Bless, Donna
Donna, I kept thinking to myself as I typed KJVBS why you didn't use KJPBS? I'm just getting old and need new glasses, I guess. Sorry about that.
I don't care for Unity either but have never used Kubuntu. However, Ubuntu has recently announced that they are dropping Unity development and are returning to Gnome. I don't know in which release the switch will take place in. I am glad you are using Qt. I have read of the difficulty that Gtk developers have in dealing with changes imposed by Gtk version updates (the Xiphos Bible app project in particular). Yours is a very polished looking and working Linux app using Qt. Also, I get tired of apps spewing all kinds of Gtk messages all over my console - even when working correctly. Ubuntu 16.04 LTS is what I am using and I don't need Unity much to have to deal with it.
It is my intention to eventually also port BibleVox to the CMU Flite speech engine. The high quality voices are available for it, also (BibleVox provides a script to down-load and install them in Festival on an Ubuntu installation - I believe it will work for Kubuntu). I have not looked into what must be done to port my TTS processing modifications to it yet. However, did you per chance try compiling Flite for LSB? The advantage being it is much smaller and faster (written in "C") than Festival (less impact on available hardware resources). Just curious.
The BibleVoxLex.scm file is read by the Festival speech engine upon startup. A server configuration reads it as well. So, Festival takes care of POS processing and uses the lexicons it is given to use. If you run the BibleVoxConf.bash script, it will create a .festivalrc file in your home directory which will inform Festival of where to find the BibleVoxLex.scm file (and you can configure which voice to use). See the BibleVox/README.md -> Installation -> BibleVox Configuration notes. So, your Festival system is ready to use the BibleVox lexicon as is (again, I haven't finished KJV name entries and all KJV common word pronunciation corrections). How you feed Bible text to Festival is the part I don't know. I currently run Festival on demand. You can look at and play with my BibleVox narration scripts to see what I do. I do want to find out how to include my TTS mods in a server configuration, though. You will notice that the init_speech.scm script is fed to Festival which includes my TTS mods.
Upon looking at your repository earlier, I started looking into Travis. I have no experience with it. If you point me to what to do, I'll take a crack at compiling if you like (or, I wouldn't mind getting stated with a build from you to help with finishing up my KJV lexicon entries and testing). My experience: I am retired. I used Linux at work developing Digital Signal Processing (DSP) software and hardware based test equipment for the Navy (software written in assemblers and "C"). I am old enough to have started on DOS (I actually predate microprocessors), got exasperated at Windows 3.1 (and Microsoft) and switched in the late 90's to Linux (before I had hardware powerful enough to run an Xserver). I don't know C++, but poked around in it years ago. That being said, my work was very specific and I am not an expert in any particular OS. However, I still have a few brain cells firing to learn new stuff.
If you would prefer to continue a conversation without filling up your GitHub issues page, here is my direct route: mea4git1@use.startmail.com.
Best regards, Michael
No, I haven't tried compiling Flite for LSB. Festival will work well, though, as it isn't difficult for people to install via their system package manager and just point KJPBS to it. Besides, I already have everything working well with Festival in KJPBS and don't really have time to rewrite KJPBS to use another system.
For the details of how I'm calling Festival, refer to the "KingJamesPureBibleSearch/programs/qt-speech" folder in the code repository and the QtSpeech_unx.cpp file in there. Basically, it's talking to it via a standard TCP Socket connection to the server and sending commands to it -- very similar to running the festival_client from the command-line (see the man page on "festival_client"). The only complicated part of it in KJPBS is that I'm using multithreading to keep the main app from hanging while it's speaking. All of the speech processing happens on a separate thread -- there's actually three parts of KJPBS that's multi-threaded. One is the main search engine logic (when it's enabled), the second is the online webchannel version to distribute the load across all cores, and the third is text-to-speech.
The way TTS works in KJPBS is that you can highlight a word or phrase or verse, etc, click the "speak" button, and KJPBS will send that text to Festival to speak. Actually, it will queue it with the rest of the phrases that have already been added and the other thread will send it when the TTS engine gets ready for it, because if it's in the middle of speaking, you wouldn't necessarily want to wait until it's done to queue up the next phrase. The best way to get familiar with it is to compile that version and try it out.
For the compiling, you don't really need any Travis experience. Travis is just the build server available via GitHub that automatically kicks off a code build and test sequence each time you check code into the repository -- it's mainly designed to catch commits that break a particular build. To use it correctly, I'd have to set it up for all of the different builds I support, as the idea is to catch when a change made for one OS breaks the build for another as early as possible, but I currently only have it set up for the webchannel build.
The reason I brought up Travis is that the configuration file for it, written in YAML, is basically just a list of command-line things you'd run on your Linux system's command-prompt to do the build. For the most part, you could simply run each of those commands on your system and it would compile it. Now -- you'll not want to run it exactly as it's there, as that's a different version of Linux and since it's a "one off throw away build system", I'm taking some liberties in how I'm doing some of the system package installs, forcing some changes that you wouldn't want to do on your actual system. And I also skip the Qt build step, as the free version of Travis doesn't allow enough runtime to actually compile Qt. So, I replaced it with a prebuilt Qt to make that work, but I have a "real.travis.yml" file that has the actual Qt build steps for reference or you can actually use a pre-built Qt, but you will need the source files for it and you'll need to do the "tweak" steps to the source folder described in the .yml file, needed because KJPBS works with either Qt 4 or Qt 5 and most of those tweaks makes the dependent source folders look the same for it. The other thing you'll want to change is the build settings to build the GUI version of KJPBS instead of the webchannel.
But otherwise, it's pretty much just running all of the commands listed in that .yml file. Since a thread discussing text-to-speech really isn't the place to discuss how to compile KJPBS, I'll ping you at your email address and walk you through how to compile it.
The other thing to do is to run the "get-festival.sh" script in the aforementioned qt-speech folder. Assuming the links in the script haven't gone stale (it's been a while since I've run it), then it should download and compile a local copy of Festival that can be directly used for compiling the Festival support into KJPBS. That will enable building the parts that directly integrates Festival with KJPBS. Right off, I can't remember if that piece is also needed if you only want to run it as client-server or not. But it shouldn't hurt anything to do.
Anyway.. start looking at the .travis.yml and real.travis.yml files to get an idea of the commands to run for building KJPBS and try running the get-festival.sh script from your checkout folder, and I'll ping you at your email address to walk you through the compile...
Also, another reason I haven't spent much effort in releasing the TTS feature in KJPBS is that I already have nine different narrations available on my live Webchannel search (http://webchannel.purebiblesearch.com/), in the "Bible Audio" options at the top of that page. Those human narrations are less mechanical and much more pleasant to listen to than the best of TTS algorithms I've found.
So the TTS feature is, at best, a help for the visually impaired and for the most part, they already have system-wide TTS features set up anyway. I intentionally designed KJPBS with full keyboard navigation support as well as mouse navigation to facilitate those system helper functions, as most operate as a "keyboard wedge".
I've spoken with a couple of KJPBS users who are visually impaired, and it seems to be working well for them using their existing system-wide utilities, without the TTS option in KJPBS. In fact, it's one more button they'd have to locate. So that's why I haven't worked harder to get it released.
It would be nice to have proper name pronunciation in the TTS logistics, and that's worth pursuing, but I think most people will probably prefer the nine narrations on the Webchannel version.
Donna, Really nice app. Would my GitHub BibleVox project be of interest to you for supporting a KJV text narration capability? MEAdams