前言

木子特别怀念互联网初期听音乐的自由。近年来，随着国内版权意识的提高，音乐版权越来越分散，想要听到自己喜欢的歌曲，往往需要在多个应用间进行切换，包括：网易云音乐、QQ 音乐、咪咕音乐等，并且需要订阅多家流媒体服务。这种频繁切换不仅麻烦，而且即使购买了某些 APP 的 VIP 服务，下载的歌曲仍然是加密的，VIP 到期后某些歌曲依然不能播放，非常让人困扰。此外，国内主流音乐流媒体加入了许多与音乐无关的功能，并利用算法强制拉伸音频，从而诱导用户购买更高价的订阅服务，极少有平台真正关注听歌用户的体验。

当然不仅仅是这些问题，包括很多音乐并不是根据自己的个人听歌意愿进行分类的，比如：很多 80 后的同学喜欢听经典老歌，虽然一些 APP 也会分类经典老歌系列，但很多并不是个人想听的，造成被迫去听，这就不爽了。所以为了实现听歌自由，构建一个自己的音乐流媒体服务成了必须。

无损音乐

构建个人音乐流媒体最重要的一点就是歌曲本身的质量，提到质量就不得不提无损音乐，在非数据音乐时代，购买光盘可能是获取音乐的最佳途径。无损音乐格式有多种，每种格式都有其独特的特性和用途。以下是几种主要的无损音乐格式及其区别：

1. FLAC (Free Lossless Audio Codec):

   • 特点: 开源且常用的无损编码格式。
   • 优点: 支持多种设备和操作系统，压缩比相对较高，文件体积较小但音质不受损。
   • 缺点: 不被所有的便携设备和播放器原生支持，但支持范围逐步扩大。

2. ALAC (Apple Lossless Audio Codec):

   • 特点: 苹果公司开发的无损音频格式。
   • 优点: 与苹果的生态系统（如 iTunes 和 iOS 设备）完全兼容，确保高品质音频。
   • 缺点: 比 FLAC 稍大的文件体积，原生支持限于苹果生态。

3. WAV (Waveform Audio File Format):

   • 特点: 最早的音频格式之一，常见于 Windows 系统中。
   • 优点: 无压缩格式，音质保真度高，广泛支持。
   • 缺点: 文件体积大，不具备任何压缩，存储成本较高。

4. AIFF (Audio Interchange File Format):

   • 特点: 类似于 WAV，但更多用于苹果系统。
   • 优点: 无压缩格式，音质保真度高，与 macOS 系统高兼容。
   • 缺点: 文件体积大，不具备任何压缩，重放设备较少，但较 WAV 稍微灵活。

5. APE (Monkey’s Audio):

   • 特点: 独特的高压缩比无损格式。
   • 优点: 压缩效率相对较高，文件体积比 FLAC 还要小。
   • 缺点: 编码/解码速度较慢，兼容性不如 FLAC 和 ALAC。

6. WMA Lossless (Windows Media Audio Lossless):

   • 特点: 微软开发的无损音频格式。
   • 优点: 与 Windows 系统完美兼容，文件体积小。
   • 缺点: 在 macOS 和 Linux 系统中的原生支持差，使用人群有限。

它们的主要区别主要集中在以下几个方面：

• 文件压缩比: APE > FLAC > ALAC > WMA Lossless
• 兼容性: WAV、FLAC、ALAC（苹果设备）、WMA Lossless（Windows 设备）
• 文件体积: WAV 和 AIFF 未压缩，文件最大；FLAC 和 ALAC 中等；APE 和 WMA Lossless 较小。

当然除了以上说到的这些格式外，还有像 AC-3、Dolby TrueHD、DTS-HD Master Audio 等格式。选择哪种格式取决于具体的使用情景和需求，例如：存储空间、设备兼容性和音质要求。对于日常使用和广泛设备兼容，FLAC 和 ALAC 是较好的选择。

木子建议条件允许情况下选择 WAV 未压缩文件，不管是采样率还是比特率都是最高的（比特率 1411Kbps CD 音质），其次 FLAC 比特率一般在 800 – 1000 Kbps，最后 APE 比特率 44 Kbps。

音频文件专用比特率计算公式：【比特率】（Kbps）=【量化采样点】（kHZ） ×【位深】（bit/采样点）×【声道数量】（一般为2）

举例：

一个采样率为 44.1 kHZ，采样大小为 16 bit，双声道的 PCM 编码的 WAV 文件，比特率 = 44.1K x 16 × 2 = 1411.2 Kbps。如下图所示：

常见的 Audio CD 一般都采用 PCM 编码，一张光盘的容量只能容纳 72 分钟的音乐信息，而常见的 wav 歌曲大部分是 PCM 格式的。

比特率

比特率（Bitrate）是指音频数据每秒传输的比特数，以 kbps（kilobits per second）为单位。比特率直接影响音频文件的质量和大小：比特率越高，音频质量越好，但相应文件大小也越大；比特率越低，音频质量越差，但文件大小较小。以下是常见比特率的比较，以及它们之间的主要区别：

低比特率 (32 kbps, 48 kbps, 64 kbps)

• 32 kbps:
  • 音质: 非常低。通常会有明显的压缩伪影、低频和高频的细节损失。
  • 适用场景: 通常用于语音通信（如电话、在线会议系统），音质要求不高但需要极高的压缩率。
• 48 kbps:
  • 音质: 略好于 32 kbps，但仍然适用于低质量音频，如 AM 广播或语音录音。
  • 适用场景: 语音邮件、流媒体低带宽使用、某些播客和在线广播。
• 64 kbps:
  • 音质: 较低；音乐细节丢失明显，但比纯语音内容更好一些。
  • 适用场景: 低带宽情况下可以使用，如某些低质量流媒体服务或广播。

中比特率 (96 kbps, 128 kbps, 192 kbps)

• 96 kbps:

  • 音质: 相对较低，但比 64 kbps 有显著改善；适合语音和低质量音乐。
  • 适用场景: 网络流媒体、部分网络广播和带宽有限的情况。

• 128 kbps:

  • 音质: 被认为是较为普遍接受的音质水平。有一定的压缩伪影，但许多普通听众可以接受。
  • 适用场景: 网络电台、流媒体服务和随身听设备。在有限存储空间条件下，普遍使用。

• 192 kbps:

  • 音质: 比 128 kbps 更接近 CD 质量音频，可以更好地保留高频和低频细节。
  • 适用场景: 更高质量的流媒体服务、在线音乐平台和本地音乐存储。

高比特率 (256 kbps, 320 kbps)

• 256 kbps:

  • 音质: 高质量，接近于 CD 质量，大多数人难以分辨高清音频的微小差别。
  • 适用场景: 高音质需求的流媒体服务、购买和下载的高质音乐（比如 iTunes 中的 AAC 格式）。

• 320 kbps:

  • 音质: 非常高质量，为常见有损音频格式的最高比特率，几乎不能区别于 CD 质量。
  • 适用场景: 高保真音乐播放、音频发烧友、近乎 CD 质量的在线音乐服务（如 Spotify 高质量流媒体）。

选择比特率的考虑因素

1. 音质需求:

   • 如果对音质有高要求：选择高比特率（如 256 kbps、320 kbps），或无损格式。
   • 对音质要求一般：选择中比特率（如 128 kbps、192 kbps）。
   • 对音质要求低：可以选择低比特率（如 32 kbps、64 kbps）。

2. 存储空间:

   • 存储空间有限时：选择低或中比特率（如 64 kbps、128 kbps）。
   • 存储空间充足时：可以选择更高比特率（如 256 kbps、320 kbps）或无损格式。

3. 传输带宽:

   • 网络带宽有限时：低比特率（如 48 kbps、96 kbps）便于传输。
   • 网络带宽宽裕时：可以选择高比特率（如 192 kbps 及更高）以提高音频质量。

4. 收听环境:

   • 在嘈杂环境中：低比特率可能已经足够，因为环境噪音掩盖了细节。
   • 在安静的高保真环境中：高比特率和无损格式能够提供最佳听觉体验。

总结来说，比特率的选择应根据具体使用场景、存储和传输条件、以及音质要求来平衡。如果需要高音质体验，建议选择高比特率或无损格式，而在存储和带宽有限的情况下，可以考虑中低比特率。

在现在的网络环境下，不管是 4G、5G、WIFI 下，都可以无脑选择最高比特率以及无损播放。局域网有线环境就更不用说了。

声道

在音乐和音频内容中，不同的声道布局提供了不同的听觉体验，适用于各种场景和需求。以下是几种常见的声道配置及其特点和适用场景：

单声道（1.0）

• 特点: 只有一个音频通道，所有声音信息集中在这一通道上。
• 适用场景:
  • 电话通信、对讲机。
  • 早期的广播和录音。
  • 对声道分离要求不高的场合，如某些讲座和历史音频记录。
• 音效体验: 没有立体声效果，所有声音从同一位置发出。

立体声（2.0）

• 特点: 有两个独立的音频通道，分别对应左声道和右声道。
• 适用场景:
  • 大多数音乐录音和播放。
  • 电影和电视的基础音频。
  • 日常的音乐欣赏，包括耳机和家庭立体声系统。
• 音效体验: 提供空间感和简单的方向感，通常用于录制和播放标准的音乐和影视内容。

2.1 声道

• 特点: 在 2.0 的基础上增加了一个独立的低频声道（低音炮）。
• 适用场景:
  • 用于增强低音效果的音乐和电影播放。
  • 家庭音响系统，用于更好的低音表现。
• 音效体验: 提供更丰富的低音频段的表现，增强整体音频的深度和震撼感。

环绕声（5.1）

• 特点: 包含五个全频带声道（左前、中央、右前、左后、右后）和一个低频声道（低音炮）。
• 适用场景:
  • 电影和电视的家庭影院系统。
  • 游戏音频系统。
  • 音乐会和演唱会的 DVD 和蓝光音频。
• 音效体验: 提供环绕声场，增强沉浸感和空间感，适合影音娱乐和动态音频效果的环境。

7.1 声道

• 特点: 包含七个全频带声道（左前、中央、右前、左侧、右侧、左后、右后）和一个低频声道（低音炮）。
• 适用场景:
  • 高端家庭影院系统。
  • 高清电影和蓝光光碟。
  • 高端影音系统的游戏音频和专业音频工程。
• 音效体验: 提供更精确的定位和更丰富的环绕声效果，适合追求高级沉浸体验的用户。

杜比全景声（Dolby Atmos）和 DTS:X

• 特点: 基于对象的音频格式，可以动态调整声道并添加天花板扬声器，支持更大的自由度和立体感。
• 适用场景:
  • 高级家庭影院和公共电影院。
  • 特别制作的 3D 音频内容。
  • 现代高清电影、流媒体和游戏音频。
• 音效体验: 提供三维立体音效，声音可以从不同高度和角度传来，极大提升了现场感和沉浸感。

9.1 和 11.1 声道

• 特点: 分别包含九个或十一声道，进一步增加侧向和顶部声道。
• 适用场景:
  • 专业影院、高端家庭影院系统。
  • 用于展示复杂音频工程的专业空间和演出。
• 音效体验: 提供极致的环绕和三维音效体验，多声道布局能展现最细腻的声音定位效果。

每种声道配置都有其独特的特点和适用场景，从简单的单声道和立体声配置，到复杂的多声道和三维音效系统。选择适当的声道配置取决于具体的听觉需求、设备配置以及内容类型：

• 音乐: 通常使用 2.0、2.1 声道。
• 电影和电视: 常用 5.1 或 7.1 声道，要求高的使用杜比全景声（Dolby Atmos）或 DTS:X。
• 游戏: 同样多采用 5.1 或 7.1 声道配置，追求沉浸体验的使用三维音效系统。

根据个人喜好和使用情景，可以选择适合的声道配置来获得最佳的听觉体验。

关于发烧音乐的玄学，不仅仅只是这些，还包括：线材、场地、距离、方位等等，记得前段时间 360 董事长周鸿祎还请台湾音乐爱乐协会理事长蔡克信去家中摆位，有兴趣的同学可以去哔哩哔哩查看相关视频：蔡克信-哔哩哔哩_bilibili。木子这种木耳就不班门弄斧，听个响还过得去就行了。

最终方案

普通人实现所谓的音乐自由，就只有靠自己手搓了。目前实现听歌自由最重要的一点就是歌曲的下载，现在想下载一个歌曲可不是 2000 年那个时代了，随便可以下载，您需要有各种姿势来实现。下载歌曲只是第一步，管理音乐才是最难的。一般构建自己的音乐库包括以下几步：

1. 下载歌曲（无损音乐： APE、FLAC、WAV、DTS 等）
2. 整理歌曲元数据（标题、文件名、歌手、专辑、风格、年份、歌词、专辑封面、光盘编号、音轨号、总音轨数、总光盘数等等，最消耗时间部分）
3. 下载歌词
4. 下载专辑封面（自制专辑封面）
5. 选择合适播放器
6. 合适的听歌场地、功放音箱或耳机（存在玄学，木子木耳😂）

歌曲下载：可以使用 LX Music + 音源，音源大家自行搜索下载，木子这里就不推荐了（据说作者被请去喝了几次茶，现在软件内已经不自带音源了）。
音乐流媒体服务器：推荐使用 GitHub – navidrome/navidrome: 🎧☁️ Your Personal Streaming Service。
元数据刮削：推荐使用 GitHub – xhongc/music-tag-web，相关教程： 项目介绍 | Music Tag Web 或 项目介绍 | Music Tag Web V2。
音乐播放器：推荐使用 GitHub – gitbobobo/StreamMusic: 支持 Android、iOS、macOS、Windows 平台的 Subsonic/Navidrome/Jellyfin/Emby/AudioStation 客户端。。
歌词 API 服务：推荐使用 GitHub – HisAtri/LrcApi，它可以很好的与 StreamMusic 自定义 API 关联，实现歌词文件单独，而不放在歌曲本身的元数据中。

所以木子现在的软件方案是：Navidrome + Music-Tag-Web + StreamMusic + LrcApi 组合，实现车机、手机、电脑、电视四端的听歌自由。
不管是 Windows 用户还是 macOS 用户，如果您使用本地音乐播放器，木子都强烈推荐：Foobar 2000，如果是 macOS 用户可以结合 LyricsX 歌词加载，实现听歌自由。
Android 端推荐使用 Poweramp 或 Foobar 2000

这套方案也并不是完美无缺的，存在以下问题：

1. 虽然 Navidrome 可以读取同一路径下的封面，但无法读取歌词文件 .lrc，对应的音乐流播放器几乎都不支持显示 .lrc 歌词，必须修改歌曲原文件（比如：.ape、.wav、.flac 等格式文件），将对应的歌词、音乐封面等元数据写入歌曲原文件一起。

2. 音流播放器支持外挂歌词 API，所以可以使用 LrcAPI + 音流结合来实现歌词外挂。

3. 木子会用 Music Tag Web 手动刮削一次标题、艺术家、专辑、年份、歌词、专辑封面，并选择将对应的“导出 lrc”，这样歌词会以歌曲文件名单独存储一份文件，比如：快乐老家.ape 对应歌词文件为 快乐老家.lrc

4. 一个专辑里面有不同的歌手，专辑不会合并，它会将不同的专辑拆解到不同的歌手，这个很不符合听歌者的需求。解决方法：自己创建一个歌单，再将对应专辑的歌曲添加至对应歌单。

5. 很多的音乐流播放器都不支持基于文件夹显示歌曲列表，音流 VIP 支持此功能。

Navidrome

Navidrome 是一款基于 Web 的开源音乐收藏服务器和流媒体播放器。它让您可以自由地从任何浏览器或移动设备收听您的音乐收藏。它就像您的个人 Spotify。采用 Go 语言开发，内存占用很低，界面简单，而且还兼容 Subsonic API。具体特点、部署文档，可以参考官方文档：Documentation | Navidrome

客户端除了可以使用 Navidrome 自带的网页端 Web UI 以外，Navidrome 还兼容所有 Subsonic 客户端，具体参考：Navidrome Overview | Navidrome

部署 Navidrome

因为木子在 NAS 中部署，所以采用 Docker 部署方式，具体参考：Installing with Docker | Navidrome

说明: 基于前期构建的 traefik 网关，详见: DIY NAS系列12 — Traefik 出口网关配置
在 docker-compose.yaml 文件中，会对重要的配置进行说明，因个人网络环境等不同，需要根据自身实际情况调整配置。

❯ cat > docker-compose.yml << \EOF
services:
  navidrome:
    image: deluan/navidrome:latest
    container_name: navidrome
    user: 0:0
    ports:
      - 4533:4533
    restart: unless-stopped
    environment:
      ND_SCANSCHEDULE: 1h
      ND_LOGLEVEL: info  
      ND_SESSIONTIMEOUT: 24h
      ND_BASEURL: "https://music.rockylinux.cn"
      ND_ENABLETRANSCODINGCONFIG: "true"
      ND_TRANSCODINGCACHESIZE: "4000M"
      ND_IMAGECACHESIZE: "1000M"
      ND_DEFAULTLANGUAGE: "zh-Hans"
    volumes:
      - "/Demo/DockerData/navidrome:/data" # navidrome 数据存放目录
      - "/Demo/Music:/music:ro" # 音乐存放目录
    networks:
      - traefik_net
    labels:
      - traefik.enable=true
      - traefik.docker.network=traefik_net
      - traefik.http.routers.navidrome.rule=Host(`music.rockylinux.cn`)
      - traefik.http.routers.navidrome.entryPoints=websecure
      - traefik.http.routers.navidrome.tls.certresolver=myresolver
      - traefik.http.routers.navidrome.service=navidrome
      - traefik.http.services.navidrome.loadbalancer.server.port=4533
networks:
  traefik_net:
    external: true
EOF

# 启用服务
❯ docker compose up -d

# 确保服务启动成功
❯ docker compose ps
NAME        IMAGE                     COMMAND            SERVICE     CREATED        STATUS                  PORTS
navidrome   deluan/navidrome:latest   "/app/navidrome"   navidrome   29 hours ago   Up 29 hours (healthy)   0.0.0.0:4533->4533/tcp, :::4533->4533/tcp

具体参数说明：

• ND_LOGLEVEL：日志级别，默认为 info。
• ND_BASEURL：配置代理后面的 Navidrome 基本 URL，默认为空。
• ND_SESSIONTIMEOUT：Navidrome 在关闭 Web UI 空闲会话之前将等待多长时间，默认 24h。
• ND_ENABLETRANSCODINGCONFIG：在 UI 界面启用转码设置功能，默认 False。之所以要转码，是因为无损音乐文件比较大，所以需要进行转码，便于客户端进行播放。
• ND_IMAGECACHESIZE：图像（艺术作品）缓存的大小。设置为"0"可禁用缓存。默认 100MB。
• ND_TRANSCODINGCACHESIZE：转码缓存的大小。设置为"0"可禁用缓存。默认 100MB。
• ND_DEFAULTLANGUAGE：设置程序默认语言

Navidrome 具有丰富的环境变量可以进行配置，具体参考：Navidrome Configuration Options | Navidrome

初始化配置

打开 https://music.rockylinux.cn 进入登录界面，首先创建登录账号密码，默认首次创建的用户为管理员账号。

设置中文

右上角用户头像 — Personal — Language 选择 简体中文。

Music-Tag-Web

部署 Music-Tag-Web

『音乐标签』Web 版是一款可以编辑歌曲的标题，专辑，艺术家，歌词，封面等信息的音乐标签编辑器程序，支持 FLAC, APE, WAV, AIFF, WV, TTA, MP3, M4A, OGG, MPC, OPUS, WMA, DSF, DFF, MP4等音频格式。
为什么开发 web 版？ 在使用 Navidrome 时，我的音乐都是在远程服务器上的，本地的 Musictag 和 mp3tag 不能满足我的需求，我需要部署在远程服务器上去需改线上的音乐标签，相当于在使用 Navidrome 的边车应用。

作者特别提到为什么开发 Web 版的 Music Tag，是为了配合 Navidrome 来进行音乐元数据刮削。具体功能参考：GitHub – xhongc/music-tag-web

❯ cat > docker-compose.yml << \EOF
services:
  musictag:
    image: xhongc/music_tag_web:latest
    container_name: musictag
    user: 0:0
    ports:
      - 8002:8002
    volumes:
      - /Demo/Music:/app/media:rw # 本地音乐存放目录，与 Navidrome 音乐存放目录相同，因为 music_tag_web 需要将刮削的元数据写入音乐文件，所以需要有写权限。
      - /Demo/DockerData/musictag:/app/data # music_tag_web 本身数据存放位置
    restart: unless-stopped
    networks:
      - traefik_net
    labels:
      - traefik.enable=true
      - traefik.docker.network=traefik_net
      - traefik.http.routers.musictag.rule=Host(`musictag.rockylinux.cn`)
      - traefik.http.routers.musictag.entryPoints=websecure
      - traefik.http.routers.musictag.tls.certresolver=myresolver
      - traefik.http.routers.musictag.service=musictag
      - traefik.http.services.musictag.loadbalancer.server.port=8002
networks:
  traefik_net:
    external: true
EOF

# 启用服务
❯ docker compose up -d

# 确保服务启动成功
❯ docker compose ps
NAME       IMAGE                         COMMAND                   SERVICE    CREATED       STATUS       PORTS
musictag   xhongc/music_tag_web:latest   "/entrypoint.sh /usr…"   musictag   2 hours ago   Up 2 hours   0.0.0.0:8002->8002/tcp, :::8002->8002/tcp

初始化配置

打开 http://127.0.0.1:8002/admin ，默认账号密码为：admin/admin，首次登录请务必修改默认密码。

需要注意的是如果您使用了 Nginx、Traefik 反向代理，在修改密码提交时会报错：

禁止访问 (403)
CSRF 验证失败. 请求被中断.

这是因为 Django 框架安全限制造成，木子已经向项目提交 【Bug问题】: Nginx Traefik 修改密码报错 CSRF · Issue #294 · xhongc/music-tag-web · GitHub，输出了一个解决方案给作者，与作者联调了一下，发现方案不可行。于是细看了一下服务的启动逻辑，是通过 supervisord 来启动 Nginx 进行反代的，也就是说如果您在前端再配置一个 Nginx 或 Traefik 反代，本质就是两层反代。只需要修改 Nginx 配置，确保在 Nginx 配置中添加如下头信息转发设置，以便 Django 能够正确接收请求头信息即可。

root@59e1d615481f:~# vi /app/compose/prod/nginx/nginx.conf
        location / {
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forwarded-Proto $scheme;
            proxy_pass http://127.0.0.1:8001;
            root   /app/templates;
            index  index.html;
        }

如果您不想折腾，可以直接通过本地 IP 登录，进行密码修改。

如下图所示，修改密码。

修改完成以后，就可以通过正常的反向代理地址 Music Tag Web 进行登录。

V2 版本的后台管理进行了美化，更加的漂亮。

看项目 README.md 说明 V1 与 V2 的部署区别于端口设置不同，但木子使用是 8002 端口，版本显示还是 V1，但不影响刮削，暂时不纠结了。

与 V1部署的区别是容器内端口改为 8002，Docker Compose 部署去掉了 command: /start 配置。

元数据刮削

所有的元数据刮削都是写入对应歌曲原文件的，如果您选择“导出 lrc”，就会在歌曲文件夹产生一个对应歌曲的歌词文件，比如：歌曲 记事本.ape 对应歌词文件 记事本.lrc（如下列表所示），默认歌词也会写入歌曲原文件。之所以导出歌词文件，是因为并非所有音乐播放器都支持内置歌词显示，所以木子将所有歌曲的歌词都导出了一份。本质歌词存在两份：歌曲本身元数据存一份，歌词文件存一份。

.rwxr--r--@  31M root  2 12月 15:48  至少还有你.ape
.rw-r--r--  1.8k root  2 12月 15:48  至少还有你.lrc
.rwxr--r--@  29M root  2 12月 16:16  记事本.ape
.rw-r--r--  1.7k root  2 12月 16:16  记事本.lrc
.rwxr--r--@  27M root  2 12月 15:38  该死的温柔.ape
.rw-r--r--  1.5k root  2 12月 15:38  该死的温柔.lrc
.rwxr--r--@  28M root  2 12月 15:36  说谎.ape
.rw-r--r--   805 root  2 12月 15:36  说谎.lrc
.rwxr--r--@  33M root  2 12月 15:35  过火.ape
.rw-r--r--  2.0k root  2 12月 15:35  过火.lrc
.rwxr--r--@  19M root  2 12月 15:49  铁血丹心.ape
.rw-r--r--  1.3k root  2 12月 15:49  铁血丹心.lrc
.rw-r--r--   723 root  2 12月 15:47  难忘今宵.lrc
.rwxr--r--@  41M root  2 12月 15:47  难忘今宵.wav
.rwxr--r--@  26M root  2 12月 15:49  雨蝶.ape
.rw-r--r--  1.7k root  2 12月 15:49  雨蝶.lrc
.rwxr--r--@  21M root  2 12月 15:39  青藏高原.ape
.rw-r--r--   635 root  2 12月 15:39  青藏高原.lrc
.rwxr--r--@  33M root  2 12月 15:39  风中的承诺.ape
.rw-r--r--  1.9k root  2 12月 15:39  风中的承诺.lrc
.rwxr--r--@  24M root  2 12月 15:39  飘雪.ape
.rw-r--r--  1.5k root  2 12月 15:39  飘雪.lrc

具体刮削的操作，参考下图所示，本身 music-tag-web 自动批量刮削功能，如果您不是第一次刮削，不建议使用批量刮削，这可能造成您之前整理的数据毁于一旦。建议手动指定音乐刮削，此列表分为三个模块，从左到右依次是原文件（左侧）、元数据（中间）、刮削的在线数据（右侧）。点击右侧刮削的任何数据，会自动写入中间的元数据部份。

专辑名称：如果说什么没有辜负过 80 后，99.99% 的 80 后可能会说只有音乐，2000 年前后的音乐真是各路神仙打架，比起现在的鬼叫👻，真得不知道强多少。所以木子将这些歌曲合成一个专辑名：《唯有音乐不负 80 后》。

但是 Navidrome 的音乐分类，并不是按照专辑来的，比如一个专辑中有多个不同的歌手，就像群星 CD，这种里面不止一个歌手，它就会将对应的专辑拆解成多个人的，点击某一个“名称”时，只会进入对应某一个歌手的对应专辑列表。
比如：木子这里点击专辑歌手 “付笛声，任静” 的 “唯有音乐不负 80 后” ，进去后对应列表就只有他们唱的一首 “知心爱人”（当然如果这个专辑中有多首他们的歌曲，都会显示出来）。

木子现在的解决方法是：先创建歌单，然后将对应专辑的歌曲导入对应歌单即可。

创建歌单：

导入专辑至歌单：

右下角选择一页显示的歌曲数量，最多为 50 首，如果您的专辑歌曲超过 50 首，可以需要添加几次，在右下角进行翻页。具体操作如下图所示：

这时候对应歌单中就会显示所有专辑内歌曲，并且如果您在其它支持 Subsonic 客户端上配置 Navidrome API 并使用相同的账号，歌单会在不同的客户端同步，比如：音流。

LrcAPI

以下为作者对 LrcAPI 的简介：

Navidrome 只识别音乐内嵌歌词，Emby 则会尝试读取同名的 lrc 文件，不同的后端，质量参差不齐的音乐库，都可能导致前端无法获取音乐的歌词封面等信息，影响使用体验（虽然我知道99.9%的人不会看歌词，但是我知道99.999%的人不能忍受没有歌词）。
因此，LrcAPI是我适配音流自定义API，开发出的一款歌词&封面&更多功能的API。
项目完全免费并使用GPLv3开源，支持Docker部署。
LrcAPI 同时支持从音乐元数据和同名 lrc 文件中获取歌词，也支持从网络查询匹配对应的歌词，同时支持歌曲封面、歌手头像的检索和匹配，也支持将网络搜索的结果保存到音频元数据。

部署 LrcAPI

简单说，它是一款与音流播放器整合的服务，主要用于实现歌词刮削、歌词文件加载等需求。
Github 链接： GitHub – HisAtri/LrcApi
部署文档文档： LrcAPI使用文档

❯ cat > docker-compose.yml << \EOF
services:
  musiclrc:
    image: hisatri/lrcapi:1.5.7
    container_name: lrcapi
    ports:
      - 28883:28883
    volumes:
      - /Demo/Music:/app/media:ro # 音乐存放目录，与 navidrome 相同
    environment:
      - API_AUTH=password # 配置基础认证
    restart: unless-stopped
    networks:
      - traefik_net
    labels:
      - traefik.enable=true
      - traefik.docker.network=traefik_net
      - traefik.http.routers.musiclrc.rule=Host(`musiclrc.rockylinux.cn`)
      - traefik.http.routers.musiclrc.entryPoints=websecure
      - traefik.http.routers.musiclrc.tls.certresolver=myresolver
      - traefik.http.routers.musiclrc.service=musiclrc
      - traefik.http.services.musiclrc.loadbalancer.server.port=28883
networks:
  traefik_net:
    external: true
EOF

# 启用服务
❯ docker compose up -d

# 确保服务启动成功
❯ docker compose ps
NAME      IMAGE                  COMMAND                SERVICE    CREATED      STATUS      PORTS
lrcapi    hisatri/lrcapi:1.5.7   "python /app/app.py"   musiclrc   1 days ago   Up 1 days   0.0.0.0:28883->28883/tcp, :::28883->28883/tcp

--auth 参数用于 header 鉴权，留空则跳过鉴权。验证 header 中的 Authorization 或 Authentication 字段。如果鉴权不符合，则返回 403 响应。也可以使用环境变量 API_AUTH 定义，其优先性低于 --auth 参数，方便在 Docker 中部署。-e API_AUTH=自定义一个鉴权key。

初始化配置

打开对应页面： https://musiclrc.rockylinux.cn

可以看到对应的 API 地址、封面 API 地址等，这个需要至音流播放器进行配置。

API 地址：https://musiclrc.rockylinux.cn/lyrics
新版 API 地址：https://musiclrc.rockylinux.cn/jsonapi
封面 API 地址：https://musiclrc.rockylinux.cn/cover

在音流上配置新版 API 地址测试，发现歌词不会显现，旧版 API 地址是 OK 的，具体原因未细究。

音流播放器配置如下，点击“设置”图标 — 自定义 API — 输入对应 API_AUTH 和 API 接口地址信息，点击“保存”即可。
这时候播放音乐，优先调用歌曲自带歌词，如果没有再调用本地存储的相同歌名的歌词文件，再没有就在线刮削歌词。

客户端软件

前文提到，Navidrome 支持所有 Subsonic 客户端。下载相应的客户端，使用 Navidrome 的 API 地址、账号、密码登录，就能访问和播放服务器上的音乐了。
Subsonic 客户端参考 Subsonic，提供了包括：iPhone、iPad、Android、BlackBerry、Windows、macOS、TV、Browser 等多种客户端软件。
木子建议使用音流，它支持 Subsonic、Navidrome、Emby、Jellyfin、AudioStation、Plex 服务器端，并支持 iOS、Android、macOS、Windows 客户端。高级功能需要收费，但免费的功能已经足够听音乐的需求了。

Sonixd 配置

前期木子使用的是 sonixd，它支持 Windows、macOS、Linux 操作系统，也是一款非常不错的音乐流播放器，具体配置如下。

输入 Server 地址，以及登录 Navidrome 用户名、密码，点击 “Connect” 登录。

登录成功，默认界面为 English。

点击右上角的“设置” — “Theme” — “Language”，切换至“简体中文”。

中文界面如下，整个显示效果还是不错的。

音流配置

以 macOS 操作系统音流客户端配置为例，Android、iOS、Windows 客户端配置与 macOS 客户端相同。

下载 最新版本 | 音流 播放器，安装过程略。打开应用，选择“Navidrome”。

输入 Navidrome 主机地址，以及登录用户名、密码，点击“登录”。

登录成功，点击“进入首页”。

首页如下，对应“我的歌单”也会同步下来。

刷新歌单：可以将在 Navidrome Web 界面创建歌单同步过来。

音质设置：

WiFi 情况下优先无损音质，转码格式采用 AAC，这里有明确说明 AAC 格式可能需要服务器端添加配置才能正常播放（具体配置参考下方说明）。

木子有些音乐是 DCA(DTS Coherent Acoustics) 格式的，直接播放就是沙沙声（炒豆子的声音），这时候就需要转码，像音流播放器本地可以直接转码，但是 Navidrome Web 端或 Sonixd 客户端就需要在服务器端配置 “客户端” 的转码才生效。

如下图所示，选择指定的客户端进行转码设置，这里以设置 Navidrome Web 播放器为例。

配置根据实际情况调整，木子因为是内网所以选择转码编号：acc audio 最大比特率：320。

转码格式默认有三种：MP3、OPUS、AAC，三者的区别如下：

1. MP3 (MPEG-1 Audio Layer III) :
   • 特点 : 最广泛使用的有损音频压缩格式。
   • 优点 : 高兼容性，几乎所有的设备和软件都支持。
   • 缺点 : 相对于较新的有损音频格式，压缩效率较低，音质在低比特率下较差。
   • 使用场景 : 适用于几乎所有流媒体和便携设备，尤其在带宽和存储空间有限的情况下。
2. OPUS :
   • 特点 : 开源的有损音频格式，专为优化低延时和高压缩效率设计。
   • 优点 : 在低比特率情况下提供更高的音质，特别适合实时通信应用（如VoIP）和低延时场景。
   • 缺点 : 虽然兼容性逐渐提升，但依然不如MP3和AAC广泛。
   • 使用场景 : 网络通信、实时音频传输（如语音聊天、会议软件）和高效流媒体服务。
3. AAC (Advanced Audio Coding) :
   • 特点 : 现代有损音频编码标准，采用了更高效的压缩算法。
   • 优点 : 在相同的比特率下比MP3提供更好的音质，广泛用于流媒体、广播和Apple产品中。
   • 缺点 : 比特率较高时音质有所提升，但与无损格式相比仍有音质损失。
   • 使用场景 : 音乐流媒体服务（如 Apple Music）、广播和多媒体应用。

如果您发现音流 APP 中存在音乐搜索不到，但是 Navidrome 中确实存在此音乐，大概率是两边的数据不同步，这时候可以点击“设置” — “资源库” — “立即同步” 即可。

Android

音流播放器 Android、iOS、Windows 配置与 macOS 客户端相同，具体配置参考 macOS 客户端。

资源分享

无损音乐下载可以到 23ape.net 下载，不需要会员，不需要登录，直接下载。当然您有更好的，可以在评论区分享。
如果您的睡眠🛌不好，可以听听大海的声音，一个专业的白噪音网站：Sound Box – 专业的白噪音生成器 | 免费在线白噪声 | 情境音效助眠放松平台。