为什么 Chrome 在播放 .flac 音频文件时，拖拽进度条有延迟？

[yodhcn]

发现个奇怪的问题，Chrome 在播放 flac 时，无法根据播放时长计算该请求 flac 文件的第几个字节，只能通过不断下载，来试探有没有到达目标的时间节点。

有人遇到过类似的问题吗？更见鬼的是，Firefox 上就没有这个问题。

[注] chrome 是最新版的 119.0.6045.160

请求的是相同的 flac 文件，响应头 content-type = audio/flac

Chrome 播放 flac

Firefox 播放 flac

破案了，问了个做流媒体网站的网友，他说是因为 Chrome 没有考虑到 flac 的 SEEKTABLE 为空的情况：

flac 有一个 seek table 记录了 seek point <-> byte range 的对应关系，这个元数据不是必要的。

按理来说，音频应当：

1. 要么提供有效的 seek table，浏览器直接查 seek table
2. 要么就干脆不提供 seek table，浏览器自己想办法探测（在这种情况下，chrome 和 firefox 都能正常进入二分探测模式）

如果 flac 音频却提供了一个空的 seek table，将导致浏览器行为异常，进入 fallback

metaflac --list D:\docker_volumes_root\nginx\static\flac\06_DDD-OD.flac

METADATA block #0
  type: 0 (STREAMINFO)
  is last: false
  length: 34
  minimum blocksize: 4096 samples
  maximum blocksize: 4096 samples
  minimum framesize: 1407 bytes
  maximum framesize: 20134 bytes
  sample_rate: 96000 Hz
  channels: 2
  bits-per-sample: 24
  total samples: 353775343
  MD5 signature: d6e8bfcb7c040b54db777e5574032fa3
METADATA block #1
  type: 4 (VORBIS_COMMENT)
  is last: false
  length: 40
  vendor string: reference libFLAC 1.1.3 20130526
  comments: 0
METADATA block #2
  type: 3 (SEEKTABLE)
  is last: true
  length: 0
  seek points: 0  # flac 文件提供了空的 SEEKTABLE

• chrome fallback 为 暴力加载音频直到 seek point
• firefox fallback 只当 seek table 不存在，进入正常的探测流程，二分法逐步探测逼近 seek point

[ysc3839]

都是 HTTP/2 请求的吗？

[niubiman]

flac 文件太大了吧

[hesetiema]

哥们还去提了一个 bug 吗，哈哈，有意思。但我看有些单词应该是 flac ，不是 falc.

[yodhcn]

@hesetiema

艹，有个 flac 打错了。

另外，这其实也算不上 bug ，但既然 Firefox 都支持了，Chrome 是不是也应该跟进一下？