Update on 2026-03-17: 使用某下载器对 TOGENASHI TOGEARI - Fragile Violet - Single 进行了复测，发现解码失败的问题仍然存在，而且元信息里的 Encoded date 仍然是 2025-06-23，证明苹果并没有重新编码。鉴于内录测试已经证明了下载器的可靠性，故此次并没有重新使用内录法测试，有兴趣的可自行验证。
TL;DR for non-Chinese readers: Since around May 2025, We’ve discovered that many lossless ALAC files sourced from Apple Music are fundamentally corrupted—an issue that remains unfixed as of March 2026. Through rigorous internal recording tests, where We captured raw audio directly from the official Windows client (shout out to @TheM14) and compared it with pristine tracks from platforms like MORA and Tidal, We’ve proven that this is not a third-party downloader or DRM decryption glitch, but a defect originating directly from Apple’s own source files or encoders. Because these corrupted files consistently fail standard integrity checks in software like foobar2000 and throw specific processing errors in FFmpeg, I’ve included automated batch scripts (for Windows, Bash, and PowerShell) below to help you easily scan your own local library. Ultimately, Apple Music’s lossless tracks can no longer be blindly trusted for high-fidelity archiving; I strongly advise you to verify your files, be cautious of converted FLACs that might mask these underlying errors, and always cross-reference your music with known good sources.
在大约今年5月份之后，Apple Music 某个节点上的无损音乐编码器似乎坏掉了，导致他们提供的音乐源文件就是爆的，相比于其他来源会出现丢失采样的问题。根据社区的实验，内录官方客户端并分析采样，会发现问题依然存在，因此该问题似乎与社区中热门的第三方下载实现无关。
叠甲在先：
尽管 Apple Music 的下载方案已从去年 DRM 被公开破拆之后成为马奇诺防线，并可在多个国内平台看到教程，但本文并不提供任何下载指导，也不鼓励任何形式的侵权行为。
本文的方法论建立在对几张典型专辑的实际测试之上，我并非 Apple Music 的利益相关者，我甚至并不知道当前的情况是 Apple Music 官方的编码器压坏了，还是 Apple 故意为之，推出了某个很新的妙妙 DRM 方案。众所周知，Apple Music 的编码器会对音频进行一些特殊处理（比如将部分数字母带™的响度调高），如果这次发现的音频问题在内录后依然存在，那么我认为它就不应被归类为 DRM，而是一种事实上的音频水印。
Stream Metadata: encoder : Lavc62.13.101 pcm_s16le creation_time : 2025-06-23T04:06:21.000000Z handler_name : Fragile Violet vendor_id : [0][0][0][0] [alac @ 00000289a4f48580] invalid element channel count [aist#0:0/alac @ 00000289a2cc8fc0] [dec:alac @ 00000289a2cc9180] Error submitting packet to decoder: Invalid data found when processing input [alac @ 00000289a2cee6c0] invalid element channel count [alac @ 00000289a4f48580] invalid element channel count [aist#0:0/alac @ 00000289a2cc8fc0] [dec:alac @ 00000289a2cc9180] Error submitting packet to decoder: Invalid data found when processing input Last message repeated 1 times [alac @ 00000289a4f79a40] Syntax element 4 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented. [aist#0:0/alac @ 00000289a2cc8fc0] [dec:alac @ 00000289a2cc9180] Error submitting packet to decoder: Not yet implemented in FFmpeg, patches welcome [out#0/wav @ 00000289a2c23080] video:0KiB audio:32168KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.000929% size= 32168KiB time=00:03:07.10 bitrate=1408.4kbits/s speed=3.54e+03x elapsed=0:00:00.05
此前的发现在社区内引发了广泛讨论，其中不乏有观点认为这是 Apple Music 的一种防盗版机制。为了厘清这一问题，本段将提供一份客户端内录的验证记录，让每位读者都能亲手检验——这些音频瑕疵究竟是源于 DRM 保护，还是 Apple 自身的编码器缺陷。 在动手前，请务必再次阅读以下声明：首先，出于版权考量，本文不会涉及任何下载教学，我们假设您已合法拥有需要验证的音乐。其次，我们判断的逻辑很简单，也已在上文中叙述：如果所谓的“问题”在内录后仍然存在，那它就和 DRM 无关了，而是一种被编码进音频里的“事实水印”，是该和国内的流媒体坐一桌的。
干掉 Windows 自带的 CAudioLimiter。 这是 Windows 操作系统音频引擎中一个内置的音频处理组件。它的主要功能是作为一个峰值限制器（limiter），防止音频信号在输出时超过最大电平（0 dBFS），从而避免产生削波（clipping）失真。但为了忠实地还原音频，我们需要确保录制的音频不经过任何额外处理。你可以参考 B 站上的 BV1GPNezjEsM 来干掉它。（在进行任何有关注册表的操作前，请手动备份注册表）
在进行后续对比之前，我们必须首先确保录音能够精确还原 Apple Music 输出的原始音频流。我们可以使用 foobar2000 的 Binary Comparator 组件（下称 bitcompare）来进行对比，你可以在 foobar2000 的组件库 中找到它并安装，请注意一下这个组件只有 32 位格式。 此处，我们手里有三份音源，一份是通过工具下载解密 DRM 获得的 ALAC（decrypted.m4a），一份是内录的 WAV（recorded.wav），另一份是通过 MORA 自购下载的无损 FLAC（mora.flac）。
首先将 decrypted.m4a 与 mora.flac 进行比较：
此处 bitcompare 没有找到差别，证明了下载解密工具本身没有问题，两个来源的音源是一致的。
接下来对比 mora.flac 与 recorded.wav：
注意到 bitcompare 的提示： Differences found in compared tracks; the tracks became identical after applying offset and truncating first/last samples. Extra leading/trailing sections contained only null samples.
我们显然不能在内录的时候做到和原曲完全同步，因此 bitcompare 通过对齐和裁剪的方式来忽略掉了前后多余的采样点（事实上全是空的），然后发现中间的部分是完全一致的。 通过如上的对比，我们可以得出结论：内录是没问题的，解密也是没问题的。因为可以和 MORA 自购下载的文件对齐每个采样点的数值，如果不是完美解密这根本不可能。
如果你正在使用社区里比较流行的下载实现，请务必把他们提供的完整性验证功能打开（原理实际上和本文是类似的）。在排除了网络、账户等个人因素后，若校验持续失败，则应判定 Apple Music 的官方音源本身已损坏。此时，请果断放弃该来源，以避免收藏或传播有问题的音频。
本文提供的方法与结论仅供参考。此方法可有效识别并排除部分存在问题的专辑，但无法保证通过验证的专辑绝对无误。若您获取了 Apple Music 的 ALAC 音频文件，最可靠的验证方式仍是与其他无损且已知无音频水印与后处理的音源（如通过对比未压缩音轨的 MD5 哈希值）进行交叉比对。在撰写本文时，我对一些文件进行了此类交叉验证，目前尚未发现响度匹配而 MD5 值不同的案例，欢迎评论区补充拍砖。
FOR /F "tokens=2 delims==" %%IIN ('wmic os get LocalDateTime /value') DOSET "dt=%%I" SET "CURRENT_DATE=%dt:~0,4%-%dt:~4,2%-%dt:~6,2%" SET "CURRENT_TIME=%dt:~8,2%-%dt:~10,2%-%dt:~12,2%"
SET "report_basename=ALAC_Scan_Report_%CURRENT_DATE%_%CURRENT_TIME%.txt" SET "report_file=%~dp0%report_basename%" SET "temp_log=%TEMP%\ffmpeg_scan_error.log"
SET /A problem_count=0 SET /A total_files_scanned=0
if$problem; then problem_count=$((problem_count + 1)) echo" [状态] 发现问题！" append_report "[状态] 发现问题！" append_report "[详情] FFmpeg 完整输出:" cat"$temp_log" >> "$report_file" else echo" [状态] 正常" append_report "[状态] 正常" if grep -F " Audio:""$temp_log" >/dev/null 2>&1; then while IFS= read -r line; do echo" [信息] $line" append_report "[信息] $line" done < <(grep -F " Audio:""$temp_log") fi fi }
scan_directory() { local target_dir="$1" echo"--- 正在递归扫描文件夹: \"$target_dir\" ---" while IFS= read -r -d '' f; do process_file "$f" done < <(find "$target_dir" -type f -iname '*.m4a' -print0) }
if [[ $# -eq 0 ]]; then echo"[模式] 未提供参数，将递归扫描当前目录。" echo scan_directory "." else echo"[模式] 检测到传入参数，将处理指定的文件或文件夹。" echo for path in"$@"; do if [[ -d "$path" ]]; then scan_directory "$path" elif [[ -f "$path" ]]; then ext="${path##*.}" ext="${ext,,}" if [[ "$ext" == "m4a" ]]; then process_file "$path" else echo"[跳过] \"$(basename "$path")\" 不是 M4A 文件。" fi else echo"[跳过] \"$path\" 无法访问。" fi done fi
if [[ $problem_count -gt 0 ]]; then ifcommand -v xdg-open >/dev/null 2>&1; then xdg-open "$report_file" >/dev/null 2>&1 & elifcommand -v open >/dev/null 2>&1; then open "$report_file" >/dev/null 2>&1 & fi fi
