Windows 本地音乐播放器简史

# 前言

近几年，随着 Vibe coding 的兴起，桌面软件又出现了一轮“重新造轮子”的潮流。如果你还不了解 Vibe  coding，它通常指开发者用自然语言描述需求，由 AI Agent 快速搭建应用的一种开发方式。它降低了写代码的门槛，也让许多个人开发者和小团队更容易做出可运行的软件原型。比如，我在  B 站上就经常能刷到很多音乐播放器，框架不是 Electron 就是 Flutter，估计 Tauri  也快了。这让我意识到，很多原本功能并不复杂的工具，也开始用 Electron 或类似的跨平台框架来开发了。

然而，所谓  Electron，说白了就是把 Chromium 浏览器内核和 Node.js 运行环境打包进去，好处是前端开发者可以配合 AI  用网页技术写桌面程序，但问题也正出在这里，将浏览器内核打包进去，安装包就注定越来越大，也会带来启动越来越慢，内存占用越来越高的性能问题。对于本地音频播放器这类软件，我个人认为，播放一首本地  MP3 或 FLAC，也许并不需要塞进一个庞大的浏览器运行时。

回顾那些仍然有爱好者使用的老牌 Windows 本地播放器，它们追求的是小体积、低占用、插件强大、可换肤、音频输出可控，同时也重视本地文件管理。很多播放器外观极具个性，性能也十分能打。这种反差让我不禁开始思考，本地音频播放器到底是如何一步步演变的。

本文就按照时间顺序，聊聊 Windows 本地音频播放器的发展历史。当然，本人的时间、阅历和知识量有限，所以编写的这一文章所涉及的只是蜻蜓点水。如有缺漏，还请海涵。

---

# 一、从这一刻起，历史发生了巨变

## 1.1 是你逼我的

本地音频播放器的历史，首先是一段和硬件相较劲的历史。今天的电脑，无论是低端还是高端，播放 MP3、FLAC、WAV 都估计没有什么压力。但在 1990 年代末，连实时解码 MP3 这么简单的任务，对普通家用电脑来说也是一项前所未有的挑战。

当时常见的 CPU 是 Intel Pentium，也就是奔腾处理器，还有早期 Pentium II。内存容量也很有限，许多家庭电脑只有几十 MB。用户一边播放音乐，一边打开网页、复制文件或者运行其他程序，很容易遇到声音卡顿、爆音，甚至系统还会钟离假死给你看。

![维基百科上的初代 Pentium MMX](http://cdn.07212121.xyz/2026/05/38d201be39d9e82fd1b833e287aad040.Pentium-mmx1.webp)

那时 Windows 的音频架构也不成熟。Windows 95/98/NT 4.0 虽然已经支持多媒体，但音频 API、系统混音器、声卡驱动都远没有后来稳定。音频 API 可以理解为应用程序调用系统声音功能的一套接口。播放器开发者经常需要认真调整缓冲区、输出线程优先级，甚至使用汇编代码优化解码流程。汇编语言比 C、C++ 更接近机器指令，写起来更容易掉头发，但在早期硬件性能紧张的年代，可以带来更直接的性能优化。

## 1.2 WHY MP3?

MP3 之所以重要，是因为它解决了当时最现实的问题，也就是音频文件体积过大的问题。

标准 CD 音频规格是 44.1 kHz、16 bit、双声道，码率大约 1411 kbps。44.1 kHz 表示每秒采样 44100 次，16 bit 表示每个采样点用 16 位数据记录声音强弱，双声道则对应左右两个声道。这么一算，一首几分钟的 WAV 文件可能就有几十 MB 甚至上百 MB。在拨号上网和小容量硬盘的年代，这种体积想要传播和保存难如登天。

MP3 通过有损压缩，把一首歌压缩到原来的十分之一左右，非常简单粗暴，也非常有效。有损压缩，顾名思义，压缩之后就无法完全还原原始数据了。像图片里的 JPEG、视频里的 H.264、音频里的 MP3 都属于常见的有损压缩。它们共同的思路是尽量丢掉人不太容易察觉的信息，用更小的体积换取尽可能可接受的感知质量。

MP3 的核心思路是心理声学模型。所谓心理声学，研究的是人耳和大脑如何感知声音。编码器根据人耳听觉特点，舍弃一部分不容易被察觉的声音信息。比如，一个很响的声音会掩盖附近频率里较弱的声音。某些瞬间出现的强音，也会让前后很短时间内的细节不容易被察觉。编码器正是利用这些规律，把有限码率集中分配给更容易被听见的部分。这样一来，128 kbps 的 MP3 通常只有几 MB，普通用户完全可以接受。

MP3 并非是 MPEG 音频标准里的唯一格式，它的诞生还源自一场智斗巅峰。1987 年开始，在欧盟 EUREKA 计划推动的数字音频广播项目中，逐渐形成了两条主要技术路线。一边是 Philips、CCETT 等主导的 MUSICAM 方案，主打低复杂度的时域子带编码，硬件友好、延迟低，约 30ms，适合广播传输。另一边是德国 Fraunhofer IIS 牵头的 ASPEC 方案。ASPEC 的灵魂人物 Karlheinz Brandenburg 后来被称为 MP3 之父，他采用了更激进的 MDCT 变换和复杂心理声学模型，频率分辨率更高、压缩效率更好，但计算负荷也大得多。

![这位英俊的老男人就是 Karlheinz Brandenburg](http://cdn.07212121.xyz/2026/05/b34cf1342566ab32864cfadd1fdd39e7.Karlheinz-Brandenburg.webp)

MPEG 是 Moving Picture Experts Group 的缩写，中文通常称为动态图像专家组。虽然名字里有图像，但 MPEG 标准同时涵盖视频和音频压缩。EUREKA 计划则是欧洲推动高科技产业合作的一个大型科研项目框架，数字音频广播只是计划的一部分。

1991 年瑞典斯德哥尔摩的 ISO-MPEG 听证会上，两大方案几乎打成平手。那怎么办呢？最终委员会就达成了一个方案，将 MPEG-1 音频拆分为了三个层：

Layer I 最简单，接近数字卡带所用的 PASC 格式。Layer II，也就是 MP2，保留了 MUSICAM 的广播优势，后来在数字广播领域，以及影音光碟领域占据主导。Layer III，也就是 MP3，则是 ASPEC 的演进，面向高压缩率场景。当时人们没有想到，兼顾文件体积和听觉质量的 MP3 让它在互联网传播中意外胜出，成为了主流音频格式。

MP3 所依赖的 MDCT 是什么呢？它全称 Modified Discrete Cosine Transform，中文可译为修正离散余弦变换。本质上，它是一种把声音从时间上的波形变化拆解成不同频率成分的数学方法。这么说是不是听起来有点头疼？简单来说，人听到的是连续变化的声音波形，MDCT 把他们拆解成更容易让压缩算法进行分析的频率空间。这样压缩算法就可以判断哪些部分重要，哪些部分不重要，方便编码器进行资源分配，缩减体积。

具体到编码流程，MP3 首先会将音频切成 1152 个样本为一帧的数据块。编码器先用多相滤波器组分成 32 个子带，再通过 MDCT 在每个子带内做进一步频域细分，共产生 576 条频线。同时，系统并行运行 FFT 快速傅里叶分析，模拟人耳的掩蔽效应。FFT 是 Fast Fourier Transform 的缩写，意思是快速傅里叶变换，它可以高效分析一段信号里包含哪些频率成分，这在前面也提到了。一个响的声音会盖住附近弱的声音，巨响前后紧邻的细节也很难被察觉。任何低于掩蔽阈值的频率成分，编码器都会认为感知意义很低，可以大胆丢弃。最后，量化后的数据在有限码率预算内反复迭代分配比特，再用霍夫曼编码压缩成标准 MPEG 帧。霍夫曼编码是一种常见的无损压缩方法，基本思路是让出现频率高的数据使用较短编码，让出现频率低的数据使用较长编码。整个过程在 1990 年代的个人电脑上还显得非常吃力，这也是早期播放器必须死磕性能的直接原因。

正因为编码器中留下了大量可调空间，不同 MP3 编码器的音质才会有明显差异。MP3 标准规定了最终比特流应该怎么被解码，但如何从原始 PCM 音频生成一个更好听的 MP3，则留给了编码器开发者大量的发挥空间。心理声学模型、比特分配、量化策略和瞬态处理，都会影响最终效果。

噢我的上帝啊，PCM 又是什么东西？它是 Pulse Code Modulation 的缩写，中文叫脉冲编码调制。它可以理解成未经压缩的原始数字音频文件，WAV 文件里常见的未压缩音频通常就是 PCM。不过可别误会咯，PCM 本身不能直接播放。MP3、FLAC 等格式在播放时，最终都需要被解码成 PCM，再交给系统或声卡输出。

### 早期音频格式一览

| 格式                   | 主要开发者 / 组织                         | 核心编码方式                       | 主要历史用途                    | 主要限制                          |
| ---------------------- | ----------------------------------------- | ---------------------------------- | ------------------------------- | --------------------------------- |
| MPEG-1 Layer I / MP1   | ISO / IEC MPEG                            | 基础子带编码，配合简单心理声学模型 | 早期低功耗硬件、实验性设备      | 压缩效率较低，占用带宽较高        |
| MPEG-1 Layer II / MP2  | MUSICAM 阵营，包括 Philips、CCETT、IRT 等 | 32 个子带的时域编码                | 数字广播 DAB、VCD、早期数字电视 | 在低码率网络传播中不如 MP3 有优势 |
| MPEG-1 Layer III / MP3 | Fraunhofer 等                             | 子带滤波加 MDCT 变换编码           | 个人电脑、P2P 网络、便携播放器  | 早期硬件解码压力较大              |
| ATRAC                  | Sony                                      | 子带变换编码，动态块长             | MiniDisc、Sony 早期随身听       | 索批的闭源垃圾玩意儿，给云长送去  |
| VQF / TwinVQ           | NTT / Yamaha                              | 向量量化和变换编码                 | 早期互联网高压缩音频            | 编码延迟高，解码计算量也较大      |

ATRAC 是 Sony 为 MiniDisc 等设备开发的音频压缩技术。MiniDisc 曾经是一种很有代表性的便携数字音乐介质，外观看起来像小型光盘装在保护壳里。不过这和索尼自己的便携游戏机 PSP 使用的 UMD 光盘也有区别，不要混淆。VQF 或 TwinVQ 则是另一种早期高压缩音频方案，曾经短暂吸引过一些互联网用户，但由于生态、性能和工具链等原因，最终没有成为主流。

1993 年，刚才提到的 Fraunhofer 注册了 MP3 编码和解码的核心专利，随后与 Thomson 等公司组成专利池。专利池可以理解为多个专利持有人把相关专利集中打包授权。对于厂商来说，专利池有时可以减少逐一谈判的麻烦，但也意味着使用某项技术需要持续支付授权费用。从 1998 年开始，商业编解码器必须缴费，这就造成了一个假象，很多人以为 MP3 是免费的，实际上每卖出一份编码器，厂商都要向 Fraunhofer 付费。这个免费听、收费编的模式，后来直接刺激了 LAME 等开源编码器的诞生，也促使 AAC 等新格式在推广时更重视授权策略。直到 2017 年 MP3 专利在美国全部到期，Fraunhofer 官方才正式宣布终结授权计划，得以翻篇。

1990 年代中后期，大量家庭用户还在使用 28.8 kbps 或 56 kbps 拨号网络。拨号上网需要通过电话线连接互联网，速度慢，连接时还会占用电话线路。正好，MP3 可以把一首 CD 音轨从几十 MB 压到几 MB，方便音乐文件通过网络传播。Napster、KaZaA、电驴等 P2P 网络因此兴起，电脑开始成为很多人收集、整理、播放音乐的中心。

P2P 是 Peer to Peer 的缩写，中文常译为点对点网络。传统下载通常是用户从服务器下载文件，P2P 则让用户之间互相传输数据。每个下载者也可能同时成为上传者，这让热门文件可以快速传播。数字音乐在互联网上的爆发，与 P2P 网络关系极深，当然了，P2P 网络不光传播音乐，这就是另一段历史了。

MP3 的流行也带动了便携硬件的发展。后来使用硬盘存储的 iPod，也建立在数字音乐文件已经普及的基础上。没有大量已经被用户接受的数字音乐文件，便携播放器就很难形成后来的市场规模。

从这一刻起，历史发生了巨变。

## 1.3 曲线救国

如果说播放器负责听，编码器就负责做出 MP3 文件。早期比较重要的 MP3 编码工具之一是 Fraunhofer 的 L3enc。它是命令行程序（没有图形界面需要你敲命令来运行的程序，现在可以缩写成 CLI），可以把音频编码成 MP3，但速度慢，不仅授权不自由，刚才也提到，它还 TMD 要钱。对于正在兴起的免费软件和开源社区来说，严格约束让人非常难受。我最讨厌的就是严格约束！（锤）

1998 年，程序员 Mike Cheng 发起了 LAME 项目。LAME 的全称是 LAME Ain't an MP3 Encoder，意思就是“LAME 不是一个 MP3 编码器”，这个名字带有递归缩写和规避法律的意思。递归缩写是黑客文化里常见的一种命名方式，缩写本身又包含缩写本体，比如 GNU 的全称 GNU's Not Unix（感觉非常适合老资历用来扯淡）。

![LAME 的 LOGO](http://cdn.07212121.xyz/2026/05/f31c99482afbe12ffe621be395901b85.Lamelogo.webp)

LAME 在起步阶段故意强调自己只是研究性质的源码项目，并不直接提供官方可执行编码器。这是一种刻意的法律规避策略。后来许多中国开发者都学到了这一策略，在 GitHub 上的很多项目 README 里灵活运用（虽然有些项目还是没有逃过制裁）。

Mike Cheng 在起步阶段修改了 ISO 参考编码器的 dist10 分支源码，那部分代码当时被认为是专利风险最低的公共代码，然后仅以教育和研究为目的发布源代码，不提供编译好的可执行文件。这么一来，LAME 就站在了言论和学习材料的位置上。第三方要编译和使用，法律风险由他们自己承担。Mike Cheng 本人后来公开说过：“如果 Fraunhofer 一开始就允许免费使用，谁还会写 LAME？”

ISO 参考编码器可以理解为标准制定过程中提供的示例实现。它的目的主要是说明标准该如何被实现，代码质量和编码效果通常并不一定适合普通用户长期使用。dist10 则是当时 MPEG 音频参考代码中的一个版本分支。很多早期开源音频项目，都在参考实现、专利边界和实际可用性之间艰难试探。

后来 Mark Taylor 接手开发，为 LAME 添加了 GPSYCHO 心理声学模型。这是 LAME 质量飞跃的关键。GPSYCHO 是一个完全重新实现的模型，在噪声分配、联合立体声，也就是 M/S 编码决策，以及瞬态处理上都比原始的 ISO 模型出色很多。联合立体声并不等于把立体声简单变成单声道，它通常会利用左右声道之间的相似性，用更高效的方式记录声场信息，从而把节省下来的码率分配给更关键的声音细节。瞬态处理则关系到鼓点、拍手、爆破音等短时间强烈声音的编码质量，处理不好就容易出现毛刺感。

Takehiro Tominaga、Naoki Shibata、Gabriel Bouvigne、Robert Hegemann 等虽然我不认识但是肯定很 NB 的大佬，也对项目做出重要贡献。到 LAME 3.81 左右，项目已经基本替换掉旧的参考代码，成为一个相对独立的 LGPL 授权 MP3 编码器。

LGPL 是 Lesser General Public License 的缩写，中文常译为较宽松通用公共许可证，简单来说就是一种开源协议。它允许软件库被更广泛地链接和使用，同时仍然要求对库本身的修改保持开放。

LAME 的 VBR 模式尤其受欢迎。VBR 是 Variable Bitrate 的缩写，中文叫可变码率。它会根据音乐内容的复杂程度动态分配码率。安静片段可以大幅降低流量，而复杂高潮部分自动拉高。这样既能控制文件体积，又能把码率花在真正需要的地方。很多人熟悉的 `-V 0`、`-V 2` 这类参数，就是 LAME VBR 时代留下的经典选择。在 128 到 192 kbps 的中高码率段，LAME 被公认为音质最优的 MP3 编码器之一。

这里也可以顺带解释一下 CBR 和 ABR。CBR 是 Constant Bitrate，也就是恒定码率，整首歌一直保持相同码率。它简单、兼容性好，但复杂片段可能不够用，简单片段又会浪费。ABR 是 Average Bitrate，也就是平均码率，目标是让整首歌的平均码率接近用户设定值。所以权衡之下，VBR 更强调感知质量，按照内容复杂度分配码率，因此在同等体积下经常更划算。 VBR、CBR、ABR 也用在了视频解码上面。

LAME 官方在整个专利有效期内，也就是 1999 到 2017 年，从未发布过官方编译的可执行文件，仅以源码形式存在。这种策略让它一直在合法边缘活跃了将近二十年，成为开源社区对抗商业专利的经典案例。直到 2017 年前后，MP3 相关核心专利陆续到期，Audacity、FFmpeg 等工具才可以直接附带 LAME，让用户一键转换 MP3。

播放器端也有类似的法律问题。Winamp 早期解码链条经历过 AMP、Nitrane、Fraunhofer 授权解码器等阶段。AMP 引擎最初由 Tomislav Uzelac 开发，他是最早的 PC 端 MP3 解码器实现者之一。后来 PlayMedia 指控 Nullsoft / AOL 使用的 Nitrane 解码器侵犯其 AMP 播放引擎相关权益，这起纠纷最终以 AOL 向 PlayMedia 支付 750 万美元和解而告终，也成为当年软件专利纠纷的一个典型案例。

Nullsoft 是 Winamp 背后的公司，后来被 AOL 收购。AOL 是 America Online 的缩写，曾经是美国互联网服务巨头。早期数字音乐软件的开发者既要解决性能问题，也要面对专利授权、代码来源和商业并购带来的复杂压力。一个看似简单的播放按钮背后，没想到还要牵涉到算法、标准、专利、商业授权、开源社区和用户需求等多重因素。正因为这些力量长期碰撞，后来 Windows 本地播放器才会发展出如此丰富又分化明显的技术路线。

后来，LAME 编码器也被一些开源软件使用。

---

# 二、音乐播放器的百家争鸣

## 2.1 老霸道了 —— Winamp

1997 年 4 月 21 日，Justin Frankel 和 Dmitry Boldyrev 发布了 Winamp 的早期版本。Justin Frankel 当时才 19 岁，已经从犹他大学退学，用 C++ 编写出了最初的 WinAMP。WinAMP 这个名字来自 Windows Audio MPEG Player，可以理解为 Windows 上的 MPEG 音频播放器。它的核心解码部分基于 Tomislav Uzelac 的 AMP 引擎。AMP 是较早在 PC 上实现 MP3 实时解码的软件引擎之一，在那个 CPU 资源很紧张的年代，它的重要性非常高。最初的 Winamp 非常简陋，本质上只是一个能播放 MP3 的小工具。但在当时，它已经足够重要。它能在普通家用电脑上相对稳定地实时播放 MP3，而且资源占用很低。

[album type="photos"]
![维基百科上的 Justin Frankel 图片](http://cdn.07212121.xyz/2026/05/905a0c0b24086ad7be8708bd06357598.Justin_Frankel.webp)

![你现在还可以在 https://www.askjf.com 询问这位大佬问题](http://cdn.07212121.xyz/2026/05/bf87668682181f061aff50ba32e38466.AskFrankel.webp)
[/album]

很快，Winamp 0.92 引入了后来非常经典的界面。深灰色小窗口、银色按钮、绿色 LED 风格文字。这种看起来像实体音响面板的设计，是当时桌面软件常见的拟物化风格。所谓拟物化，就是让软件界面模仿现实世界里的物品，例如旋钮、按钮、仪表盘、金属面板和液晶显示屏，就比如说早期的 IOS 系统界面。它不像今天许多播放器那样大面积留白，更像一个小型音响设备挂在桌面上。对于 1990 年代末的用户来说，这种界面非常直观，也很有科技感。

[album type="photos"]
![Winamp 0.2a](http://cdn.07212121.xyz/2026/05/451ce9265947ffbcdae3d4c0ef921f5c.Winamp_0.2a.webp)

![Winamp 0.92](http://cdn.07212121.xyz/2026/05/7cd09aac46fbdbae7cbb8d96df9ddf28.WinAMP_0.92.webp)

![Winamp 1.006](http://cdn.07212121.xyz/2026/05/c4ec4fe4d6611211c6eb07239bb8660c.Winamp1.006.webp)
[/album]

[album type="photos"]
![Winamp 2.0](http://cdn.07212121.xyz/2026/05/33f33638428bd7591591f2f78338b1dc.Winamp2.webp)

![Winamp 3.0](http://cdn.07212121.xyz/2026/05/4d780b81a7ee9c7c99f65b188ca57125.Winamp3.webp)

![Winamp 5.0](http://cdn.07212121.xyz/2026/05/04cb97574412f3ccbc62283186c8fe0d.Winamp5.webp)
[/album]

[album type="photos"]
![Winamp 5.5 现代皮肤](http://cdn.07212121.xyz/2026/05/ba4379a780c11e7da2bb2c6420a97f09.Winamp_5.5.webp)

![Winamp 5.666](http://cdn.07212121.xyz/2026/05/d812a45d0db975ab0702e1b58a8830e7.Winamp_5.666_media_player.webp)

![Winamp 5.9.2](http://cdn.07212121.xyz/2026/05/2ec51e8b98fe37e8da34eeae70cd2008.WinAmp_5.9.2,_Windows_10.webp)
[/album]

1998 年，Justin Frankel 正式成立了 Nullsoft 公司。Winamp 2.0 在同年 9 月发布，并确立了它最重要的架构，也就是插件系统。Winamp 的意义由此超出了播放器本身，开始具备平台属性。这里的平台属性可以理解为，软件本体提供基础能力，更多功能可以由第三方插件不断扩展。这样的模式让 Winamp 不再只是一个固定功能的小播放器，而像一个可以不断生长的音频工具环境。

输入插件负责解码 MP3、WAV、OGG、FLAC 等格式。输出插件负责把 PCM 音频流送到 WaveOut、DirectSound 等系统音频接口。DSP 插件可以做均衡器、混响、音效处理。可视化插件则可以根据音乐实时生成图像。DSP 是 Digital Signal Processing 的缩写，中文叫数字信号处理。播放器里的均衡器、音量归一化、低音增强、混响、环绕效果等，都属于常见 DSP 处理。WaveOut 和 DirectSound 则是 Windows 上曾经广泛使用的音频输出接口，后面会有所提到。

Winamp 的插件结构可以概括为

```mermaid
graph TD
    A["音频文件<br/>MP3 / OGG / FLAC / WAV"] --> B["输入插件<br/>负责读取与解码"]
    B --> C["核心播放引擎<br/>管理播放状态与音频流"]
    C --> D["DSP 插件<br/>均衡器 / 混响 / 音效处理"]
    D --> E["输出插件<br/>WaveOut / DirectSound 等"]
    E --> F["声卡 / DAC / 系统音频设备"]

C --> G["可视化插件<br/>AVS / MilkDrop"]
    C --> H["皮肤系统<br/>.wsz 经典皮肤"]
```

Winamp 的插件系统有两个意义。第一，它让播放器可以快速支持新格式，不必每次都重写核心程序。第二，它形成了一个庞大的用户社区。很多用户并不写代码，但会下载皮肤、可视化效果、歌词插件、音效插件，把 Winamp 改造成自己喜欢的样子。对于当时的桌面软件文化来说，这种可改造性非常重要。用户并非只能被动接受软件作者给出的固定界面和固定功能，相反，他们可以发挥自己的才能，通过社区作品参与到软件体验的塑造中。

Winamp 的皮肤格式 `.wsz` 本质上就是一个改名后的压缩包，里面包含位图资源和配置文件。位图资源可以理解为界面上每一个按钮、背景、滑块、数字显示区域对应的图片素材。配置文件则告诉播放器这些素材应该放在哪里、怎样响应鼠标操作。这种设计大大降低了用户参与门槛。会画图的人可以做皮肤，会写代码的人可以做插件，会折腾的人可以把播放器改得面目全非。那个年代的桌面软件，真的很有自己动手的气质。

![Winamp 皮肤之多以至于让我们可以进行长时间的探索...](http://cdn.07212121.xyz/2026/05/92bede3e9809ce3658d6d2913e333d6f.Winamp_Skin.webp)

Winamp 的可视化插件尤其有代表性。AVS 允许用户用数学公式生成随音乐变化的图形。AVS 是 Advanced Visualization Studio 的缩写，它让普通用户也可以通过预设和公式制作动态图形。后来 Ryan Geiss 开发的 MilkDrop（国内有人称之为奶滴）使用 DirectX 和显卡加速，可以实时生成流体、分形、旋转、变形等复杂视觉效果。对很多人来说，Winamp 同时承担了播放工具和桌面视觉组件的角色。音乐播放不再只是声音从音箱里出来，屏幕上也会出现随着节奏变化的动态画面。

![Milkdrop 示意图](http://cdn.07212121.xyz/2026/05/046184e7f3c70884f06e6d157cd816b6.Milkdrop_Spikeball.webp)

1999 年，AOL 以约 8000 万美元收购 Nullsoft，当时整个团队不过寥寥几人。收购之后，Frankel 很快对 AOL 的官僚化不满。2000 年他甚至在 AOL 内部偷偷创办了名叫 Gnutella 的 P2P 网络，用户之间可以直接互相搜索和传输文件。这件事直接与公司战略相悖，引起轩然大波。与此同时，AOL 还试图在 Winamp 中集成一个叫 Mjuice 的加密 DRM 付费下载服务，结果因为互操作性差、用户反感而迅速失败。DRM 是 Digital Rights Management 的缩写，中文通常叫数字版权管理。它会通过加密、账号授权、设备绑定等方式限制文件复制和播放。这些事件都说明，大公司平台逻辑和轻量工具逻辑之间的冲突，是不可调和的。

2002 年发布的 Winamp3 是这种冲突的集中爆发。Winamp3 基于 Wasabi 框架重写，Wasabi 可以理解为 Nullsoft 试图打造的一套通用媒体应用框架（意思绝对不是我 SB 哈）。目标是跨平台、支持更高级的皮肤和界面能力，想把播放器做成一个像浏览器那样的大平台，所有功能都组件化。不过俗话说的好，想法很宏大，落地很痛苦。插件质量参差不齐，崩溃频繁。老版 2.x 皮肤完全不兼容，社区分化严重。框架本身臃肿，启动速度远逊 2.x。Frankel 后来在论坛里公开承认，试图把播放器做成平台是一个错误。

Winamp3 的失败直接导致了用户的分裂。很多人宁愿停留在 Winamp 2 也不愿升级。后来 Winamp 5 试图把 Winamp 2 的稳定性和 Winamp3 的部分新功能结合起来。它的确挽回了一部分用户，但原始团队已经逐渐离开。Frankel 在 2003 年前后基本淡出 Winamp 开发，后来创办了 Cockos，开发出专业级数字音频工作站 REAPER，至今在音频工程圈有极高口碑。REAPER 的路线依然是低价、高效、完全用户自主，这一点和 Frankel 早年的工具观念很一致。

一个原本以轻量、高效、可扩展著称的软件，就这样在商业化和平台化压力下逐渐变重。

不过后来，Winamp 分出来了一个社区分支，改名为了 WACUP。Winamp 本身也因为开源事件被炎上了一段时间。关于现在还在持续维护中的 WACUP，我会在 Winamp 的推荐文章中详细阐明其历史。

Winamp 留下的影响远远超过播放器本身。插件系统、皮肤文化、可视化社区、轻量桌面工具的审美，都成为后来许多音频软件绕不开的参照。

---

## 2.2 反对花哨 —— Foobar2000

Winamp3 的失败，给另一类播放器留下了空间。

很多高级用户并不需要花哨界面，他们更在意播放是否准确、资源占用是否低、格式支持是否干净、音频输出路径是否可控。Foobar2000 就是在这样的背景下出现的。

Foobar2000 的作者 Peter Pawlowski 早在 Winamp 时代就作为 Nullsoft 的签约外包开发者，长期负责输出插件的维护和声卡驱动兼容性问题。Winamp3 开发期间，他多次尝试说服团队采用更稳定的架构路径，但管理层执意推进 Wasabi 框架。2002 年底，Pawlowski 心灰意冷地离开，个人网站上只留下一句神秘信息：“THIS PAGE 1ST DEATH :[”，社区一度为他维护的那些关键插件源码去向感到恐慌。

很快，Pawlowski 开始从头构建自己的播放器。2002 年 12 月，他发布了 foobar2000。这个软件从一开始就和 Winamp 走了完全相反的路线。界面朴素到几乎没有装饰，文本为主，默认外观看起来像一个高级的设置对话框，而不像一个娱乐工具。

[album type="photos"]
![一位国外用户的早期 Foobar2000 0.95 界面](http://cdn.07212121.xyz/2026/05/3382c44b877cc89d81535109d37f904f.fb2k_095b1.webp)

![我自用的加了插件的 Foobar2000 2.25.8 界面](http://cdn.07212121.xyz/2026/05/f9bd13b7778e23eb8469fa3c6164fbb2.Foobar2000_myself.webp)
[/album]

那么 Foobar2000 中的 Foobar 是什么意思呢？估计也就程序员才能知道 Foobar 是什么。简单来说，Foobar 就是一个占位符，本质上和数学里面的 abc、xyz 没什么差别，本身相对于使用的场景来说也没有任何意义。大概就相当于 Hello world 之类的。有关 Foobar 的来源是什么，为什么会选它作为占位符，众说纷纭，这是题外话了。

Foobar2000 的核心理念非常明确。本地文件优先，模块化扩展，低延迟，高精度，避免无意义的界面负担。为了避免重蹈 Winamp3 插件混乱的覆辙，他选择将核心闭源，开放组件 SDK。核心程序只包含基础播放框架、解码调度、播放队列管理和 DSP 链调度，保持统一和稳定。第三方开发者则可以通过开放 SDK 编写解码器、界面组件、标签工具和输出插件。SDK 是 Software Development Kit 的缩写，也就是软件开发工具包。它提供接口文档、头文件、示例代码等，让第三方开发者可以按照统一规则为软件扩展功能。这种微核心设计，让内核本身极少崩溃，扩展能力又可以非常强。

Foobar2000 的架构可以这样理解

```mermaid
graph TD
    A["本地音频文件<br/>MP3 / FLAC / APE / AAC / Opus 等"] --> B["格式解码组件"]
    B --> C["Foobar2000 核心引擎<br/>播放列表 / 队列 / 音频处理"]
    C --> D["高精度音频处理管线<br/>32-bit 浮点 / ReplayGain / DSP"]
    D --> E{"输出方式"}

E --> F["DirectSound / WASAPI 共享"]
    E --> G["ASIO"]
    E --> H["Kernel Streaming"]
    E --> I["WASAPI Exclusive"]

C --> J["第三方组件 SDK<br/>界面 / 标签 / 转换 / 工具扩展"]
    C --> K["极简界面与自定义布局"]
```

Foobar2000 在发烧友圈子里流行，和它对音频输出链路的重视有直接关系。Pawlowski 对 Windows 的 KMixer 内核混音器造成的音质损失了然于心，因此 Foobar2000 从一开始就积极支持 Kernel Streaming，当时几乎没有播放器这样做。后来它又迅速跟进 WASAPI 独占模式，满足了用户对 bit-perfect 输出、外置 DAC 和低干扰播放路径的需求。

KMixer 是 Windows 2000 和 Windows XP 时代的重要音频组件，它负责把多个程序的声音混合在一起，再统一交给声卡输出。问题在于，KMixer 可能会对音频进行重采样和位深转换。例如一首 44.1 kHz 的 CD 音频，可能被系统转换成 48 kHz 再输出。对普通用户来说，这通常不一定能明显听出差别，但对希望保持原始音频数据的用户来说，这种处理会破坏所谓的 bit-perfect。

Bit-perfect 又是个什么玩意儿呢？TMD 包子你这个 SB 能不能别放洋屁了？没办法，这群老外就喜欢造这些词。那么简单来说，所谓的 bit-perfect ，意思是音频数据从文件解码到 DAC 输出之前，尽量不被系统混音、重采样、音效处理或音量归一化修改。就是想喝不受污染的娃哈哈纯净水。Kernel Streaming 则是一种更底层的音频输出方式，可以绕过一部分系统混音环节，但兼容性和稳定性很依赖驱动。

Foobar2000 的转换器框架也很强，可以调用外部命令行编码器，如前面提到的 LAME，和 FLAC，Opus。它也具备了播放器和本地音乐库处理工具的能力。Opus 是一种较新的开放音频编码格式，适合语音、音乐、低延迟网络传输等多种场景，在中低码率下表现很好，像 TeamSpeak 这种语音交流软件，就使用这种格式。这样下来，Foobar2000 可以把本地音频批量转换成不同格式，也可以在转换过程中保留标签、封面和目录结构。对收藏很多音乐的人来说，这类功能非常实用。用户可以把 FLAC 收藏保存在硬盘里，再批量转成较小体积的 MP3 放到手机中。

Foobar2000 还很早就完整实现了 ReplayGain 标准，专门解决切歌时声音忽大忽小、总得手动调音量的问题。这背后的原因是持续几十年的响度战争。早期唱片公司为了让自家 CD 在唱片店里听起来比别家更响，制作时会把声音压得很平，动态范围变得很小。这样声音确实更大了，但设备好的人一听就能发现，音乐缺少起伏，听久了容易疲劳，不够爽。这种做法后来蔓延到电台和流媒体，成了行业里的普遍习惯。

我们平时说的音量其实包含两个概念。一个是音箱旋钮控制的输出电平，另一个是人耳感受到的响度。一首动态被压缩的歌，即使音量开得很低，听起来也可能比动态丰富的歌更响。ReplayGain 要做的就是对齐这些歌的感知响度。它会扫描音频文件，依据 ITU-R BS.1770 算法算出每首歌听起来有多响，然后把增益值写入标签，播放时自动调整，让过响的歌变轻，过轻的歌变响。这样无论怎么播放，都不用再手动调音量了，永远保持在一个让人耳舒服的状态。

扫描时会生成两种增益值。Track Gain 是单曲增益，适合随机播放时让每首歌音量接近。Album Gain 是专辑增益，会保留专辑内曲目之间原本的相对音量关系，适合完整听专辑。还可以开启防削波功能（True Peak 检测），避免因为增益过大导致数字削波。数字削波指音频信号超过数字系统能表示的最大范围，波形顶部被硬生生切平，听起来可能会出现刺耳失真。对于拥有大量跨年代、跨版本收藏的用户来说，这个功能几乎是必需品。

2023 年，Foobar2000 2.0 发布，加入了原生 64 位、深色模式、ARM 架构支持等现代化改进。64 位程序可以更好地利用现代系统资源，ARM 架构支持则对应越来越多使用 ARM 处理器的 Windows 设备。社区里流传着一个评价，Foobar2000 是一款 20 年 UI 几乎不变、却不显得过时的软件。Pawlowski 自己在论坛里反复强调的一句话也说明了根本态度，Bit-perfect 是工具，而不是什么信仰。

这不禁让我想起了中文互联网上的视玄学为信仰的某些老烧，他们认为 Foobar2000 不同版本之间的音质会各不相同。光是这样也就罢了。没想到有人还认为官方英文版与民间汉化版之间的音质也有差别，这就离谱了。如此暴论实在让我哭笑不得。甚至有些人还批评 Foobar2000 作者这位参与过 Winamp 工作的经验丰富的程序员不懂所谓的音质，他们这样自视清高，自以为是，殊不知这样的态度是为人所不齿的。

![什么时候高音甜 中音准 低音劲？](http://cdn.07212121.xyz/2026/05/573b59b8568bc74a45224aebfedf5dcc.laoshao.webp)

Foobar2000 的特别之处，就在于它非常尊重使用者的判断。你可以把它用成一个极简播放器，只保留播放列表和基础按钮。你也可以安装大量组件，把它改造成资料库、标签编辑器、转码工具、输出控制中心和复杂界面系统。它的学习门槛确实比一般播放器高，但一旦配置完成，就会成为非常稳定、非常耐用的本地音乐工作台。

---

## 2.3 中国人民更爱用 —— 千千静听

2000 年代初，中国桌面软件市场快速发展。宽带开始普及，本地 MP3 收藏越来越常见。但国外播放器对中文用户并不友好。

Winamp、Foobar2000 虽然强大，却经常遇到几个问题。中文标签乱码、歌词显示麻烦、插件配置复杂、界面本地化不完整。这些问题对熟悉电脑和英文软件的用户来说也许还能解决，但对更广泛的普通用户来说，这明显影响了使用体验。

乱码问题尤其普遍。用户打开一首歌，歌名、歌手、专辑名可能直接变成一堆看不懂的字符。普通用户并不想研究 ID3、Unicode、代码页这些技术细节，他们只希望打开软件后能正常看到中文。关于乱码的技术背景，后文会在收藏管理一节详细说明。

千千静听就是在这种需求下流行起来的。它最早由郑南岭开发。郑南岭毕业于同济大学，童年家境贫寒，他后来开发软件时所坚持的那种纯净、不打扰用户的气质，多少也与这段经历有关。千千静听早期曾叫 MP3 随身听，后来为了避免重名，改名为千千静听。名字直接取自陈慧娴的经典歌曲《千千阙歌》，既有时代情怀，又是一个极好的中文命名。这个名字温柔、顺口、容易记住，也天然适合一款面向中文用户的听歌软件。

郑南岭本人曾是 Winamp 的早期用户，对 Winamp 那种主面板、均衡器、播放列表可以自由拖开、组合的模块化设计非常熟悉。千千静听的界面几乎完全继承了这套逻辑：各个面板都能独立拖动、吸附或拆开，用户可以根据自己的习惯在桌面上灵活布置。这种自由度在当时的中文软件里很难见到，也让千千静听一上手就有一种亲切感。

[album type="photos"]
![千千静听其中一个版本的默认皮肤](http://cdn.07212121.xyz/2026/05/0c7b1a1309b5845d152bf9623b505de9.TTplayer_myself.webp)
![向前辈 Winamp 致敬！](http://cdn.07212121.xyz/2026/05/a6c1ad55037127e6f86e66bfb7e0f4ec.ttplayer_winamp.webp)

![果宝机甲 解体！](http://cdn.07212121.xyz/2026/05/da111292e7e8df935067a3dd3bb4f30a.TTplayer_vs_Winamp.webp)
[/album]

千千静听的技术路线主打中文用户体验。它抓住了中文标签、歌词显示、简繁转换、热键控制和轻量界面这些高频需求。它体积小、启动快、界面清楚，默认就能处理中文标签，支持歌词搜索和同步显示。背后是郑南岭对中文编码混乱的深刻理解。当时的 MP3 标签有按 GBK 写的，有按 Big5 写的，有按 UTF-8 写的，播放器如果不主动检测并转换，一打开就是乱码。为什么会这样呢？后文会详细阐明。千千静听则内置了自动编码识别和简繁转换功能，甚至对日文汉字错误映射也做了修正，这对普通用户来说完全是无感但至关重要的体验。

歌词是千千静听另一条护城河。它普及了 LRC 歌词格式。LRC 是一种带时间戳的纯文本歌词格式，比如 `[00:15.23]故事的小黄花~`，播放器可以按时间同步高亮滚动。纯文本意味着它可以用记事本打开和编辑，时间戳则告诉播放器某一句歌词应该在什么时候出现。千千静听还架设了服务端自动匹配下载机制，只要播放歌曲，软件就能根据歌名和艺术家自动检索并下载歌词，用户几乎不用手动找。对喜欢中文流行歌，想要看歌词、跟唱的人来说，这种体验就是开袋即食。

千千静听的功能关系可以这样表示

```mermaid
graph TD
    A["本地音频文件"] --> B["播放核心<br/>MP3 解码 / 多格式支持"]
    B --> C["音频输出<br/>WaveOut / DirectSound"]
    B --> D["标签识别<br/>中文信息处理"]
    D --> E["歌曲信息<br/>歌手 / 标题 / 专辑"]
    E --> F["在线歌词服务器查询"]
    F --> G["下载 LRC 歌词"]
    G --> H["同步滚动歌词显示"]

B --> I["全局热键<br/>后台 / 游戏中控制播放"]
    B --> J["迷你模式<br/>桌面常驻小窗口"]
    H --> K["简繁转换<br/>提高歌词可读性"]
```

全局热键也是当年非常实用的功能。所谓全局热键，就是即使播放器窗口没有位于前台，用户也能通过键盘快捷键控制播放、暂停、上一首、下一首和音量。迷你模式则适合把播放器缩成一个小条放在桌面角落，既不占空间，又可以随时看到歌曲和歌词。

巅峰时期，千千静听在国内音乐播放器市场装机率一度高达约 70%，而它的核心开发几乎只有郑南岭一个人。这种个人开发的极致成果，在同时期的中国软件圈里是很少见的。千千静听也举办过国内范围的皮肤设计大赛，将中文用户的桌面个性化推向了一个新的高度。很多用户会专门去论坛下载皮肤、歌词插件和美化资源，把千千静听摆在桌面上长期使用。它既是听歌工具，也是个人电脑桌面的一部分。

![我搜集到的一款天天静听二次元皮肤展示图](http://cdn.07212121.xyz/2026/05/cd1efc5736163dd727a7ed1dd26beea8.机神飞翔之阿娜扎布拉德.webp)

2006 年，百度收购千千静听，郑南岭带领团队完成了两年的代码过渡，之后选择去国外休息了两年，生活态度颇为低调。此后，软件逐渐被纳入百度音乐体系。商业化之后，安装包开始捆绑推广，软件内出现弹窗和运营入口，经典版本 5.x 及之前所代表的那种本地纯净体验逐渐消失。到更晚期的 7.x 版本和百度音乐阶段，官方路线已经和很多老用户心中的经典千千静听出现明显差异。

千千静听的轨迹，和 Winamp 被 AOL 收购后的迷茫有相似之处。又一个因好用而积累起庞大用户的工具，在商业化压力下被平台逻辑捆绑，最终从为用户服务滑向为流量服务。对经历过那个纯粹播放器年代的人来说，这不仅是功能上的损失，更像是一种对软件作为工具这一理念的背离。

千千静听能够成为中国用户心中的经典，靠的并非单一功能。它把中文标签、自动歌词、轻量播放、快捷键、迷你窗口、皮肤文化和低打扰体验组合在一起，正好命中了当时国内用户最真实的桌面听歌场景。它没有让普通用户先学会复杂设置，再享受音乐。它把复杂问题藏在背后，让用户打开软件就能听歌、看歌词、整理列表。这正是它在中文互联网记忆中长期被怀念的原因。

## 2.4 善打太极 —— AIMP

到 2000 年代中期，Windows 本地播放器市场已经出现了很明显的分化。

Winamp 曾经是最有代表性的桌面播放器。它轻巧、好看、支持皮肤和插件，也拥有非常活跃的社区文化。但在后期，尤其是 Winamp3 时代以及 AOL 收购之后，许多老用户开始批评它变得越来越臃肿，启动变慢，功能变杂，插件生态也逐渐显得混乱。一个原本以轻快著称的播放器，慢慢背上了臃肿的评价。

Foobar2000 则走向了另一端。它强大、干净、可扩展，音频输出和组件系统都很优秀，但对普通用户并不算友好。很多人第一次打开 Foobar2000，会觉得它更像一个工程工具。界面极简，默认外观朴素，很多功能需要自己配置组件、调整布局、理解设置项。它当然好用，但前提是用户愿意折腾。对于只想打开软件、导入歌曲、换个漂亮皮肤、舒服听歌的人来说，Foobar2000 显得太“极客”了。我感觉有点像 MPV 的定位。

那么有没有一种播放器，可以继承 Winamp 的漂亮界面、皮肤文化和易用性，又不会重蹈后期 Winamp 臃肿不稳的老路；同时，它还要比 Foobar2000 更容易上手，比普通系统播放器更轻巧、更可控呢？

AIMP 由俄罗斯开发者 Artem Izmaylov 开发，最初发布于 2006 年。AIMP 这个名字来自 Artem Izmaylov Media Player。它的研发动机非常清楚，就是做一款平衡型播放器。它既要好看，也要轻；既要容易用，也要有足够的音频处理能力；既要继承 Winamp 式的小窗口、可移动、皮肤、播放列表和均衡器传统，又要在稳定性、资源占用和现代音频输出方面做得更好。

[album type="photos"]
![作者早期的A.I.M.P.（注意不是AIMP）v1](http://cdn.07212121.xyz/2026/05/3e8a0c470b8d9bb5e66980996f37e5ad.A.I.M.P._v1.webp)

![A.I.M.P. v2](http://cdn.07212121.xyz/2026/05/c35db6baeee6ebdea03b194293e05459.A.I.M.P._v2.webp)

![A.I.M.P. v3](http://cdn.07212121.xyz/2026/05/459da8502b1ce54e28f4a522f5b1e7f4.A.I.M.P._v3.webp)
[/album]

[album type="photos"]
![A.I.M.P. v4](http://cdn.07212121.xyz/2026/05/ae9d4fca67aaded78706805c77679c4f.A.I.M.P._v4.webp)

![A.I.M.P. v5](http://cdn.07212121.xyz/2026/05/b5890536094e84b006916a8170c7f5a9.A.I.M.P._v5.webp)
[/album]

[album type="photos"]
![AIMP 最新正式版本 v5.40.2716 默认样式一](http://cdn.07212121.xyz/2026/05/005e0f322b8b004ba71a6aaa600ab4bd.AIMP_1.webp)

![样式二](http://cdn.07212121.xyz/2026/05/9d9b4694597449574301f1789c63f792.AIMP_2.webp)

![样式三](http://cdn.07212121.xyz/2026/05/b10fab3f36a494571b609a819bfb7b29.AIMP_3.webp)
[/album]

所以，AIMP 更像是来打太极的。想要漂亮界面的人，可以用它；想要低资源占用的人，可以用它；想要基本音质设置、输出设置、标签编辑和网络电台的人，也可以用它。

我一直觉得，俄罗斯和东欧开发者在桌面软件领域长期有一种很鲜明的风格。它们开发出来的软件，体积小，功能密度高，资源占用克制。AIMP 身上也有这种气质。它的界面做得精致，启动速度很快，安装包体积不大，但功能却相当完整。对那些厌倦了臃肿播放器，又不想花大量时间折腾组件的用户来说，AIMP 很容易成为一个自然选择。

早期 AIMP 使用 BASS 音频库。BASS 是 Un4seen Developments 开发的一套音频处理库，可以提供解码、播放、流媒体、录音、DSP 处理以及多种输出支持。使用成熟音频库的好处是，播放器开发者不必从零开始编写每一种格式的解码和输出逻辑，可以把更多精力放在界面、播放列表、音效、标签编辑和整体体验上。

到了后来的版本，AIMP 逐步发展出更完整的自有音频处理体系。它支持 32 位浮点音频处理、多段均衡器、混响、合唱、镶边、变调、变速等 DSP 效果。32 位浮点处理可以理解为播放器在内部计算音量、均衡、混音和音效时，使用余量更大的数据格式，从而降低多次处理叠加时出现削波和失真的风险。

均衡器，也就是 EQ，可以让用户增强或削弱不同频段。低频关系到鼓点和低音，中频影响人声主体，高频则影响明亮感和空气感。混响可以模拟空间反射，让声音像是在房间、礼堂或更大的空间里播放。合唱、镶边、变调和变速则让 AIMP 不只是一个简单播放器，也能承担一些日常音频处理和娱乐用途。

AIMP 另一个让用户印象深刻的特点，是缓存做得很积极。它可以把整首歌或较大一部分音频提前读入内存，减少机械硬盘持续读取带来的影响。在机械硬盘仍然普遍使用的时代，硬盘寻道、文件碎片、后台读写都有可能影响播放稳定性。提前缓存到内存后，播放过程就更不容易被硬盘状态干扰。

网络电台播放也受益于缓存。网络连接可能波动，播放器提前缓冲一小段音频，就可以在短暂网络抖动时继续播放。对喜欢听在线电台的人来说，这种稳定性很重要。

AIMP 的工作流程大致可以这样理解：

```mermaid
graph TD
    A["本地音频 / 网络电台"] --> B["解码层<br/>早期 BASS / 后期自有音频体系"]
    B --> C["32-bit 音频处理管线"]
    C --> D["DSP 效果<br/>均衡器 / 混响 / 合唱 / 变速变调"]
    D --> E["缓存机制<br/>整曲缓存 / 网络电台缓冲"]
    E --> F{"输出方式"}

F --> G["DirectSound"]
    F --> H["ASIO"]
    F --> I["WASAPI / WASAPI Exclusive"]

B --> J["标签编辑器<br/>批量修改元数据"]
    B --> K["ACS 皮肤引擎<br/>拟物界面 / 复古面板"]
```

在输出方式上，AIMP 也兼顾了普通用户和进阶用户。DirectSound 适合日常使用，兼容性好，可以和其他程序一起发声。ASIO 常见于专业音频环境，特点是低延迟。WASAPI 是 Windows Vista 以后更现代的系统音频接口，其中 WASAPI Exclusive 是独占模式，可以让播放器更直接地控制音频设备，减少系统混音器的介入。

对于外置 DAC 用户来说，这些输出选项很有意义。用户有时希望播放 44.1 kHz 文件时设备就工作在 44.1 kHz，播放 96 kHz 文件时再切换到 96 kHz。AIMP 提供更细致的输出设置之后，就能同时满足普通播放和进阶播放需求。

AIMP 的界面风格也是它成功的重要原因。它保留了 Winamp 时代小窗口播放器的传统，同时把皮肤系统做得更精致。很多 AIMP 皮肤会模拟磁带机、CD 机、功放、调音台、收音机、电子管设备或 VU 表。VU 表是传统音频设备上常见的指针式电平表，用来显示声音强弱。即使它在现代播放器里更多是一种视觉装饰，也能给用户带来“正在操作真实音响设备”的感觉。

AIMP 使用 ACS 皮肤引擎支持换肤。相比早期 Winamp 主要围绕固定布局替换位图，AIMP 的皮肤可以实现更复杂的界面结构和交互效果。AIMP 甚至有一款专门制作皮肤的软件。因此，AIMP 社区里出现了大量拟物化、复古化、器材化的皮肤。它可以把播放器变成一台卡座、一台迷你音响，甚至一组专业机架设备。插一嘴，其实 AIMP 的二次元皮肤也挺有意思。

![AIMP 官网的一些皮肤展示](http://cdn.07212121.xyz/2026/05/391bd42d965ca31bbf0e9277027c17f9.AIMP_Skins.webp)

同时，AIMP 并不要求用户像 Foobar2000 那样从零开始搭建体验。安装完成后，播放列表、均衡器、音效、皮肤、标签编辑、格式转换、网络电台等常用功能都已经准备好。想简单听歌的人可以直接用，想进一步调整输出和音效的人也有空间继续折腾。

AIMP 还内置了实用的标签编辑器。标签编辑器可以批量修改歌名、歌手、专辑、年份、流派、曲目编号和封面等元数据。收藏数量增加后，批量修改标签会比逐首手动整理高效得多。网络电台也是常用功能之一，在流媒体音乐服务全面普及之前，网络电台是很多人发现新音乐、收听国外频道和播放背景音乐的重要方式。

简单说，AIMP 的成功来自一种平衡。它吸收了 Winamp 的漂亮外观和易用传统，避开了后期 Winamp 臃肿不稳的问题；它具备一定的音频输出和处理能力，却不像 Foobar2000 那样要求用户先跨过较高的配置门槛。它好看、轻快、稳定、功能完整，也保留了足够的折腾空间。如果说 Foobar2000 是给愿意亲手搭建系统的玩家准备的工具箱，那么 AIMP 就更像一台开箱即用、外观漂亮、功能齐全的小型桌面音响。它不一定在每一个专业维度上都走到极致，但它算一个不臃肿、不难用、又足够漂亮和好听的如此平衡的播放器。

---

## 2.5 仓鼠还想继续做仓鼠 —— MusicBee

2000 年代后期，电脑硬盘容量快速增长。从几十 GB、几百 GB 走向 TB 级容量之后，本地音乐收藏的规模也随之膨胀。有些用户的硬盘里已经装满了几千首、几万首歌曲，甚至包含不同版本、不同压制来源、整轨镜像、现场录音、古典全集、动漫原声和大量稀有资源。我愿意管他们叫仓鼠党。

仓鼠党这个说法来自网络文化，形容喜欢不断收集、保存内容的人。对于音乐收藏者来说，这种行为很容易理解。硬盘容量变大之后，保存的门槛降低了，整理的难度却迅速提升了。

这个时候，管理能力开始成为播放器的核心竞争点。当音乐文件夹里有上万首歌时，用户会遇到很多问题：文件名混乱，专辑封面缺失，歌手名写法不统一，同一专辑分散在不同目录，标签错误，重复文件过多，设备同步麻烦。这些问题已经超出了单纯解码的范围，属于数据库和元数据管理问题。数据库可以帮助软件建立索引，按照歌曲、专辑、艺人、流派、年代、评分、播放次数和自定义字段快速查找内容。元数据则是附着在音乐文件上的描述信息，例如歌名、歌手、专辑名、曲目编号、发行年份、封面和歌词。只有把文件本身、数据库索引和标签信息协调起来，大型音乐库才可能真正好用。

MusicBee 就是这一阶段的代表。

MusicBee 由英国独立开发者 Steven Mayall 开发。Mayall 自己就是一个仓鼠党，个人音乐库积累了几万首歌曲，涵盖古典、摇滚、爵士等复杂流派，标签混乱到几乎无法管理。古典音乐对标签管理尤其苛刻，同一首作品可能同时涉及作曲家、指挥、乐团、独奏者、作品编号、乐章、录音年份和唱片版本。当时的 iTunes 和 Windows Media Player 已经具备资料库能力，但它们的管理规则、界面逻辑和文件控制方式并不能满足 Mayall 对大型本地收藏的需求。他希望拥有更强的库管理、更细的自定义排序、更方便的重复检测、更灵活的批量标签功能，以及由用户决定的文件组织方式。于是，他自学 VB.NET，在 2008 年 12 月发布了 MusicBee。

![俺用的 MusicBee 界面](http://cdn.07212121.xyz/2026/05/cbd16836f2bb2908b82be1917ea1af6b.musicbee.webp)

VB.NET 是微软 .NET 平台上的一种编程语言。.NET 则是微软推出的软件开发平台，许多 Windows 应用会借助它来构建图形界面、处理数据和组织程序逻辑。MusicBee 选择这一技术路线，让开发者能够较快构建复杂的资料库和界面功能，而播放部分则可以依托成熟的音频引擎保证稳定性。

MusicBee 的定位面向大规模本地音乐库，承担整理、浏览、播放、同步和维护工作。它吸收了 iTunes 的资料库思路，同时尽量避免 iTunes Windows 版长期被用户诟病的臃肿、迟缓和文件控制限制。它可以监控指定文件夹，自动扫描新音乐、删除失效项目、更新标签变化，并把这些内容加入资料库。用户把新专辑复制进音乐目录后，MusicBee 可以自动发现内容，读取标签，获取封面，再按照用户设定的分类方式显示出来。这里的索引有点像图书馆目录卡。歌曲实际仍然保存在硬盘文件夹里，MusicBee 的数据库则记录它们的位置、标签、封面、评分和播放状态。这样一来，用户搜索某位歌手或某个年份时，不需要逐个打开硬盘目录，数据库可以迅速返回结果。

MusicBee 的音频播放部分基于成熟的 BASS 库，能够提供稳定的格式解码和输出能力。它也支持 ASIO、WASAPI、DirectSound 等常见输出路径。对于收藏规模很大的用户来说，管理和播放本来就应当连接在一起，整理好专辑之后随时播放，播放过程中发现错误标签再随手修正，这才是自然的使用流程。

MusicBee 的工作方式可以概括为

```mermaid
graph TD
    A["本地音乐文件夹"] --> B["高速目录监控<br/>新增 / 删除 / 修改"]
    B --> C["资料库数据库<br/>索引歌曲 / 专辑 / 艺人"]
    C --> D["元数据扫描与清洗"]
    D --> E["MusicBrainz / 在线数据库匹配"]
    E --> F["补全标签<br/>歌名 / 专辑 / 封面 / 曲目号"]

C --> G["播放模块<br/>BASS 音频引擎"]
    G --> H["ASIO / WASAPI / DirectSound 输出"]

C --> I["自动文件整理<br/>按标签重命名和移动"]
    C --> J["设备同步<br/>Android / 便携播放器"]
    J --> K["实时转码<br/>同步时转换格式"]
```

MusicBee 把播放器和整理工具结合得非常深。用户可以定义文件命名规则，按照流派、艺人、年份、专辑、音轨号和标题自动移动和重命名文件。只要标签准确，硬盘上的实际目录结构也可以自动保持整洁。这非常适合大量导入音乐的场景，因为用户可能从不同来源获得文件，有些文件夹按中文名排列，有些按英文名排列，有些只剩下 track01、track02 这类没有辨识度的文件名。通过标签清洗和自动移动，原本杂乱的文件能够逐渐变成统一组织的收藏体系。

MusicBee 还能够接入 MusicBrainz 等在线数据库。MusicBrainz 是一个开放的音乐元数据数据库，社区会维护专辑、艺人、发行版本、曲目顺序、条码和关联信息。通过在线匹配，MusicBee 可以帮助用户补全缺失的歌名、专辑名、封面、曲目编号和艺人资料。进一步来说，部分整理工具还能够借助音频指纹识别歌曲。音频指纹并非完整保存歌曲内容，它会提取音频里相对稳定的特征，生成一段用于比对的识别信息。即使用户把同一首歌转换成不同码率的 MP3，或者文件名被改得完全认不出来，只要声音内容仍然足够相似，数据库就可能识别出它对应的正式曲目。

智能播放列表也是 MusicBee 特别适合大型资料库的一项功能。普通播放列表通常需要用户手动拖入歌曲，智能播放列表则可以根据规则自动生成和更新。例如，用户可以建立“评分四星以上且两年内没有播放过的爵士乐”“最近加入的无损专辑”“1980 年代女声歌曲”“还没有封面的文件”这一类列表。随着资料库内容变化，列表会自动更新，大型收藏就不会只是躺在硬盘深处吃灰，而会重新被用户发现和播放。

重复文件检测同样重要。一首歌可能同时保存为 MP3、FLAC、APE，也可能因为重复下载出现多个完全一致的副本。MusicBee 可以帮助用户按照标题、标签、时长、码率甚至内容特征检查重复项，让整理工作更加可控。

设备同步则对应了 2000 年代后期到智能手机时代的常见需求。用户可能在电脑上收藏 FLAC、APE 等无损文件，但便携播放器或手机容量有限。MusicBee 可以在同步时进行实时转码，例如电脑里继续保存 FLAC 归档，传输到手机时自动转换成 MP3 或 AAC。这样既能保证电脑上的收藏质量，也能节省移动设备空间。

MusicBee 的界面同样围绕资料库使用方式展开。用户可以按照专辑封面浏览，也可以按艺人、流派、年份、作曲家、评分和文件位置查看。虽然 MusicBee 功能极多，但 Mayall 长期坚持以独立开发方式维护，资源占用相对克制。对于拥有上万首歌曲的资料库，它通常仍能保持较好的响应速度。

如果说 AIMP 更像一台外观漂亮、功能全面的桌面音响，MusicBee 就更像一座私人音乐图书馆。它让收藏者可以把零散文件整理成有结构、有封面、有标签、有规则、可以持续维护的个人资料库。仓鼠党保存音乐的冲动不会因为文件越来越多而消失，MusicBee 提供的价值，就是让这些收藏最终能够被找到、被理解、被播放，也被长久保存。

---

# 三、大手的抉择

## 3.1 最普及最稀烂

对于很多普通 Windows 用户来说，WMP 才是他们接触到的第一款本地播放器。它不需要额外下载，不需要选择安装包，也不需要研究插件。电脑装好 Windows，双击一个音乐文件，系统默认打开的往往就是它。

![运行在我的 Windows 10 上的 WMP 12](http://cdn.07212121.xyz/2026/05/1f3b01a84bf3dd0f055501af1b7197c8.WMP.webp)

默认软件有一种天然优势。它会出现在开始菜单里，会接管文件关联，会写进系统帮助和新手教程里，也会成为很多人对“播放器”这个概念的第一印象。WMP 的历史可以追溯到早期 Windows 的多媒体扩展时代。到了 Windows 98、Windows 2000 和 Windows XP 年代，它真正成为大众用户熟悉的系统播放器。随着光驱、声卡、MP3 文件和家庭电脑普及，WMP 承担的不只是播放任务，它还承担了普通人进入数字音乐时代的一整套入口功能。

其中最重要的功能之一是 CD 抓轨。CD 抓轨通常叫 Rip，意思是把音乐 CD 里的音轨读取出来，保存成电脑上的音频文件。用户把 CD 放进光驱，WMP 可以读取音轨，再把它们保存为 WMA、MP3 或其他格式。对于许多用户来说，这就是他们第一次把实体唱片变成电脑文件的过程。原本只能在 CD 机里播放的专辑，经过抓轨之后，可以出现在电脑音乐库里，可以复制到 MP3 播放器里，也可以刻录成新的光盘。

刻录是 WMP 的另一个时代功能。用户可以把电脑里的歌曲整理成播放列表，再写入可录制光盘。今天看起来，刻录音乐 CD 已经有些遥远，但在 USB 闪存盘、智能手机和车载蓝牙普及之前，它是非常常见的音乐携带方式。

WMP 还承担了设备同步功能。在智能手机成为主流之前，市场上存在大量 MP3 播放器、硬盘播放器和支持音乐播放的便携设备。用户需要把电脑里的歌曲传到设备里，还要考虑格式、容量、播放列表和兼容性。WMP 试图把音乐库、抓轨、刻录和设备同步放进同一个界面体系，让普通用户不必在一堆工具之间来回切换。

这背后其实是微软的一整套数字媒体生态设想。Windows、Windows Media Player、WMA、DRM、便携设备认证和在线音乐服务，被微软放在同一个大框架里。WMA 是 Windows Media Audio 的缩写，是微软推出的音频压缩格式。很多用户用 WMP 抓轨时，如果没有修改默认设置，就可能得到一批 WMA 文件。WMA DRM 则是微软数字音乐生态里的版权保护机制，对用户来说，它也经常意味着 SB。换电脑、重装系统、迁移账号或更换播放器后，受 DRM 保护的歌曲可能出现无法播放的问题。

微软还推出过 PlaysForSure 认证，希望在线音乐商店、播放器软件和便携硬件之间能够通过统一规则协作。这个设想看起来完整，但实际体验并不总是顺畅。不同厂商支持程度不一，DRM 授权也会制造不确定性。与此同时，苹果用 iPod 和 iTunes 建立了更强势的消费级音乐生态；而在更广泛的民间使用环境里，MP3 仍然凭借兼容性成为真正的通用格式。WMA 因此始终没有真正取代 MP3。

在 WMP 10 和 WMP 11 阶段，Windows Media Player 的音乐库体验已经相当成熟。它可以提供资料库视图、专辑封面、艺人分类、评分系统、播放列表、自动元数据获取、抓轨设置和设备同步。资料库视图对普通用户影响很大，用户可以按照艺人、专辑、歌曲、流派和评分浏览收藏，而不是文件夹。

WMP 的优势来自系统整合，局限也来自系统整合。它覆盖面广，学习成本低，适合普通用户。但对高级用户来说，它的自由度并不够。想细调音频输出，想自由选择解码组件，想批量清洗标签，想按自己的规则组织文件，WMP 就显得不够灵活。这也是为什么很多用户后来会转向 Foobar2000、AIMP 或 MusicBee。

微软当然也不可能只守着 WMP。面对苹果的生态，微软曾试图用 WMA、PlaysForSure 构筑阵营，但后来自己又转向了 Zune。2006 年，微软推出 Zune，既是便携播放器品牌，也是对应的软件和音乐服务。Zune Software 和传统 WMP 很不一样，它的界面很有设计感，大字号、横向布局、专辑封面、简洁动效，这些元素后来都在 Windows Phone 和 Metro 设计语言中看到影子。

![维基百科上的 Zune 播放器](http://cdn.07212121.xyz/2026/05/239a322979d4b7c4d37008cb8fef6008.Zune80and4.webp)

Zune 可以管理本地音乐，访问 Zune Marketplace，同步 Zune 设备，还提供 Zune Pass 订阅服务。Zune Pass 其实已经有了后来流媒体订阅的雏形：按月付费。但 Zune 来得太晚，生态没有形成足够规模。更伤用户信任的是，Zune 并不兼容此前 PlaysForSure 体系购买的内容。这种策略变化，对数字内容用户来说非常致命，因为用户投入的是购买、整理、同步和长期使用习惯。

Zune 最终没能成功，被苹果的 iPod 家族踩在地上摩擦，硬件停产，服务逐渐并入 Xbox Music。到了 Windows 8 时代，微软全面推进 Metro / Modern UI，音乐服务也被纳入更大的账号和跨设备战略中。Xbox Music 这个名字本身就说明了当时微软既要又要的思路。后来 Xbox Music 又改名为 Groove Music，采用 UWP 应用形式，试图承担在线音乐订阅入口。但到这个阶段，音乐服务的竞争已经不是“系统默认播放器好不好用”能决定的了。真正关键的是版权曲库、推荐算法、移动端生态、歌单文化和跨平台覆盖。

关于 UWP，我本人也有些许怨言。可能后面会出一篇文章讲一讲。

![Groove Music 界面](http://cdn.07212121.xyz/2026/05/1a9dcb682ca970768b9e01d23fae47c6.Groove_Music.webp)

2017 年，微软宣布停止 Groove Music Pass 服务，并与 Spotify 合作，引导用户迁移。Groove Music 应用本身继续作为本地播放工具存在，但作为音乐服务入口的使命基本结束。后来 Windows 11 又推出新的 Media Player，界面符合现代风格，承担基础本地音频视频播放功能。经典 WMP 仍然以遗留组件形式保留，你还是可以在 Windows 10/11 上使用它。

![新版 Media Player](http://cdn.07212121.xyz/2026/05/dfa07d43b62ca122366b89bc7d4a0e39.media-player-3.webp)

微软官方播放器路线可以简单表示为：

```mermaid
graph TD
    A["微软官方音乐路线"] --> B["Windows Media Player"]
    B --> C["WMA / DRM / CD 抓轨 / 媒体库 / 设备同步"]

A --> D["PlaysForSure"]
    D --> E["第三方设备和在线商店联盟"]

A --> F["Zune"]
    F --> G["Zune Software / Zune Marketplace / Zune Pass"]

A --> H["Xbox Music"]
    H --> I["Groove Music"]

I --> J["Groove Music Pass 关闭"]
    J --> K["Windows 11 Media Player"]

B --> L["经典 WMP 作为遗留组件保留"]
```

微软不是没有播放器，也不是没有战略。它的问题恰恰是战略太多，而且不够连续。WMP、WMA、PlaysForSure、Zune、Xbox Music、Groove Music，每一步看似都有自己的节奏，但实际上就像是一只无头苍蝇不断乱转。用户很难形成长期信任。WMP 是默认入口，但没有取代 Winamp；Groove Music 是系统应用，但没有赢过 Spotify 和本土在线音乐客户端。这么一盘好棋，微软又下输了。

...嗯？为什么我要说“又”？

---

## 3.2 手机就是苹果

苹果的 iTunes 不是传统意义上那种轻量播放器，它也想用资料库、商店、设备和账号，把音乐管理变成一个完整生态。

2001 年 1 月，苹果发布 iTunes。它最初来自 SoundJam MP，苹果收购后将其改造成播放器和管理软件。早期 iTunes 的核心功能并不复杂，就是播放 MP3、管理音乐库、抓取 CD、刻录光盘什么的。它真正改变历史，是因为同年 10 月 iPod 发布。iPod 需要电脑端管理工具，iTunes 正好承担这个角色。在 iPod 之前，很多 MP3 播放器的管理方式接近 U 盘，用户把文件复制进去，设备读取文件夹或简单列表。这种方式自由，但体验粗糙。iTunes 则采用更强的资料库思路：用户在 iTunes 里整理音乐，再同步到 iPod，鼓励按照歌曲、艺人、专辑、流派、播放列表来浏览。这套逻辑非常苹果，它牺牲了一部分文件自由，换取端到端体验。

什么？WMP 不也是这样的吗？噢，它是抄的来着。

![早期 iTunes 界面](http://cdn.07212121.xyz/2026/05/2d55ff9995ea0c3008e92cdf264daf4b.iTunes.webp)

2003 年，iTunes Music Store 上线。苹果把播放器、在线商店、账号支付和 iPod 连接起来，形成了数字音乐商业化历史上非常关键的一步。用户可以用 0.99 美元购买单曲，下载到 iTunes，再同步到 iPod。这对当时唱片业非常重要，因为 Napster 之后，互联网文件共享已经让传统唱片销售受到巨大冲击。苹果提供了一条相对方便、价格明确的合法购买路径。早期 iTunes Store 销售的音乐使用 AAC 编码，并带有 FairPlay DRM。后来在用户压力和市场竞争下，苹果又一次的妥协，逐步转向无 DRM 音乐，2009 年，大部分音乐取消 DRM。这说明用户对可迁移、可长期保存的文件仍然有强需求。

iTunes 的资料库结构可以这样理解

```mermaid
graph TD
    A["CD / 本地音频 / iTunes Store"] --> B["iTunes 资料库"]
    B --> C["元数据管理<br/>歌名 / 艺人 / 专辑 / 封面"]
    B --> D["播放列表<br/>普通列表 / 智能播放列表"]
    B --> E["评分与播放次数"]
    B --> F["文件整理<br/>iTunes Media 文件夹"]

B --> G["iPod / iPhone / iPad 同步"]
    G --> H["设备端浏览<br/>歌曲 / 专辑 / 艺人 / 流派"]

B --> I["账号与商店"]
    I --> J["购买 / 下载 / 授权"]
```

iTunes 对文件的处理哲学，和 Foobar2000、AIMP、MusicBee 截然不同。Foobar2000 是工具箱，一切由用户决定。iTunes 是管家，它替用户接管一切，导入的音乐会被复制到 iTunes Media 文件夹，按它自己的规则重新组织。对普通用户，这消灭了混乱。对喜欢手工管理目录的人，这简直是一种冒犯。这也就解释了两种用户的长期分裂，一方拥抱资料库管理，一方死守文件自主权。iTunes 毫无保留地站在了前者那一边，并且赢得了市场。

所以在 Windows 上，iTunes 的口碑一直很复杂。Windows 用户经常抱怨 iTunes 臃肿、启动慢、后台服务多、文件管理不自由（毕竟Windows 版的 iTunes 本身就是乔帮主的妥协产物啦）。尤其是已经习惯了本地音乐播放器的用户，会觉得 iTunes 过度接管，不像一个干净播放器。该死，Only Apple can do...

不过，不能因为 Windows 版 iTunes 的臃肿体验，就低估它的历史意义。iTunes 普及了几个非常重要的习惯：按资料库听歌；智能播放列表；评分、播放次数和最近播放时间等长期行为记录；设备同步。它让数字音乐第一次以商业闭环的方式进入大众生活。Yes, only Apple can do.

随着 iPhone 兴起，iTunes 的角色继续扩大，变成设备备份、应用管理、系统更新和媒体管理中心。功能越来越多，也越来越臃肿。2015 年，Apple Music 上线，苹果正式进入订阅流媒体时代。2019 年，macOS Catalina 中苹果拆分 iTunes，音乐、播客、电视分别独立。iTunes 这个庞然大物在 Mac 上退出历史中心，Windows 上后来也逐步推出独立的 Apple Music、Apple TV 等应用。

iTunes 连接了两个时代。它从本地数字音乐时代出发，靠 CD 抓轨、资料库和 iPod 同步，成功改变了人们消费音乐的方式。随着 Apple Music 的到来，它又进入流媒体时代，逐步从“管理文件”转向“访问服务”。于是，越来越多的人选择拥抱流媒体。

---

# 四、深入技术腹地

## 4.1 音频输出链路超进化

前面讲播放器时，反复出现了 WaveOut、DirectSound、Kernel Streaming、ASIO、WASAPI、bit-perfect、DAC 这些词。它们看起来像老资历的黑话（并非看起来像），但其实背后对应的是 Windows 音频系统几十年来的变化。本地音频播放器的发展，不只是界面和功能的变化，也是一段 Windows 音频输出链路不断重构的历史。

用户点击播放之后，音频文件并不是直接变成耳机里的声音。大致流程是，播放器先把 MP3、FLAC 等格式解码成 PCM，然后把 PCM 交给 Windows 音频系统，Windows 再把声音交给声卡驱动或外置 DAC，最后由 DAC 把数字信号转换成模拟信号，送到耳机或音箱。

早期 Windows 播放音频主要依赖 MME / WaveOut。MME 是 Multimedia Extensions 的缩写，WaveOut 是其中用于输出波形音频的接口。它的优点是兼容性极好，几乎所有声卡和系统都能用。缺点是接口比较老，延迟较高，对现代低延迟和精确控制需求支持有限。听歌时，几十毫秒甚至更高延迟通常问题不大，但在录音、编曲等场景中，延迟过高会非常明显。

后来 DirectSound 出现，成为 Windows 9x 到 XP 时代非常重要的音频接口。DirectSound 属于 DirectX 体系，最初主要服务游戏和多媒体应用。在独立声卡和硬件混音比较常见的年代，DirectSound 可以让多个程序同时发声，也可以提供硬件加速、3D 音效等能力。对播放器来说，DirectSound 的优点是比 WaveOut 更现代，稳定性和兼容性也不错。很多播放器长期默认提供 DirectSound 输出插件。

但在 Windows 2000 和 XP 时代，很多发烧友对系统音频链路有一个长期不满，就是前面提到过的 KMixer。KMixer 是 XP 及更早 NT 系统里负责混音的内核组件。在绝大部分情况下，电脑不可能一次只能有一个程序发声，于是 KMixer 就负责把多个程序的音频流混合成一个输出流再交给声卡。问题在于，不同程序的声音可能有不同采样率、不同位深，为了混在一起，KMixer 往往需要重采样和格式转换。XP 时代 KMixer 的重采样质量并不总是令人满意，而且它会让音频数据不再保持原样。这就触发了 bit-perfect 用户的敏感点。

于是，绕过 KMixer 成为当时很多播放器高级输出插件的重要卖点。Kernel Streaming 可以让应用程序通过更底层的驱动路径把音频送到设备，尽量避开普通系统混音流程。Foobar2000 很早支持 Kernel Streaming，正因为 Peter Pawlowski 非常清楚这些问题的复杂性。Kernel Streaming 的优点是路径短、干预少，不过缺点也很明显，兼容性不稳定，对声卡驱动要求高，配置不够友好。

另一条路线是 ASIO。ASIO 是 Steinberg 为专业音频软件推出的低延迟驱动协议，主要服务录音棚、编曲、实时监听和专业音频制作。它绕过 Windows 常规音频栈，让软件可以以较低延迟直接与音频接口通信。后来很多播放器也支持 ASIO 输出，对部分外置 DAC 来说，厂商会提供 ASIO 驱动，用户就能让播放器通过 ASIO 直接输出到设备。不过ASIO 并不是“音质变好”的神奇按钮。它的核心价值是低延迟、稳定、绕过系统混音以及精确控制设备。听普通本地音乐时，如果 WASAPI 独占已经能实现干净输出，ASIO 未必带来可闻提升，无需过度迷信。

真正让 Windows 音频架构出现重要变化的是 Windows Vista。Vista 引入了全新的音频栈，把许多原本处于内核态的音频处理移动到用户态，目标之一就是提高音频系统稳定性。同时，Vista 引入 WASAPI。WASAPI 是 Windows Audio Session API 的缩写，成为 Vista 以后 Windows 音频应用的重要接口。WASAPI 有两种常见模式：共享模式和独占模式。共享模式下，多个程序可以同时发声，系统音量混音器可以分别控制每个程序的音量。独占模式下，一个应用可以独自占用音频设备，播放器可以尝试按照音乐文件本身的采样率、位深输出，减少系统混音器介入。这就是很多发烧友喜欢的 WASAPI Exclusive。

WASAPI 的出现，让 Windows 上实现 bit-perfect 输出变得比 XP 时代更规范、更稳定。用户不再必须依赖兼容性参差不齐的 Kernel Streaming，也不一定要借助专业音频领域的 ASIO。Foobar2000、AIMP、MusicBee 等播放器都陆续支持 WASAPI 独占，外置 DAC 用户也因此获得了更简单可靠的输出路径。

可以把 Windows 音频输出路线简化成下面这样

```mermaid
graph TD
    A["播放器解码<br/>MP3 / FLAC / AAC -> PCM"] --> B{"输出接口选择"}

B --> C["WaveOut / MME<br/>早期接口 / 兼容性强 / 延迟较高"]
    B --> D["DirectSound<br/>XP 时代常用 / 游戏与多媒体传统"]
    B --> E["Kernel Streaming<br/>绕过 KMixer / 兼容性依赖驱动"]
    B --> F["ASIO<br/>专业音频 / 低延迟 / 厂商驱动"]
    B --> G["WASAPI Shared<br/>Vista 以后 / 多程序混音"]
    B --> H["WASAPI Exclusive<br/>独占设备 / 更适合 bit-perfect"]

C --> I["Windows 音频系统 / 声卡驱动"]
    D --> I
    E --> J["声卡 / DAC"]
    F --> J
    G --> I
    H --> J
    I --> J
    J --> K["耳机 / 音箱"]
```

这张图只是帮助理解，实际系统内部会更复杂。不同 Windows 版本、不同声卡驱动、不同播放器实现，都会改变实际路径。但大致可以这么说：WaveOut 和 DirectSound 偏官方传统派，Kernel Streaming 和 ASIO 偏民间，WASAPI 是 Vista 之后的官方维新派，其中独占模式更适合追求干净输出。

额，所以，bit-perfect 到底有没有必要呢？如果你只是用笔记本扬声器、蓝牙耳机或者普通小音箱随便听歌，系统混音和重采样通常不会是最大瓶颈。蓝牙耳机还会再经过 SBC、AAC、aptX、LDAC 等蓝牙编码，所谓 bit-perfect 在蓝牙链路里很快就不成立了。但如果你拥有一套不错的音频系统，并且希望播放器不要擅自改变采样率，不要经过系统音效，不要被聊天提示音混进来，那么追求所谓的 bit-perfect 是没有问题的。

这里还有一个常见误区，认为播放器音质差异一定巨大。实际上，如果两个播放器使用同样解码器，关闭所有 DSP、音量一致、输出路径一致，并且都实现 bit-perfect，那么理论上送到 DAC 的 PCM 数据应当相同，此时它们不该有明显音质差异。真正造成差异的，往往是默认音量、均衡器、重采样器、ReplayGain、系统音效、输出模式和心理预期。高质量重采样可以减少失真和伪影，现代 CPU 性能已经足够强，因此高质量重采样不再像早年那样耗费资源。这里再拷打一下那些老烧...

所以，本地播放器在音频输出上的演进，可以理解为从“能响”走向“可控”。早期用户最关心的是 MP3 能不能流畅播放，后来关心能不能支持更多格式，再后来开始关心系统有没有重采样，是否能绕过混音器，外置 DAC 能否自动切换采样率。Foobar2000、AIMP、MusicBee 等播放器之所以能长期存在，就是因为它们不仅能播放文件，还把这些控制权交还给用户。这也是经典本地播放器和现代流媒体客户端的一个重要差别，开放 OR 不开放。

---

## 4.2 无损格式 登场

MP3 改变了音乐传播方式，但它毕竟是有损压缩。在拨号上网和小硬盘时代，几 MB 一首歌是巨大的胜利。可到了宽带普及、硬盘变大之后，用户开始产生疑问，既然容量不再那么紧张，那为什么还要为了省空间丢掉声音信息呢？于是许多人都产生了无损的需求。

无损压缩的含义很直接，压缩之后可以完全还原原始 PCM 数据。它和 ZIP、RAR 压缩文档有点类似。无损编码不会丢掉信息，只是用更聪明的方法表示数据冗余。代价是压缩率不可能像 MP3 那么夸张。CD 音频原始码率大约 1411 kbps，无损压缩后常见码率可能在 600 到 1000 kbps 之间。

为什么音频能无损压缩呢？因为声音数据里存在规律。相邻采样点通常不会完全随机变化，左右声道之间也常常存在相关性。无损编码器会预测下一个采样值，再只保存预测误差。预测越准确，误差越小，就越容易压缩。最后再通过熵编码等方式把这些误差信息进一步压缩。

FLAC 是无损音频格式中最重要的一种。它全称 Free Lossless Audio Codec，意思是自由无损音频编码。它由 Josh Coalson 在 2000 年左右发起，后来成为开放、免专利费、跨平台支持极好的无损格式。FLAC 的设计我认为非常完美。它压缩率不错，解码速度快，容错能力强，适合流式播放，标签和封面支持也完善。更重要的是，它 Free，它开放。这意味着，播放器、转码器、硬件厂商和开源社区都可以放心支持 FLAC，不必担心会带来任何的复杂授权问题。

![FLAC LOGO](http://cdn.07212121.xyz/2026/05/f4a93123cf1b06441220b59622a9a7f7.FLAC_logo.webp)

FLAC 的开放属性极大推动了它在本地音乐收藏中的普及。许多免费开源的软件都能支持 FLAC。后来很多便携播放器、车机、手机系统、Hi-Fi 设备也陆续支持 FLAC。对于想长期保存音乐的人来说，FLAC 几乎成了默认答案。

FLAC 还支持校验，编码时可以记录音频数据的 MD5 校验值，解码或测试时可以验证文件是否损坏。对收藏者来说，知道自己的无损文件没有被硬盘坏道、复制错误或下载损坏影响，充满了无比的安心感。

FLAC 的基本流程可以这样理解

```mermaid
graph TD
    A["原始 PCM 音频<br/>例如 CD 抓轨 WAV"] --> B["分块处理"]
    B --> C["线性预测<br/>估计采样变化趋势"]
    C --> D["保存预测残差<br/>实际值 - 预测值"]
    D --> E["熵编码压缩"]
    E --> F["FLAC 文件<br/>音频帧 / 标签 / 封面 / 校验"]

F --> G["解码"]
    G --> H["还原 PCM<br/>与原始数据一致"]
```

除了 FLAC，中国用户还非常熟悉 APE。APE 是 Monkey's Audio 的文件格式，由 Matthew T. Ashland 开发。它同样是无损压缩，早年在中文互联网和俄罗斯、东欧资源圈非常流行，很多无损音乐资源都以 APE 形式传播，尤其常见的是整轨 APE 加 CUE 文件。CUE 是一种索引文件，用于描述光盘音轨布局。整轨抓取时，用户会把一整张 CD 保存成一个大的 APE 或 WAV 文件，再用 CUE 文件记录每首歌的起止时间、标题、歌手和音轨编号。

整轨 APE + CUE 在早年很流行，因为它接近完整光盘备份，资源发布者打包方便，一个音频文件加一个索引文件即可传播整张专辑。但 APE 并不像 FLAC 那样拥有开放友好的生态标准，跨平台支持较弱；解码复杂度更高，对硬件和便携设备不友好；文件容错能力较差；标签生态也不如 FLAC 统一。后来随着 FLAC 普及，越来越多用户把 APE 转成 FLAC 保存。CUE 本身也容易带来编码问题，很多中文 CUE 文件使用 GBK 或 Big5 编码，播放器按 UTF-8 读取就会乱码，用户常常需要手动修正。

除了 FLAC 和 APE，还有 ALAC、WavPack、TTA 等无损格式。ALAC 是苹果无损音频编码，适合苹果生态用户，早期绑定较深，后来开源（苹果开源吗嗯哼哼哼）。WavPack 支持混合模式，可以生成有损主文件加校正文件来还原无损。TTA 生态规模较小。这些格式大致可以比较如下：

| 格式    | 开放性               | 压缩率   | 解码速度 | 兼容性     | 典型用途               |
| ------- | -------------------- | -------- | -------- | ---------- | ---------------------- |
| FLAC    | 开放、免授权费       | 较好     | 快       | 极好       | 长期收藏、跨平台播放   |
| APE     | 相对封闭             | 通常略高 | 较慢     | 一般       | 早年无损资源、整轨 CUE |
| ALAC    | 苹果生态强，后期开源 | 较好     | 较快     | 苹果设备好 | 户子苹果生态           |
| WavPack | 开放                 | 较好     | 较快     | 中等       | 发烧友收藏、混合模式   |
| TTA     | 开放度尚可           | 较好     | 较快     | 较弱       | 小众无损收藏           |

无损格式的流行，改变了播放器的功能重点。第一，播放器必须支持更多格式。第二，播放器必须更重视标签，因为不同格式的标签写法不同，播放器需要统一显示。第三，播放器需要支持高分辨率音频，如 24 bit / 96 kHz，并能正确输出。第四，播放器需要具备转码能力，很多用户会把 FLAC 作为电脑归档格式，再转成 MP3 或 AAC 放进手机。Foobar2000 的 Converter、MusicBee 的同步转码、AIMP 的音频转换器，都服务于这一需求。

无损音乐还催生了很多围绕“真假无损”的讨论。并不是扩展名写着 FLAC 就一定是真无损。有人可能把低码率 MP3 转成 FLAC，这样文件会变大，但被 MP3 丢掉的信息不会回来。判断伪无损可以借助频谱分析，低码率 MP3 往往在高频处有明显截止。有时候甚至分析频谱也不一定能判别是否是真无损。

Exact Audio Copy（EAC）在无损收藏圈也非常重要。EAC 是一款经典 CD 抓轨软件，强调精确读取和错误校验。它可配合 AccurateRip 数据库验证抓轨是否与其他用户结果一致。对于认真收藏 CD 的用户来说，一份带有 EAC 日志和 AccurateRip 验证的 FLAC，比来源不明的“无损”更值得信任。

不过，其实很多人都在使用 Foobar2000 进行抓轨了来着。

![EAC LOGO](http://cdn.07212121.xyz/2026/05/77bb11f7f045f43fa4bc6e7a44cc163f.Exact-Audio-Copy-Icon.webp)

我们也必须以理性的角度看待无损。无损的价值首先是保存，绝不代表“听起来一定 TM 秒杀 MP3，所以 MP3 就是纯纯的垃圾，狗都不用”。在透明码率下，优秀的有损编码对大多数人和大多数音乐已经很难盲听区分。无损真正不可替代的地方在于，它保留了完整数据，适合长期归档、二次转码、编辑处理和避免有损文件反复转码导致质量的逐代下降。而无损文件则可以作为母版，需要什么格式再从它生成，平时也可以收藏。对于音乐收藏者来说，这就是 FLAC 的最大意义。

---

## 4.3 豆包，帮我整理我的音乐库

当音乐文件只有几十首时，文件名就是管理方式。但当收藏变成几千首、几万首之后，文件名就不够用了。你需要知道一首歌属于哪张专辑，曲目编号是多少，封面是什么，歌手名是否统一。想要真正创建一个音乐库，一定要重视标签管理。

标签，也就是元数据。它描述着声音的信息。播放器靠标签显示歌名、歌手、专辑、年份、流派、封面、歌词和曲目顺序。资料库软件靠标签建立索引、排序、筛选和智能播放列表。没有标签，音乐文件就是一堆无主音频；有了标签，音乐文件才组成了可以浏览、搜索和维护的收藏体系。本地音乐管理麻烦，很大一部分原因都来自标签。

不同格式使用不同标签体系。MP3 最常见的是 ID3。FLAC 通常使用 Vorbis Comment。APE 使用 APEv2。M4A、ALAC、AAC 常在 MP4 容器里保存元数据。WAV 也可以写标签，但历史上支持不统一。

先说 MP3 的 ID3。ID3v1 非常简单，写在文件末尾，字段长度固定，字符编码粗糙，适合英文，遇到中文就容易出问题。ID3v2 复杂得多，标签写在文件开头，支持更多字段、更长文本、封面、歌词。但 ID3v2 又有多个版本，不同软件支持程度并不一致。一个播放器写入 ID3v2.4 UTF-8，另一个老播放器只认 ID3v2.3 或本地代码页，就可能显示异常。有些软件会同时写 ID3v1 和 ID3v2，但两边内容不一致，播放器读取优先级不同，显示结果也不同。这也许就能解释为什么有时候 MP3 的标签这么烦。

FLAC 的标签体系通常更清爽。FLAC 使用 Vorbis Comment，字段是键值对形式，比如 `TITLE=晴天`、`ARTIST=周杰伦`。这种方式比 ID3 更灵活，也天然更适合 UTF-8。封面则通常写在 FLAC 文件的 picture block 中。正因为 FLAC 标签开放、清楚、跨平台支持好，它非常适合长期收藏。

APE 标签在 Foobar2000 等软件里支持很好，但 APE 文件本身的生态不如 FLAC 统一，历史资源又常常混用 CUE、外置封面、非 Unicode 编码文本，因此整理起来比 FLAC 麻烦得多。M4A / ALAC 的标签则跟 MP4 容器有关，如果使用非苹果播放器，某些扩展字段可能会出现映射差异。

标签字段本身也有很多讲究。`ARTIST` 通常表示曲目艺人，`ALBUMARTIST` 表示专辑艺人，用来解决合辑的归类问题。没有 `ALBUMARTIST` 时，资料库软件可能会把一张合辑拆成几十个歌手专辑。`COMPOSER` 对古典音乐非常重要，流行音乐用户通常按歌手找歌，古典音乐用户则常常按作曲家找作品。`DISCNUMBER` 用来标记多碟专辑，避免不同碟的相同曲目号混在一起。`DATE` 或 `YEAR` 也有争议，到底应该写原始发行年份，还是当前重制版发行年份？认真收藏的人往往会同时保存原始年份和发行版本信息。

可以把标签管理的关系简单表示为

```mermaid
graph TD
    A["音频文件<br/>MP3 / FLAC / APE / M4A"] --> B["标签体系"]
    B --> C["基础字段<br/>标题 / 艺人 / 专辑 / 年份"]
    B --> D["排序字段<br/>曲目号 / 碟号 / 专辑艺人"]
    B --> E["扩展字段<br/>作曲家 / 指挥 / 版本 / 条码"]
    B --> F["封面<br/>内嵌图片 / 外置 folder.jpg"]
    B --> G["歌词<br/>内嵌歌词 / 外置 LRC"]

C --> H["播放器显示"]
    D --> I["资料库排序"]
    E --> J["高级检索"]
    F --> K["专辑封面视图"]
    G --> L["同步歌词显示"]
```

中文用户遇到的最大麻烦，是编码。

为什么中文编码如此麻烦呢？早期英文环境主要使用 ASCII 或 ISO-8859 系列编码，一个字符通常占用 1 个字节。中文字符数量远超英文，必须使用更大的编码空间。大陆常用 GB2312、GBK、GB18030，台湾和香港常见 Big5，日本有 Shift-JIS，后来 UTF-8 和 UTF-16 才逐渐成为更统一的解决方案。很多 MP3 文件来自不同地区、不同软件、不同年代，标签写法混杂在一起。播放器如果只是机械读取字节，就很容易把简体中文当成繁体编码，把日文当成中文编码，或者把 UTF-8 当成本地代码页，于是屏幕上就出现各种乱码。

千千静听当年之所以让中文用户觉得舒服，很大一部分原因就在这里。它把复杂编码识别、简繁转换、日文汉字误判修正尽量做在后台。Foobar2000 则提供了另一种路线，它允许用户更精确地转换标签编码、重写标签和批量处理。

MusicBee 的价值则体现在资料库层面，它可以批量编辑标签、从在线数据库补全信息、按规则重命名文件、查找缺失封面和重复项目。

除了标签，封面也是本地音乐收藏的重要组成部分。封面也有内嵌封面和外置封面这两种常见保存方式。内嵌方便跟随文件，但会浪费空间；外置节省空间，但文件单独拷走时封面可能丢失。封面尺寸也需要平衡美观、体积和兼容性。

歌词则是中文音乐软件的重要传统。千千静听把自动搜索、下载、匹配 LRC 做成默认体验之后，很多中国用户形成了“听歌就应该有同步歌词”的习惯。LRC 简单、开放、容易编辑，因此传播极广。歌词匹配依赖文件名、歌手、标题、时长和在线数据库，匹配错歌词是很常见的问题。歌词还有版权问题，早年很多歌词服务器处在灰色地带，后来流媒体平台兴起，歌词逐渐成为平台内容资产的一部分，开放歌词库反而不如早年自由。很多老用户怀念千千静听，也是在怀念那个歌词资源随手可得的时代。

标签整理的最终目标，是让文件系统和资料库互相不打架。有些用户完全依赖播放器资料库，不在意硬盘目录；另一些用户非常重视文件夹结构，希望即使换播放器、换系统，目录本身仍然清楚。典型结构可能是按 `流派/艺人/年份 专辑/音轨号 标题` 组织。这种结构有一个好处，你脱离任何播放器也能看懂。MusicBee、Foobar2000、Mp3tag 等工具都能按标签批量重命名文件。很多认真整理音乐库的人，即使用 Foobar2000 或 MusicBee 播放，也会专门用 Mp3tag 做标签清洗。

标签、封面、歌词、目录结构这些外部数据，看起来都不是“播放”本身，却决定了本地收藏能不能长期存在。如果标签混乱，搜索会失败；封面缺失，专辑视图会破碎；编码不统一，换播放器就乱码。收藏越大，这些问题越明显。几十首歌可以靠记忆，几万首歌只能靠秩序。这也是为什么本地播放器后来分化出了不同的方向。看来，“能不能被长期管理”对于本地音乐也很重要。

---

# 五、愿你手拥自由

让我惊讶的是，Winamp、Foobar2000、千千静听、AIMP、MusicBee，这些出名的音乐播放器，一开始全都来自小团队或个人开发者。Justin Frankel 写 Winamp 时十九岁，刚从大学退学。郑南岭写千千静听时几乎是一个人包揽全部代码。AIMP 的开发者是自学代码，一步一步的搭建起这个兼顾美观与性能的播放器的。Steven Mayall 写 MusicBee 也是因为自己的几万首歌实在管不过来，市面上没有工具能满足他，于是他自学 VB.NET 自己动手。

AOL 收购 Winamp 之后，就开始往里面塞加密音乐服务，随着用户的反感迅速失败。后来又决定用 Wasabi 框架重写整个播放器，想把 Winamp 做成一个类似浏览器的综合平台，结果插件兼容性崩溃，社区分裂。百度收购千千静听后，安装包开始捆绑推广，弹窗和运营入口层层加码，逐渐失去了原有的轻巧。微软更是把这种摇摆演成了连续剧，WMP 还没真正取代本地播放器，就去推 Zune，Zune 失败后又转向 Xbox Music，再改名 Groove Music，最后 Groove Music Pass 关闭，用户又被引导迁移到 Spotify...用户很难再相信这个不断造轮子又毁轮子的失信公司了。

这些大手子手里的牌远比几个退学生和个人开发者好得多。但做出来的播放器，恰恰缺少了那些小工具身上最珍贵的东西。原因很简单，个人开发者的用户是和自己一样的拥有听歌需求的普通人。你也是听歌的人，你也讨厌弹窗，你也需要标签不乱码，你也希望启动快一点、内存少占一点。也就是说，开发者本人就是软件的受众群体和用户。所以他会去优化播放器的性能，会把软件设计成一个开放的架构，点燃社区的热情。

大公司的用户，在财务报表上是一组数字。活跃度、留存率、付费转化率、广告曝光量。软件只是触达这些数字的手段。当你的绩效考核不看你是否尊重了用户，而看你是否提升了日活，你自然会愿意往播放器里投推荐流、评论区、会员入口、活动弹窗。这些东西和播放没有任何关系，但它们能让数据好看。于是播放器越来越重，启动越来越慢，功能越来越杂，可是用户想做的只是打开一首歌而已。

我承认，大公司无法像个人开发者那样做软件，因为它的生存取决于取决于整个名叫公司的商业机器的运转效率。个人开发者可以花十年维护一个不赚钱的播放器，因为驱动他的不是增长指标，是自己想用、想做好、想被同类认可。所以这二者产生出来的矛盾，注定无法调和。

AI 降低了写代码的门槛，这本身是一件好事。更多人可以把自己的想法变成可运行的软件，这毫无疑问是进步。但门槛降低也带来了另一个问题，当代码可以被快速生成，产品可以被快速搭建，那些需要长时间打磨的东西反而容易被忽略。一个播放器最重要的地方肯定不是它能不能播放，那是基础的东西。更重要的是怎么播放、占多少资源、给用户多少控制权。这些东西不是 AI 能替你决定的。它们需要开发者自己去感受、去取舍、去在无数个微小的决定里坚持属于自己的方向。

Electron 把浏览器内核打包进桌面应用，好处是前端开发者可以用网页技术写桌面程序，代价是一个原本只需要几 MB 的工具，现在可能占用几百 MB 内存，启动时间从一瞬间变成好几秒。对于本地音频播放器这类软件来说，这种交换到底值不值得，每个用户心里都有自己的答案。我大费周折的查阅资料，体验软件来编写这篇文章，其实是更想说，当我们越来越习惯用最重的框架做最轻的任务时，我们还是要对那些曾经被人认真对待过的细节，那些对性能的挑战、对用户边界的尊重、对小体积的坚持充满敬畏。

本地播放的年代已经过去了。今天大多数人听歌靠流媒体，这没什么不好。方便本身就是一种巨大的价值，它让音乐触手可及，让好作品更容易被发现，让听歌这件事变得没有门槛。但当所有的功能都被平台控制，当所有的数据都被锁在云端，当所有的工具都要求你先登录再使用，当所有的播放器都在试图告诉你接下来听这个吧的时候，那个可以自己决定听什么、怎么听、用什么听的自由，就显得格外珍贵。这代表着，没有人能把它下架，没有人能把它变成灰色，没有人能替你做决定。

我相信，在今天这个账号、会员、云同步和算法推荐无处不在的时代，那些关于软件的小小信念依然充满分量。工具应当轻巧，应当专注，应当把控制权交给使用者。个人电脑这个词最本真的含义，就是这台机器上的一切，最终自由权应该在你手里。我们只要打开播放器，找到那一首歌，点击播放。

于是音乐就此开始。

[hplayer]
[Music server="netease" id="30612256" type="song"/]
[/hplayer]

---

第一次写这种比较长的文章，如有不足请多担待。你有没有细心的看到这里呢？嘿嘿，无论如何，我后续都会分软件进行详细的入门和插件二次元皮肤推荐，也就是上文提到的 AIMP、Foobar2000、Winamp、千千静听这四款拥有众多爱好者的本地播放软件。除此之外，我也打算攒写本地视频播放史。敬请期待喵~

# 前言

---

# 一、从这一刻起，历史发生了巨变

## 1.1 是你逼我的

![维基百科上的初代 Pentium MMX](http://cdn.07212121.xyz/2026/05/38d201be39d9e82fd1b833e287aad040.Pentium-mmx1.webp)

## 1.2 WHY MP3?

MP3 之所以重要，是因为它解决了当时最现实的问题，也就是音频文件体积过大的问题。

![这位英俊的老男人就是 Karlheinz Brandenburg](http://cdn.07212121.xyz/2026/05/b34cf1342566ab32864cfadd1fdd39e7.Karlheinz-Brandenburg.webp)

1991 年瑞典斯德哥尔摩的 ISO-MPEG 听证会上，两大方案几乎打成平手。那怎么办呢？最终委员会就达成了一个方案，将 MPEG-1 音频拆分为了三个层：

### 早期音频格式一览

从这一刻起，历史发生了巨变。

## 1.3 曲线救国

![LAME 的 LOGO](http://cdn.07212121.xyz/2026/05/f31c99482afbe12ffe621be395901b85.Lamelogo.webp)

后来，LAME 编码器也被一些开源软件使用。

---

# 二、音乐播放器的百家争鸣

## 2.1 老霸道了 —— Winamp

[album type="photos"]

![维基百科上的 Justin Frankel 图片](http://cdn.07212121.xyz/2026/05/905a0c0b24086ad7be8708bd06357598.Justin_Frankel.webp)

![你现在还可以在 https://www.askjf.com 询问这位大佬问题](http://cdn.07212121.xyz/2026/05/bf87668682181f061aff50ba32e38466.AskFrankel.webp)
[/album] </div>

[album type="photos"]

![Winamp 0.2a](http://cdn.07212121.xyz/2026/05/451ce9265947ffbcdae3d4c0ef921f5c.Winamp_0.2a.webp)

![Winamp 0.92](http://cdn.07212121.xyz/2026/05/7cd09aac46fbdbae7cbb8d96df9ddf28.WinAMP_0.92.webp)

![Winamp 1.006](http://cdn.07212121.xyz/2026/05/c4ec4fe4d6611211c6eb07239bb8660c.Winamp1.006.webp)
[/album] </div>

[album type="photos"]

![Winamp 2.0](http://cdn.07212121.xyz/2026/05/33f33638428bd7591591f2f78338b1dc.Winamp2.webp)

![Winamp 3.0](http://cdn.07212121.xyz/2026/05/4d780b81a7ee9c7c99f65b188ca57125.Winamp3.webp)

![Winamp 5.0](http://cdn.07212121.xyz/2026/05/04cb97574412f3ccbc62283186c8fe0d.Winamp5.webp)
[/album] </div>

[album type="photos"]

![Winamp 5.5 现代皮肤](http://cdn.07212121.xyz/2026/05/ba4379a780c11e7da2bb2c6420a97f09.Winamp_5.5.webp)

![Winamp 5.666](http://cdn.07212121.xyz/2026/05/d812a45d0db975ab0702e1b58a8830e7.Winamp_5.666_media_player.webp)

![Winamp 5.9.2](http://cdn.07212121.xyz/2026/05/2ec51e8b98fe37e8da34eeae70cd2008.WinAmp_5.9.2,_Windows_10.webp)
[/album] </div>

Winamp 的插件结构可以概括为

C --> G["可视化插件<br/>AVS / MilkDrop"]
    C --> H["皮肤系统<br/>.wsz 经典皮肤"]
```

![Winamp 皮肤之多以至于让我们可以进行长时间的探索...](http://cdn.07212121.xyz/2026/05/92bede3e9809ce3658d6d2913e333d6f.Winamp_Skin.webp)

![Milkdrop 示意图](http://cdn.07212121.xyz/2026/05/046184e7f3c70884f06e6d157cd816b6.Milkdrop_Spikeball.webp)

一个原本以轻量、高效、可扩展著称的软件，就这样在商业化和平台化压力下逐渐变重。

Winamp 留下的影响远远超过播放器本身。插件系统、皮肤文化、可视化社区、轻量桌面工具的审美，都成为后来许多音频软件绕不开的参照。

---

## 2.2 反对花哨 —— Foobar2000

Winamp3 的失败，给另一类播放器留下了空间。

[album type="photos"]

![一位国外用户的早期 Foobar2000 0.95 界面](http://cdn.07212121.xyz/2026/05/3382c44b877cc89d81535109d37f904f.fb2k_095b1.webp)

![我自用的加了插件的 Foobar2000 2.25.8 界面](http://cdn.07212121.xyz/2026/05/f9bd13b7778e23eb8469fa3c6164fbb2.Foobar2000_myself.webp)
[/album] </div>

Foobar2000 的架构可以这样理解

E --> F["DirectSound / WASAPI 共享"]
    E --> G["ASIO"]
    E --> H["Kernel Streaming"]
    E --> I["WASAPI Exclusive"]

C --> J["第三方组件 SDK<br/>界面 / 标签 / 转换 / 工具扩展"]
    C --> K["极简界面与自定义布局"]
```

![什么时候高音甜 中音准 低音劲？](http://cdn.07212121.xyz/2026/05/573b59b8568bc74a45224aebfedf5dcc.laoshao.webp)

---

## 2.3 中国人民更爱用 —— 千千静听

2000 年代初，中国桌面软件市场快速发展。宽带开始普及，本地 MP3 收藏越来越常见。但国外播放器对中文用户并不友好。

[album type="photos"]

![千千静听其中一个版本的默认皮肤](http://cdn.07212121.xyz/2026/05/0c7b1a1309b5845d152bf9623b505de9.TTplayer_myself.webp)
![向前辈 Winamp 致敬！](http://cdn.07212121.xyz/2026/05/a6c1ad55037127e6f86e66bfb7e0f4ec.ttplayer_winamp.webp)

![果宝机甲 解体！](http://cdn.07212121.xyz/2026/05/da111292e7e8df935067a3dd3bb4f30a.TTplayer_vs_Winamp.webp)
[/album] </div>

千千静听的功能关系可以这样表示

B --> I["全局热键<br/>后台 / 游戏中控制播放"]
    B --> J["迷你模式<br/>桌面常驻小窗口"]
    H --> K["简繁转换<br/>提高歌词可读性"]
```

![我搜集到的一款天天静听二次元皮肤展示图](http://cdn.07212121.xyz/2026/05/cd1efc5736163dd727a7ed1dd26beea8.机神飞翔之阿娜扎布拉德.webp)

## 2.4 善打太极 —— AIMP

到 2000 年代中期，Windows 本地播放器市场已经出现了很明显的分化。

[album type="photos"]

![作者早期的A.I.M.P.（注意不是AIMP）v1](http://cdn.07212121.xyz/2026/05/3e8a0c470b8d9bb5e66980996f37e5ad.A.I.M.P._v1.webp)

![A.I.M.P. v2](http://cdn.07212121.xyz/2026/05/c35db6baeee6ebdea03b194293e05459.A.I.M.P._v2.webp)

![A.I.M.P. v3](http://cdn.07212121.xyz/2026/05/459da8502b1ce54e28f4a522f5b1e7f4.A.I.M.P._v3.webp)
[/album] </div>

[album type="photos"]

![A.I.M.P. v4](http://cdn.07212121.xyz/2026/05/ae9d4fca67aaded78706805c77679c4f.A.I.M.P._v4.webp)

![A.I.M.P. v5](http://cdn.07212121.xyz/2026/05/b5890536094e84b006916a8170c7f5a9.A.I.M.P._v5.webp)
[/album] </div>

[album type="photos"]

![AIMP 最新正式版本 v5.40.2716 默认样式一](http://cdn.07212121.xyz/2026/05/005e0f322b8b004ba71a6aaa600ab4bd.AIMP_1.webp)

![样式二](http://cdn.07212121.xyz/2026/05/9d9b4694597449574301f1789c63f792.AIMP_2.webp)

![样式三](http://cdn.07212121.xyz/2026/05/b10fab3f36a494571b609a819bfb7b29.AIMP_3.webp)
[/album] </div>

AIMP 的工作流程大致可以这样理解：

F --> G["DirectSound"]
    F --> H["ASIO"]
    F --> I["WASAPI / WASAPI Exclusive"]

B --> J["标签编辑器<br/>批量修改元数据"]
    B --> K["ACS 皮肤引擎<br/>拟物界面 / 复古面板"]
```

![AIMP 官网的一些皮肤展示](http://cdn.07212121.xyz/2026/05/391bd42d965ca31bbf0e9277027c17f9.AIMP_Skins.webp)

---

## 2.5 仓鼠还想继续做仓鼠 —— MusicBee

MusicBee 就是这一阶段的代表。

![俺用的 MusicBee 界面](http://cdn.07212121.xyz/2026/05/cbd16836f2bb2908b82be1917ea1af6b.musicbee.webp)

MusicBee 的工作方式可以概括为

C --> G["播放模块<br/>BASS 音频引擎"]
    G --> H["ASIO / WASAPI / DirectSound 输出"]

C --> I["自动文件整理<br/>按标签重命名和移动"]
    C --> J["设备同步<br/>Android / 便携播放器"]
    J --> K["实时转码<br/>同步时转换格式"]
```

---

# 三、大手的抉择

## 3.1 最普及最稀烂

![运行在我的 Windows 10 上的 WMP 12](http://cdn.07212121.xyz/2026/05/1f3b01a84bf3dd0f055501af1b7197c8.WMP.webp)

![维基百科上的 Zune 播放器](http://cdn.07212121.xyz/2026/05/239a322979d4b7c4d37008cb8fef6008.Zune80and4.webp)

关于 UWP，我本人也有些许怨言。可能后面会出一篇文章讲一讲。

![Groove Music 界面](http://cdn.07212121.xyz/2026/05/1a9dcb682ca970768b9e01d23fae47c6.Groove_Music.webp)

![新版 Media Player](http://cdn.07212121.xyz/2026/05/dfa07d43b62ca122366b89bc7d4a0e39.media-player-3.webp)

微软官方播放器路线可以简单表示为：

```mermaid
graph TD
    A["微软官方音乐路线"] --> B["Windows Media Player"]
    B --> C["WMA / DRM / CD 抓轨 / 媒体库 / 设备同步"]

A --> D["PlaysForSure"]
    D --> E["第三方设备和在线商店联盟"]

A --> F["Zune"]
    F --> G["Zune Software / Zune Marketplace / Zune Pass"]

A --> H["Xbox Music"]
    H --> I["Groove Music"]

I --> J["Groove Music Pass 关闭"]
    J --> K["Windows 11 Media Player"]

B --> L["经典 WMP 作为遗留组件保留"]
```

...嗯？为什么我要说“又”？

---

## 3.2 手机就是苹果

苹果的 iTunes 不是传统意义上那种轻量播放器，它也想用资料库、商店、设备和账号，把音乐管理变成一个完整生态。

什么？WMP 不也是这样的吗？噢，它是抄的来着。

![早期 iTunes 界面](http://cdn.07212121.xyz/2026/05/2d55ff9995ea0c3008e92cdf264daf4b.iTunes.webp)

iTunes 的资料库结构可以这样理解

B --> G["iPod / iPhone / iPad 同步"]
    G --> H["设备端浏览<br/>歌曲 / 专辑 / 艺人 / 流派"]

B --> I["账号与商店"]
    I --> J["购买 / 下载 / 授权"]
```

---

# 四、深入技术腹地

## 4.1 音频输出链路超进化

可以把 Windows 音频输出路线简化成下面这样

```mermaid
graph TD
    A["播放器解码<br/>MP3 / FLAC / AAC -> PCM"] --> B{"输出接口选择"}

C --> I["Windows 音频系统 / 声卡驱动"]
    D --> I
    E --> J["声卡 / DAC"]
    F --> J
    G --> I
    H --> J
    I --> J
    J --> K["耳机 / 音箱"]
```

---

## 4.2 无损格式 登场

![FLAC LOGO](http://cdn.07212121.xyz/2026/05/f4a93123cf1b06441220b59622a9a7f7.FLAC_logo.webp)

FLAC 的基本流程可以这样理解

F --> G["解码"]
    G --> H["还原 PCM<br/>与原始数据一致"]
```

不过，其实很多人都在使用 Foobar2000 进行抓轨了来着。

![EAC LOGO](http://cdn.07212121.xyz/2026/05/77bb11f7f045f43fa4bc6e7a44cc163f.Exact-Audio-Copy-Icon.webp)

---

## 4.3 豆包，帮我整理我的音乐库

可以把标签管理的关系简单表示为

C --> H["播放器显示"]
    D --> I["资料库排序"]
    E --> J["高级检索"]
    F --> K["专辑封面视图"]
    G --> L["同步歌词显示"]
```

中文用户遇到的最大麻烦，是编码。

MusicBee 的价值则体现在资料库层面，它可以批量编辑标签、从在线数据库补全信息、按规则重命名文件、查找缺失封面和重复项目。

---

# 五、愿你手拥自由

于是音乐就此开始。

---

最后修改：2026 年 05 月 29 日

我很穷请给我钱喵我很穷请给我钱喵我很穷请给我钱喵~

5 条评论

Anon Microsoft Edge 148.0.0.0 Windows 10 中国山西太原联通 CN AS
June 1st, 2026 at 05:48 pm

+0.09

回复
妄恶挽歌 Microsoft Edge 148.0.0.0 Windows 10 中国山东青岛移动 CN AS
May 29th, 2026 at 08:56 am

这是论文？

回复
1. BaoZi_Fly Google Chrome 114.0.5735.196 Android 12 中国湖北武汉联通 CN AS 1
  May 29th, 2026 at 01:22 pm
  
  @妄恶挽歌
  
  不是～
  
  回复
H_E_I Microsoft Edge 148.0.0.0 Windows 10 中国四川资阳电信 CN AS 1
May 29th, 2026 at 02:36 am

也许我也该去整个本地音乐播放器，然后再把软件的歌单都整出来，毕竟边玩游戏边听音乐还是很不错的 ╭( ･ㅂ･)و ̑̑

回复
1. BaoZi_Fly Firefox 140.0 Windows 10 中国湖北武汉联通 CN AS
  May 29th, 2026 at 02:38 am
  
  @H_E_I
  
  支持你的决定噢~
  
  回复