Disons que votre ordinateur transcrit audio (de quelqu'un parle) au texte. Parce qu'il regarde les valeurs numériques de l'audio, cela "rend-il" la transcription plus rapide que le temps nécessaire pour la jouer en temps réel? J'imagine que ce n'est pas "écouter" comme un humain, il le traite plutôt numériquement. Ai-je raison dans cette hypothèse?
La même question postulerait pour analyser la vidéo.
Ma confusion est la suivante: lors de la lecture de l'audio à un taux plus rapide, les mots ne deviennent pas clairs, alors comment l'ordinateur compense-t-il cela? Excusez-moi si je manque quelque chose de base et fondamental ici.
Edit: Lorsque j'utilise le terme "temps réel" dans cette question, je ne veux pas dire au moment de l'enregistrement, puis transcrit en temps réel. Je veux dire que je veux dire la lecture à une vitesse 1x (ou la vitesse de lecture en temps réel). Il semble que certaines personnes n'ont pas attrapé ce que je voulais dire.
Si les données sont sur le disque, par exemple, une NVME moderne peut lire à 5+ GB/S, ce qui est beaucoup plus rapide que les débiteurs normalement utilisés pour stocker des données vocales. Bien sûr, l'algorithme réel appliqué peut être plus plus ou moins complexe, nous ne pouvons donc pas garantir qu'il sera traité à la vitesse de lecture maximale, mais il n'y a rien d'inhérent que cette analyse soit en temps réel en temps réel.
Le même principe s'applique à la vidéo mais qui nécessite beaucoup plus de débit en raison de la quantité énorme de données dans de tels fichiers. Cela dépend évidemment de la résolution, du taux d'images et de la complexité de l'analyse. Il est effectivement difficile d'effectuer une analyse vidéo sophistiquée en temps réel, car l'analyse est presque toujours effectuée sur une vidéo décompressée, le processeur doit donc avoir le temps de décoder et d'analyser dans une courte période de temps et de conserver des données qui s'écoule de manière à ce que, au moment où une analyse a une analyse. Est fait, le bloc de vidéo suivant est déjà décodé et en mémoire. C'est quelque chose que j'ai travaillé pendant presque une décennie.
Lorsque vous lisez une vidéo plus rapide, les mots ne sont pas clairs pour vous mais les données sont exactement identiques. La vitesse à laquelle l'audio est en cours de traitement n'affecte pas la capacité de l'algorithme de comprendre le logiciel sait exactement combien de temps chaque échantillon audio représente.
J'irais un peu plus loin que la réponse actuelle et j'aimerais contredire l'idée que l'ordinateur est en quelque sorte "à la lecture" des fichiers du tout. Cela impliquerait que le traitement est nécessairement un processus strictement séquentiel, à partir du début du fichier et de votre chemin vers la fin.
En réalité, la plupart Les algorithmes de traitement audio seront un peu séquentiels - après tout, c'est la manière dont les fichiers son sont destinés à être interprétés lors de la lecture de la consommation humaine. Mais d'autres méthodes sont concevables: par exemple, indiquez que vous souhaitez rédiger un programme qui détermine le volume moyen d'un fichier son. Vous pouvez traverser tout le fichier et mesurer le volume de chaque extrait; Mais ce serait également une stratégie valide (bien que peut-être moins précise) pour simplement échantillonner des extraits au hasard et mesurer ceux-ci. Notez que maintenant le fichier n'est pas "lu" du tout; L'algorithme regarde simplement quelques points de données qu'il a choisi par lui-même, il est libre de le faire dans n'importe quel ordre qu'il aime.
Cela signifie que parler de "jouer" Le fichier n'est pas vraiment le bon terme ici, même lorsque le traitement se produit de manière séquentielle, l'ordinateur n'est pas "à l'écoute" pour sons, c'est simplement Traitement A DataSet (les fichiers audio ne sont pas vraiment autre qu'une liste de valeurs de pression d'air enregistrées au fil du temps). Peut-être que la meilleure analogie n'est pas un humain écoute à l'audio, mais en l'analysant par regarder à la forme d'onde du fichier audio:
Dans ce cas, vous n'êtes pas du tout contraint par l'échelle de temps réelle de l'audio, mais vous pouvez examiner quelle que soit la partie de la forme d'onde que vous souhaitez si longtemps que vous souhaitez (et si vous êtes assez rapide, vous pouvez en effet " Lisez "la forme d'onde dans une période plus courte que la lecture de l'audio d'origine prendrait). Bien sûr, si c'est une très longue impression de formulaire d'onde, vous devez toujours avoir à "marcher" pour un bit pour atteindre la section qui vous intéresse (ou si vous êtes un ordinateur, recherchez la bonne position sur le disque dur). Mais la vitesse que vous marchez ou que vous lisez n'est pas intrinsèquement liée aux étiquettes de temps (imaginaire) sur l'axe des x, c'est-à-dire le "temps réel" de l'audio.
Votre question principale est la suivante:
"Un ordinateur peut-il analyser audio plus rapide que la lecture en temps réel?"
D'autres grandes réponses ici, mais voici - ce que je considère - être un exemple très banal du monde réel d'ordinateurs analysant l'audio plus rapide que la lecture audio en temps réel ...
Tout dépend de la vitesse de votre système et de votre matériel, mais même 20-ish il y a 20 ans, convertir un CD en fichiers MP3 a toujours été plus rapide que la lecture en temps réel du CD Audio.
Ainsi, par exemple, comment un CD audio de 45 minutes peut-il être converti en mp3 en moins de 45 minutes? Comment cela pourrait-il se produire si l'ordinateur a été contraint par des limites de lecture audio? Ce sont toutes les données du côté des données, mais contraintes aux niveaux humains lors de la lecture.
Pensez-y: un ordinateur lit les données audio brutes d'un CD à une vitesse plus rapide que la lecture audio normale et l'exécution d'un algorithme contre celui-ci pour convertir l'audio brut en un format de données audio compressé.
Et quand il s'agit de transcrire de texte de l'audio, c'est un processus d'analyse numérique similaire, mais avec une sortie différente. Un processus beaucoup plus complexe que de simplement transcoder l'audio d'un format à un autre, mais c'est toujours un autre processus d'analyse numérique.
PS: au flux apparemment sans fin des commentateurs qui souhaitent souligner que les PC avant 1995 ne pouvaient pas encoder des mp3 plus rapidement que le temps réel ... Oui, je sais ... c'est pourquoi je qualifie ce que j'ai posté en disant "... sur un système informatique moderne ... "Ainsi que dire" ... mais même 20 ans il y a des années ... "aussi.
Le premier codeur MP est sorti le 7 juillet 1994 et le .mp3
extension a été formellement choisi le 14 juillet 1995. Le point de cette réponse est d'expliquer à un niveau élevé que sur les PC modernes L'acte d'analyser l'audio plus rapide que la lecture en temps réel existe déjà d'une manière que nous utilisons tous: l'acte de convertir un CD audio en fichiers MP3.
Les enregistrements joués à une vitesse supérieure deviennent incompréhensibles pour les humains, car nous recevons plus de données que nous pouvons traiter. Notre corps et ses cerveaux ont des limites et une fois que le "débit de données" est légèrement dépassé, nous commençons à ramasser uniquement des parties de ce qui est dit. Tournez la vitesse et cela devient gibberish.
Un ordinateur n'a pas l'expérience de ce phénomène car sa perception du temps dans l'enregistrement n'est pas basée sur la durée réelle qui s'est passée, mais sur la quantité de données traitées. Un ordinateur ne lira jamais les données du disque plus rapidement qu'il ne peut le traiter1, donc ça n'a jamais surchargé. Le taux de données correspond toujours parfaitement à la vitesse de traitement.
1 À moins que cela ne soit dit de le faire par un programme de buggy, mais cela s'applique à chaque question informatique.
Malgré les bonnes réponses ici, je vais devoir aller pour un solide
Certains algorithmes dépendent de la puissance de traitement de la force brute. Plus vous obtenez de puissance de traitement, plus vous pouvez traiter (ou le traitement plus précis). Nous sommes à un moment où la plupart des traitements audio ne sont plus limités de ressources. Le traitement de la vidéo est toujours limité de ressources, comme on peut le voir par la pointe de la technologie de la technologie dans le jeu.
Après cela, le problème que vous avez avec le traitement en temps réel est latence - Dans ce cas, le retard entre vous dire quelque chose et l'ordinateur mettant le texte. Tous les algorithmes de traitement ont un certain retard, mais tout ce qui est basé sur Fourier Transforms est particulièrement limité par cela. Par un théorème mathématique, la fréquence inférieure que vous souhaitez reconnaître, plus vous avez besoin de données à repérer, et donc plus le délai est long avant que l'ordinateur vous donne un résultat. Donc, vous avez frappé un point où cela n'a pas d'importance à quelle vitesse vous pouvez faire les mathématiques, vous êtes toujours au moins aussi loin derrière.
Le défi pour le traitement en temps réel est de trouver un endroit sucré où vous pouvez obtenir un traitement raisonnablement efficace et avoir le retard relativement imperceptible pour les utilisateurs. C'est toujours un compromis entre les retards plus faibles et les résultats de qualité supérieure, et l'algorithme optimal pour cela peut être une question de goût personnel comme autre chose.
Et dans le cas extrême, certains algorithmes ne peuvent tout simplement pas être courus en temps réel. Certains algorithmes de filtrage très efficaces existent, ce qui nécessite que les données soient exécutées à l'envers, par exemple. Celles-ci peuvent donner de très bons résultats pour la post-traitement des données enregistrées, mais bien sûr, sont tout à fait impossibles à courir avec des données en temps réel.
Puisque vous avez demandé de convertir le discours au texte ....
Ma confusion est la suivante: lors de la lecture de l'audio à un taux plus rapide, les mots ne deviennent pas clairs, alors comment l'ordinateur compense-t-il cela?
Je ne suis pas sûr, mais on dirait que vous pensez que le processus de reconnaissance vocale (ou de traitement audio en temps réel en général) fonctionne comme celui-ci:
Mais ce n'est pas ce qui se passe. Une fois que l'audio est converti en octets, tout est géré par des algorithmes de traitement du signal, et ces algorithmes de traitement de signal peuvent fonctionner aussi rapidement que la CPU peut gérer.
Voici un exemple de la manière dont un système de discours à texte super simple pourrait fonctionner. Il aura deux threads, un fil d'acquisition audio et un fil de traitement de signal. Le fil d'acquisition audio exécute les étapes suivantes dans une boucle:
Ce processus produit des octets à un taux fixe, à savoir la taux d'échantillonnage multiplié par le nombre d'octets utilisés pour stocker chaque échantillon. Par exemple, un système de discours à texte peut mesurer la onde sonore 8000 fois par seconde et utiliser deux octets pour stocker chacune de ces mesures. Il ajoute de 16 000 octets (96 000 bits) de données audio au tampon par seconde.
Bien que cela se produise, le thread de traitement du signal fait ce qui suit dans une boucle:
La taille de chaque groupe d'octets et la quantité de temps prise pour traiter ces octets varient en fonction de l'utilisation de l'algorithme. Par exemple, supposons que l'algorithme de traitement du signal soit conçu pour fonctionner à une demi-seconde d'audio à la fois. Ça va attendre que cela trouve au moins 8 000 octets (0,5 seconde d'audio) dans le tampon, puis déplacez ces 8 000 octets du tampon dans une autre partie de la mémoire et courez, disons, A Fourier Transform sur ou les nourrir dans un réseau neuronal , ouc.
Quel que soit le fil de traitement du signal avec ces 8 000 octets, s'il finit en moins d'une demi-seconde, c'est bien; Il peut simplement attendre que 8 000 octets sont à nouveau disponibles dans le tampon et recommencent. Bien sûr, si cela prend plus d'une demi-seconde, c'est un problème, car le thread de traitement audio ajoute des données au tampon plus rapidement que le thread de traitement du signal peut le supprimer. Lorsque le tampon est plein, il n'a pas d'autre choix que de commencer à jeter des données audio. Les concepteurs d'algorithmes de traitement audio en temps réel s'assurent donc que leur algorithme peut traiter une demi-seconde (ou autre) d'audio en moins d'une seconde (ou autre) de temps réel, de sorte que le tampon ne t remplir.
En d'autres termes, dans n'importe quel système qui traite audio en temps réel (y compris la reconnaissance vocale et de nombreux autres), le traitement réel a pour être capable de travailler plus rapidement que la lecture en temps réel afin de ne pas épuiser les ressources du système.
Remarque: Je travaille pour une entreprise de reconnaissance vocale, bien que tout ce que j'ai dit ci-dessus soit assez génériques sur le traitement audio en temps réel et non spécifique au produit que je travaille.
L'ordinateur sera limité par son propre matériel, principalement de la CPU lors du traitement de l'audio (peut-être GPU si pour une raison quelconque serait utilisé). Cela pourrait être une vitesse en temps réel (1x), plus lente que celle (si l'ordinateur ne pouvait pas le traiter aussi rapidement, il peut nécessiter plus de temps, par exemple 1.5x pour le traiter, par exemple, le rendu vidéo prend souvent un long Temps, plus qu'il ne jouerait à chaque partie), et pourrait aussi le faire plus rapidement que cela.
Maintenant, la partie que je pense manque aux autres réponses est que l'ordinateur aura probablement besoin de savoir quelle est la vitesse normale. Tout dépend de la façon dont il détermine les mots, mais il prend probablement en compte la longueur de chaque phonème, pour laquelle il remarquerait la durée de la longueur (par exemple, un "phoneme" qui n'a probablement pas eu de bruit de fond). Si vous aviez un fichier audio, il examinera simplement les informations de synchronisation qu'il dispose et traitera le fichier dès qu'il peut la terminer. Si vous fournissez comme entrée un audio beaucoup plus rapide que le temps réel, il aura probablement besoin de dire qu'il est joué à un certain taux.
ne chose à considérer également est la manière dont un ordinateur est-il audio par rapport à un ordinateur. Pour un audio humain, une séquence de vibrations ne peut être traitée que en temps réel par le cerveau en lisant ces vibrations à l'oreille. Ainsi, le cerveau apprend et est conçu de manière à gérer l'audio à la vitesse à laquelle elle est produite.
Quant à un ordinateur, nous numérisons audio dans un format que l'ordinateur peut lire - une séquence d'amplitudes comme liste. Contrairement aux vibrations, nous avons enregistré ces données, une liste simple peut être lue à toute vitesse que l'ordinateur peut récupérer ces données de la mémoire/le disque dur et de le traiter dans la CPU. Bien sûr, la vitesse dépend des opérations utilisées et du matériel utilisé. Si nous stockons l'audio sur une disquette et utilisons un microcontrôleur pour traiter l'audio, il peut être encore plus lent que le cerveau humain pour décoder ces signaux. En ce qui concerne le matériel moderne, il est probable que nous puissions traiter ces données (pour des opérations simples) à une vitesse de plusieurs centaines de fois plus rapidement qu'un ordinateur.
Cela dépend également de l'opération effectuée. Les cerveaux sont brillants à la prise de vibrations et déterminant les fréquences correspondantes dans ce signal, pour notre cerveau de traiter et de convertir en musique ou en sons. Il est également très bon de reconnaître les mots dans un signal audio. Pour les ordinateurs, ses forces proviennent de toutes les opérations pouvant être vectorisées et ont une solution dans les calculs P-volume, les transformations de Fourier, etc. sont tous très rapides pour calculer. La reconnaissance des mots reste un problème très difficile, et prend donc plus de temps - souvent des ordinateurs envoient les données à un serveur (telles que les TTS de Google) pour traiter et renvoyer sa réponse. Dans ce cas, le temps de traitement est limité par la bande passante Internet, et il est probable que les humains seront plus rapides, même si le signal vocal est déjà connu.