Puppy Linux Discussion Forum

[mcewanw]

Good Quality Text To Speech synthesiser dotpet

A special research version of flite from:

http://hts-engine.sourceforge.net/

As it stands, this program, buffers and plays a maximum of 1024 characters, but the program could be compiled to use a larger buffer, though with a bigger processing start delay (EDIT: Alternative 32kByte speech buffer version now also available below):

flite+hts_engine-0.91.mce02.pet compiled on Puppy 4.3.1

The dotpet includes flitet, flitet2wav, flitetf, and flitetf2wav. These are very small shell scripts which the dotpet installs in /usr/local/bin. Open them in any text editor to see brief, simple, usage instructions, which are repeated here:

# Usage:

# flitet "hello world" | aplay

# flitet2wav "hello world" outfile.wav

# flitetf infile1.txt [infile2.txe ... infileN.txt] | aplay

# flitetf2wav infile1.txt outfile.wav

In the above, t on its own stands for command line typed text, whereas, tf stands for "text file".

At last - a good quality, open-source Text to Speak synthesiser: a special compile of flite with the new HTS voices. The HTS voice is trained using Hidden Markov Model from the CMU ARCTIC database. Festival TTS could use CMU ARCTIC, but that required a 100 MB download of the voice data... But this new technique of using HMM results in pretty much as good quality with only a 2 MB voice data download!

Much to my surprise the dotpet for this came out at only 1.4 MB download size!

I'm very excited about this program! Goodbye espeak for me!

Also attached a sample in case you want to hear the quality before downloading/installing flite_hts_engine: amigo.wav (tarred and gzipped to satisfy forum upload requirements)
--------------------------------------------

Also attached is the older version (flite+hts_engine-0.91.f.pet), which has the limitation that it only sends its output to a wavfile, so can't pipe directly to, for example, aplay. (Note that you can only install one of the two versions; I suggest you use the flite_hts_engine_0.91.mce one, since being able to pipe from stdout is a huge benefit).

Older version:
flite+hts_engine-0.91.f.pet was also compiled on Puppy 4.3.1

This older version includes flitet2aplay, flitet2wav, flitetf2aplay, flitetf2wav, flitet_aplay, and flitetf_aplay These are very small shell scripts which the dotpet installs in /usr/local/bin.

Example usage of these older scripts; enter in a terminal window (e.g. rxvt terminal):

flitet2aplay "hello world"
flitet2wav "Good Night from me" output.wav
flitetf2aplay infile1.txt [infile2.txt ...]
flitetf2wav infile.txt output.wav
flitet_aplay "My name is William"
flitetf_aplay infile1.txt [infile2.txt ...]

In the above, t on its own stands for command line typed text, whereas, tf stands for "text file". The t_ and tf_ versions use a fifo (named pipe called /tmp/flitefifo) instead of a temporary regular file as a means of communicating to aplay.

[mcewanw]

Took me a while getting this all together into a 1.4 MByte dotpet, but it is now done: attached to the first post in this thread. A small download for such relatively good speech quality.

Note that this is very different from standard flite. Not only is the quality of speech much better and more natural than that produced by standard flite or espeak but the usage of the main executable (/usr/bin/flite_hts_engine is quite complicated in that it involved many options for feeding in the speech parameters. That's why I've supplied the four small scripts (/usr/local/bin/flitet2aplay etc).

You should examine the contents of these scripts if you want to see how to use the main executable on its own, or in your own scripts etc. I didn't find a way of piping the output of flite_hts_engine to aplay, so resorted to using a temporary output file (/tmp/fliteout.wav). Anyway, these small scripts are just simple exemplars, which you are welcome to improve upon.

You might also find the Documentation file for flite_hts_engine a worthwhile read:

http://downloads.sourceforge.net/hts-engine/flite%2Bhts_engine_readme-0.91.txt

[mcewanw]

The bad news is that I made a wee mistake, in the first upload (flite+hts_engine-0.91.pet) so relatively quickly (I"m on dialup) re-uploaded the fixed version: flite+hts_engine-0.91.b.pet

Actually, the main program was fine in both, but I used a $1 is the small script flitet2aplay when a "$@" was much more flexible, rendering it easy to use as a mod to technosaurus's excellent hotkeys-0.1.pet for text2speech. To do that, simply change technosaurus's code for /usr/bin/text2speech to:

EDIT: Altered the code below so it works with the latest flite_hts_engine...mce... dotpet downloadable from the first post in this thread.

[MU]

impressioning!

Note: if the downloaded file is called
flite%2Bhts_engine-0.91.b.pet
then you must rename it to:
flite+hts_engine-0.91.b.pet

Mark

[amigo]

Excellent! I had a play with it the other day. I found some other voices that work with it as well. I was dissapointed that it doesn't directly speak from the text (I mean that it has to be outputted to a wav and then played. Maybe we can get one of those studenty that developed it to patch that capability in there. What they appear to be doing is using the flite text-to-speech engine, but then coupling that to another voice internally before finally outputting it as a wav. flite itself can output wav files instead of speaking directly, so there must be a way to channel the output from the hts_engine directly to the audio device -do I hear MU rustling about and looking into this??? Hint, hint

I've been using flite for a long time and always wanted nicer voices -I have my drag-n-drop source-to-package program notifying me with spoken messages -which can include the name of the package, but it would be un-handy to have to output and then play a wav file.

I've never gotten around to actually trying espeak and don't know how space it needs, but flite is a thousand times smaller and easier to get going than festival. With these hts voices we can have the same voice quality now as festival -even though it is a bit bigger than flite by itself. i fonyl we could figure out how to get flite or flite_hts to load voices on-the-fly.

Your scripts are great anyway -that's exactly what I was going to do with flite_hts -but you've saved me a bit of time

Another thing to work on is finding out how to create even more voices in different languages -it's all very compley for my old brain. If I were younger, I'd probably be studying working in this field, though. It makes rocket science look like kids-play. text-to-speech s the easy part -it's speech-to-text that is a bugger!

Edit: I just listened to the amigo.wav file... you'll get a more accurate rendering of my voice by playing that text directly with flite LOL.
I call the standard flite voice 'Bruce' as it sounds a lot like the voice(named Bruce) I used to have on my iMac using some t2s program I found.
MU will get a kick out of this: since I am in Germany, I tried to teach Bruce to speak German by feeding it 'weirdly' spelled English. For while we had a recording of Bruce on our phone answering machine -I made him speak German but with a distinctly 'Ami' accent. ROFL

[mcewanw]

New dotpet uploaded, and I've changed the name to get rid of the plus sign, so now: flite_hts_engine-0.91.c.pet

[mcewanw]

Updated the dotpet to version 0.91.d (I had made a scripting error in 0.91.c sorry). Refer to the first post of this thread for changes, usage details.

EDIT: I note that flite_hts_engine seems to have a bug in that, it terminates on reading a txt file as soon as it encounters a carriage return. I'll have to double check if that is true. I don't think the problem lies in my /usr/local/bin/flite... scripts (but I'll check that too!).

Using flitet_aplay or flitet2aplay with text from the clipboard [called up by Alt-l (i.e. Alt-small L), for example, from technosaurus's hotkeys-0.1.pet text2speech script, doesn't seem to choke on any embedded carriage returns, which is currently mainly how I am using flite_hts_engine: http://www.murga-linux.com/puppy/viewtopic.php?p=365966#365966)

Yep, I'll update a workaround for that bug (using cat and a pipe).

[mcewanw]

0.91.e dotpet now uploaded

with workaround to carriage return 'bug' in flite_hts_engine (as described in previous post).

Note that you can now also concatenate files on the commandline with flitetf_aplay and flitetf2aplay scripts.
e.g. flitetf_aplay infile1.txt infile2.txt infile3.txt ...

[mcewanw]

0.91.f dotpet uploaded

fixes a bug in flitet_aplay

[amigo]

Great! I had the same idea of using a fifo to be able to play the output directly -glad to hear it works. That should make it much easier to stream long teyts -I mean if you were converting long texts it could be a problem with both time and disk space.

I've been trying to get some other hts voices to work, but they seem to be made for festival, so no luck yet...

Thanks very much for versioning your pets I missed c,d and e overnight, but at least I know that today's version is different just by glancing.

[mcewanw]

I've discovered a current limitation; flite_hts_engine will only play back a text of maximum size 1024 characters, which is fine for some applications, but not so good for reading books. For texts larger than 1000 characters in size you'd need to write a program to send the text to flite_hts_engine in chunks, and for best effect the chunks should stop on word boundaries... [for example, send a chunk, and as soon as aplay closes, send another chunk to reopen aplay etc... Personally, I'd do that in C since easy to make aplay block, but then, it might be easier to modify flite_hts_engine such that it doesn't have the limitation and also produces output to stdout so that it can be piped...] That nuisance limitation creates a nice programming project for somebody!

If I am wrong about this limitation, please let me know - but 1024 text characters is the maximum I get processed by flite_hts_engine at a time on my system.

EDIT: On further thought, whilst it would be relatively easy to write a short shell script or C program to send blocks of words to flite_hts_engine, the problem would then be the wait involved in it processing the new block prior to sending it to aplay - that would be a painful delay! So looks like we have to accept the 1000 char limit for now or dig into a bit C programming/modify flite_hts_engine in the hope of removing some of these limits (the -o output.wav bit shouldn't be too tricky at least). Alas, I have no time for that for some months due to selling house and international relocation - but I'll check back later to see if the problems have been resolved meantime.

[mcewanw]

I think this is probably the cause of the 1024 character to speech limitation:

#define INPUT_BUFF_SIZE 1024

It is near the top of flite_hts_engine.c (in the bin folder of the untarred source code). So easy at least to increase the INPUT_BUFF_SIZE and recompile. I'll try that as a test, but leave the dotpet as it is for the moment.

It is probably not good to increase the input buffer too much anyway - the processing delay before speed first starts would tend to increase proportionally I think.

[mcewanw]

Yes, increasing that buffer size to, for example, from 1024 to 2048 does double the amount of text spoken before the program shuts down. Actually, I couldn't resist going a bit further and made a few other changes to the C source code such that, on recompiling, I can now do the likes of:

flite_hts_engine the_voice_parameters... "hello world" | aplay

i.e. in the new version I am working on you don't need a wav file or a fifo all - so that bit solved (though some tidying up/extra code to finish off before uploading the new dotpet and scripts). I'll C code it in such that you have a choice of a wav file or use a direct pipe to, for example, aplay... but I don't really want to change the buffer from 1024 since the processing delay before it starts playing becomes annoying (on my machine anyway).

@amigo:
How long does a big chunk of text (over 1024 chars) take to start playing (using say flitetf_aplay) on your machine (and what specs has your machine?)

Can standard flite read any size of text and without startup delays? Actually, I'll install that and check. I expect the old voices didn't require much computation.

[amigo]

I've been playing with this too. I wrapped the existing scripts into a single app which (trys) to make sense of any options given. I#ll post it below.
But first, flite doesn't have any limitations about file size and starts streaming the output right away AFAIK. Of course I realized right away that the wait time would be long for larger texts using flite_hts_engine, but I hadn't found the limit to total text size -even though I thought I was feeding pretty long text to it. It had me wonderinf how we could stream the input into the program, but my first attempts at using straight cat without the echo were not working. This:
echo -E $(cat "$@") converts the text from files into a single long line.

I think you might find it easier to get flite_hts_engine to output to stdout than trying to 'chunk' the input. A look at the code for flite itself should give some clues on how to do it since it can either write to a file or output speech directly.

I'll get back at your later with my results -I'll need to to put together some example text with measured length.

Here's my flite_hts wrapper script:

[mcewanw]

new 0.91.mce01 dotpet uploaded

(EDIT: had a bug in the scripts. Uploading 0.91.mce02 soon...:-)

writes to stdout or wav

It was easy. I just left the buffer at 1024 for now though, since in my experience flite_hts_engine tends to garble text quite frequently when it comes across certain combinations of words, so long files not so good anyway, but I'll take a poll on that. Can easily compile a larger buffer version if wanted.

I only needed to make one change to allow the output to go to either stdout or to a wav. Just needed to set the wav file descriptor (wavfp) to stdout as its default state, in the attached (modified in that way) source file: flite_hts_engine.c (attached as a tar.gz)

I should make a diff, I know, but I'm tired and need to sleep...

Read the first post for new usage instructions. Clearly the scripts have radically changed (only 4 helper scripts needed to get going now...)

mcewanw http://wiak.org