因此，假设您的计算机正在将（某人说话的）音频转录为文本。因为它正在查看音频的数字值，所以它“渲染”转录的速度是否比实时播放它所花费的时间更快？我想它不像人类那样“听”，而是以数字方式处理它。我的这个假设是对的吗？
同样的问题也适用于分析视频。
我的困惑是：以更快的速度播放音频时，单词变得不清楚，那么计算机如何补偿呢？如果我在这里遗漏了一些基本和基本的东西，请原谅。
编辑：当我在这个问题中使用“实时”一词时，我并不是指在录制时，然后实时转录。相反，我的意思是以 1 倍速度（或实时播放速度）播放。似乎有些人没有听懂我的意思。
是的。绝对地。
算法可以尽可能快地处理数据，因为它们可以读取它们并通过 CPU 获取它们。
例如，如果数据在磁盘上，现代 NVMe 可以以 5+ GB/s 的速度读取，这比通常用于存储语音数据的比特率快得多。当然，实际应用的算法可能或多或少复杂，因此我们不能保证它会以最大读取速度进行处理，但没有任何内在因素将这种分析限制为实时速度。
同样的原则也适用于视频，但由于此类文件中的数据量很大，因此需要更多的吞吐量。这显然取决于分析的分辨率、帧速率和复杂性。实时执行复杂的视频分析实际上很困难，因为分析几乎总是在解压缩的视频上进行，因此处理器必须有时间在短时间内解码和分析并保持数据流动，以便在进行一些分析时完成后，下一个视频块已经解码并在内存中。这是我工作了近十年的事情。
当您更快地播放视频时，文字对您来说不清楚，但数据完全相同。处理音频的速度不会影响算法理解它的能力。软件确切地知道每个音频样本代表多少时间。
我会比当前的答案更进一步，并且想反驳计算机以某种方式“播放”文件的想法。这意味着处理必须是一个严格的顺序过程，从文件的开头开始，一直到最后。
实际上，大多数音频处理算法都会有一定的顺序性——毕竟，在播放声音文件以供人类消费时，这就是解释声音文件的方式。但其他方法也是可以想象的：例如，假设您要编写一个程序来确定声音文件的平均响度。您可以浏览整个文件并测量每个片段的响度；但它也是一种有效（尽管可能不太准确）的策略，只是随机抽取一些片段并进行测量。请注意，现在该文件根本没有“播放”；该算法只是查看它自己选择的一些数据点，它可以按照它喜欢的任何顺序自由地这样做。
这意味着在这里谈论“播放”文件根本不是正确的术语——即使处理确实是按顺序进行的，计算机也不是在“听”声音，它只是在处理数据集（音频文件除了随时间记录的气压值列表之外，实际上并没有其他任何东西）。也许更好的类比不是人类在听音频，而是通过查看音频文件的波形来分析它：
在这种情况下，您根本不受音频的实际时间尺度的限制，而是可以查看波形的任何部分，无论您想要多长时间（如果您的速度足够快，您确实可以“在比播放原始音频更短的时间内读取波形）。当然，如果它是一个很长的波形打印输出，您可能仍然需要“走”一点才能到达您感兴趣的部分（或者如果您是计算机，请寻找硬盘驱动器上的正确位置）。但是你走路或阅读的速度与 x 轴上的（想象的）时间标签没有内在的联系，即音频的“实时”。
你的核心问题是这样的：
这里还有其他很好的答案，但这里是——我认为——是计算机分析音频比实时音频播放更快的一个非常常见的现实世界示例……
在现代计算机系统上将音频 CD 转换为 MP3 文件总是比实时播放该 CD 上的音频要快。
这完全取决于您的系统和硬件的速度，但即使在 20 年前，将 CD 转换为 MP3 文件也总是比实时播放 CD 音频要快。
那么，例如，一张 45 分钟的音频 CD 如何在不到 45 分钟的时间内转换为 MP3？如果计算机受到音频播放限制的限制，怎么会发生这种情况？它是数据端的所有数据，但在回放时受限于人类水平。
想一想：一台计算机正在以比正常音频播放更快的速度从 CD 读取原始音频数据，并针对它运行算法以将原始音频转换为压缩的音频数据格式。
当涉及从音频转录文本时，这是一个类似的数字分析过程，但输出不同。这是一个远比将音频从一种格式转码为另一种格式的复杂过程，但它仍然是另一个数字分析过程。
PS：对于看似无穷无尽的评论者，他们想要指出 1995 年之前的 PC 无法比实时更快地编码 MP3……是的，我知道……这就是为什么我用“……在现代计算机系统上”来限定我发布的内容……”以及陈述“……但即使是 20 年前……”也是如此。
第一个MP3 编码器于 1994 年 7 月 7 日问世，并于
.mp31995 年 7 月 14 日正式选择扩展。这个答案的重点是在非常高的层次上解释在现代 PC 上分析音频的行为比实时播放更快已经以我们都使用的方式存在：将音频 CD 转换为 MP3 文件的行为。计算机体验音频的方式与我们不同。
以更高速度播放的录音对于人类来说变得难以理解，因为我们接收到的数据超出了我们的处理能力。我们的身体和大脑是有限制的，一旦稍微超过“数据速率”，我们就会开始只接收部分内容。加快速度，它变得乱码。
计算机不会遇到这种现象，因为它对记录时间的感知不是基于实际经过的时间，而是基于处理的数据量。计算机从磁盘读取数据的速度永远不会超过其处理数据的速度1，因此它永远不会超载。数据速率始终与处理速度完美匹配。
1除非有错误的程序告诉它这样做，但这适用于每一个计算机问题。
尽管这里有很好的答案，但我还是要坚持下去
这取决于
一些算法依赖于蛮力处理能力。您拥有的处理能力越强，您可以进行的处理就越多（或更准确的处理）。我们现在处于大多数音频处理不再受资源限制的地步。然而，视频处理仍然是资源有限的，这可以从游戏中持续的最新技术中看出。
在那之后，实时处理的问题是延迟——在这种情况下，你说某事和计算机发出文本之间的延迟。所有处理算法都有一些延迟，但任何基于傅里叶变换的算法都特别受此限制。根据数学定理，您希望能够识别的频率越低，您需要识别它的数据就越多，因此计算机给出结果之前的延迟就越长。所以你确实达到了一个点，不管你做数学有多快，你总是至少落后那么远。
实时处理的挑战是找到一个最佳点，在那里你可以获得相当有效的处理，并且延迟对用户来说相对不易察觉。这始终是在更低延迟和更高质量结果之间进行权衡，为此最佳算法可能与其他任何事情一样取决于个人喜好。
而在极端情况下，一些算法根本无法实时运行。例如，存在一些非常有效的过滤算法，它们要求数据向后运行。这些可以为记录数据的后处理提供非常好的结果，但当然完全不可能使用实时数据运行。
既然你问到将语音转换为文本......
我不确定，但听起来您可能会认为语音识别（或一般的实时音频处理）的过程是这样的：
但事实并非如此。一旦音频转换为字节，一切都由信号处理算法处理，而这些信号处理算法可以以 CPU 所能管理的速度运行。
这是一个超级简单的语音到文本系统如何工作的示例。它将有两个线程，一个音频采集线程和一个信号处理线程。音频采集线程循环运行以下步骤：
此过程以固定速率产生字节，即采样率乘以用于存储每个样本的字节数。例如，语音到文本系统可能每秒测量 8000 次声波并使用两个字节来存储每个测量值，因此它每秒向缓冲区添加 16000 字节（96000 位）的音频数据。
当这种情况发生时，信号处理线程正在循环中执行以下操作：
每组字节的大小以及处理这些字节所花费的时间量取决于所使用的算法。例如，假设信号处理算法设计为一次对半秒的音频进行操作。它会一直等到在缓冲区中找到至少 8000 字节（0.5 秒的音频），然后将这 8000 字节从缓冲区移动到内存的另一部分，然后对它们进行傅里叶变换，或者将它们输入神经网络，等等。
无论信号处理线程对这 8000 个字节做什么，如果它在不到半秒的时间内完成，那很好；它可以等到缓冲区中再次有 8000 个字节可用并重新开始。当然，如果超过半秒，那就有问题了，因为音频处理线程将数据添加到缓冲区的速度比信号处理线程可以删除它的速度要快。当缓冲区已满时，它别无选择，只能开始丢弃音频数据。因此，实时音频处理算法的设计者不遗余力地确保他们的算法可以在不到半秒（或任何时间）的时间内处理半秒（或任何时间）的音频，以便缓冲区不会t 填满。
换句话说，在任何实时处理音频的系统（包括语音识别和许多其他系统）中，实际处理必须能够比实时回放更快地工作，这样它才不会耗尽系统的资源。
注意：我在一家语音识别公司工作，尽管我上面所说的一切都是关于实时音频处理的非常通用的信息，而不是特定于我工作的产品。
当前时间和速度对于处理过去信号的记录没有任何意义。录音本身有时间信息。
处理信号的性能限制是 CPU 数字运算和/或 CPU 从内存、磁盘、网络或来自任何地方的数据读取数据的速度。对于音频，这通常比每挂钟秒 1 个信号秒快得多，但您当然可以在一台古老的慢速计算机上运行效率低下和/或计算密集型的算法，并且每分钟只运行 1 个信号秒，并且以每秒 10 个信号秒的速度在现代 CPU 上运行相同的输出文件。
如果该源是实时转换麦克风输入的模拟->数字转换器，那么这就是将速度限制设置为 1 个信号秒/真实世界秒1的原因，而不是 CPU 本身。
关键概念是现实世界挂钟时间的流逝与计算机如何处理数字采样音频数据的意义或相关性为零。数据带有自己的时间信息。
能够以至少与实时一样快的速度做某事通常很有用，这意味着您可以跟上外部世界，而不必将其保存到磁盘并离线处理，但除此之外，您只是在做数学运算从时间的样本
t=123.456s。类比：查看天气记录的打印输出
如果您有一些过去 7 天的天气记录打印输出，如果您每天翻页并读取超过 1 天的实时数据，您如何识别冻融循环和变化的风型？显而易见的答案是“什么？我为什么要读那么慢，这与分析记录的数据有什么关系？” 这正是计算机对任何类型的记录信号（视频、音频、来自键盘键盘记录器的击键记录等）进行任何类型处理的情况。
除了查看数字样本之外，计算机不会以任何方式“体验”录制的音频。对我们来说，查看数字列表毫无意义。电脑也一样；他们什么都不懂。（就像您查看过去温度表时不会感到冷或热一样。）
如果您编写一组要遵循的步骤，他们就会这样做。程序员需要找到有用的步骤集来使计算机在音频数据上运行。如果这组步骤碰巧有一个有用的结果，那么运行它以获得该结果可能很有用。比如在某个时间间隔内找到峰值样本值，标准化音量，过滤掉某个频率范围，或者更复杂的事情，比如输出一系列文本字符（语音->文本），或者音频的压缩表示（例如 mp3、AAC 、作品或 FLAC）。
在任何时候，这些对计算机都没有任何“意义”。这只是代表声音的数字，但 CPU 本身并不知道也不关心它们代表什么。它只是做加法、乘法、比较+分支来根据数据运行不同的代码，诸如此类。（即运行机器代码，在寄存器和内存中有数字）。
语音识别只是分析信号的一种特殊情况。就 CPU 和操作系统而言，它与将音频文件压缩为
.zip、.flac、.mp3或没有根本不同。.opus显然，您使用的算法有很大不同，但它们不依赖于实时性、CPU 频率或其他任何东西，并且无论 CPU 多快或多慢都会给出相同的结果。我假设你明白你的电脑越快，它压缩一百兆数据的速度就越快，但你仍然得到完全相同的输出文件。这完全正常，对吧？语音->文本或其他音频或视频处理是相同的。
所有文件格式都包含时间信息（或者您单独提供）。在大多数文件（例如 simple
.wav）中，没有为每个样本存储单独的显式时间戳，但是整个文件有一个元数据告诉您采样率是（例如）48kHz，因此计算机知道每个48,000 个样本构成一秒的记录时间。这是等效的，让计算机知道录音的每个部分对应的时间。计算机的速度有多慢或多快是零差异。例如，您可以在 20 到 40 年前在计算机上运行音频处理程序（假设它可以将足够多的内容加载到 RAM 中以完全运行您的算法），并且可能需要数小时或数天才能完成 2 分钟的音频, 与现代计算机的 10 秒相比。
数字运算速度与实时，处理时间与信号时间，只是性能数字。它与计时
zip（或zstd）压缩文件所需的时间没有根本区别：您可以将结果报告为每输入兆字节的秒数。使用音频和视频输入文件，您可以测量样本或未压缩字节的输入大小，并报告每秒处理音频的 MB 速度。或者您可以及时测量并报告处理速度与实时的比率。例如，音频压缩器通常将它们实现的速度报告为信号时间/处理时间的比率。即它们比 1x 播放快多少或慢多少。如果您在视频游戏上运行基准测试，您通常会看到帧以疯狂的高速飞过。（或非常低）。根据游戏的不同，它模拟游戏时间的速度比正常快得多，因为您告诉它进行基准测试，因此它不会将其速度限制为每真实秒 1 游戏秒。它每真实秒模拟超过 1 游戏秒的游戏时间。如果游戏中的汽车发生跳跃并在空中停留了 90 帧（在标准 60Hz 下为 1.5 游戏秒），无论基准运行速度有多快或多慢，这仍然是正确的。（真正的游戏通常没有基于固定帧速率的模拟时间，从过去的 2 天开始就没有，而是假设你有一个简单的游戏引擎，它总是必须以 60Hz 运行才能实时运行。）
有关数字采样的更多信息，请参阅 Monty Montgomery 的数字采样演示25 分钟视频讲座/演示和第 2 部分。动机是解释为什么 96kHz / 24 位音频并不明显优于标准 44.1kHz / 16 位，尤其是在正确抖动的情况下，但它是从零开始到数字采样概念的一个很好的介绍。（Monty 开发了著名的 Ogg/Vorbis 开源音频编解码器，并为目前质量最好的音频压缩器 Opus 做出了贡献。）他甚至使用了一些真实的物理示波器，包括演示中的模拟示波器，显示信号转换为数字信号并返回模拟信号，以证明数字采样有效。
看到信号可以变成一系列数字可能有助于理解计算机如何处理它们。
（当然，这一切都是通过实时处理完成的，所以 IDK 是否可以帮助您理解时间对信号处理没有意义的概念，除非您专门进行实时处理，其中 real-now = signal-now。 )
脚注 1： 处理那一秒的音频数据将花费不到 1 CPU 秒的时间，因此 CPU 可以在等待更多数据在缓冲区中建立时花费一些时间处于低功耗睡眠状态。否则，您的 CPU 有时会落后并丢弃部分音频输入以赶上，或者只是落后，这取决于以实时或离线方式管理输入和输出的软件的设计。
如果您关心实时使用情况，您希望 CPU 更快，这样即使在最坏的情况下，它也不会落后于实时。（而且，您的算法必须设计为不需要对信号的未来部分进行“前瞻”。在实时用例中，如果没有缓冲，您将无法访问那些您想要的秒数向前看。）除此之外，在已经录制的文件上实时运行信号处理与离线运行信号处理之间没有根本区别（就 CPU 的工作方式而言）。
我知道您没有询问实时处理，但有趣的是，实时与离线信号处理之间的主要区别在于实时引入了 CPU 在处理中“落后太多”的可能性，如果你试图让它运行慢代码。这可能有助于清楚地表明，与人类大脑不同，它总是花费与每秒信号所需的 CPU 时间一样多的 CPU 时间，而不是根据速度进行不同的处理。
（你可以编写一个程序，当它落后时切换到更简单、更快的算法，但这不是我的意思。）
计算机可以调整音频数据的速度
计算机和大脑之间的区别在于，计算机通常可以改变它们处理音频的速度。大脑在这方面是有限的。
如果播放速度过快，大脑无法减慢音频速度，但如果需要，计算机可以更慢地读取和处理音频文件。如果可以的话，他们还可以更快地读取和处理音频文件。
计算机将程序分解成非常小的、正确执行的子任务
计算机处理位：一和零。他们在其中内置了一组非常小的子任务，例如将两个由一定数量的位组成的数字相加。
只要正确执行加法等子任务，无论执行多快，您都将获得相同的正确结果。
然后我们将这些子任务组合成完整的程序来执行音频处理等操作。那么当这些子任务的速度增加时，我们的程序的速度会发生什么变化呢？我们程序的速度将会提高。
众所周知，计算机的加法速度比大脑快得多。
子任务加速是程序加速
计算机开始时非常慢。
由于我们的音频处理程序由正确执行的子任务组成，并且由于计算机可以以它们可以处理的任何速度处理音频数据，因此计算机开始处理音频的速度将比播放速度慢得多。
当子任务使用较新的计算机加速时，音频处理程序也会加速。我们现在拥有可以比播放速度更快地完成大多数音频处理任务的计算机。
计算机将受到其自身硬件的限制，主要是处理音频时的 CPU（如果出于某种原因可能会使用 GPU）。这可能是实时速度（1x），比那个慢（如果计算机不能这么快处理它，它可能需要更多时间，例如 1.5x 来处理它，例如视频渲染通常需要很长时间，超过它会演奏每个部分），并且也可以比这更快。
现在，我觉得其他答案中缺少的部分是计算机可能需要知道正常速度是多少。这一切都取决于它如何确定单词，但它可能会考虑每个音素的长度，它会记下它被说出多长时间（例如，仅持续 1ms 的“音素”可能是背景噪音）。如果您有一个音频文件，它只会查看它所拥有的时间信息，并在完成后立即处理该文件。如果您提供比实时快得多的音频作为输入，则可能需要告知它正在以特定速率播放。
还要考虑的一件事是人类与计算机相比如何处理音频。对于人类来说，音频是一系列振动，只有通过读取耳朵中的这些振动，才能由大脑实时处理。因此，大脑以某种方式学习并被设计为以音频产生的速度处理音频。
对于计算机，我们将音频数字化为计算机可以读取的格式 - 一系列幅度作为列表。与我们记录此数据的振动不同，可以以计算机可以从内存/硬盘驱动器检索该数据并在 CPU 中处理它的任何速度读取一个简单的列表。当然速度取决于使用的操作和使用的硬件。如果我们将音频存储在软盘上并使用微控制器来处理音频，那么解码这些信号的速度可能比人脑还要慢。至于现代硬件，我们很可能以比计算机快数百倍的速度处理这些数据（用于简单操作）。
它还取决于执行的操作。大脑非常擅长接收振动并确定该信号中的相应频率，以便我们的大脑处理并转换为音乐或声音。它也非常擅长识别音频信号中的单词。对于计算机来说，它的优势来自于任何可以向量化的操作，并且在 P - 体积计算、傅里叶变换等方面都有解决方案，计算机计算起来都非常快。单词识别仍然是一个非常困难的问题，因此需要更长的时间 - 通常计算机将数据发送到服务器（例如 Google 的 TTS）以处理并返回其答案。在这种情况下，处理时间受到互联网带宽的限制，即使语音信号已知，人类也可能会更快。