cnbatch

对于音频而言，其实数据都用不着，亲耳聆听十分直观。
极端点的做法是，把一段 48KHz 采样率的音频，转换成 8KHz 的音频，然后播放，可以听得出高频部份完完全全地丢失了

“播放 48KHz 采样率的音乐，输出到只支持 44.1Hz 的音频接口，这算用到映射吧”

没那么简单，对于音频而言，这种操作叫做“降采样” (Downsampling)。可以参考简单描述：
https://zh.wikipedia.org/zh-cn/%E9%99%8D%E9%87%87%E6%A0%B7
并不能简单地“映射”，实际操作过程中还会用到低通滤波器删除部份高频，防止混叠。
干这事的，既可以是硬件，也可以是软件
https://stackoverflow.com/questions/238382/downsampling-and-applying-a-lowpass-filter-to-digital-audio

打字打快了，应该是 RFC 3162
（早知道直接复制粘贴）

NAS-IPv6-Address 看起来应该是 RFC 3262 的内容：
https://datatracker.ietf.org/doc/html/rfc3162
在 Section 6 直接就提到有 NAS-IPv6-Address 这个 attribute

其实如果各大系统能够完整实现 NPTv6 的话，那就可以 LAN 只分配内网地址（ FD00::/8 ），路由器根据目的地址再按照预设好的规则做前缀转换。

目前只能以奇技淫巧的方式去实现 14 楼的操作，比如 OpenWRT 的“反向掩码”（或者叫做“负掩码”），这里就有讨论：
/t/915393

个人猜测，可能是跟“最长前缀匹配”有关

首先是 V 站曾经有人发过的《检验 IPv6 的最长前缀匹配机制》 /t/779881 里面提到 RFC 3484 。
RFC 3484 的第五章规则 3 提到，不要使用已过期的地址。
结合附言的现象，我猜可能因为禁用后导致 240e 前缀的地址实际上过期了，于是主动把默认源地址改成 2409 的前缀去访问，当 240e 恢复之后，由于 240e 和 2409 是同类型的公网地址，所以不会主动把默认源地址切换回去。

至于为什么重启电脑、禁用网卡再恢复（两者相都会重设网卡设置）后会优先选择 240e ，个人猜测，可能与前缀有关。
2409 的二进制：0010010000001001
240e 的二进制：0010010000001110
排除掉前面相同的部份，可以得到剩下的不同部份：
9: 1001
e: 1110
以 AND 操作做匹配的话，9 的前缀只能匹配 1 个 bit ，E 的前缀可以再匹配 3 个 bit 。
然后 Windows 简单粗暴地认为前缀 E 更加适合。

这是单纯靠猜，我也无法保证一定就是这样。如果有三线接入的话，可以再看看 2408 、2409 、240e 共存时会不会也这样。

由 Zig 自行决定传值还是传引用，这样做实在是自作聪明。如果 Zig 仍然坚持这种设计，那就只能长期停留在“玩具”的阶段。

不明白你要表达什么意思，建议截图+更详细的描述

顺便问问，这里提供的思路能否把 DPI 调到高于 500%呢？比如调到 600%