Resolver problemas

Saiba mais sobre as etapas de solução de problemas que podem ser úteis se você tiver problemas ao usar a Speech-to-Text.

Não é possível autenticar a Speech-to-Text

É possível que você receba uma mensagem de erro indicando que o "Application Default Credentials" está indisponível ou pode ser que você esteja se perguntando como ter uma chave de API para usar na Speech-to-Text.

A conversão de voz em texto usa o Application Default Credentials para autenticação.

É necessário ter uma conta de serviço para seu projeto, fazer o download da chave (arquivo JSON) da sua conta de serviço no ambiente de desenvolvimento e definir o local desse arquivo JSON em uma variável de ambiente denominada GOOGLE_APPLICATION_CREDENTIALS.

Além disso, a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS precisa estar disponível no contexto que você chama a API Speech-to-Text. Por exemplo, se você definir a variável a partir de uma sessão do terminal, mas executou seu código no depurador do ambiente de desenvolvimento integrado, o contexto de execução do seu código poderá não ter acesso à variável. Nesse caso, nossa solicitação para a conversão de voz em texto pode falhar por falta de autenticação adequada.

Para mais informações sobre como definir a variável de ambiente GOOGLE_APPLICATION_CREDENTIALS, consulte os guias de início rápido da conversão de voz em texto ou a documentação sobre como usar o Application Default Credentials.

A Speech-to-Text retorna uma resposta vazia

Há vários motivos para a Speech-to-Text retornar uma resposta vazia. A origem do problema pode ser a RecognitionConfig ou o próprio áudio.

Resolver problemas RecognitionConfig

O objeto RecognitionConfig (ou StreamingRecognitionConfig) faz parte de uma solicitação de reconhecimento da Speech-to-Text. Existem duas categorias principais de campos que precisam ser definidas para executar uma transcrição corretamente:

  • configuração de áudio;
  • modelo e linguagem.

Uma das causas mais comuns de respostas vazias (por exemplo, receber uma resposta JSON {} vazia) é fornecer informações incorretas sobre os metadados de áudio. Se os campos de configuração de áudio não estiverem definidos corretamente, a transcrição provavelmente falhará e o modelo de reconhecimento retornará resultados vazios.

A configuração de áudio contém os metadados do áudio fornecido. É possível conseguir os metadados do arquivo de áudio usando o comando ffprobe, que faz parte do FFMPEG.

No exemplo a seguir, demonstramos o uso do ffprobe para receber os metadados de https://storage.googleapis.com/cloud-samples-tests/Speech/Commercial_mono.wav.

$ ffprobe commercial_mono.wav
[...]
Input #0, wav, from 'commercial_mono.wav':
  Duration: 00:00:35.75, bitrate: 128 kb/s
  Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 8000 Hz, 1 channels, s16, 128 kb/s

Com o comando acima, vemos que o arquivo tem:

  • sample_rate_hertz: 8000
  • canais: 1
  • codificação LINEAR16 (s16)

Você pode usar essas informações na RecognitionConfig.

Outros motivos relacionados a áudio para uma resposta vazia podem estar relacionados à codificação de áudio. Veja algumas outras ferramentas e coisas para tentar:

  1. Reproduza o arquivo e ouça o áudio. Ele está claro? A fala está compreensível?

    Para reproduzir arquivos, você pode usar o comando SoX (Sound eXchange) play. Alguns exemplos baseados em diferentes codificações de áudio são mostrados abaixo.

    Os arquivos FLAC incluem um cabeçalho que indica a taxa de amostra, o tipo de codificação e o número de canais. Eles podem ser reproduzidos da seguinte maneira:

    play audio.flac

    Os arquivos LINEAR16 não incluem cabeçalho. Para reproduzi-los, você precisa especificar a taxa de amostra, o tipo de codificação e o número de canais. A codificação LINEAR16 precisa ser 16 bits, de número inteiro assinado e little endian.

    play --channels=1 --bits=16 --rate=16000 --encoding=signed-integer \
--endian=little audio.raw

    Os arquivos MULAW também não incluem um cabeçalho e geralmente usam uma taxa de amostra menor.

    play --channels=1 --rate=8000 --encoding=u-law audio.raw

  2. Verifique se a codificação de áudio de seus dados corresponde aos parâmetros que você enviou em RecognitionConfig. Por exemplo, se sua solicitação for especificada, os parâmetros de dados de áudio "encoding":"FLAC" e "sampleRateHertz":16000, listados pelo comando SoXplay devem corresponder a esses parâmetros, da seguinte maneira:

    play audio.flac

    precisa listar:

    Encoding: FLAC
Channels: 1 @ 16-bit
Sampleratehertz: 16000Hz

    Se a lista do SoX mostrar um Sampleratehertz diferente de 16000Hz, altere o "sampleRateHertz" em InitialRecognizeRequest para corresponder. Se o Encoding não for FLAC ou o Channels não for 1 @ 16-bit, você não poderá usar esse arquivo diretamente e será necessário convertê-lo em uma codificação compatível (consulte a próxima etapa).

  3. Se o arquivo de áudio não estiver em codificação FLAC, tente convertê-lo para esse formato usando o SoX. Então, repita as etapas acima para reproduzir o arquivo e verificar a codificação, o sampleRateHertz e os canais. Estes são alguns exemplos de conversão de vários formatos de arquivos de áudio para a codificação FLAC.

    sox audio.wav --channels=1 --bits=16 audio.flac
sox audio.ogg --channels=1 --bits=16 audio.flac
sox audio.au --channels=1 --bits=16 audio.flac
sox audio.aiff --channels=1 --bits=16 audio.flac

    Para converter um arquivo RAW para FLAC, é preciso conhecer a codificação de áudio do arquivo. Por exemplo, para converter um arquivo estéreo de 16 bits little endian em 16.000 Hz para FLAC:

    sox --channels=2 --bits=16 --rate=16000 --encoding=signed-integer \
--endian=little audio.raw --channels=1 --bits=16 audio.flac

  4. Execute o exemplo do Guia de início rápido ou um dos Aplicativos de amostra com o arquivo de áudio de amostra fornecido. Quando o exemplo estiver sendo executado corretamente, substitua o arquivo de amostra de áudio pelo seu arquivo de áudio.

Configuração de modelo e linguagem

A seleção de modelos é muito importante para conseguir resultados de transcrição de alta qualidade. A Speech-to-Text fornece vários modelos que foram ajustados para diferentes casos de uso e precisam ser escolhidos para corresponder ao áudio. Por exemplo, alguns modelos, como latest_short e command_and_search, são modelos curtos, o que significa que são mais adequados para áudios e prompts curtos. Esses modelos provavelmente retornarão resultados assim que detectarem um período de silêncio. Modelos longos, por outro lado, como latest_short, phone_call, video and default, são mais adequados para áudios mais longos e não são tão sensíveis à interpretação do silêncio como o fim do áudio.

Se o reconhecimento terminar muito abruptamente ou não retornar rapidamente, convém verificar e testar outros modelos para ver se você consegue uma melhor qualidade de transcrição. É possível testar vários modelos usando a IU de fala.

Resultados inesperados do reconhecimento de fala

Se os resultados retornados pela Speech-to-Text não forem os esperados: