Dear Peter and fellow festival maintainers, I think commit 9857746e5c9ca106b8f051a0198af05152fad0b1 fixes this. See commitdiff at [1].
Basically I added a flag to know whether or not proclaim_voice was found. If proclaim_voice is not found, voice is registered as it was done before the patch. I think this solves the issue once and for all. [1] http://anonscm.debian.org/gitweb/?p=tts/festival.git;a=commitdiff;h=9857746e5c9ca106b8f051a0198af05152fad0b1 2014-04-16 6:10 GMT+02:00 Peter Drysdale <drysdalep...@gmail.com>: > Dear Sergio and fellow festival maintainers, > > Sorry for the delay - I only bisected this yesterday due to breaking > of loading of some demo voices with an unhelpful error message. > > I wish to revisit the solution for closing this bug. > The solution changes the behaviour of (voice.list). > In particular voices which do not contain proclaim_voice information > fail to appear in the voice list. The current version of festival will list > such voices. This would be less of a problem except for > some of upstream's provided demo voices do not include this information. > I didn't find this earlier since I do not use those demo voices but users > often use them since they are explicitly provided by upstream. > > It should be noted that the last paragraph of Chapter 24 of the Festival > manual > (which we ship) discusses that (voice.list) should contain possible voices > not > just valid voices. > > Would it be possibly to alter this patch solution so although default voice > is > set from a valid list - BUT (voice.list) continues to contain possibly > invalid and/or > voices without proclaim_voice (such as upstream's provided demo voices). > > best regards, > Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
