Test of Text-to-Speech (TTS) Abbreviations in Waze Clients

Image This is the place to discuss issues that are relevant for locations in the US. For any other discussions, please use the main forums.

Moderator: adriansinger

Re: US Regional Coordinators Resources

Postby GizmoGuy411 » Fri May 23, 2014 8:09 am

sketch wrote:
AlanOfTheBerg wrote:
GizmoGuy411 wrote:"Nat" says "National"

This should be removed. It's not a good abbreviation and there are "Nat" streets in the US.

"Nat'l" should say "National". But yes, "Nat" should not. We really should be more careful with these.


I was not clear in the list. "Nat" was NOT our submitted request. It is an old abbreviation that always said "National". And yes it should be removed.

It was added to the list to show all the abbreviations we current have for an item.

Please recheck the list above, as I have revised it and added a few more and have added some notes.

We may need to reconsider some other additional old abbreviations.
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: US Regional Coordinators Resources

Postby GizmoGuy411 » Sat May 24, 2014 3:25 pm

sketch wrote:
GizmoGuy411 wrote:"NE-123" says "Northwest 123"

I hope this is a typo!


I'm sure enough it was a typo that I changed the post.

I had 15 min to get on the forum and read some posts and try to test, and the TTS server is down. So more later.
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: Test of Text-to-Speech (TTS) Abbreviations in Waze Clien

Postby GizmoGuy411 » Sat May 24, 2014 3:47 pm

jdeyoung wrote:I ran across the following UR:
https://www.waze.com/editor/?lon=-88.01232&lat=41.60056&zoom=5&layers=933&env=usa
@report:The street name is correct. It is "SR-7 / 159th St". But it says "State Route Seven Thousand One Hundred Fifty Ninth Street".

For those unable to see that UR.
Have there been any recent changes to fix this? I searched and couldn't find anything related to this particular thing. And if this isn't TTS issue per se, what would be the recommendation to fix?


I've been testing this for a few days, and have more tests to go. So far, here is a progress report with some interesting test results. (For those not aware, a "%20" in the text is a space.)

"Exit to SR-7 / 159th St" Tests in the format; TEXT SUBMITTED = TTS RESULTS

SR-7%20/%20159th%20St = state route seven thousand one hundred and fifty nineth street

SR-7%20/%20159st%20St = state route seven thousand one hundred and fifty nine street street

SR-7%20/%205013st%20St = state route seven <pause> five thousand thirteenth street
(notice that it ignores the first "st" in this example)

SR-7%20/%205013nd%20St = state route seven <pause> five thousand thirteenth street
(notice that it ignores the "nd" in this example)

SR-7%20/%205013rd%20St = state route seven <pause> five thousand thirteenth street
(notice that it ignores the "rd" in this example)

SR-7%20/%205013th%20St = state route seven <pause> five thousand thirteenth street
(notice that it ignores the "th" in this example)

SR-7%20/%205012th%20St = state route seven <pause> five thousand thirteenth street
(notice that it ignores the "th" in this example)

Observations:
- Although I was able to remove the "Exit to " from the tests, I did not yet work to narrow the test further.
- Numbers from 0 to 999 produce the error. Numbers from 1000 to some untested limit do not. Further testing is needed for digit count rather then actual numbers, such as "0999" vs "999".
- "...st, ...nd, ...rd, ...th" as number suffixes are usually ignored, in favor of what the actual number would say. The "...st" is an exception for some cases that I need to test for again.
- At one point in the tests I heard "Saint" for "st" (no period). I will need to test further to discover it again.
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: Test of Text-to-Speech (TTS) Abbreviations in Waze Clien

Postby GizmoGuy411 » Wed Jun 04, 2014 3:46 am

On going problems with "N" not being pronounced as "North" STILL!

I'll try to test this issue more to resubmit it AGAIN to Waze.

The two other strange issues mentioned earlier are still not submitted to them, as testing has been tenuous at best lately with the ongoing zero byte TTS file returns as many of you have noticed in the beta clients.
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: Test of Text-to-Speech (TTS) Abbreviations in Waze Clien

Postby GizmoGuy411 » Wed Jun 04, 2014 4:49 am

GizmoGuy411 wrote:On going problems with "N" not being pronounced as "North" STILL!

I'll try to test this issue more to resubmit it AGAIN to Waze.

The two other strange issues mentioned earlier are still not submitted to them, as testing has been tenuous at best lately with the ongoing zero byte TTS file returns as many of you have noticed in the beta clients.



Initial tests are not confirming the problem:

http://www.gizmoguy411.com/Waze/TTS/Gar ... wy%20N.mp3

http://www.gizmoguy411.com/Waze/TTS/New%20Jersey%20Tpke N.mp3

Could you provide segment Permalinks so they can also be tested?
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: Test of Text-to-Speech (TTS) Abbreviations in Waze Clien

Postby GizmoGuy411 » Wed Jun 04, 2014 6:19 am

qwaletee wrote:Have we ever had a problem with X=10th before? Per the UR below, the X in Malcolm X Blvd was being pronounced "tenth." I don't know if this is an isolated occurrence. I imagine if it is a problem, it could be resolved by changing "X" to "X." (with a period).

https://www.waze.com/editor/?zoom=5&lat ... 35&endshow


Although I had recently submitted the "Malcolm X" issue to Waze, I have since removed the submission as there is a larger issue with Roman Numerals that needs to be addressed. In another thread elsewhere, I posted the following:

GizmoGuy411 wrote:While testing other TTS issues, the "Malcolm X" issue was mentioned again in the TTS test thread.

Here are the very inconsistent results I found testing just a few Roman Numeral examples:

Fred IV = Fred eye vee
Fred X = Fred ex
Fred XIV = Fred fifth
Louis IV = Louis eye vee
Louis X = Louis ex
Louis XIV = Louis fifth
John IV = John the forth
John X = John the tenth
John XIV = John the four-teenth
Malcolm IV = Malcolm the fourth
Malcolm X = Malcolm the tenth
Malcolm XIV = Malcolm the four-teenth
Mark IV = Mark eye vee
Mark X = Mark ex
Mark XIV = Mark fifth

Curiously the results for [Malcolm X] are correct for Roman Numeral usage, but wrong for what we need for that particular name,whereas other names with "X" say "ex" as in the letter x.

We may need to use [Malcolm "X"] to get the results we want, in order to differentiate from Roman Numerals usage. This would be consistent with the use of quotes around N, E, S, and W to get the letters pronounced instead of the cardinal directions.

Also note that for some names "XIV" is pronounced "fifth" and other others "fourteenth".
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: Roman numerals

Postby GizmoGuy411 » Wed Jun 04, 2014 6:55 am

dbraughlr wrote:Whether Louis XIV is read as lewis ex eye vee or lewis fourteenth, it won't be perfect.

I think we want C, D, I, L, M, V, and X pronounced as letters. It seems that Roman numerals are the exceptions and should require special notation if used at all.


While the logic that the Roman Numerals are the exceptions, and therefore should require special notations seems correct, we have to remember that we have already have set a precedence to use quotes around the letters N, E, S, and W, to get the them pronounced as letters instead of the cardinal directions.

Therefore we may need to follow suite for the letters used for Roman Numerals too.

Of course there are other conflicts to consider as well including: (examples using valid Roman Numerals only, and not every combination of the letters used in Roman Numerals)

CD = cd or 400 ?
CM = centimeter or 900 ?
DC = District of Columbia or 600 ?
MD = Maryland or 1500 ?
MI = Michigan or 1001 ?
MIX = Mix or 1009 ?
MM = millimeter or 2000 ?

So maybe Roman Numerals could use a period after them instead of quotes to differentiate them.
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: Roman numerals

Postby GizmoGuy411 » Wed Jun 04, 2014 3:10 pm

dbraughlr wrote:
GizmoGuy411 wrote:Therefore we may need to follow suite for the letters used for Roman Numerals too.

From what you listed, there are thousands of them. That's clutter.
What range do you really intend to cover?

GizmoGuy411 wrote:So maybe Roman Numerals could use a period after them instead of quotes to differentiate them.

That doesn't seem likely, at least not if you intend to cover a range beyond 1 to 30.

What's wrong with using Louis the 14th instead of Louis XIV.? If anything, our experience with N/E/S/W should tell us that it was a bad precedent that should not be expanded.


I agree with sketch in that I am really not very concerned about Roman Numerals and that the letters themselves are more important at least for North America using the English voices.

What I am MORE concerned with is why these variations exist in the first place and if they are indicators of some bad RegEx that needs to be addressed at the Waze end, as other parts of the world may need Roman Numerals.

So any submission I may to Waze at this point will be to just point out the inconsistencies. We have plenty of one off issues with TTS pronunciation that is something that may be able to be adjusted in the future via the editor on an individual basis.

Issues like "Sulgrave Dr" being pronounced in the past as "Sulgrave Doctor" however where of concern as in this case it may have been indicative of a wider problem that could effect other names as Doctor vs Drive was more of a global concern.

Actually I don't think there are many more instances than those I listed as potential conflicts with Roman Numerals. This was limited to valid Roman Numerals, not simply every possible combination of letters used in Roman Numerals. I'll edit that in the prior post.
Not sure I agree with you that there are thousands of RN combinations, as many combinations of the letters in RNs are not actually valid RNs.
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: Test of Text-to-Speech (TTS) Abbreviations in Waze Clien

Postby GizmoGuy411 » Sun Jun 08, 2014 4:37 pm

AlanOfTheBerg wrote:
sketch wrote:https://www.waze.com/editor/?lon=-90.18022&lat=29.99981&zoom=5&layers=1925&env=usa&segments=20949819 "to Clearview Pkwy N"

I tried 16 times to download the TTS for this segment and got empty files every time. Not sure what's going on here. I know with 100% I heard two different "Pkwy N"-ending segments pronounced with "north" so this is ... confusing/concerning. The TTS system appears to be pretty unstable right now.

Finally got it: https://www.dropbox.com/s/sxefwon98h5s2 ... _1.mp3.mp3

Question is, why isn't the app getting this same thing?


Here is the TTS audio file from that actual segment (rather than web TTS test) using the Android beta client:
http://gizmoguy411.com/Waze/TTS/Clearvi ... wy%20N.mp3

It still sounds correct, saying, "then stay to the right to Clearview Parkway north".

And here is the same segment TTS from the Android non-beta client 3.7.8.0:
http://gizmoguy411.com/Waze/TTS/Clearvi ... .7.8.0.mp3

It also sounds correct saying, "at Clearview Parkway north".

I'm beginning to wonder if the "cc@tts" command is not always clearing the cache correctly.

Note: I deleted my previous post and reposted this to Alan's post regarding this, and my addition of the non-beta TTS audio file.
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

Re: Test of Text-to-Speech (TTS) Abbreviations in Waze Clien

Postby GizmoGuy411 » Sun Jun 08, 2014 4:58 pm

Kobes1878 wrote:


Hi all -

First off, great work @gizmoguy. I've been following this forum and cleared my cache as advised above. Here is another example of the "Enn" error getting on to the NJTpke over here. Id imagine a lot of these ramps would produce the same pronunciation.


I just tested your segment in both the current beta client and in the non-beta 3.7.8.0. client and both said "... north" for me.

However while testing I noticed something curious and troubling at this segment street named "Exit 4: SR-73 / Camden / Philadelphia":
url=https://www.waze.com/editor/?lon=-75.0722&lat=39.86048&zoom=5&layers=933&segments=66875972&env=usa

In the beta client, it incorrectly said "exit 4, ess arr 73, Camden, Phildelphia" and in the non-beta the same segment it correctly said "exit4, state route 73, Camden, Phildelphia ...
ImageImageImageImage

Global Champ
U.S. CM
U.S. Great Lakes RC: IL, IN, MI, OH, WI
AM: NW OH, NE IN, SE MI
Wiki Profile
Verizon: Galaxy S4 w/ Android 4.4.2 & iPad "3" w/ iOS 8.1.1
GizmoGuy411
Global Champ Mentor
Global Champ Mentor
 
Posts: 1280
Joined: Wed Oct 13, 2010 3:14 am
Location: NW Ohio, SE Michigan, NW Indiana tri-state area
Has thanked: 345 times
Been thanked: 206 times

PreviousNext

Return to United States

Who is online

Users browsing this forum: No registered users