Então, digamos que seu computador esteja transcrevendo áudio (de alguém falando) para texto. Por estar analisando os valores digitais do áudio, ele “renderiza” a transcrição mais rápido do que o tempo que leva para reproduzi-la em tempo real? Eu imagino que não está “ouvindo” como um humano faria, mas sim processa digitalmente. Estou certo nesta suposição?
A mesma pergunta se aplicaria à análise de vídeo.
Minha confusão é: ao reproduzir o áudio em uma taxa mais rápida, as palavras ficam obscuras, então como o computador compensa isso? Desculpe-me se estou faltando algo básico e fundamental aqui.
Edit: Quando eu uso o termo “tempo real” nesta questão, não me refiro no momento da gravação, e depois transcrevo em tempo real. Em vez disso, quero dizer reprodução em velocidade 1x (ou velocidade de reprodução em tempo real). Parece que algumas pessoas não entenderam o que eu quis dizer.
Sim. Absolutamente.
Os algoritmos podem processar dados tão rápido quanto podem lê-los e passá-los pela CPU.
Se os dados estiverem em disco, por exemplo, um NVMe moderno pode ler a mais de 5 GB/s, o que é muito mais rápido do que as taxas de bits normalmente usadas para armazenar dados de voz. Claro, o algoritmo real que está sendo aplicado pode ser mais ou menos complexo, então não podemos garantir que ele será processado na velocidade máxima de leitura, mas não há nada inerente que limite essa análise a ser em velocidade em tempo real.
O mesmo princípio se aplica ao vídeo, mas isso requer muito mais taxa de transferência devido à enorme quantidade de dados nesses arquivos. Isso obviamente depende da resolução, rácio de fotogramas e complexidade da análise. Na verdade, é difícil realizar análises de vídeo sofisticadas em tempo real porque a análise é quase sempre feita em vídeo descompactado, portanto, o processador deve ter tempo para decodificar e analisar em um curto período de tempo e manter os dados fluindo para que, no momento, alguma análise é feito, o próximo bloco de vídeo já está decodificado e na memória. Isso é algo em que trabalhei por quase uma década.
Quando você reproduz o vídeo mais rapidamente, as palavras não são claras para você, mas os dados são exatamente os mesmos. A velocidade com que o áudio está sendo processado não afeta a capacidade do algoritmo de entendê-lo. O software sabe exatamente quanto tempo cada amostra de áudio representa.
Eu iria um pouco além da resposta atual e gostaria de contradizer a ideia de que o computador está de alguma forma "reproduzindo" os arquivos. Isso implicaria que o processamento é necessariamente um processo estritamente sequencial, começando desde o início do arquivo e indo até o final.
Na realidade, a maioria dos algoritmos de processamento de áudio será um pouco sequencial - afinal, é assim que os arquivos de som devem ser interpretados ao reproduzi-los para consumo humano. Mas outros métodos são concebíveis: por exemplo, digamos que você queira escrever um programa que determine o volume médio de um arquivo de som. Você pode percorrer todo o arquivo e medir o volume de cada trecho; mas também seria uma estratégia válida (embora talvez menos precisa) apenas amostrar alguns trechos aleatoriamente e medi-los. Observe que agora o arquivo não é "reproduzido" de forma alguma; o algoritmo está simplesmente olhando para alguns pontos de dados que escolheu por si mesmo, é livre para fazê-lo na ordem que desejar.
Isso significa que falar em "reproduzir" o arquivo não é realmente o termo correto aqui - mesmo quando o processamento acontece sequencialmente, o computador não está "ouvindo" sons, está simplesmente processando um conjunto de dados (arquivos de áudio não são realmente nada além de uma lista de valores de pressão de ar registrados ao longo do tempo). Talvez a melhor analogia não seja um humano ouvindo o áudio, mas analisando-o observando a forma de onda do arquivo de áudio:
Nesse caso, você não está limitado pela escala de tempo real do áudio, mas pode olhar para qualquer parte da forma de onda que desejar pelo tempo que desejar (e se você for rápido o suficiente, poderá de fato " leia" a forma de onda em um tempo menor do que a reprodução do áudio original levaria). Claro, se for uma impressão de forma de onda muito longa, você ainda pode ter que "andar" um pouco para chegar à seção em que está interessado (ou se você for um computador, procure a posição correta no disco rígido). Mas a velocidade que você está andando ou lendo não está intrinsecamente ligada aos rótulos de tempo (imaginários) no eixo x, ou seja, o "tempo real" do áudio.
Sua pergunta central é esta:
Outras ótimas respostas aqui, mas aqui está - o que eu considero - um exemplo muito comum do mundo real de computadores analisando áudio mais rapidamente do que a reprodução de áudio em tempo real ...
Converter um CD de áudio para arquivos MP3 em um sistema de computador moderno é sempre mais rápido do que a reprodução em tempo real do áudio desse CD.
Tudo depende da velocidade do seu sistema e hardware, mas mesmo 20 anos atrás, converter um CD para arquivos MP3 era sempre mais rápido do que a reprodução em tempo real do áudio do CD.
Então, por exemplo, como um CD de áudio de 45 minutos pode ser convertido em MP3 em menos de 45 minutos? Como isso poderia ocorrer se o computador fosse restringido por limites de reprodução de áudio? São todos os dados do lado dos dados, mas restritos aos níveis humanos na reprodução.
Pense nisso: um computador está lendo os dados de áudio bruto de um CD a uma velocidade mais rápida do que a reprodução de áudio normal e executando um algoritmo nele para converter o áudio bruto em um formato de dados de áudio compactado.
E quando se trata de transcrever texto de áudio, é um processo de análise digital semelhante, mas com saída diferente. Um processo muito mais complexo do que apenas transcodificar áudio de um formato para outro, mas ainda é outro processo de análise digital.
PS: Para o fluxo aparentemente interminável de comentaristas que querem apontar que os PCs anteriores a 1995 não podiam codificar MP3s mais rápido que o tempo real… Sim, eu sei… É por isso que qualifico o que postei dizendo “…em um sistema de computador moderno …”, bem como afirmando “… mas até 20 anos atrás…” também.
O primeiro codificador de MP3 foi lançado em 7 de julho de 1994 e a
.mp3extensão foi formalmente escolhida em 14 de julho de 1995. O objetivo desta resposta é explicar em um nível muito alto que nos PCs modernos o ato de analisar o áudio mais rápido do que a reprodução em tempo real já existe de uma forma que todos nós usamos: O ato de converter um CD de áudio para arquivos MP3.Os computadores não experimentam o áudio da mesma forma que nós.
Gravações reproduzidas em alta velocidade tornam-se incompreensíveis para humanos porque estamos recebendo mais dados do que podemos processar. Nossos corpos e cérebros têm limites e uma vez que a "taxa de dados" é ligeiramente excedida, começamos a captar apenas partes do que está sendo dito. Aumente a velocidade e isso se torna rabiscado.
Um computador não experimenta esse fenômeno porque sua percepção de tempo na gravação não é baseada no tempo real que passou, mas na quantidade de dados processados. Um computador nunca lerá dados do disco mais rápido do que pode processá-los 1 , portanto, nunca ficará sobrecarregado. A taxa de dados sempre corresponde perfeitamente à velocidade de processamento.
1 A menos que seja instruído a fazê-lo por um programa de buggy, mas isso se aplica a todas as questões de computador.
Apesar das boas respostas aqui, eu vou ter que ir para um sólido
Depende
Alguns algoritmos dependem do poder de processamento de força bruta. Quanto mais poder de processamento você tiver, mais processamento (ou processamento mais preciso) você poderá fazer. Estamos em um ponto agora em que a maior parte do processamento de áudio não tem mais recursos limitados. O processamento de vídeo ainda é limitado em recursos, como pode ser visto pelo contínuo estado da arte em jogos.
Depois disso, porém, o problema que você tem com o processamento em tempo real é a latência - neste caso, o atraso entre você dizer algo e o computador colocar o texto. Todos os algoritmos de processamento têm algum atraso, mas qualquer coisa baseada em transformadas de Fourier é especialmente limitada por isso. Por um teorema matemático, quanto menor a frequência que você deseja reconhecer, mais dados você precisa para localizá-lo e, portanto, maior o atraso antes que o computador forneça um resultado. Então você chega a um ponto em que não importa o quão rápido você possa fazer as contas, você está sempre pelo menos tão atrasado.
O desafio para o processamento em tempo real é encontrar um ponto ideal onde você possa obter um processamento razoavelmente eficaz e ter o atraso relativamente imperceptível para os usuários. Este é sempre um compromisso entre atrasos menores e resultados de maior qualidade, e o algoritmo ideal para isso pode ser uma questão de gosto pessoal como qualquer outra coisa.
E no caso extremo, alguns algoritmos simplesmente não podem ser executados em tempo real. Existem alguns algoritmos de filtragem muito eficazes que exigem que os dados sejam executados de trás para frente, por exemplo. Estes podem dar resultados muito bons para pós-processamento de dados gravados, mas é claro que são totalmente impossíveis de executar com dados em tempo real.
Desde que você perguntou sobre a conversão de fala em texto ....
Não tenho certeza, mas parece que você pode estar pensando que o processo de reconhecimento de fala (ou processamento de áudio em tempo real em geral) funciona assim:
Mas não é isso que acontece. Uma vez que o áudio é convertido em bytes, tudo é tratado por algoritmos de processamento de sinal, e esses algoritmos de processamento de sinal podem ser executados tão rápido quanto a CPU pode gerenciar.
Aqui está um exemplo de como um sistema supersimples de conversão de fala em texto pode funcionar. Ele terá dois threads, um thread de aquisição de áudio e um thread de processamento de sinal. O thread de aquisição de áudio executa as seguintes etapas em um loop:
Este processo produz bytes a uma taxa fixa, ou seja, a taxa de amostragem multiplicada pelo número de bytes usados para armazenar cada amostra. Por exemplo, um sistema de fala para texto pode medir a onda sonora 8.000 vezes por segundo e usar dois bytes para armazenar cada uma dessas medições, de modo que adiciona 16.000 bytes (96.000 bits) de dados de áudio ao buffer por segundo.
Enquanto isso está acontecendo, o thread de processamento de sinal está fazendo o seguinte em um loop:
O tamanho de cada grupo de bytes e a quantidade de tempo necessária para processar esses bytes variam dependendo de qual algoritmo está sendo usado. Por exemplo, suponha que o algoritmo de processamento de sinal seja projetado para operar em meio segundo de áudio por vez. Ele vai esperar até encontrar pelo menos 8.000 bytes (0,5 segundos de áudio) no buffer, então mover esses 8.000 bytes do buffer para outra parte da memória e executar, digamos, uma transformação de Fourier neles, ou alimentá-los em um rede neural , ou assim por diante.
O que quer que a thread de processamento de sinal faça com esses 8.000 bytes, se ela terminar em menos de meio segundo, tudo bem; ele pode esperar até que haja 8.000 bytes disponíveis no buffer novamente e recomeçar. É claro que, se demorar mais de meio segundo, isso é um problema, porque o encadeamento de processamento de áudio adiciona dados ao buffer mais rapidamente do que o encadeamento de processamento de sinal pode removê-los. Quando o buffer fica cheio, ele não tem escolha a não ser começar a jogar fora os dados de áudio. Assim, os designers de algoritmos de processamento de áudio em tempo real fazem um grande esforço para garantir que seu algoritmo possa processar meio segundo (ou qualquer outro) de áudio em menos de meio segundo (ou qualquer outro) de tempo real, para que o buffer não t encher.
Em outras palavras, em qualquer sistema que processe áudio em tempo real (incluindo reconhecimento de fala e muitos outros), o processamento real deve ser capaz de funcionar mais rápido do que a reprodução em tempo real para não esgotar os recursos do sistema.
Observação: trabalho para uma empresa de reconhecimento de fala, embora tudo o que disse acima seja uma informação bastante genérica sobre processamento de áudio em tempo real e não específica do produto em que trabalho.
A hora e a velocidade atuais não têm significado para o processamento de gravações de sinais anteriores. A gravação em si tem informações de tempo.
Os limites de desempenho nos sinais de processamento são o processamento de números da CPU e/ou a rapidez com que a CPU pode ler esses dados da memória, disco, rede ou de onde quer que venham. Para áudio, muitas vezes isso é muito mais rápido do que 1 segundo de sinal por segundo de relógio de parede, mas você certamente pode executar um algoritmo ineficiente e/ou computacionalmente intensivo em um computador lento antigo e ir apenas a 1 segundo de sinal por minuto, e obtenha o arquivo de saída idêntico ao executado em uma CPU moderna a 10 segundos de sinal por segundo.
Se essa fonte for um conversor analógico->digital que está convertendo uma entrada de microfone em tempo real, é isso que define o limite de velocidade para 1 sinal-segundo por segundo do mundo real 1 , não a própria CPU.
O conceito-chave é que a passagem do tempo do relógio de parede do mundo real tem zero significado ou relevância para como um computador processa dados de áudio amostrados digitalmente; os dados vêm com suas próprias informações de tempo.
Muitas vezes é útil poder fazer algo pelo menos tão rápido quanto em tempo real, o que significa que você pode acompanhar o mundo exterior em vez de ter que salvá-lo em disco e processar offline, mas fora isso você está apenas fazendo matemática em as amostras do tempo
t=123.456s.Analogia: olhando para impressões de registros meteorológicos
Se você tiver algumas impressões de registros meteorológicos dos últimos 7 dias, como você pode reconhecer ciclos de congelamento e degelo e mudanças nos padrões de vento, se você virar as páginas e ler mais rápido do que 1 dia de dados por dia em tempo real? A resposta óbvia é "o quê? Por que eu teria que ler tão devagar, e o que isso tem a ver com a análise de dados gravados?" Esse é exatamente o caso de um computador fazendo qualquer tipo de processamento em sinais gravados de qualquer tipo (vídeo, áudio, registros de pressionamento de tecla de um keylogger de teclado, etc.)
Os computadores não "experimentam" o áudio gravado de outra forma que não seja olhando para as amostras digitais. Para nós, ver listas de números não teria sentido. O mesmo para computadores; eles realmente não entendem nada . (Assim como você não sente frio ou calor ao olhar para uma tabela de temperaturas anteriores.)
Se você programar um conjunto de etapas a seguir, elas o farão. Cabe aos programadores encontrar conjuntos úteis de etapas para fazer os computadores funcionarem com dados de áudio. Se esse conjunto de etapas tiver um resultado útil, executá-lo para obter esse resultado pode ser útil. Como encontrar o valor de amostra de pico em algum intervalo, normalizar o volume, filtrar alguma faixa de frequência ou algo mais complexo, como emitir uma sequência de caracteres de texto (fala->texto) ou uma representação compactada do áudio (por exemplo, mp3, AAC , Opus ou FLAC).
Em nenhum momento isso "significa" nada para o computador. São apenas números que representam o som, mas a própria CPU não sabe ou se importa com o que eles representam. Está apenas fazendo adição, multiplicação, comparação + ramificação para executar código diferente dependendo dos dados e coisas assim. (ou seja, código de máquina em execução, com números nos registradores e na memória).
O reconhecimento de fala é apenas um caso especial do que você pode fazer para analisar um sinal. Não é fundamentalmente diferente de compactar o arquivo de áudio em um
.zip,.flac,.mp3ou.opus, no que diz respeito à CPU e ao sistema operacional. Obviamente, os algoritmos que você usaria são muito diferentes, mas nada neles depende do tempo real, da frequência da CPU ou qualquer outra coisa, e dará o mesmo resultado, não importa o quão rápido ou lento seja o CPU.Suponho que você entenda que quanto mais rápido seu computador, mais rápido ele pode compactar cem megas de dados, mas você ainda obtém exatamente o mesmo arquivo de saída. Isso é totalmente normal, certo? Fala->texto ou outro processamento de áudio ou vídeo é o mesmo.
Todos os formatos de arquivo contêm informações de tempo (ou você as fornece separadamente). Na maioria dos arquivos (como simple
.wav) não há um timestamp explícito separado armazenado para cada amostra, mas há um pedaço de metadados para todo o arquivo que informa que a taxa de amostragem foi (por exemplo) 48kHz, então o computador sabe que cada 48.000 amostras compõem um segundo de tempo gravado . Isso é equivalente e permite que o computador saiba a que horas cada parte da gravação de áudio corresponde.Não faz diferença o quão lento ou rápido o computador é. por exemplo, você pode executar um programa de processamento de áudio em um computador de 20 a 40 anos atrás (supondo que ele possa carregar o suficiente na RAM para executar seu algoritmo), e pode levar horas ou dias para fazer algo com 2 minutos de áudio , vs. 10 segundos para um computador moderno.
A velocidade de processamento de números versus tempo real, tempo de processamento versus tempo de sinal, é apenas o número de desempenho. Não é fundamentalmente diferente de cronometrar quanto tempo leva para
zip(ouzstd) compactar um arquivo: você pode relatar os resultados como segundos por megabyte de entrada. Com arquivos de entrada de áudio e vídeo, você pode medir o tamanho de entrada em amostras, ou bytes não compactados, e relatar a velocidade em MB de áudio processado por segundo. Ou você pode medir a tempo e relatar uma proporção de quão rápido você processou em relação ao tempo real. Por exemplo, os compressores de áudio geralmente relatam a velocidade que atingiram como uma proporção de tempo de sinal / tempo de processamento. ou seja, quanto mais rápido ou mais lento eles eram do que a reprodução em 1x.Se você executar um benchmark em um videogame , muitas vezes verá os quadros voando em alta velocidade. (Ou muito baixo). Dependendo do jogo, ele está simulando o tempo de jogo muito mais rápido que o normal, porque você disse para ele fazer um benchmark para não limitar sua velocidade a 1 segundo de jogo por segundo real. Está simulando mais de 1 segundo de jogo de tempo de jogo por segundo real. Se um carro no jogo der um pulo e estiver no ar por 90 quadros (1,5 segundos de jogo em 60Hz padrão), isso ainda seria verdade, independentemente de quão rápido ou lento o benchmark estivesse rodando. (Jogos reais geralmente não têm seu tempo de simulação baseado em uma taxa de quadros fixa, não desde os 2d dias antigos, mas finge que você tinha um mecanismo de jogo simples que sempre tinha que rodar a 60Hz para fazer em tempo real.)
Para obter mais informações sobre amostragem digital, consulte Monty Montgomery's digital sampling show-and-tell 25 min video lecture/demo e part2 . A motivação foi explicar por que o áudio de 96kHz / 24 bits não é perceptivelmente melhor que o padrão de 44,1kHz / 16 bits, especialmente se pontilhado corretamente, mas é uma ótima introdução do zero aos conceitos de amostragem digital. (Monty desenvolveu o codec de áudio de código aberto Ogg/Vorbis e contribuiu para o Opus, o atual compressor de áudio de melhor qualidade.) Ele até usa alguns osciloscópios físicos reais, incluindo um analógico na demonstração, mostrando sinais se transformando em digitais e voltando para analógicos , para provar que a amostragem digital funciona.
Ver que os sinais podem se transformar em uma sequência de números pode ajudar a entender como os computadores podem processá-los.
(Claro que tudo isso é feito com processamento em tempo real, então IDK se isso ajudar você a entender o conceito de que o tempo não tem significado para o processamento de sinal, a menos que você esteja especificamente fazendo processamento em tempo real onde real-agora = sinal-agora. )
Nota de rodapé 1: Levará menos de 1 segundo de CPU para processar esse segundo de dados de áudio, para que a CPU possa passar algum tempo em suspensão de baixo consumo enquanto espera que mais dados se acumulem em um buffer. Caso contrário, sua CPU às vezes ficará para trás e descartará partes da entrada de áudio para recuperar o atraso, ou simplesmente ficará para trás, dependendo do design do software que gerencia a entrada e a saída em tempo real ou estilo offline.
Se você se preocupa com o uso em tempo real, deseja que a CPU seja mais rápida para que, mesmo no pior dos casos, ela não fique atrás do tempo real. (Além disso, seu algoritmo deve ser projetado para não precisar de "antecipação" em partes futuras do sinal. Em um caso de uso em tempo real, você não pode obter acesso a elas sem buffer por quantos segundos desejar Além disso, não há diferença fundamental (em termos de como a CPU funciona) entre executar o processamento de sinal em tempo real versus offline em arquivos já gravados.
I know you didn't ask about real-time processing, but it's interesting to note that the major difference between real-time vs. offline signal processing is that real-time introduces the possibility of the CPU "getting too far behind" in processing, if you try to make it run slow code. This maybe helps make clear that unlike a human brain, it always takes as much CPU time as it needs per second of signal, not processing differently depending on speed.
(You could write a program that switches to a simpler faster algorithm when it's getting behind, but that's not what I mean.)
Computers can adjust the speed audio data comes at them
The difference between computers and brains is that computers can generally change the speed at which they handle audio. Brains are limited in that respect.
While brains can't do anything to slow down audio if it's played too fast, computers can read and process an audio file slower if they need to. They can also read and process an audio file quicker if they're able to.
Computers break up programs into very small, correctly performed subtasks
Computers deal with bits: ones and zeroes. They have built into them a set of very small subtasks like adding together two numbers that are made up of a certain number of bits.
As long as the subtasks like addition are performed correctly, you'll get the same correct results no matter how quickly they're performed.
Em seguida, combinamos essas subtarefas em programas inteiros que fazem coisas como processamento de áudio. Então, o que acontece com a velocidade de nossos programas quando a velocidade dessas subtarefas aumenta? A velocidade de nossos programas aumentará.
Como é comumente conhecido, os computadores são muito, muito mais rápidos na adição do que os cérebros.
Aceleração de subtarefas são acelerações de programa
Os computadores começaram a ser muito lentos.
Como nossos programas de processamento de áudio são compostos de subtarefas executadas corretamente e como os computadores podem processar dados de áudio em qualquer velocidade que possam manipular, os computadores começarão a processar o áudio muito mais lentamente do que a velocidade de reprodução.
Quando as subtarefas aceleram com computadores mais novos, os programas de processamento de áudio aceleram. Agora temos computadores que podem fazer a maioria das tarefas de processamento de áudio mais rápido que a velocidade de reprodução.
O computador será restringido por seu próprio hardware, principalmente CPU ao processar o áudio (talvez GPU se por algum motivo isso fosse usado). Esta pode ser a velocidade em tempo real (1x), mais lenta que isso (se o computador não puder processá-lo tão rápido, pode exigir mais tempo, por exemplo, 1,5x para processá-lo, por exemplo, a renderização de vídeo geralmente leva muito tempo, mais de tocaria cada parte), e também poderia fazê-lo mais rápido do que isso.
Agora, a parte que sinto que está faltando nas outras respostas é que o computador provavelmente precisará saber qual é a velocidade normal. Tudo depende de como ele determina as palavras, mas provavelmente leva em consideração a duração de cada fonema, para o qual ele anotaria quanto tempo foi falado (por exemplo, um 'fonema' que durou apenas 1ms provavelmente era ruído de fundo). Se você tiver um arquivo de áudio, ele simplesmente analisará as informações de tempo que ele possui e processará o arquivo assim que puder finalizá-lo. Se você estiver fornecendo como entrada um áudio muito mais rápido que o tempo real, provavelmente precisará ser informado de que está sendo reproduzido em uma determinada taxa.
One thing to consider as well is how a human processes audio versus a computer. For a human, audio is a sequence of vibrations which can only be processed in real-time by the brain through reading these vibrations in the ear. Thus, the brain learns to and is designed in some ways to handle audio at the speed at which it is produced.
As for a computer, we digitize audio into a format which the computer can read - a sequence of amplitudes as a list. Unlike the vibrations we recorded this data from, a simple list can be read at whatever speed the computer can retrieve that data from memory / the hard drive and process it in the CPU. Of course speed depends on the operations used and the hardware used. If we store the audio on a floppy disk and use a microcontroller to process the audio it may be even slower than the human brain at decoding those signals. As for modern hardware, it is likely that we can process this data (for simple operations) at a speed many hundreds of times faster than a computer.
It also depends on the operation performed. Brains are brilliant at taking vibrations and determining the corresponding frequencies in that signal, for our brains to process and convert to music or sounds. It is also very good at recognising words within an audio signal. For computers, its strengths come from any operations which can be vectorised and have a solution in P - volume calculations, Fourier transforms, etc. are all very quick for computers to calculate. Word recognition is still a very hard problem, and so takes longer - often computers send the data to a server (such as Google's TTS) to process and return its answer back. In this case processing time is limited by internet bandwidth, and it is likely that humans will be quicker, even if the voice signal is already known.