具有一些特定要求的 .NET 中的录音

Posted 2023-02-25

【中文标题】具有一些特定要求的 .NET 中的录音

【英文标题】：Sound recording in .NET with some specific requirements

【发布时间】：2009-09-06 00:21:29

【问题描述】：

有大量关于从 .NET 录制声音的教程和博客。我已经阅读并从根本上理解了各种选项，但不确定哪种方法最简单，同时仍能满足我的要求：

最小

开始和停止录制 由 .NET 程序控制 从默认麦克风录制到 文件 尽量减少对最终用户的要求 计算机（即理想情况下没有要求 对于最新的 DirectX） 保存到任何常见的压缩文件 格式

理想

删除安静的录音区域 触发记录的开始/停止 在存在声音输入时（记录 只有当有事情要做时 记录） 能够恢复录制， 附加到以前保存的文件

我可以计算出实施的细节，我只是在寻找关于根据我的要求集开始的最佳路径的建议。

【参考方案1】：

我更喜欢使用 waveIn* API 函数（waveInOpen 等）录制音频。虽然这个 API 已经老了（15 年以上）并且比你想的更难使用，但它可以做你上面提到的所有事情（除了一个），根本不需要 DirectX，并且适用于每个版本的 Windows回到 Windows 95（尽管 .Net 在 Windows 98 之前的任何东西上都不起作用），甚至包括 Windows Mobile（当我发现它时，最后一个事实让我大吃一惊）。

它无法处理的一件事是保存为任何常见的压缩文件格式（但我不认为使用 DirectSound 录制 - 另一个主要选项 - 也可以处理此问题）。但是，有许多与 .Net 兼容的库可以为您处理这个要求（NAudio 非常值得推荐，尽管我从未使用过它）。使用 waveIn* 录制的优点之一（与 DirectSound 具有相同的优势）是您可以录制到内存中（而不是直接录制到文件中），因此您可以轻松地对音频进行任何操作（例如，将其保存到一个文件，去掉安静的部分，通过 FFT 过滤它，改变格式等）。许多与 .Net 兼容的库都是为处理内存缓冲区而不是文件而编写的，因此将音频始终保存在内存中是一个很大的好处。

可以触发录制的开始和停止，尽管不是您想的那样。使用 waveIn* API，您基本上可以从默认音频源开始录制，并且 API 开始用录制的声音填充内存缓冲区。当每个缓冲区被填满时，您会收到通知，然后您可以对每个缓冲区执行任何您喜欢的操作。对于实际录制到文件，您可以简单地扫描每个缓冲区，如果缓冲区是空的（不包含可听见的声音），您只需将其丢弃而不将内容写入文件。

这是一个 CodeProject 示例，展示了如何使用 waveIn* 和 waveOut* API：

http://www.codeproject.com/KB/audio-video/cswavrec.aspx?msg=2137882

我之前实际上在 C# 中使用过这个项目，并且效果很好。

【讨论】：

感谢您周到的回答。您提到的代码项目文章是我仔细查看的一个来源。我将把它打开一段时间，看看我得到了哪些其他回复，但这肯定很有用。

@MusiGenesis：您能详细说明“不包含可听见的声音”吗？在缓冲区中查找值高于某个阈值的样本是否足以将其视为静音？此类解决方案的典型缓冲区大约代表多少（毫秒）秒的音频？

@Eric J：每个缓冲区的大小完全取决于你作为程序员。如果您使用非常小的缓冲区，您可以让您的 UI 在视觉上非常快速地响应音频信息（即具有非常低的延迟），但它更容易受到故障和中断的影响。如果您使用非常大的缓冲区（例如 1 秒 / 44100 个样本），您将获得更少的故障，但您的 UI 将至少比您听到的内容晚 1 秒。

我最近编写的一个应用程序对每个缓冲区进行 FFT，并实时（接近）显示光谱仪。在这个应用程序中，我使用了 2048 个样本的缓冲区，大约是 5 毫秒。我通过实验选择了 2048，因为 FFT 必须在长度为 2 的幂的缓冲区上完成，并且 5 毫秒延迟相对于 Windows 调度您已经面临的最小 15 毫秒延迟来说很小。

实际上，这样的延迟已经超过 15 毫秒。我从 Larry Osterman（他是 SO 的用户，也是 Windows 音频代码的工程师 [！]）那里了解到，由于 .Net 中的 CLR，您的延迟可能会高达 250 毫秒或更糟。