技术信息

    本部分包含有关 Music Assistant 工作原理的更深入技术信息，供感兴趣的人参考。

    音量标准化

    根据此官方文档 https://tech.ebu.ch/docs/r/r128.pdf，完全避免削波的标准化值应为 -23 LUFS，但每个平台的值不同，因此很难获得正确的值。

    以下是母带插件开发商 izotope 比较不同平台如 YouTube、Spotify、Deezer、Tidal 等的好文档。此页面很好地解释了整个主题

    注意到上述内容，默认值为 -17，这在 99% 的情况下应该是一个很好的折衷方案。MA 最初将其设置为 EBU 的标准值 -23，但后来有人抱怨音乐太安静。

    一般来说，不建议关闭音量标准化，因为有太多不同的响度级别，特别是如果从不同来源播放音乐。MA 使用基于 EBU-R128 标准的综合响度级别，只调整整个曲目的增益上下，因此只要使用足够低的值保持余量，就不会压缩动态范围。MA 的限制器设置为 -1.5dB 以防止削波。用户有责任为音量标准化的目标级别使用合理的值，我们建议值在 -23 到 -12 LUFS 之间。默认值设置为 -17 LUFS。

    如果仅从一个来源（例如 Deezer）播放音频，并且该音频源已经标准化了其音频文件，则在 MA 中禁用标准化是安全的。如果从不同来源播放音频或音频在源处未标准化，强烈建议保持标准化启用以获得最佳体验。

    请注意，所有音频在播放时都会被分析。如果音频源没有可用的综合响度测量，MA 将回退到动态标准化器，其准确性较低，但至少会防止音量级别的突然下降或激增。请参阅我们在流媒体服务器设置中提供的设置来微调行为，您可以在核心控制器部分下的设置菜单中找到这些设置。

    更多技术细节

    如果曲目已经通过重播增益标签获得音量标准化数据，则将使用该数据代替以下过程。即使标签信息是在测量之后添加的，也是如此。

    所有曲目在内部由 Music Assistant 处理为原始 pcm。因此，播放的所有内容将首先解码为源采样率中的 32 位浮点原始 pcm（除非显式启用/需要重采样，例如启用流模式时），并且在提取原始源媒体时完成增益调整，因此传递到流媒体引擎的 pcm 块已经应用了增益调整。通过这种方式，在（最终）16 或 24 位位深内应该有足够的余量。如果播放目标不支持高于 16 位的位深，将应用抖动将信号再次降低到 16 位而不损失质量。

    MA 中的所有进一步处理都在 PCM 原始音频级别完成，例如 DSP 设置 - 如果启用"流模式"，交叉淡入淡出也在原始 pcm 块上完成，但这会将所有音频重采样到一个静态采样率和位深，以创建一个音频"流"发送给播放器。

    链中的最后部分是 MA 需要将音频发送给播放器。默认情况下，我们将原始 PCM 编码为 FLAC，因为它是无损的，同时仍提供相当数量的压缩。对于不能很好地处理 FLAC 或只是为了节省带宽的播放器，我们提供一个选项（每个播放器）改为编码为 MP3。

    流媒体服务器设置包含许多选项，这些选项决定音量标准化将如何执行。此外，单个播放器设置提供启用和禁用此功能的选项以及调整目标级别。

    曲目排队

    MA 有两种将曲目排队到播放器的方式：

    原生排队支持 播放器具有原生排队支持，因此我们告诉它在当前曲目结束前下一首曲目是什么。这是一个特殊功能，并非所有播放器都支持。例如，Squeezelite、Google Cast 和 Sonos 播放器支持（并且默认启用）。某些 DLNA 播放器支持它，但其他不支持，因此我们提供一个播放器设置来启用它，以便用户可以尝试看看播放器是否接受它。这样做的好处是完全支持无缝播放，并且在 Squeezelite 和 Sonos 的情况下，还支持交叉淡入淡出。完整的元数据也将发送到当前正在播放的播放器。

    流模式 作为原生排队的替代方案，我们还可以向播放器发送一个音频流，让 Music Assistant 将歌曲拼接在一起（无缝或交叉淡入淡出）。此模式默认用于 AirPlay、Snapcast 和从 Home Assistant 导入的任何媒体播放器，如果启用交叉淡入淡出，DLNA 和 Cast 也将使用流模式。这种方法的缺点是大多数播放器会丢失元数据显示（在扬声器本身上）。但是，某些 DLNA 播放器支持"icy metadata"，这是我们发送的通知正在播放内容的信息。

    关于播放器支持的说明：始终优先选择 Music Assistant 内的原生播放器提供者，而不是从 Home Assistant 导入的通用播放器！ Home Assistant 中的媒体播放器设计时考虑的是播放器/音乐的自动化，而不是提供最佳的流媒体体验本身。 Music Assistant 中的原生播放器提供者已经过优化调整，以提供最佳（音频）质量和体验，并支持分组和排队等导入功能。

    播放器完美同步

    只有在准确知道播放器播放每个音频帧的确切（毫秒精确）时间戳时，扬声器之间的音频同步才可能。实际上，有两种常用的策略来同步音频：

    1. 向每个播放器发送带有时间戳的帧 - 有一个主时钟，音频帧发送到同步组中的每个接收设备，包括时间戳。因此，每个播放器都知道何时应该播放每一帧，它可以丢弃或注入帧以保持同步。这种策略通常用于专有协议，如 Google Cast、Sonos、Roon RAAT、BluOS 甚至 Apple AirPlay (RAOP)。 这是迄今为止最好（最精确）的同步方法，因为每个播放器负责将正确的音频帧发送到 DAC（或数字传输）。

    2. 服务器端校正同步。每个播放器从集中源接收音频流，然后服务器跟踪每个播放器的延迟并通过暂停/快进、更快/更慢播放或注入帧来校正它。这更容易实现，因为客户端唯一需要的是客户端的准确进度报告（它播放了多少毫秒），服务器包含所有集中逻辑来保持同步。例如，Squeezelite 和 Snapcast 使用此方法。

    时间同步的工作效果取决于多种因素，但通常您会发现策略 1 优于策略 2 和/或策略 2 需要调整才能正确工作。例如，在 Snapcast 上，您可能会听到跳过（调整时的声音小干扰），而 Squeezelite 在基于 WiFi 的设备上工作效果较差，因为播放器延迟会变化。

    建议：要获得最佳的播放器同步音频体验，尽量坚持使用一个生态系统，如果可能，选择实现策略 1（专有协议）的选项之一。

    AirPlay 是首选，因为它是一个非常好的同步协议，最初是专有的，但已被逆向工程。您现在可以在商用音频设备（甚至是高端设备）和 DIY 设备中拥有 AirPlay 目标。它大大优于所有策略 2 流协议。同样适用于带有 google cast 协议的 35 美元 chromecast audio 适配器。它开箱即用，效果非常好。