Xamanian

Parece que perdi tempo em abrir um tópico sobre lang e voices... O amigo d780 foi o único que entendeu a lógica da coisa (obrigado!!!!). Nenhum fórum de GPS sobrevive quando apresenta a solução para apenas uma pessoa, para apenas um caso, etc. Ou se olha a coisa como comunidade (bom para um, bom para todos), ou se olha a coisa como "serviço personalizado para atender fulano". A segunda opção, como mostra a experiência em relação a um grande fórum irmão, leva ao naufrágio. Fazer tratamento de pronúncia para as vozes e traduzir/adaptar o lang com expressões que traduzem melhor aquilo que significa para o português não é tarefa fácil, é inglória. Quem tenta é sempre alvo de pancadaria. O amigo d780 sabem bem disso, por isso o estimo muito. Várias pessoas ousaram, onde cito (alguns apenas), Sherlock, d780, Luís Carlos (Rio/GPS), Fidelis e outros. Tentei durante anos, não por querer assumir o trabalho ou achar que faria melhor, mas apenas por acreditar que poderia contribuir com aquilo que julgo ser melhor para mim (se não fui claro, faço apenas e tão-somente para mim, mas faço questão de compartilhar com todos, goste-se ou não do resultado final). Não é bom, que seja ignorado! Nunca me neguei a auxiliar quem quer que fosse; sempre "abri o jogo", apresentando aquilo que aprendi, com o intuito de minimizar esforços daqueles que querem aprender. Então seria fácil vir aqui e dizer qual a solução para a pergunta inicial (ou seja, o primeiro post). Mas não, parece que alguém surgiu meio que do nada, lançou uma pergunta estúpida (sim, estúpida, pois a voz da Raquel nunca apresentou problemas com a pronúncia de "radar") e outros foram "no vácuo", feito gado indo para o abate (perdoem-me, caros amigos induzidos). O camarada nunca foi participativo e chega abrindo um tópico sobre o mesmo assunto daquele que abri... E justamente aquele do dia de ontem! Ele não leu ou leu e quis desviar o tópico criado? Nunca mais quis criar um tópico sobre lang/voice depois de tanto ter apanhado! Abri a pedido do amigo Thoth e com apoio do amigo Nelson. E por que o camarada não foi lá, ler e contribuir? Contribuição se faz com sugestões e críticas, mas também com perguntas! Pois as respostas dadas, se satisfatórias, geram um banco de dados para todos os leitores futuros que consultarem este fórum. Simples assim. Não se faz uma sociedade equilibrada atendendo individualidades, mas sim atendendo o coletivo. Se não for bom para todos, não deveria ser bom para quem quer que seja. Democracia não significa "fazer o que eu quero", significa compartilhamento com o próximo (se é bom para ele, é bom para mim; se é bom para mim, tem que ser bom para ele. E vale a reciprocidade da negativa: o não ser bom, etc.). Democracia é ser solidário, saber compartilhar benefícios, mas também saber absolver as dores de um como se fossem suas. .XA.

s.wrxsti, será que o seu disponível é antigo (ou de firmware antigo), de modo que o mesmo foi afetado pelo bug do GPS? Falo sobre o assunto deste tópico: http://gpsclube.com/forum/index.php?/topic/4176-gps-vai-parar-de-funcionar/&do=findComment&comment=46877 Isto está acontecendo apenas com uma determinada skin ou com todas? As diMka, que é o caso desta skin deste tópico, permite fazer ajustes sobre deste tipo. Para isso, vá em configurações regionais e veja como está setado o horário. Nas configurações do GPS (do dispositivo) também é possível ajustar o horário manualmente ou pelo sinal de GPS. Se o seu permitir este tipo de ajuste (acredito que sim), então é interessante fazer um teste: configurar o horário para ser atualizado pelos satélites, mas terá que levar o aparelho em um lugar aberto, deixar os sinais carregados e em seguida verificar se o horário está correto. Se aparecer 1999, então você tem um problema. A grande questão é que os navegadores GPS usam os satélites para ajustar as horas, então este teste pode responder a pergunta inicial e que pode ser melhor compreendida no link indicado. Mas não se assuste, pode ser outra coisa também, alguma coisa que ainda não pensamos. Tentarei ajudá-lo. Abraços.

s.wrxsti caro amigo, abra o arquivo info.ini de cada voz e procure pela linha que começa com (logo no início, linhas abaixo): name="... Você verá: name="Felipe: voz TTS Pro - Loquendo 7.7_MF" name="Fernanda: voz TTS Pro - Loquendo 7.7_MF" name="Gabriela: voz TTS Pro - Loquendo 7.7_MF" name="Raquel: voz TTS Pro - Nuance 4.5_MF" Estas linhas, uma em cada info.ini, representa exatamente o nome da voz que aparecerá naquele menu de configuração/seleção das vozes (TTS ou gravada). Nada pode ser diferente disso, caso contrário, estará usando uma voz diferente destas que postei ontem. Linhas abaixo da indicada (name="...) aparecerá outra com o início sex="..., onde ... significa male ou female. Nos arquivos que postei há um ponto e vírgula no início da linha (por exemplo, ;sex="female"), onde este ponto e vírgula significa que a linha foi comentada, isto é, o comando foi ignorado. Assim sendo, qualquer uma das vozes de ontem (arquivos, claro) tem um ponto e vírgula em seu início, de modo que nunca aparecerá "masculino" ou "feminino" diante do nome da voz. Faço isso por motivo óbvio: em nosso país é fácil identificar um nome próprio que é de origem masculino ou feminino, de modo que uma informação a mais na tela só serve para poluir. Pelo que entendi de seu post, no seu caso aparece o feminino ou o masculino. Se for o caso, não é uma das vozes de ontem. Mais: se ouviu o som das vozes como comentei no post anterior, então não há problemas com elas, de modo que as configurações de vozes TTS Pro deverão aparecer corretamente (ou deveriam!). Por fim, informo, fiz testes aqui e até agora não encontrei problema algum com as vozes, exceto, possivelmente aquelas para Primo 2.4 para Android (@Coelko), que ainda não pude testar (pelo menos hoje). Para WinCE e Android (Primo 2.0), tudo ok. E para quem possa interessar pelo tema: os arquivos internos das vozes (ou seja, o tal tratamento de correção de erros de pronúncias), são todos iguais. O que muda entre as versões Primo 2.0 e 2.4, Android ou WinCE, e para Nextgen, é apenas o tal arquivo info.ini, que é aquele que faz funcionar ou não as vozes (e que depende mais de pacotes do que das vozes, pois são baseados nos navegadores originais com modificações -- o grande problema!). Assim, se uma voz tem problema com um sistema, com um navegador, terá com todos; se não tem com um deles, não terá com os demais (problemas aqui se refere ao funcionar ou não, o que é diferente de ainda conter ou não falhas de pronúncias). Grande abraço!

Sim, pode inserir e testar. Tem algum tempo que não testo as vozes com Primo 2.4. Abração.

s.wrxsti vou fazer alguns testes aqui, pois este tipo de problema que você relatou não poderia acontecer (sim, sei qual é o problema que gera estas coisas). Verifique o seguinte: 1. Abra o arquivo info.ini que fica no zip da voz da Fernanda (TTS 7, ou 7.7, só fui direto). Lá no final verá a seguinte linha: testsound="Este é um mecanismo de síntese de voz da Loquendo. O meu nome é Fernanda, e a minha língua é o português do Brasil." Esta frase depois do sinal de igual é aquela que você deveria ouvir. 2. Fazendo a mesma coisa com a voz do Felipe, verá: testsound="Este é um mecanismo de síntese de voz da Loquendo. O meu nome é Felipe, e a minha língua é o português do Brasil." Estas são as frases para testes de voz, que são ouvidas quando se clica sobre o nome da voz no menu que citou. A frase que você relatou fica no arquivo branding.zip, basta abrir o info.ini deste arquivo para confirmar. Isto não deveria acontecer. 3. A opção de configurações de voz TTS Pro ficar desabilitada é sinal de falta de aspas em uma das frases (ou seja, a tradução/adaptação do inglês para o português). É um velho conhecido meu. Porém nos tratamentos que faço, uso um programinha que verifica se existem erros, não apenas de falta de aspas, mas outros também. Não era para acontecer, mas vou verificar novamente. 4. Outra coisa que gera o problema acima (não aparecer as configurações da TTS) é usar uma skin que tem uma frase que não está ou no lang (idiomas) ou nas vozes. Por outro lado, estas vozes foram preparadas para a maioria das skins disponíveis, incluindo módulos ux, etc. No caso das diMka, mais ainda, pois sempre usei skins apenas deste tipo e das mais variadas modificações existentes (ou seja, tudo traduzido e presente nas vozes e lang). 5. Vá no menu que citou, de configurações de vozes (isto é, para selecionar uma) e veja se aparece nomes como estes: Felipe: voz TTS Pro - Loquendo 7.7_MF, Fernanda: voz TTS Pro - Loquendo 7.7_MF. A grafia tem que ser esta. Se sim, ok. 6. Uma possibilidade é que você estava usando vozes antigas, de modo que problemas podem surgir com a adoção de outras com mais recursos. Neste caso é preciso apagar a pasta Save e reconfigurar tudo do zero (só faça isso se fizer um backup da mesma antes, pois o problema pode não estar aí). Bem, agradeço o retorno, onde prometo verificar tudo e corrigir se for o caso. Valeu, meu caro! Abraços!

s.wrxsti realmente a Acapela é só para Android, assim como a Svox. Mas tem um detalhe interessante: a seleção do engine de voz tem que ser feita nas configurações do Android, de modo que a voz selecionada no Primo não tem efeito (aparentemente!). Mas mesmo assim é aconselhável selecionar a voz de acordo com o engine escolhida no Android. Motivo: cada voz tem uma característica própria, uma palavra pronunciada corretamente com um engine pode não se outro for escolhido. E aqui o tratamento é feito voz por voz, daí a importância do "casamento" entre o arquivo de voz e o engine (só em Android, pois no WinCE a voz é selecionada no próprio navegador). Coelko, você já deve ter lido vários posts meus dizendo que prefiro o Primo 2.0 para Android ao invés de um 2.4. Um dos problemas é este das vozes. Cada pacote implica em um apk e uma configuração diferente e daí surgem problemas. Mas é possível resolver o problema, mas mexendo nas vozes. Caso queira saber, deixo as dicas: 1. Extraia o arquivo info.ini que fica na raiz do zip de cada uma das vozes (sim, tem que ser feito uma por uma); 2. Localize as linhas abaixo: tts_mode_mixed=0 tts_rate="100" tts_srate="14000" Algumas vozes funcionam bem com tts_rate="50" e tts_srate="22050" mesmo com um Primo 2.4. Aliás, estes dois valores (50 e 22050) são os valores padrão para Primo 2.0 e 2.4 WinCE e Primo 2.0 Android. Mais, inclusive para o Nextgen! 3. Tente mudar os valores acima, um de cada vez. Ou seja, primeiro mude o tts_rate de 100 para 50; se der certo, ok. Caso contrário, tente mudar o tts-srate de 14000 para 22050, mas mantenha o anterior fixado. E por fim, altere os dois valores e teste novamente. 4. Mas os melhores valores para serem testados são aqueles presentes no info.ini de uma voz que funciona corretamente. Tente abrir uma voz e verificar os valores adotados e depois modificar estas de ontem. Observo que os valores usados ficaram bons para certos usuários, que me deram um retorno nesse sentido tempos atrás. Em particular, usando a voz da Raquel (100 e 14000) com o Fast Ultimate para Android. Como este pacote fez sucesso, então resolvi deixar do modo que postei ontem. Enfim, teste da maneira que falei, mas leve em conta que valores bons para uma dada voz podem não funcionar em outras. Depois relate para a gente, tanto sucesso como insucesso. E se possível, informe qual pacote está usando em seus testes. Tenho outras sugestões também, mas temos que ir aos poucos, para não dar confusão. Assim que encontrarmos um bom funcionamento, então posto uma versão atualizada. Abraços aos amigos!

Caro amigo Arbex, em relação ao Primo, só confio (até hoje, claro) no executável que citou e naquele que está no pacote do Sherlock e que o Nelson postou recentemente. São muito confiáveis e estáveis, diferentemente dos executáveis mais novos (que não uso nem que a "vaca tussa"! São horrorosos!). Penso assim, o melhor navegador GPS é aquele que atende plenamente as nossas necessidades. Não faço questão do mais novo, pois estes foram elaborados para certos hardwares e que nem sempre temos disponibilidade para comprar. O seu retorno é gratificante, pois sinaliza que meus testes aqui coadunam com a prática experimentadas, não apenas por mim, mas por terceiros (no caso, você). Não basta opinar, é preciso oferecer algo crível. Além do caso que citou, que é para WinCE, eu uso um Primo 2.0 para Android (na CM do carro), pois funciona muitíssimo bem. Não conheço um Primo 2.4 que funcione de modo tão estável e confiável. Estou tentando usar o Nextgen, mas está difícil, mesmo depois de tantos anos "na praça", o considero ruim (mas insisto com ele, pois não teremos Primo para sempre). Tudo no Nextgen é muito ruim, lamentavelmente... Mas quem sabe... Grande abraço!!!

Arbex, é um arquivo complementar da voz Svox Luciana, para correção de pronúncias. Ele é inserido na subpasta \content\voice, junto com as vozes. As pastas da Nuance, Vocalizer (que é da Nuance) e Loquendo, eu não forneço, pois se trata de material com direitos autorais. Só mesmo as correções de pronúncias e nada mais. Mas acredito que este material esteja disponível aqui no fórum, pois tempos atrás os vi. Abração!

Pessoal, no arquivo em anexo (txt) estão presentes links para o arquivo de idioma (lang) e arquivos de vozes TTS com a última atualização que tenho. No momento apenas para Primo (WinCE e Android); em breve, também para Nextgen. Antes de substituir os arquivos que estão sendo usados, sugiro que se faça um backup dos mesmos. Além disso, deve-se observar o tipo de sistema operacional (WinCE ou Android), bem como a versão do Primo (2.0 ou 2.4). A voz da Raquel para WinCE, que se encontra na subpasta "Primo 2.4", também pode ser usada em Primo 2.0. Já as vozes da Loquendo é preciso mais atenção: a versão 7.7 só funciona em Primo 2.4 e a versão 6.5 apenas em Primo 2.0. Em relação as vozes para Android, também deve-se observar a versão do Primo. Mas cabe observar que para este sistema há mais vozes disponíveis, incluindo aí a Acapela Márcia, Nuance Felipe e Luciana e Svox Luciana. Não se deve confundir com Loquendo Felipe e Nuance Felipe, o mesmo com as vozes Nuance Luciana e Svox Luciana (o nome é o mesmo, mas o engine não). Solicito que sejam relatados falhas, erros, problemas em geral. E se possível, gostaria que apontassem erros de pronúncias percebidos para que um tratamento seja feito; assim todos ganham. Pede-se também que as sugestões sejam acompanhadas do nome exato da via e/ou logradouro, como aparece na tela, indicando o mapa usado (TT ou Here), e se possível, uma rota para que testes sejam realizados. Por fim, junto ao anexo será informada uma data e hora da última versão disponível, que será sempre atualizada aqui neste primeiro post. []'s .XA. (02/06/19, 15:55) GPS Clube.txt

Grande amigo Thoth, falta neste fórum um lugar (tópico) para a atualização de vozes e lang, não temos um tópico específico para isso. Então apenas disponibilizo um arquivo atualizado (lang e vozes) quando há necessidade (em virtude de mudanças, em alguma ux ou skin). Por que nunca houve um lugar comum para atualização de vozes e arquivo de idioma neste fórum? É um lugar de gente experiente e tarimbada... Faço questão de contribuir com correções, mas o fórum tem que ajudar também! Grande abraço nobre amigo! PS.: não tem nada mais atual do que aquelas atualizações, pois não recebo mais ajudas (reclamações sobre problemas de pronúncias),o que faço é para "consumo próprio" (aquilo que percebo).

Nelson, o arquivo FJW é só para Nextgen, embora este navegador também aceite o FJV. Já o Primo só aceita o arquivo FJV para as junções, tanto WinCE quanto Android. As junções aparecem em dois formatos: (a) aquelas da NNG (que ficam no data.zip) e que são figuras genéricas sobre o tipo de junção, nada real; ( as junções do arquivo FJV, que são figuras estáticas, porém imitando, através de desenhos em 3D, a forma real da junção. Estas figuras do último tipo se dividem em dois grupos: imagens simples ou foto realísticas. A diferença, basicamente, encontra-se nas placas de indicação (aquelas verdes e azuis, chamada erroneamente no passado de "toponímicas". Estas últimas são aquelas placas azuis nas esquinas de ruas contendo os nomes das mesmas). O Primo pode exibir as imagens de junções clássicas e foto realísticas, o que conta aí é o uso de licença específica para as foto realísticas. Já o Nextgen só exibe junções foto realísticas, tanto aquelas do arquivo FJV quanto do arquivo FWV. Porém, ambos navegadores exibem imagens da NNG, aquelas mais simples e genéricas. Cabe observar um detalhe: quando se usa mapa da TomTom, apenas as junções da NNG são exibidas, pois não existe um FJV ou FWV para estes mapas em nosso país. Já o o uso dos conteúdos da Here, quando o Primo ou Nextgen são configurados adequadamente, pode exibir junções tanto da NNG (pois possuem informações no arquivo FBL do mapa) quanto aquelas dos arquivos FJV/JWV. Mais ainda: tanto o Primo quanto o Nextgen, com conteúdo da Here selecionado, dão prioridade para as junções do arquivo FJV/FWV. Explico: caso exista uma informação no FBL para exibir uma junção da NNG (figuras bmp que ficam no data.zip), bem como uma informação sobre a mesma junção no arquivo FJV/FWV, então a exibição será a do último tipo, sendo aquela da NNG ignorada. Em suma, só aparece junção da NNG, com mapa Here, se não existir uma correspondente no FJV/FWV. Grande abraço!

s.wrxstio módulo ux DriverAlert, versão para WinCE e Android, pode ser baixado nos links presentes no txt em anexo. Ambos conduzem ao mesmo arquivo contendo as duas versões. A senha também está no txt. Abraços, .XA. GPS Clube.txt

Nelson, qual teste? Pergunto porque falei de dois: uma rota em BH e outro sobre as imagens clássicas de junções e as foto realísticas. Respondo os dois casos. Para a rota, basta ir em Rotas, no primeiro ponto, que corresponde ao GPS ligado, basta inserir o primeiro endereço e número. Depois na setinha com o símbolo "+" (canto esquerdo superior), clicar e inserir endereço e número. Feito isso, para "Ir" e depois da rota calculada, clicar em "Simulação", que pode ser feito também na tela Minha rota, clicando-se no botão Mais... Acho que não era isso, mas fica para quem não sabe como simular uma navegação. O segundo caso dá mais trabalho. Primeiro é preciso pegar uma rota, como aquela que você me indicou e simular a navegação, mas usando as licenças antigas, sem estas novas que habilitam as junções foto realísticas. Se aparecer uma imagem de junção da Here (FJV), então fica claro que nem toda junção foto realística está disponível no FJV. O problema que um teste apenas não prova nada, pois realmente uma junção do FJV pode ter sido removida. Então é preciso traçar novas rotas. Além de testes deste tipo, também é preciso voltar com os mapas e FJV anteriores, como o 2018.Q1, pois é preciso saber se o problema está no 2018.Q2 apenas, ou não. Lembro-me de ver muitas imagens de junções foto realísticas no Here 2017.Q4 e vi algumas no 2018.Q1 no estado de SP, mas neste atual 2018.Q2 não vi nenhuma em SP, só imagens de junções da NNG. Ou retiraram muitas ou mantiveram, mas de modo que não aparecem mais se for do tipo foto realística. Não duvido que estejam fazendo algo neste sentido. Tempos atrás cortaram a exibição de imagens de junções no Primo 2.0 para WinCe. Recentemente o Primo não funciona com o TMC, em por rádio e nem por Wi-Fi. E por que não retirariam as junções foto realísticas do Primo? Assim restaria apenas o Nextgen com este recurso. Neste caso, vale mais um teste: o Nextgen, como mostrei em posts antigos neste mesmo tópico, funciona com os arquivos FJV e FJW, ambos para junções. Uma ideia é simular uma rota no Nextgen, primeiro usando o FJW e depois o FJV. Em tese, deveria aparecer junções foto realísticas em ambos os casos. Mas se aparecer apenas no FJW... É porque "caparam" o FJV. E se aparecer junções foto realísticas com ambos os arquivos (um de cada vez, claro), então o Primo foi bloqueado ou limitado. Ou seja, para o segundo tipo de teste que falei é preciso muito tempo, paciência e muitas rotas conhecidas nas quais sabidamente se via junções anteriormente, clássicas ou foto realísticas. Para as clássicas é preciso usar as antigas licenças que conhecemos; para as foto realísticas, as novas licenças. Não sei se era isso e nem sei se ajudei, mas se errei, pergunte de novo, caro amigo. Abração!

Nelson, fiz o teste aqui e realmente só aparece a imagem da NNG, nada do arquivo FJV. Aliás, fiz testes em outros pontos no estado de São Paulo, inclusive capital, e só vi junções da NNG, ainda não vi do FJV, mas via muitas imagens deste tipo em SP. Parece que foram substituídas pelas da NNG. E para piorar, estou vendo poucas. Mas faça um teste aí, pois irá ver uma do FJV (e um túnel, com figura estática): Partida: Belo Horizonte, Avenida Dom Pedro II, 397. Chegada: Belo Horizonte, Avenida Cristiano Machado, 800. Preciso me certificar se as junções que não são realísticas aparecem nos lugares que não vejo mais junções do FJV. Sim, a dúvida é saber se existem no FJV imagens realísticas e não realísticas diferentes. Se este for o caso, então a habilitação das realísticas poderia impedir o aparecimento das comuns. Não creio nisso, mas é preciso testar. Para isso é preciso usar as licenças antigas, traçar rotas que teriam as junções do FJV sabidamente e fazer testes. Mas rota indicada acima mostra correta uma imagem do FJV, ou seja, demonstra que tudo está ok. Abração!

Nelson, não é preciso modificar o sys.txt para as novas imagens de junções, as configurações são as mesmas para as junções comuns. Se as junções da Here (arquivo FJV) já aparecem normalmente, nada mais é preciso, apenas as licenças que habilitam as imagens fotorrealísticas. Mas note bem, a figura que você postou não é uma imagem de junção do arquivo FJV (ou FJW), mas sim uma imagem de junção da NNG, que usa figuras que ficam no data.zip. Estas figuras da NNG não são mudadas com as novas licenças, apenas as figuras presentes no arquivo FJV. Ou seja, é preciso fazer testes em regiões/lugares onde aparecem imagens de junções da Here (FJV ou FJW). São Paulo tem muitas deste tipo, é só tentar uma rota e testar. As novas licenças (créditos ao nosso amigo Boki do GPS Power, e que aparece por aqui também) servem para Primo Android e WinCE. No caso do WinCE, apenas Primo 2.4, pois já faz um bom tempo que o Primo 2.0 e anteriores não exibem mais imagens de junções. Já no Primo para Android, tanto a versão 2.0 quanto a 2.4 funcionam corretamente com as novas licenças. E pelo que me lembro dos posts do Boki, estas licenças também funcionam no Nextgen. As mesmas estão em anexo (senha: GPS Clube). A pasta com inscrição "minimal" contém o mínimo de licenças para o funcionamento dos navegadores com todas as funções. Acho que foi nosso amigo SPY/DF que postou, ainda Point (créditos a ele; se outra pessoa, que me desculpe). A outra pasta contém aquelas fornecidas pelo Boki. Grande abraço! Licenças.zip

Fabiano, entendo que ficou muito claro o que você pretende. Agora consigo comentar um pouco mais. O que você quer não é um recurso do Primo, nem do Amigo, nem mesmo do iGO8 ou do Nextgen. O resultado positivo que você obteve está relacionado com a voz, pois com TTS não é possível. Vejo algumas alternativas para você pensar e testar: 1. Se você prefere uma rota traçada no Waze, basta usar o Primo normalmente, mas sem carregar uma rota nele também. Assim ele continuará avisando os pontos de alerta (radares, lombadas, etc.), mas continuará ouvindo também as instruções de navegação através do Waze. Em suma, trace rota em um deles e navegue (também) com o outro, mas sem rota traçada. Entendo que a maneira mais simples de obter o que deseja. 2. No Primo, nas configurações de sons, avisos e alertas, você pode configurar a voz TTS para alerta apenas o que você quiser, de modo que poderá desabilitar muita coisa, mas que se mantenha os pontos de alerta habilitados, caso contrário não ouvirá os avisos. Neste mesmo lugar é possível fazer outros ajustes de voz TTS (Wiman): ou você desabilita tudo ou configura para a voz falar minimamente. Ainda nas configurações de som, na parte de configurações avançadas, você pode configurar a voz TTS para falar só o essencial (nomes de ruas completos, só nome, só números, etc.). Em verbosidade você pode selecionar o menor nível: são três níveis, o maior faz com que a TTS, em cada manobra, repita a informação 3 vezes; no nível médio 2 vezes e no mínimo, 1 vez. Note que com estas sugestões você ainda terá voz TTS falando em rota traçada, mas irá diminuir muito a falação. Esta sugestão deve ser tentada apenas se você ainda quiser traçar rotas no Primo e no Waze. 3. Esta sugestão eu nunca testei, pois gosto de ter a TTS com todos os recursos habilitados, pois só uso o Primo em minha CM e este me atende plenamente. Consiste em fazer uma alteração no sys.txt. Tente: [tts] always_say_road_names= 0 ; (valor padrão = 3) announce_exit_directions=0 ; (valor padrão = 1) announce_street_name=0 ; (valor padrão =1) priority="LOW" ; (valor padrão = HIGH") skip_exit_numbers=1 ; (valor padrão = 0) Estes comandos setados com o valor 0 (os três primeiros) bloqueia o anúncio de nomes das vias (ruas, avenidas, etc.), manobras, etc. A prioridade é autoexplicativa. A última linha está relacionada com o número de saídas (de rotatórias, rodovias, etc.). O valor 1 diz para tal recurso ser ignorado. Não sei dizer se desabilitar estes recursos poderá implicar em outros bloqueios da TTS como, por exemplo, os pontos de alerta. Como afirmei, nunca testei antes. Além disso, talvez seja necessário apagar a pasta Save (mas antes faça um backup), pois acredito que o system.ini possa conter alguma informação com valores diferentes (em geral ele é atualizado pelo sys.txt, mas neste caso eu não testei). Por fim comento sobre a minha experiência com o Waze (um navegador online) e o Primo (um navegador off line). A primeira coisa é que um navegador online contém todos os arquivos de conteúdos (mapas, POI, etc.), o que permite um maior número de informações ao calcular uma rota, ou mesmo em navegação sem rota traçada. Com isso se tem maior segurança na rota informada pelo navegador. Como o Waze é um navegador off line, certas coisas não são possíveis. Menos de um mês atrás lia um artigo de uma jornalista em um site sobre automóveis, onde narrava a sua aventura com o Waze no norte noroeste argentino. Ela se declarava fã do Waze, mas igualmente decepcionada com o navegador. Bem, ela escreveu o artigo e não se deu conta do problema que tinha enfrentado, que consistia em o Waze não informar sobre postos, hotéis, etc. na vizinhança do lugar onde ela e o marido se encontrava, e o tempo todo o Waze fazer cálculo errado de nova rota. Motivo: o navegador é online. Quando ele traça uma rota, ele baixa tudo o que é necessário para a viagem, mas se algo mudar e não tiver sinal de Internet, ele não terá como atualizar os dados. Foi o que aconteceu com ela, problema na estrada, necessidade de desvio, foi parar em um lugar desconhecido (e fora da rota original) e sem Internet, o Waze não conseguia fazer outra rota e nem apontar os POI na região, pois estes dados não tinham sido baixados. Para quem confiava cegamente no Waze, foi uma baita decepção, bem como a comprovação na prática que este tipo de navegador (online) não é muito confiável. O mesmo ocorre com o Google Maps, um navegador online. Por outro lado, as empresas Audi, BMW e Mercedes-Benz formaram um grupo e compraram a NNG (a desenvolvedora, húngara, do iGO8, Amigo, Primo e Nextgen) e estão usando estes produtos em seus carros. Pergunto: Por que empresas desta envergadura optaram por navegador off line ao invés dos famosos espelhamentos (para uso de Waze e GMaps)? A resposta é autoexplicativa. Apesar de ter restrições a certos navegadores, não chego a ter "mente fechada"; vira e mexe eu volto e testo aqueles que não me agradaram antes. É o caso do Waze, que voltei a testar em janeiro e fevereiro últimos. Simplesmente intragável! Ruim é pouco! Mas algo me chamou atenção: o TMC funcionando e "buracos" como ponto de alerta. Gostei, mas fui testar. Buracos na pista funciona até que alguém tampe o buraco, mas como depende de pessoas para cadastrar e descadastrar, problemas surgiram: é totalmente inconfiável, pois recebia avisos de buracos que eram inexistentes, bem como não recebia aviso onde havia. O TMC é ilusório, simplesmente é um banco de dados que informa a velocidade média da via em determinada hora do dia e em determinado dia da semana. Ora, o arquivo FSP do Primo e Nextgen faz isso muito bem e é off line. Já informações sobre acidentes, via interditada, etc. depende de cadastramento de usuários, algo sempre crítico. Em suma, o que parecia ser bom, não atende, ao menos para mim. Já navegadores off line também têm seus problemas. Um deles é que a atualização de mapas demora basta, mesmo que um processo acelerado de atualização esteja ocorrendo em nosso país. Ainda tem muitas falhas nos mapas e isto pode gerar problemas. Conheço uma cidade que tem duas avenidas que se cruzam em determinado ponto. Uma avenida é pista dupla e tem duas faixas cada; a outra avenida tem três pistas, sendo duas com duas faixas e uma com três faixas. Pois bem, o mapa da Here indica uma manobra para cruzar a esquerda em uma delas, sendo que seria necessário atravessar 7 faixas da mais larga. Como assim? E até hoje 6 acidentes neste ponto, onde os motoristas alegavam seguir as informações do GPS... É claro que não se deve seguir as orientações do GPS ao pé da letra, pois a legislação é clara, deve-se seguir as placas e agentes de trânsito, GPS é só um auxiliar. Por outro lado, não é admissível que um erro tão crasso permaneça neste mapa. Em navegadores online as correções são mais rápidas, mas no geral os mapas não são bons, pois as pessoas só corrigem cidades maiores e rodovias; o interiorzão sofre... Bem, não uso o Waze pois o classifico como muito fraco e limitado. Se o que está em jogo é um navegador online, então opto pelo Google Maps, pelos em POI é imbatível e tem um mapa bem confiável. Mas não critico quem gosta do Waze, ele tem coisas interessantes sim, porém não chegou ao ponto para que eu migre para ele. Abraços, .XA.

Amigo Arbex, veja, o branding segue uma lógica padrão, que não tem mistérios (sim, há detalhes, comento depois). Assim, ou ele funciona ou não. É verdade que o gerenciamento dos POI na skin diMka é diferente daquele na skin padrão, mas não acredito que o Ziko tenha alterado alguma coisa neste ponto. Então suspeito da pasta Save. Explico: o arquivo poi_visiblities.txt, que fica na subpasta /save/profiles/01, é uma cópia de arquivo de mesmo nome e que fica na pasta \ui_igo9\defaults (ou ui_android, ou ui_nextgen). Originalmente este arquivo habilita os postos de combustíveis e pouca coisa mais. Então o usuário faz suas configurações, marcando ou desmarcando os POI que lhe interessa. A "memorização" é feita através de uma gravação de informações no arquivo poi_visibilities.txt que fica na citada subpasta da Save. Nos branding que preparo sempre habilito todos os POI, fazendo assim: apago o poi_visibilities.txt da Save, depois habilito os POI um a um. Em seguida entro na citada subpasta, copio o poi_visibilities.txt e o insiro no branding.zip, especificamente na pasta \ui_igo9\defaults. Assim, se o poi_visibilities.txt que está na \save\profiles\01 for apagado, então o arquivo poi_visibilities.txt que está no branding.zip será usado, sobrepondo aquele do data.zip. Pois bem, no seu caso, muito provavelmente existe um arquivo poi_visibilities.txt na pasta Save que pode estar diferente daquele preparado por mim e que pode estar gerando o problema. Explico: cada pessoa que faz um branding usa nomes diferentes para os arquivos bmp's. Caso este arquivo tenha mantido um nome de bmp e que não esteja no branding que eu fiz, então o Primo tentará carregá-lo, mas não o encontrará. Consequência: travamento por não encontrar arquivo. Sugestão: entre na pasta \save\profiles\01, localize o arquivo poi_visibilities.txt e o apague (antes, faça um backup dele). Saia no navegador, carregue novamente. Se tudo der certo, verá todos os POI habilitados. Agora tente desabilitar aqueles que não são de seu interesse. Em tese, não deverá ter problemas. Caso surja algum, tente observar qual categoria e qual ponto específico (loja, supermercado, banco, etc.) está apresentando problema e me fale (assim poderei verificar se é um erro meu ou se o problema é de outra ordem). Ah, não precisa apagar toda a pasta Save, somente o citado arquivo. Abração!

Tenho acompanhado este tópico desde a sua abertura, porém não consigo sugerir nada, visto que não consegui entender exatamente o que Fabiano deseja. Como já foi dito, basta usar o navegador GPS sem uma rota traçada, pois assim o usuário só receberá avisos por voz nos pontos de alerta (radares, lombadas, etc.). Claro, se tiver a ux Wiman, então é preciso configurá-la para não ficar falando nomes de ruas e bairros (só com TT selecionado) sem rota traçada. Mas se há necessidade de traçar uma rota, então o segredo de qualquer navegador GPS (e não apenas o Primo) é a navegação ponto a ponto, isto é, uma voz informando cada manobra, cada rua, etc. Não querer ouvir uma voz com rota traçada, então é melhor não usar GPS! Claro, a importância da voz alertando cada manobra se deve ao fato de que o motorista dirige olhando para a via (rua, estrada, etc.) e não para a tela do GPS! Como está nítido que o Fabiano não é um estúpido, pelo contrário, só me resta dizer que acredito que ele deseja algo diferente e que não conseguiu ser claro o bastante para receber uma ajuda definitiva. Agora é com você, Fabiano, seja mais claro! []'s .XA.

Pessoal, o txt do primeiro post foi atualizado, contendo dois links de servidores distintos, uma vez que o DBR está offline. Estes arquivos já contemplam correções feitas a partir das falhas notadas e comentadas pelo Cláudio posts acima. []'s .XA.

Versa, é o hospedeiro de arquivos DBR que está offline e não o link em si. Dias atrás corrigi um pequeno erro nos branding, mas não pude atualizar o link naquele servidor, pois está off, tem dias que está assim. Vou usar outro hospedeiro, atualizar o txt, avisando assim que for feito. Abraços, .XA.

Bruski, como afirmei, sempre procurei pacotes repletos de recursos, sem economizar em memória RAM e clock. Por outro lado, afirmei que a solução para problemas em dispositivos com hardware limitado não está na limitação dos módulos ux, conteúdos, etc., mas sim no executável. Isto não foi citado no post inicial do amigo. Mas poderia me dizer onde isto foi dito, seja por você ou por quem quer que seja? Nunca li o que comentei post acima por aí, em fórum algum. Isto é experiência de um Xamanian da vida, que tem mais de 10 anos realizando testes; isto não é carteirada, é experiência mesmo. Não se trata de "cada caso é um caso", mas sim em saber como as coisas são na prática. Disse ao seu amigo, respeito você e muito, mas este tipo de resposta não é legal, passa ideia de "carteirada" de quem não tem carteira para dar! Dá para ser cordial, basta tentar; eu tento! Ah, e não engano, pois cito nomes e situações, mas deixando claro que os erros informados (por mim) serão sempre meus, não daqueles que cito. Abraços cordiais, .XA.

Bruski, tudo o que você citou sobre sua experiência com aparelhos de baixa quantidade de memória RAM e baixo clock (em MHz) é correto, mas existem "detalhes" também. Um dos grandes problemas que enfrentei no início foi encontrar um pacote limpo, sem alterações, pois todos disponíveis em fóruns nacionais eram personalizados. A questão era encontrar solução para lambança feita por terceiros. Com o tempo encontrei vários pacotes limpos e aí pude entender muita coisa (estudando, comparando, etc.). A primeira conclusão (óbvia) é que a NNG personaliza seus navegadores de acordo com o hardware que será comercializado por seu cliente. Isto implica dizer que o navegador está personalizado para um tipo de hardware, limitado ou "parrudo". Indo direto ao ponto: a solução está no entendimento do executável e para qual tipo de aparelho foi desenvolvido. Além disso, um desbloqueio mal feito implicaria em uma série de transtornos (e tem muitos assim por aí). Tempos atrás, em um fórum irmão já "falecido", o nobre amigo Sherlock disponibilizou um autêntico Primo 2.4, cuja versão do executável é 9.6.13.263722. Com o tempo surgiam versões cada vez mais novas dos executáveis, havendo uma correria para ter o "novo". Já este pacote do SK era enxuto, limpo, basicão, eu diria, mas rodava "redondo". Mas sempre procurei ter aparelhos com hardware "sobrando", então eu buscava o maior número de recursos, melhor visual, etc. Basta ver o "peso" das várias versões do Enterprise e SW (Star Wars) -- os mais antigos entenderão esta parte... Recentemente, não mais do que dois meses, um amigo comprou um aparelho GPS e me pediu para instalar um navegador (qualquer um), já que o dele não funcionava (sem sinal de satélites). Fiquei de ajudar, mas levei um susto ao me deparar com um Multilaser com tela de 4.7" e resolução 480x272, porém com apenas 64 MB de RAM. Pensei: nem o (ótimo!) Amigo do Cláudio funcionará, terei que partir para um iGO8 basicão. Nada... Comecei com um Primo 2.0 e fui adiante, sem problemas. Aí percebi que podia ir além e considerar um Primo 2.4. Deu pau! Foi quando me lembrei do Primo 2.4 do SK, cujo executável citei acima. Funcionou muito bem e de maneira estável, sem falha alguma. Ufa! Decidi instalar os módulos ux´s que entendia pertinentes, branding.zip que usava, etc. Continuou estável. Inseri voz TTS, DEM, edifício e pontos de referência 3D, phoneme, etc. Continuou estável e muito funcional. E hoje o pacote continua funcionando muito bem, sem problema algum, para satisfação do meu amigo. O detalhe que mencionei no início, como já ficou muito claro, é usar um executável programado para hardware limitado. Todo o resto funciona se esta base estiver ok. Este pacote do SK não tem alteração no data.zip, não tem TMC-wifi-bluetooth-etc. habilitado (até porque raros são os dispositivos com tais recursos), é o funcional, aquilo que se espera de um pacote simples, funcional e confiável. E por fim, nas CM a única coisa que é preciso observar é se a CPU é a mesma para o GPS e todo o sistema da mesma (idem para a memória RAM) ou se ela usa hardware dedicado para cada um. Se compartilhado, um problemão à vista (mas só naquelas muito antigas); se não, então basta usar um pacote com bons executável e data.zip. Abração, .XA.

Coelko, bem lembrado! Aliás, aproveito para deixar uma dica na mesma linha, pois que poucas pessoas sabem. As imagens de junções, como todos sabem, só aparecem com rota traçada. Quando elas surgem na tela e caso o condutor entenda que ela atrapalha mais do que ajuda (em certas situações, claro), basta clicar na tela para que a mesma seja removida; caso queira a mesma de volta, basta clicar sobre o carrinho. O mesmo pode ser feito com o protetor de tela, para quem gosta de usar (e sai ao clicar na tela e retorna ao clicar sobre o carrinho). Ligeiramente diferente, mas na mesma linha, o mesmo pode ser feito com aquelas placas azuis e verdes no topo da tela (que as pessoas chamavam, erroneamente, de toponímicas). Clicando-se sobre elas, as mesma somem, mas aparecerá um pequeno ícone retangular (azul e verde) no lugar, que ao ser clicado faz retornar as tais placas. Abração!

Pessoal, como falei em outro tópico, este branding foi feito do zero, onde todos os ícones foram recriados, mesmo tendo vários com aparência conhecida. Os arquivos de extensão .icons também foram elaborados do zero, mas os mesmos usavam, no início, nomes de arquivos .bmp que foram modificados com o tempo. Logo isto poderia implicar em falhas; aconteceu. O amigo Cláudio, ontem, alertou para pelo menos dois problemas. Na verdade não existe falta de arquivo, todos estão presentes, os bitmaps. Mas tinha pelo menos um arquivo .icons com duas falhas: usavam nomes antigos para arquivos que foram renomeados. A solução para este caso consiste em trocar o arquivo original por um corrigido. Deixo em anexo o arquivo que deve ser usado. Basta baixar o zip, descompactar (não tem senha) e inserir o arquivo poi_shopping.icons na subpasta \icons\poi (isto deve ser feito no branding.zip que está sendo usado, mas observo que todos aqueles do pack têm o mesmo problema; ou seja, na prática todos devem ser corrigido). Em tempo futuro irei disponibilizar novo pack (pode haver mais erros). Em relação ao problema apontado no Nextgen, como eu disse ontem, não é um problema em si, é uma característica. Até o Primo a NNG usava um ícone específico para agrupar POI de uma mesma categoria quando em dada região se tem mais de um ponto de interesse (por exemplo, dois ou mais postos de combustíveis, dois ou mais bancos, etc.). No Nextgen, além dessa característica, a NNG adotou um ícone específico para agrupar vários POI, mesmo de categorias diferentes; por exemplo, um ícone agrupando bancos, postos, lojas, etc. O objetivo é deixar a tela de navegação com menos ícones, menos "poluída" visualmente. Eu não gosto disso, mas entendo a lógica. Para ficar livre desta situação é comum o uso de um ícone transparente no lugar dos dois ícones originais. Isto não impede o agrupamento de ícones da mesma categoria, mas impede que o ícone de agrupamento de categorias diferentes apareça na tela. No caso do agrupamento de POI da mesma categoria, ao usar-se um transparente, o ícone que aparecerá na tela será aquele que representada uma dada categoria e não mais um genérico da NNG. Por que que outros branding.zip não era assim no Nextgen? Porque as pessoas simplesmente desconhecem o que falei acima e nunca pensaram em um branding feito deste jeito. Os tais dois ícones genéricos da NNG ficam no data.zip e as pessoas nunca pensaram em personalizá-los levando-os para o branding.zip. Resolvi fazer um branding de acordo com meu gosto pessoal e compartilhá-lo com todos, mas é claro que o meu gosto pode ser suprimido: basta, na subpasta \icons\poi, localizar os arquivos "mixedpoi.icon" e "multipoi.icon", aliás pode-se remover todos os arquivos desta pasta com extensão .icon (note-se a ausência de um "s" no final da extensão). Porém todos aqueles de extensão .icons devem permanecer. Cabe mais uma explicação para aqueles que gostam do assunto: o agrupamento de ícones de POI está relacionado com a configuração da distância de exibição dos ícones na tela de navegação. No caso do Primo, a skin diMka permite configurar a distância de exibição para cada categoria e para cada ponto de alerta em particular; mais, permite selecionar outro ícone manualmente. Não me lembro se a skin padrão permite tais ajustes. No caso no Nextgen com a skin original, não é possível alterar a distância e nem o ícone; não me recordo se as skins do Pongo e outras permitem. Pois bem, quanto maior a distância configurada, mais ícones aparecerão na tela. Aí entra o recurso da NNG de agrupar por categoria e por várias categorias quando se tem muitos POI habilitados pelo usuário. É razoável imaginar que uma região de muito comércio se tenha muitos ícones na tela quando o usuário habilita muitos pontos de interesses nas configurações da skin. Se os pontos de interesse forem configurados para serem exibidos na tela de navegação a partir de 5 km, por exemplo, tudo que estiver neste raio irá para a tela, de modo que um agrupamento será feito. Se a distância for reduzida para 1 km, então diminui-se a quantidade de ícones e nem sempre ocorre o agrupamento (exceto em regiões com grande comércio, etc.). Optei por uma explicação técnica para que surja um debate sobre como proceder no caso do branding, isto é, o que queremos de fato. O que apresentei é algo do meu gosto pessoal, mas nada impede que possamos convencionar algo e preparar um novo branding. Estou sempre aberto ao diálogo e as boas ideias que sempre surgem daí. Abraços! poi_shopping.zip

Cláudio, obrigado pelo retorno. Vou ver o que está acontecendo, pois 800x480 é a resolução que uso o tempo inteiro e não deu erro. Pode ter ocorrido problema ao fazer a conversão para o WinCE (uso Android). Por isso pedi ajuda, pois não tive tempo para testar tudo, mas corrigirei tudo aqui e disponibilizarei novo ícone. Edit: o erro do Tenda Atacado é o mesmo do Le Lis Blanc. Havia um erro de grafia no segundo e uma modificação de nomes de arquivos nos de supermercado. No caso do Tenda Atacada o nome do arquivo correto (no icon citado) é: superm_tenda_atacado.bmp, basta trocar o anterior por este, mas farei isso aqui e disponibilizarei novo link. Coelko, os ícones que você refere são aqueles relacionados a cada categoria, o que é correto. Explico: quando há mais de um posto de combustíveis, por exemplo, na mesma região, então o Primo e o Nextgen agrupa tudo em um único ícone que representa a categoria (no caso, posto de combustíveis). Isto é correto. No caso do Primo é comum usar um ícone específico, chamado multpoi, para agrupar tudo. No Nextgen isto é feito para o multipoi (grupos da mesma categoria), bem como o multigroup (quando se tem um agrupamento de categorias diferentes). A sacada usada no passado e que ainda me agrada é criar um ícone transparente, de modo que aparece apenas o agrupamento pela categoria em si (postos, supermercados, etc.) ao invés de um balãozinho azul representando algo genérico. Quanto ao uso do módulo ux "farol baixo", ainda não sei explicar. Só se este módulo ux feito para Nextgen estiver usando o mesmo arquivo que modifiquei para o efeito de transparência. Não notei problema algum com o Primo (onde o trabalho original do Fidelis e Rafael não apresenta problema), mas ainda não tive oportunidade de testar no Nextgen (uso a versão oficial, onde não inseri este mod para Nextgen). Vou ver o que posso fazer, não será problema algum resolver este problema. Abraços agradecidos aos dois amigos, .XA.