Hi! We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
But as we’re losing ad-revenue from this then why not make a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Whatever was in your zip, ie. effectively nothing. I didn't have time to play with the original files before you released the zip version sans sms rules.
The comma is undoubtedly the result of the comma being encountered before the \s command is rescinded (by encountering a space?). My changes have fixed this, but not the semicolon issue. I have no idea whether the semicolon issue is present in your version - possibly/probably not, but I've not tested. _________________ Go Premium X / Go 1005
Any idea how to put in a /, there are a couple of roads near me that have 2 numbers A325/B3272 - it reads the first correct, but not the second.
To test for it, or to use it in the pronunciation? To test for it, you probably have to escape it with a \ To say it just a / - or slash ? But the bigger problem is going tp be adding all that 2nd number to the parsing rules! (Does reg exp handle recursion?)
MARViN2003 wrote:
The other thing I would like to fix is Motorway junction numbers with letters after them, like J4a is read as Junction 4 a (as in apple)
Needs a \s in front of it. Didn't have much time today, but did prove to myself that \s is required to speak a letter. But trick will be finding where to parse it ...
I did get couple of things sorted today:
\0 does work. And if I test for say A325 but then opt out by returning \0 I still get the semi-colon problem. But no test at all, ie. stock TT processing, then no semi-colon. So I suspect that these Reg Exp rules get executed INSTEAD OF the standard rules, not in addition to. So we have to supply all the required fixes, we can't depend on any already being in place.
So logically your version must have the semi-colon problem too. Indeed the US version must also exhibit it - unless that are more rules in their .rex file - but they may well have never noticed, as it only seems to occur on roundabout exits, and there are/were but about 3 roundabouts in NJ and 2 in Santa Barbara! _________________ Go Premium X / Go 1005
The semi-colon pronunciation error occurs whenever the road number is at the end of the phrase, eg. as an instruction on a roundabout exit, with no road name.
I've run out of ideas on how to stop the ; being pronounced in the above circumstance. If there is a road name present than that will have a space associated with it, which seems to turn off the \s command and stop the literal pronunciation of punctuation. But I can find no way to insert a space if there isn't one already present in the stream... It seems that TT's preprocessing of the substitute text is stripping spaces.
So far I've been unable to find the ; in the input string, so I'm led to believe that TT is only passing us the road number, ie. we don't have an opportunity to remove it.
I need the command which is the opposite of \s to proceed. _________________ Go Premium X / Go 1005
Can you give me a route to test as my tomtom has Never pronounced a punctuation after a road name?
I was browsing a demo route from 1 Radford Close, Lower Hale to 1 Walnut Grove, Wooburn Green. The turn on to the A325 from the roundabout gave the error, as does the advanced notification for the later turn onto the A331.
MARViN2003 wrote:
What is your punctuation set to in your default session file?
My other files were just as you had set them in your zip. _________________ Go Premium X / Go 1005
To clarify the difference - in my mind - between the comma/dot and the semi-colon issue:
To the punctuation issue, the comma and dot I got all the time with your rex rules. My theory is that the \s turns on literal pronunciation of everything, letters which we want and punctuation which we don't. This occurred everywhere. So I got past that by making everything after the number another substitution parameter and passing it back. That way the spaces or other commands already in the stream gets passed to L7 and it switches back to normal mode before the comma or period.
BUT, in the roundabout exit I think all that is getting passed is A325 so the same trick won't work. So Kate reads \s-A-3-2-3 from our rules then Road Name; from the original stream. But in the case of a rural setting with no road name she still gets a ; and reads it as a literal.
So I *think* I either have to L7 back into normal mode but that requires an unknown command. _________________ Go Premium X / Go 1005
Yes, I agree. Came to that conclusion in last few days. It seems that with L7 we are now playing with Loquendo's code directly not TT/TeleAtlas'. Probably explains why it is not in an encrypted format (like all TeleAtlas stuff).
I don't think it is the w3 format that we have. L7.8 conformed with that. But it meant a change in command syntax, so a test could confirm, but I haven't had chance to conduct same yet. But it is equivalent to w3's spec.
What we need is the list of Loquendo commands for 7 (diff between 7.1 and 7.8 is mutable, so any will do). Not found a complete list yet, but have extracted a few from Loquendo's demos. I's love to try "Aagh!" before "Turn around when possible!"
But back to case in hand, I'm thinking I'm wrong to be looking for space to turn off \s, but not sure now what does it... Will need to study w3.org's spec. _________________ Go Premium X / Go 1005
Joined: Nov 27, 2005 Posts: 132 Location: Stroud, Gloucestershire
Posted: Tue Jun 08, 2010 1:20 pm Post subject:
Got the a new map today and began testing before I renamed the cphoneme.dat. All my B roads were totally ignored, it just read out the road names, not the road number.
Renamed the cphoneme.dat file to cphonemeold.dat and they were all read out again...
Well, in a way that is good news to me, as it means that my missing B3007 road name was not my bug! I had just re-enabled cphoneme.dat back so that was the cause. Phew! As to why, I would hazard a guess that cphoneme.dat redefines B into something else, like "be" to suit the speech system before Loquendo (L & H, I suspect) so that our rules miss it entirely. If I'm correct then we need a catchall rule as the last rule which returns everything: ".*" = "\0" would be safest if it works (if \0 works), otherwise "(.*)" = "\1" should do it.
When/if we get this road number working I need to take a look at cphoneme.dat to see if we can reduce some of its idiosyncrasies. Should be a question of just deleting what is no longer necessary/needed. Not sure if I have an editor which will read files with high-order bit set... _________________ Go Premium X / Go 1005
When/if we get this road number working I need to take a look at cphoneme.dat to see if we can reduce some of its idiosyncrasies. Should be a question of just deleting what is no longer necessary/needed. Not sure if I have an editor which will read files with high-order bit set...
Mine is most definitely not text (not even Unicode). It starts with the string "PHONEMINFO", but what follows is not readily apparent. I've reverse engineered some file formats in my time, but this one doesn't seem to provide any kind of ready starting point.
I read in a couple of places (can't find link now, of course), that it is simply encrypted by setting the high-order bit on every character except that used for carriage return/line feed.
And that some version of SQL used similar, so there was a viewer that would process.
I have reasons to believe this to be the case, but not pursued as yet. _________________ Go Premium X / Go 1005
I read in a couple of places (can't find link now, of course), that it is simply encrypted by setting the high-order bit on every character except that used for carriage return/line feed.
Well, that isn't what it's like. It has a normal distribution of bytes with and without the high bit set.
Joined: May 30, 2008 Posts: 11 Location: Devon/Cornwall
Posted: Thu Jun 10, 2010 6:20 pm Post subject: Re Fix for 730
JaguarV12e wrote:
On my 730
adding a line like:
"(^|[ \t]+)A[ \-]*([0-9][0-9]?)([0-9][0-9])[^0-9]?" = "\1 Eh \2 \3 "
changes "A One Thousand One Hundred and Ninety Eight"
to "A Eleven Ninety Eight Semicolon" (or a trailing "comma" if the road has a secondary name).
I am sure that this can be fixed
Has there ever been a fix for this for the GO 730? if i add the above line only A roads are announced everything else then defaults to Turn Left/Right ???
Posted: Today Post subject: Pocket GPS Advertising
We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
Have you considered making a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Hi! We see you’re using an ad-blocker. We’re fine with that and won’t stop you visiting the site.
But as we’re losing ad-revenue from this then why not make a donation towards website running costs?. Or you could disable your ad-blocker for this site. We think you’ll find our adverts are not overbearing!
Forum FAQ
Search
Usergroups
Profile
Log in for private messages
Log in
I had just re-enabled cphoneme.dat back so that was the cause. Phew! As to why, I would hazard a guess that cphoneme.dat redefines B into something else, like "be" to suit the speech system before Loquendo (L & H, I suspect) so that our rules miss it entirely. If I'm correct then we need a catchall rule as the last rule which returns everything: ".*" = "\0" would be safest if it works (if \0 works), otherwise "(.*)" = "\1" should do it.
