When a language or voice file in espeak-ng-data is loaded the keyword
"translator" must be set so that other language options can modify the
values in struct Translator.
CheckTranslator() provides standardized error for all switch cases that
modify a value in struct Translator.
code cleanup: move stressLength, stressAdd and stressAmp handling in LoadVoice()
From now on, stressLength must be set before stressAdd because
stressLength will overwrite any previous value. Usually stressLength is
set in a language file and stressAdd in a voice file.
Previously the order of the two commands didn't matter.
code cleanup: remove unnecessary new_translator in LoadVoice()
It looks like this was used in situations where both "language" and
"translator" voice options were found. Since bda8b6f76a "translator"
hasn't been supported.
- fix a buffer overflow in ucd_tolower leading to failure when
compiling with address sanitizer
- force the use of C++ compiler for espeak-ng
- adding a malloc to have a null-terminated string in the fuzz target
- setting (but not overwriting) ESPEAK_DATA_PATH environment
variable inside the fuzz target
espeak-ng --compile-phonemes generates phontab, but during the
generation it starts by reading the old phontab. If works just fine,
apart from an error message, if this doesn't exist but if it does exist
it is not clear whether it might end up using old or bad data (e.g.
possibly crashing if phontab is corrupted making it very non-obvious how
to fix the problem...)
The same applies to en_dict as a result of espeak-ng defaulting to the
voice 'en'; again the phontab build works if en_dict is absent but a
spurious message is output. It's not clear what would happen if someone
tried to build a reduced espeak-ng configuration with just one (non
'en') language.
The fix is to change espeak_ng_CompilePhonemeDataPath to call LoadVoice
with a new flag to indicate the voice structure is just required to
compile phoneme data (I changed the error message as well to make it
clear where it comes from - there are two identical error messages, the
other one is in voices.c)
Within LoadVoice the flag causes LoadVoice to not set a default language
or voicename and to skip loading the old phontab or dictionary (both of
which fail in a git clean -dfx build).
I checked the result by doing a compile from-scratch build sequence with
and without the patch, i.e. I did:
git clean -dfx
./autogen.sh
./configure --prefix=a-test-directory
make
make install
Then I compared the two copies of "a-test-directory" as well as the log
file output:
$ diff -r logs/*
diff -r logs/original/make.log logs/patched/make.log
175,176d174
< Unknown phoneme table: 'en'
< Can't read dictionary file:
'/home/jbowler/src/espeak-ng/master/espeak-ng-data/en_dict'
$ diff --no-dereference -r local.original local.patched
Binary files local.original/bin/speak-ng and local.patched/bin/speak-ng differ
Binary files local.original/lib/libespeak-ng.a and local.patched/lib/libespeak-ng.a differ
Binary files local.original/lib/libespeak-ng.so.1.1.51 and local.patched/lib/libespeak-ng.so.1.1.51 differ
So the change has not altered phontab or any of the other generated
files, only the binaries as would be expected. (Note that I am
comparing truely clean builds; what you get if you download the source
and build from scratch. This is the standard approach for people who
build for distribution.)
Signed-off-by: John Bowler <[email protected]>
The only way (in Dec. 2019) to get espeak_ListVoices to actually list
all the voices, including variants and mbrola voices used to be to pass
a non-null voice selector with a null language pointer. This still
seems to be supported in SetVoiceScores, which still checks for a null
language (see the check right at the top), however new code has been added
for a pseudo voice "all" lower down which seems to do the same thing but
crashes with null. This change allows "old" code to continue working.
Signed-off-by: John Bowler <[email protected]>
93d3c67df accidentally changes number handling for finnish.
D_FRACTION2 seems to match finnish number standards. It causes the
decimals to be read as numbers instead of individual digits: 12,12 is
read "twelve point twelve" instead of "twelve point one two".
It is undocumented so it might cause regressions as well.
bugfix: allow both SSSML <audio> and soundicon punctuation
All sound file information goes to soundicon_tab. The contents of the files are not
loaded to memory before they are needed for synthesis.
This removes N_SOUNDICON_SLOTS that divided soundicon_tab into two
parts for unknown reasons.
TODO: LoadConfig() is currently undocumented. The logic should be
moved to LoadVoice() and documented.
Soundicons are used for external audio with SSML <audio> tag and for
replacing punctuation names with sound files in LoadConfig().
Currently there's a bug wih soundicon slots: if both LoadConfig and
<audio> are used, the punctuation reserves all slots and no sound from
<audio> is played.
The SelectPhonemeTable(voice->phoneme_tab_ix) has no effect for tests.
Passing other values here breaks tests. That means that the relevant
calls SelectPhonemeTable() are already made in other functions.
voice->phoneme_tab_ix is set in LoadVoice().
speed.fast_settings[] was introduced in 7b2eecc724 to be used with
Sonic. Looks like after 7b2eecc724 the code related to everything
except fast_settings[0] was removed.
Might be that speed.fast_settings[0] is also irrelevant and could be
removed.
See commit message for 23a4d88f.
This commit fixes cmn and yue.
CalcPitches_Tone() now accepts cmn for translator_name.
SelectTranslator() now has a case for yue instead of zhy.
Option "language <name>"already causes SelectTranslator(<name>) to be
called. Having two options to do almost the same thing is unnecessary
and confusing.
In the long term, all options from SelectTranslator() should have a
switch case in LoadVoice() so they are user configurable (see #218). If
needed, a new option (maybe called "LoadOptions") could be added to load
an existing voice or language file.
Changes language configuration files for: hak, cmn, yue, ltg, ms, mb-ma1.
No changes to users.
voices: Change default number pronunciation rule to enabled.
docs: add details about number flags to the documentation.
It's clearly intended to be enabled by default:
- it's defined as default behaviour translate.h (NUM_DEFAULT)
- tr_languages.c sets many default values related to number processing
that have no meaning unless langopts.numbers == 1.
It is also a more sensible default since most languages will want to
have number processing on. This makes adding new languages easier
because adding an entry to tr_languages.c is unnecessary.
A negative side effect is that languages with partial number defines
might experience bugs when reading undefined numbers. This is a bug and
should be fixed.
This will have the side effect of enabling number processing for
languages that currently have it disabled. However, there shouldn't be
any.
Here's a way to check affected languages:
for voice in $(ESPEAK_DATA_PATH=`pwd` LD_LIBRARY_PATH=src:${LD_LIBRARY_PATH}
src/espeak-ng --voices | grep -v Languages | awk '{print $2}'); do
OUTPUT=$(ESPEAK_DATA_PATH=`pwd` LD_LIBRARY_PATH=src:${LD_LIBRARY_PATH}
src/espeak-ng -qx -v $voice "1 - 2 - 3 - 12 - 123") && echo "$voice:
$OUTPUT" ; done
These voices clearly benefit from enabling numbers (they already have
number rules in *_list):
ba, cmn (zh), hak, haw, ja, kok, nb, nci
Some languages are missing some definitions (like _12) in _list files.
It causes the program to skip some numbers.
Numbering needs to be turned off explicitly for:
jbo, mi, my, piqd, py, qu, quc, th, uz
Languages with no number rules at all:
chr, cv, he, nog, tk, ug