Andrew Thompson added a comment - 22/Jan/10 5:31 PM From the FS home page: "The voice channels and the conference bridge module all can operate at 8, 12, 16, 24, 32 or 48 kilohertz and can bridge channels of different rates." There has been some talk about down-sampling as part of the make process to keep users from having to download all the different bit-rates of the sound files. I expect the would be dowsampled from the highest FS supports which seems to be 48k.

Stéphane Alnet added a comment - 15/Feb/10 6:58 AM The audio files have been recorded. I'm starting to test them, and I'll be working on updating mod_say_fr over the coming weeks.

Stéphane Alnet added a comment - 15/Feb/10 11:06 AM Patch for review.

Stéphane Alnet added a comment - 15/Feb/10 1:00 PM The audio files will be available on Archive.org under http://www.archive.org/details/FrenchAudioFilesForFreeswitch

Stéphane Alnet added a comment - 15/Feb/10 1:37 PM The patch should be applied if it looks OK. Version 0.1.0 of the audio files are now on Archive.org: http://www.archive.org/download/FrenchAudioFilesForFreeswitch/freeswitch-sounds-fr-fr-sibylle-8000-0.1.0.tar.gz http://www.archive.org/download/FrenchAudioFilesForFreeswitch/freeswitch-sounds-fr-fr-sibylle-32000-0.1.0.tar.gz http://www.archive.org/download/FrenchAudioFilesForFreeswitch/freeswitch-sounds-fr-fr-sibylle-16000-0.1.0.tar.gz This probably needs to be added to a Makefile somewhere as well (make-sounds?).

Stéphane Alnet added a comment - 16/Feb/10 11:56 AM I'm working on more complete audio files and a 48kHz version. I'll post them with a new version ID (0.1.1) on Archive.org.

Stéphane Alnet added a comment - 22/Feb/10 5:16 PM The new audio files are available on archive.org. However, while testing further I found the following: 2010-02-23 00:02:34.247165 [DEBUG] switch_ivr_play_say.c:273 Handle say:[#] (fr:fr) 2010-02-23 00:02:34.267158 [ERR] mod_sndfile.c:194 Error Opening File [/opt/freeswitch/sounds/fr/fr/sibylle/phonetic-ascii/35.wav] [System error : No such file or directory.] I need to review the problem (the path is missing "8000", which I'm going to assume for now is a problem in mod_say_fr), but 35.wav is also absent from my sound archive.

Stéphane Alnet added a comment - 23/Feb/10 11:09 AM Issue was due to content of sounds archives, not due to code. I've updated the sounds files to version 0.1.3 on archive.org, and the patch file is good as it is.

Stéphane Alnet added a comment - 23/Feb/10 11:18 AM Mike, I created this under the wrong project (not sure where this actually belongs -- modapp, modevent?). Please review & commit. Thanks,

Marc Olivier Chouinard added a comment - 03/Mar/10 3:11 PM Hi, here is the mod_say_fr patch that I use with the June Wallack French sound set located at : http://svn.freeswitch.org/svn/sounds/trunk/fr/ca/june/ http://64.235.217.39/tmp/auto_git_export/mod_say_fr.diff We should consolidate work on it. The biggest reason why my patch havent been commit is Math wanted to work on how we deal with gender in a better way than I did in mine.

Stéphane Alnet added a comment - 04/Mar/10 5:02 AM Hello, Regarding the changes for gender I agree we should avoid adding new values in switch_types.h because it means we change the interface for "say" -- some languages have more variants than French does (for example classes in Swahili), which means the list would just keep growing. Since this only applies to numbers, maybe we could have the first or the last character of the "number" string/parameter be an optional "f" or "m" to indicate "féminin" and "masculin"? For example: "f21" or "F21" are "vingt-et-une", while "21" or "m21" or "M21" are "vingt-et-un". If that sounds OK then I'll merge your patch and mine + updates for mod_say_fr.c, and add fr/ca/june as the default voice for fr-CA. (Hmmm... I guess I need to look into fr/ca/june to make sure all the sounds I listed in vm/sounds.xml are there.)

Marc Olivier Chouinard added a comment - 08/Mar/10 1:19 AM I've committed my changes in r16933 with MikeJ changes to the say system to add gender support. MikeJ had a preference to do the whole recording of the number that are different rather than add different code to manage both of them. I personally hate to do sound file editing and merging (unless we do the recording too)... Anyway, I can barely see my monitor rightnow... going to bed. You should come in the Wednesday Conference call to talk about it maybe.

Stéphane Alnet added a comment - 08/Mar/10 2:51 AM I think that's cute but it won't scale. See e.g. http://search.cpan.org/~jhi/perl-5.8.1/lib/Locale/Maketext/TPJ13.pod (which I falsely assumed was known fact). I'll try to make it to Wednesday's call.

Mike Jerris added a comment - 08/Mar/10 2:57 AM what specifically won't scale?

Stéphane Alnet added a comment - 08/Mar/10 3:21 AM French is only slightly more complicated than English (two genders instead of none). In a lot of languages, the form of the numbers will be dependent on more than one parameter; for example German will be dependent on the number and on the grammatical role of the noun the number is attached to (nominative, accusative, etc.); languages based on Swahili have 14+ classes to work with. Once you combine all these, the enum for SSG_* may have a few hundred items (to account for all possible combinations), most of them irrelevant to most languages. That's why I was offering to do the matching in the language module, to keep the API the way it was (which seems sufficient) and build the intelligence inside the module itself -- which we have to do already for French, based on locale differences between e.g. "soixante-dix" and "septante" (both mean seventy, but combine differently -- "soixante-et-onze" vs "septante-un" seventy-one). Now that doesn't preclude us from describing a standard way of calling the modules -- for example using quant()'s version -- e.g. "21,feminine" instead of "F21" as I offered -- but these will only be guidelines, since each modules will need it own set of parameters.

Mike Jerris added a comment - 08/Mar/10 3:37 AM I think you misunderstood the comment. The point was, where there are minor dialect differences that are simple, such as the ones you describe for french, I would rather have a few extra sound files that are not truly necessary instead of have differences in the code for each dialect. This is mostly for maintainability. I understand the need for things such as nominative etc, I am looking at this for russian and some other languages now, but that is not what I was speaking about.

Stéphane Alnet added a comment - 08/Mar/10 4:01 AM Hmmm... OK, I guess I got confused by the fact that we now have SSG_FEMININE, etc. in switch_types.h. (Are these here to stay?) The dialect differences in French are (slightly) more complex than the one Marc described in his patch. His code is missing some subtle differences in how to enunciate some numbers in some locales (because his patch is targetted at fr-CA where these differences don't apply) -- but you can see these in the patch I posted. On the other hand these can all be constructed by playing existing sound files (i.e. files which are already named in the english fileset). But I don't see a great advantage in having code that says:   # single file   if(b == 7 && c == 1) { play("soixante-et-onze.wav"); c = 0; } rather than code that says:   # split files   if(b == 7 && c == 1) { play("sixty"); play("and"); c = 11; } In both cases we have to code the exception (and as I mentioned this exception applies to some fr locales like fr-FR, but not others like fr-CA.) (As an aside the sound set we offered for French can enunciate both locales because we recorded both forms.) I'm not sure what the alternative would be: are you suggesting a different sound file for each number between 1 and 99?

Mike Jerris added a comment - 08/Mar/10 4:17 AM I think the confusion here is I am working form the assumption that voice will always be for only one dialect (as accent would be dialect specific) . Do you have one set of recordings that can be used for multiple dialects? Yes, gender is here to say, with more to come. With my assumption, your single file example would mean no exception to code, but using a single set of sound recordings for multiple dialects seems to turn that on its head. Our directory naming style for voices also lends to this assumption, can you confirm my understanding?

Mike Jerris added a comment - 08/Mar/10 4:24 AM Additionally, we need a more generic way in the interface to handle dialect and voice selection. Probably the module should directly register all supported dialects. We need to address how this will work in respect to selecting language, dialect, voice. Right now we can only select language, but all are necessary. We started discussing these issues tonight, but need more input on a generic way to handle this

Stéphane Alnet added a comment - 08/Mar/10 4:57 AM > Do you have one set of recordings that can be used for multiple dialects? Yes, the "sibylle" sound set was recorded on purpose that way. We have both "soixante-dix" (fr-FR and others) and "septante" (fr-CA and others) for seventy, for example -- mostly because I didn't know someone else was working on another set, so I assumed it would be the default set. The "sibylle" sound set (with the appropriate locale code, which I provided) wouldn't sound foreign e.g. to Belgian listeners. > Yes, gender is here to say, with more to come. OK, that's the part I think won't scale, but see below. > With my assumption, your single file example would mean no exception to code, but using a single set of sound recordings for multiple dialects seems to turn that on its head. I think the issue Marc and I have is that not using code seems very wasteful in terms of recording time and/or sound storage. E.g. in French you have to differentiate two forms of "1", "21", "31", "41", etc. based on gender, but all the other numbers between 1 and 99 would be identical in masculine and feminine form. And all the numbers above 19 can be made of a combination "%d0.wav" with another sound file between 1 and 19 (plus "and"/"et"), in all locales. So in your approach (if I understand properly) we would either have to record or build (and store) about 160 sound files which could just be concatenated by code on the fly (just like they are in English). > Our directory naming style for voices also lends to this assumption, can you confirm my understanding? Not sure -- both Marc and I followed the same layout for the "digits" subdirectory -- staying close to the English model but adding exceptions (e.g. "1_f") where needed. So it seems the current layout makes sense. Looking at another language... in German I could see "ein" being 1.wav (nomative,masculine), "eine" 1_f.wav (nominative,feminine), "einem" 1_d.wav (dative,masculine), "einer" 1_f_d.wav, etc. On the other hand, most other digits would not need these (and combinations would not, but again something like "zwei und zwanzig" (22) can be built from "zwei" (2) "und" (and) "zwanzig" (20)). These come rather naturally; they are going to be language-specific anyhow, so why not let each language choose the most economic way to express itself? (Economic meaning also in terms of recording studio time.) As long as each dialect / locale within a specific language agrees on naming conventions for sound files, that doesn't seem too far off. > Additionally, we need a more generic way in the interface to handle dialect and voice selection. Probably the module should directly register all supported dialects. We need to address how this will work in respect to selecting language, dialect, voice. Agree, and IMHO this should also apply to gender / case / noun-class / ... None of us knows all the languages, dialects, or locales on which FreeSwitch might be used. I guess (and I might be reading too much in your approach) your fear might be that you will end up having to manage a hundred or so mod_say_XX without knowing the language themselves. In that case I'm sure that (for example) Marc and I wouldn't mind being called upon if adjustments need to be made to mod_say_fr, and I imagine it could be the same for other languages. On the other hand I think that some parts of the code (e.g. the comma/space/point removal code) could be put in a mod_say library/toolset that all languages could re-use, and which the FreeSwitch core developpers could maintain (independently from language-specific code).

Mike Jerris added a comment - 08/Mar/10 5:17 AM you are totally misunderstanding me: A param is passed in for gender, along with type, method, and probably other things in the future, there is no need for any specific language to use them if they don't need to, they are just available input. I am not saying to record ALL of those, I was saying if 1 dialect (excuse my translation to english) says seventy one as 2 words, and another says seventy-one as one word (some different pronunciation) then just always use the single sound file for those places there are exceptions. Now that i understand you use one sound set for multiple dialects, this is of course impossible. re: directories: I mean the base directory names i.e. en/us/callie I actually think you misunderstood me pretty much 100% on every response above. I am looking to have a standard way to specify language/dialect/voice, right now you can ONLY specify language, and by a dirty extension that must be stuffed into every say module, dialect, and optionally with an even dirty extension stuffed into every say module, voice selection. We need a core way to specify these without hacking this into every module with no standard way.

Stéphane Alnet added a comment - 08/Mar/10 6:37 AM As far as understanding stuff, I'm going by what's in this JIRA and was trying to guess the missing pieces, not having seen the conversation between you and Marc. > re: directories: I mean the base directory names i.e. en/us/callie I've always taken these as conventions, no more. If a voice is a French voice, it should end up in fr/fr/<voice>, French Canadian in fr/ca/<voice>, etc. My feeling is that how people use these is really up to them, since the mapping is done via configuration under lang/. In any case, let me know if/how I can further help.

Mike Jerris added a comment - 26/Apr/10 12:04 AM this isn't blocking on anything more than me having the time to properly review. I hope to get back to it soon

Fabien Toune added a comment - 14/Aug/11 4:41 AM Hello, I'm trying to use those french audio files with fs from snapshot, but the patch won't apply correctly. Am I missing something, or do I have to adapt the patch to match actual files ? Thanks !

Stéphane Alnet added a comment - 23/Aug/11 3:46 AM Fabien, FWIW: I haven't followed-up on mod_say development, and I don't really understand how we're supposed to patch for fr-FR versus fr-CA in the standard FreeSwitch code. Consequently I'm not planning to follow that route anymore, instead I've started working ( http://stephane.shimaore.net/git/?p=ccnq3.git;a=blob;f=common/freeswitch/lang/fr/say/sounds.xml ) on an alternative using conf/lang and the "phrase" command. This may not be as good (performance-wise) as a compiled module, but it's much more generic and doesn't depend on getting locale-dependent changes integrated into a module. To interface it (eg) with voicemail you could modify diff_fr.2.txt (in this JIRA) to use "phrase" with a "say" parameter (instead of the "say" command). I hope to be able to have this completed over the coming months, and I'll be happy to help if you want to make this work.

Anthony Minessale II added a comment - 25/Aug/11 11:44 AM There is not a problem working on code changes to make the language support better. I tried really hard to gather input when designing this interface, I only know English and a little French and C Basically what we have now is an attempt to put what can be done globally into the core and have each module implement whatever specifics are to that certain language. I would appreciate if you guys could assemble a multi-lingual task force and help figure out the best solution to make things the best they can be. I would like to have a czar for every language who maintains it so we can coordinate any changes. I am more than happy to change the interface however we need, for instance I have changed the en module to use say_string instead of playing the files to make it more flexible to generate spoken messages and not have to instantly play them. Let's do it right if we are going to do it.

Stéphane Alnet added a comment - 14/Mar/12 11:02 AM FWIW I implemented "say" as a phrase file (for French):    https://github.com/shimaore/ccnq3/blob/master/common/freeswitch/lang/fr/say/sounds.xml and used it to re-implement the voicemail phrase file with no dependency on "say":    https://github.com/shimaore/ccnq3/blob/master/common/freeswitch/lang/fr/vm/sounds.xml (This code only uses "phrase" and "play-file".) With pattern-matching it's easy to have a generic interface such as:   phrase("say-number", "1" ) -> "un"   phrase("say-number", "1f" ) -> "une"   phrase("say-number", "counted 1" ) -> "premier"   phrase("say-number", "counted 1f" ) -> "première" ("f" is for "feminine"; other languages could use more complex identifiers, e.g. class number: "c1", "c3" etc.). A convenient pattern is to use head-matching to pronounce segment-by-segment:   phrase("say-number", "9 million 356 thousand 672" ) This is used inside the say/sounds.xml code to rewrite large numbers into utterances.

Ken Rice added a comment - 03/Apr/13 10:43 AM Hey guys any update on this ticket? is there a good patch in the works?

Stéphane Alnet added a comment - 04/Apr/13 5:23 AM I noticed the archive.org links are obsolete. The audio files are at http://archive.org/details/FrenchAudioFilesForFreeswitch I maintain Debian packages with these files, mirrored here: http://debian.sotelips.net/shimaore/pool/main/f/freeswitch-sounds-fr-fr-sibylle/ @KenRice I've been using the phrase files I linked to above in production.

Ken Rice added a comment - 17/Apr/13 9:20 AM Hey Collins, review this for inclusions and report back

Michael Collins added a comment - 17/Apr/13 6:03 PM I have no issues with adding these to the vanilla configs. I am also okay with adding fr-fr-sibylle to our sounds repo if that's okay. My only question is whether or not this method of using phrase macros instead of say will work with fr-ca-june sounds or not. If not we just need some warning in a README or similar. -MC