撤销 issue 02 里的音频转码,把两条 FLAC 放回 dist。 - 恢复方式是**字节级还原**而非重新编码:masters/ 里两份文件的 git 对象哈希与基线 `d8c7e49:dist/assets/audios/*.flac` 完全一致,即与已发布的 v2 是同一份文件。 因此本次提交不新增任何 blob 存储——这两份内容早已在仓库历史里。 - `preset.js` 的音源指向改回 `.flac`。`pv37.mp3` 保持原样:它**没有无损源**, 把有损数据转封装成 FLAC 只会涨体积,而一个 bit 的信息都不会回来。 - 体积基准由「≤35 MB」改为「不超过已发布的 v2(104.98 MB)」,实际 **96.94 MB**, 比 v2 还小(图片部分的无损 WebP 收益仍在),不引入新的上传或订阅风险。 顺带修掉一个自己引入的 bug:改 `preset.js` 时漏写了文件名里的 `「」`, 浏览器请求 404 → `<audio>` 在 **64 ms** 内报 `MediaError.code = 4`(SRC_NOT_SUPPORTED), 看上去像"CEF 不支持 FLAC",实际是路径不存在。判定方法记进 ADR 0004: 把同一份字节交给 `decodeAudioData`,能解出正确时长就说明解码器没问题,问题在传输或路径。 验证: - `test-props`:CEF 支持 audio/flac、无解码错误、readyState=4、时长 205.1 s,14 项音源断言全过。 - `test-acceptance` 新增第 ⑤ 节音频格式不变式:xilian 两个音源全为 flac、无 `.ogg`/`.opus` 残留、`preset.js` 引用的每个音源文件都存在;三种比例 0 报错;预设往返不丢音频设置。 - 分带能量实测:FLAC 高频平滑延伸到 22 kHz(20–22 kHz 处 −50 dB),无有损断崖; 与 Opus 版逐带相差 0.0–0.3 dB。即这是一个由偏好驱动、而非由测量差异驱动的决定。
2.3 KiB
2.3 KiB
06 打包 v3 并重新发布
Status: resolved(第 4 步为人工步骤,待用户执行)
步骤与结果
-
project.json:version升到 3;描述新增"可切换各预设自带的背景音乐""自适应窗口比例"; 新增bgmcombo 与bgm_note。核对:preset的 combo 取值仍是xilian/kv37(用户已保存的设置依赖它,绝不能改)。完成。 -
preview.gif:原 160×160 / 50 帧 / 25fps / 2.0s / 821 KB,超推荐值 500 KB。 重新压缩命令(结果可复现):ffmpeg -y -i dist/preview.gif -filter_complex ` "[0:v]fps=12.5,split[a][b];[a]palettegen=max_colors=128:stats_mode=full[p];[b][p]paletteuse=dither=none" ` -loop 0 .scratch/pv-I.gif Copy-Item .scratch/pv-I.gif dist/preview.gif -Force(不能把输入输出写成同一个文件,ffmpeg 会拒绝;必须先输出到临时文件再覆盖。) 即"每 2 帧取 1 帧 + 128 色 + 不抖动",逐帧与源帧像素完全相同(第 k 帧对原第 2k 帧, 抽查 0/6/12/18/24 帧全部 SSIM 1.0、max|diff| 0),只是时间采样率减半: 160×160 / 25 帧 / 12.5fps / 2.0s / 347 KB。完成。 注:减色到 96/64/48 色收效甚微(604/519/474 KB)——体积由帧间变化量主导,不由调色板主导, 所以走帧采样率这条路更划算。
-
全量验收(
node .scratch/test-acceptance.mjs):全部通过- 总体积 96.94 MB / 33 个文件——未超已发布的 v2(104.98 MB),音频走无损后仍比 v2 小
- 0 死文件
- 音频格式不变式:xilian 两个音源均为
flac、pv37.mp3保持 mp3、已无.ogg/.opus残留、preset.js引用的音源路径全部可达 project.json解析正常、version 3、bgm 存在、preset 取值未变- 21:9 / 16:9 / 9:16 三种比例:播放器就绪、可见矩形比例与画布一致、0 控制台报错 / 0 异常
- 预设往返 10 次:自定义音源与音量 0.2 均未丢失,仍在持续绘制,0 未捕获异常
-
上传到 Workshop:人工步骤,需要用户操作。 本次为破坏性较小的重构(16:9 逐像素不变),但 21:9 / 9:16 下构图按设计改变,建议在 超宽屏与竖屏各看一眼再发布。