全双工对话语音数据集 设计说明

本文说明 synthesized_duplex_v4 这份数据由哪些设计特性构成、每个特性在文本侧和音频侧分别怎么落地、以及它们在最终产物里长什么样。

• 文本侧（Script）：把话题扩展成带打断、连续指令、长停顿、子句切分的对话脚本。
• 音频侧（TTS + Compose）：给每个片段选音色合成、对齐取时间戳、按时间轴混成双声道，并给用户侧片段打上 duplex_state / interaction_intent 标签。

产物形态：

{id}_stereo.wav      双声道成品（左=user+third，右=assistant）
{id}_timeline.json   逐段时间轴 + 文本 + 标签

左轨是用户（含第三方、附和、自语），右轨是助手。两侧可以同时发声——这就是"全双工"。

v4 相对 v2 的三处变化（本文其余部分按 v4 描述）：

一、八项数据特性总览

这套数据的每一条特性都同时有文本载体和音频处理两个面。下表是全貌，后续逐条展开。

这八项的分工可以这样理解：1–2 让说话像真人；3–4 让说话的节奏和语义边界可测；5–6 制造抢话；7–8 制造多说话人交叠。4 是 5–6 之外的第三种"助手何时能接话"信号，也是唯一显式落在文本上的。

二、逐项特性详解

1. 口语化

做什么：把书面化的问句改写成真人边想边说时的样子。

改写前：那从执行难度考虑，垃圾分类最容易在哪个环节出错？
改写后：那从执行难度上讲，垃圾分类这事儿，嗯……最容易在哪个环节出错？

约束：只改 user，绝不动 assistant；保留核心意图、事实细节、情绪；不得机械化堆砌（不能变成结巴）。

为什么重要：TTS 若拿书面文本合成，韵律会偏朗读腔；口语化后的文本自带停顿线索，合成出来更接近真实对话。

2. 短停顿（填充词）

形式：直接写进文本的语气词——嗯…… / 呃…… / 那个…… / 就是…… / ……。

特点：时长由 TTS 决定，不受控、不测量。这是它的优势（自然）也是它的局限（不能表达确定性时长）。

与长停顿的分工：短停顿管句内的短犹豫；长停顿管语义不完整处的长静音。两者可以相邻。

3. 长停顿

形式：文本里的内联标签 [600ms] / [800ms] / [1200ms]。

"text": "为什么王者荣耀里，老有人觉得……典韦打野比[600ms]对抗路强？"

判据：标签代表说话人卡在某个词上、正在把它想出来，不是"说完一个完整意思后的停顿"。

• 合法：我想买一辆大概[800ms]50万的车（修中之间，语义未完整）
• 不合法：…哪个环节[800ms]出错？（"哪个环节"是固定搭配，真人不会从中间断开）；…电动车[800ms]，到底哪个更值得入手？（前半已构成完整意思，助手此时就能回答）

档位：只能从配置的离散档位里选（pause_tiers_ms，当前批次实际出现 600 / 800）。

音频侧：两段式合成（v4 的核心变化）

v2 的做法是"合成一整句 → 对齐 → 在标记处切开 → 插 N ms 数字静音"。问题在于切点两侧都是同一条 TTS 的中间态：左半句没有句末语调，右半句没有起音，中间再接一段电平为 0 的静音，听起来像信号掉了。

v4 改为把标记当作段落切分点：

文本：家里那盒[800ms]是不是也有？
      ↓ 按标记劈开
左片段：家里那盒      右片段：是不是也有？
      ↓ 各自独立合成（同一 speaker prompt）
L.wav（带句末收束）          R.wav（带自然起音）
      ↓ 规划
[ L.wav ][ 停顿区 ][ R.wav ]

要点：

1. 标签不送 TTS。左右两段各自合成时都已是干净文本。

2. 左片段以非终句语调收尾。实测停顿前 200 ms 的 F0 斜率：v2 为 −4.4 Hz/10ms（下行，像句末），v4 为 +4.3 Hz/10ms（上行/持平，像话没说完）——这正是"卡在想词"该有的形态。

3. 停顿区不再是数字静音。v4 的停顿区是一层低电平底噪，而不是零：

   指标（10 条样本 / 55 处）	v2 切一条插零	v4 两段式
   停顿区电平	−103 dBFS	−89 dBFS（同说话人最安静 hop 平铺）
   精确零采样占比（中位）	99%	51%
   停顿区总长 vs 标记值	N + 40 ms	N + 200 ~ 300 ms
   停顿区总长 p10–p90	604–816 ms	546–1239 ms
   时间戳	按绝对秒，无误差	按绝对秒，无误差

4. 时间轴上不再做字跨度平移。两段本来就是两条 wav，各自的 CharSpan 独立，不需要 attach_pauses 那种"切点之后全部 +N"的移位。

停顿区怎么填（底噪铺设）

停顿区不填数字零，而是铺一段取自同一说话人真实合成的底噪。做法不是频谱建模，就是"抠一段最安静的波形，平铺进去"：

取材：取同样本所有 slot == user 的波形（含当前这条）。不用 backchannel / self_talk，不用对齐结果。

筛 hop：按 20 ms 一帧计算 RMS，依次剔掉——

1. |x| < 1e-6 的帧（数字静音，包括我们自己插进去的 N ms 零）；
2. RMS > −40 dBFS 的帧（当作语音）；
3. 剩下的取最小 RMS 作为"底"，只保留比它高不超过 8 dB 的帧。

合格的帧首尾拼成模板，模板两端各做最多 5 ms 淡化，避免循环拼接时咔哒。音量不抬也不压，保持原始 RMS——所以不同样本的底噪电平天然不同，这是刻意的。

填回去：在带 [Nms] 的 wav 里找连续近零、长度 ≥ 80 ms 的区间，把模板 np.tile 铺满，两端再各做 30 ms 余弦淡入淡出。找不到合格 hop、或零区不够长，就保持静音。

实测结果（10 条样本 / 55 处标记）：55 处全部铺上了模板，底噪 RMS 中位 −89 dBFS（p10 −104 / p90 −86），模板以 20 ms 为周期严格重复——这就是 np.tile 的直接证据。

已知问题

1. 停顿比标记值长，但时间戳不受影响。两段各自带着 TTS 的头尾静音，铺满后的停顿区会比 N 长 200~300 ms。这不构成时间戳错误：timeline.json 记录的是每段的绝对起止秒，停顿区只是落在左段结束与右段开始之间，下游按 start_s/end_s 取用即可，不需要用标记值反推时间。标记值表达的是"说话人打算停多久"，不承诺物理时长等于该数值。
2. 底噪电平远低于自然停顿。v4 停顿区约 −89 dBFS，而同批次自然停顿的声底中位是 −52 dBFS，两者差 37 dB；且模板通常只有 2 个不同取值（16-bit 量化下 1~2 LSB）。它解决的是"从绝对零跳出来"这个突兀感，还没有做到"听起来像房间声"。
3. 离散度变大。v2 的停顿长度紧贴 N（p10–p90 仅 200 ms 宽），v4 放宽到约 700 ms。
4. 落点校验尚未落到代码。文本侧仍由提示词约束标记落点；代码里定义的禁用左侧字符/词表没有被调用，本批仍能看到 比[600ms]对抗路、又是……[800ms]从哪儿 这类落点。

4. 子句切分

做什么：判断"用户说到哪个位置，语音助手已经获得足够开始回复的完整语义"，在那里切成子句。

"user": "按面积分倒是合理，可要是家里地多但人少，或者地少人多，会不会觉得吃亏？真闹起来怎么办？",
"user_clause": [
  "按面积分倒是合理，可要是家里地多但人少，或者地少人多，会不会觉得吃亏？",
  "真闹起来怎么办？"
]

字段语义：

硬约束：子句按序拼接必须逐字符等于原 user 文本（标点归入前一个子句）。单元素列表等价于无切点，会被归一化成 []。

音频侧：user_clause ≥ 2 时，这段 user 会被切成多个 Placement 摆放，用 src_start_ms / src_end_ms 从同一条已含停顿的 user 音频里切片。片间间隔看这个边界有没有 [Nms]，有就用它，否则按同说话人哈希间隔。

标签侧：同一轮拆出的多个片段，只有最后一个是 accept（助手可以接话），中间的片段一律 reject。见第三节。

为什么需要它：backchannel 的起声点靠 anchor 定位，而 anchor 是字级的；子句边界是语义级的。有了 user_clause，下游才知道"助手在哪几个位置抢话是合理的"。

5. 打断（Stage 1 字级 / 线索）

形式：不产生 events 对象，而是写在被打断轮（前一轮）的 turn 字段上。

关键点：assistant 是已截断的前缀文本，不参与合成——下游一律合成 assistant_full 再截。残句会被 TTS 收成完整句语调，听起来像"说完了"。

音频侧：切点取 anchor 首字之前最后一个字的 end，再放出 anchor 首字开头一小段做衰减尾（clamp(0.5 × 字长, 60, 200) ms），最后余弦淡出。下一轮 user 提前 1000 ms 叠入，制造抢话。

线索打断的细节：线索片段（稍等， / 停， / 等等，）独立成一个 Placement，其结束时刻与下一片段的起点首尾相接（间隔约 0 ms），并且比被打断的 assistant 晚结束约 300 ms——也就是说线索喊完之后，助手的话还在响一小段才被彻底盖住。本批 15 处线索打断全部如此。

6. 连续指令（sequential burst）

做什么：在一处插入 3–5 条用户连续指令，每条带一个"与下一条之间的静音"。

指令1 ──[短间隔]── 指令2 ──[长间隔]── 指令3
                    ↑ 助手刚开始说 就被指令3盖住

每条 assistant_full 回答"到它为止听到的全部指令"——因为助手开口前只听到了 1…i，不可能回答未来的指令。但写法上不是逐条罗列，而是把 1…i 当作一条复合指令自然作答。后续指令推翻前面的，以最新为准。

音频侧（场景 A′）：

nstart = 当前 user.end + tail_gap_ms
若 tail_gap < 阈值：不合成 assistant，下一轮 user 直接放在 nstart
否则：合成 assistant_full，a.start = user.end + min(gap, tail_gap)
      cut_end = nstart + interrupt_overlap
      按"听到的时长"截断 assistant
      下一轮 user 放在 nstart

短间隔时助手在时间轴上缺席**——这正是"助手还没来得及回答，用户就说下一条"的物理表达。

7. 附和 / 自语（backchannel / self_talk）

形式：Stage 2 挑轮次插入的 events 对象，place.owner = assistant、mode = overlap。

{
  "event_type": "backchannel", "speaker": "user", "text": "这样啊……",
  "place": {"owner": "assistant", "turn_idx": 2, "char": 46},
  "anchor": "别被极端案例吓住", "response": null, "ignored": false
}

两者的区别：backchannel 是回应对方（"嗯嗯"、"确实……"）；self_talk 是自言自语（"太强了吧。"）。合成时音色相同、风格参考不同（speed 1.2 vs 1.0）。

同一轮可以有多条（v4 的变化）

真人听一段较长的回复，不会只应一声——听到关键数字应一声、听到转折再嘀咕一句，是常态。因此 v4 允许同一轮承载多条事件：

实测分布（v4，10 条样本）：

共 51 条事件（41 条 backchannel + 10 条 self_talk），分布在 40 个轮次里。11 个双事件轮次的构成：4 个 backchannel+backchannel，7 个 backchannel+self_talk。

音频侧：每条事件各自在自己的 anchor 终点起声——也就是"用户听完了那个子句才有反应"——与 assistant 后半段跨轨重叠。同轮两条事件落在同一段 assistant 话语内，彼此间隔实测 4.1–10.6 s（中位 5.7 s），不会挤在一起。

8. 第三方

四种事件，构成"用户被第三方打扰"的完整链条：

为什么用 resumption 而不是"继续"：用户被打断时，原问题的后半截没说完。回到助手这边时，他会重新起头把那句话说完——这是真实对话里非常典型的修补行为。样例：

t2 user：那……这种怀疑论对政策制定，或…（被第三方打断）
t2 third：会议室等你！
t2 user：我马上过去，先开始吧          ← response_to_third
t2 user：那……这种怀疑论对政策制定和国际合作，到底造成了多大的负面影响？  ← resumption
t2 assistant：（正常回答）

音频侧：第三方总在左轨（与用户同轨）。insert_on_user/interrupt 时用户被掐断；overlap_after_event 时用户说完当前子句再停；ignore 时用户完全无视、自顾自说完。

三、标签体系：duplex_state 与 interaction_intent

这两个字段是这套数据面向训练的核心标签。它们不是对音频的客观描述，而是对"这一段在对话中扮演什么角色"的判定。

出现位置

非 assistant 段（即 user 与 third 段）都带这两个字段；assistant 段不带。

speaker=user   → 带标签
speaker=third  → 带标签
speaker=assistant → 不带

v4 当前批次 468 段中，308 段带标签（300 user + 8 third）。

取值实测分布

合计：incomplete 216、interrupt 41、backchannel 51；accept 158、reject 150。

语义

duplex_state —— 这一段的主话语处于什么状态：

interaction_intent 的判定规则（v4 修正）

v2 里这个问题片段几乎一律是 accept：同一轮被拆成两三个子句时，中间那些"话还没说完"的片段也标成了 accept；线索打断的前缀（稍等，）同样标成 accept。这会让下游误以为「助手在这里就可以接话」。

v4 改成按**「助手能否在这一段结束时接话」**判定：

1. 同一轮的多个实义片段：只有最后一个是 accept，前面的都是 reject。
2. response_to_third / address_third：恒为 reject——说话对象是身边的人，不是助手。
3. resumption：accept——重述的是完整问题。
4. interrupt 且 interrupt_cue = true：reject——用户只喊了一声"停"，紧接着就续说，话轮没有交出去。
5. interrupt 且无 cue：accept——用户已经夺走话轮。

按此规则回标全量，140 / 142 处一致（98.6%）。

各处修正的实际效果：

duplex_state 本身在这些片段上没有改变（子句仍是 incomplete，打断仍是 interrupt），修正集中在 interaction_intent。

两处残留分歧：sample 0 t3 与 sample 6 t14 的末片段被判 reject。这两处都位于跨轮的连续指令 streak 内部——按"轮内最后一个片段"的判据应为 accept，按"streak 还没结束"的语义应为 reject，两种口径在 streak 中段会打架。另有 1 处 interrupt 的 duplex_state 为 incomplete（sample 6 t4，同位置有第三方插话重叠），是全批唯一的不一致点。

标签怎么用

这两个字段是给下游训练用的：

• duplex_state 让模型知道"此刻对方说完了没有"——incomplete 表示可以开始生成，interrupt 表示要处理抢话，backchannel 表示这是短插话不是主诉求。
• interaction_intent 区分"这一段的结束处，是不是一次可响应的交互落点"。

也就是说，训练时模型看到的不只是音频，还有"这段音频在对话结构里是什么"。

四、产物结构：timeline.json

段落级时间轴，绝对秒、三位小数。

{
  "id": 0,
  "sample_rate": 16000,
  "duration_s": 319.394,
  "loudness_lufs": -23.0,
  "segments": [ ... ],
  "overlaps": [ ... ]
}

v4 当前批次：10 条样本，468 段（300 user / 160 assistant / 8 third），121 条 overlap 记录，单条时长中位 316 s。

segments[] 的字段：

event_type 全表：main interrupt sequential third_insert address_third response_to_third resumption backchannel self_talk。

字跨度不进 timeline，留在 intermediate/{id}/{turn}/{slot}.npz。

五、完整样例走查（sample 9）

下面对 9_timeline.json 逐段标注，说明每一段命中哪项特性。这条样本 281 秒、45 段、16 轮，覆盖了除 address_third 之外的全部特性（address_third 的示例取自 sample 8）（下表只列命中特性的段，不是全部 45 段）。

从这条样本能读出的几件事：

• 打断双向可见：段 4 被截断（truncated: true），段 5 提前 1.0 s 叠入（overlaps 里有一条 both）。
• 连续指令的两种节奏都出现：段 27–28 是 streak 的前两条（incomplete/reject，助手不发声）；段 29 是助手对 t10 的回复，只说了 建议选在晚上进去打 就被段 30（t11）盖住。
• 同一轮可以有多条短插话：t3 的段 10 与段 11——一条附和、一条自语，各自挂在 assistant 段 9 的不同 anchor 上。
• 第三方链完整：段 23（third）与段 22（user）在左轨重叠，用户在段 24 简短回应，段 25 重新起头重述，助手在段 26 才接话。这条链正是 §6 里 C / E / F 三个示例音频的来源。
• 长停顿贯穿全篇：3 处 [Nms]（段 3、6、17，另有一处在段 32 的子句①），都落在语义未完整处。
• 同轮中间子句是 reject：段 16 / 段 17、段 21 / 段 22、段 35 / 段 36 都是前一句 reject、后一句 accept。

六、音频局面与示例音频

下表把八项特性落到具体的音频局面上：每个局面一行，右侧是可直接播放的示例（HTML 版每行附播放器与该片的逐段时间表，含 duplex_state / interaction_intent）。

示例音频取自 audio/clips/，每条截取「事件轮 + 前后各一轮」共三轮，双声道即最终产物格式（左 = user + third，右 = assistant）。 高亮行为事件段；标「✂ 截断」的是被打断而截断的主语流段。表格同时列出该片的 duplex_state / interaction_intent——assistant 段没有这两个字段，这本身就是一条信息。

示例音频

每条示例截取「事件轮 + 前后各一轮」共三轮，双声道即最终产物格式 （左 = user + third，右 = assistant）。表格中高亮行为事件段， 标 ✂ 截断 的是被打断而截断的主语流段； 浅蓝底的是同一轮里并列的多条附和——它们各自挂在该轮 assistant 话语的 不同 anchor 上（v4 新增）。

七、文本侧怎么产生（Script）

六个阶段串联，每阶段产出下一阶段的输入：

话题文件
  → ① 主对话骨架        生成 10–15 轮问答，按比例埋入打断
  → ② 连续指令扩展      选一处插入 3–5 条连续指令
  → ③ 口语化            改写 user 文本，插入短停顿
  → ④ 长停顿标记        在语义不完整处插入 [Nms]
  → ⑤ 子句切分          判断助手何时可接话
  → ⑥ 第三方事件        插入插话 / 招呼 / 回应 / 重述

① 主对话骨架

按话题生成多轮对话。按 task_ratios 决定每轮是普通问答、话题转移还是打断。

打断怎么生成：让 user 挑一个"已经听到的信息点"作为切点，助手的话在那里被掐断。生成期就真的把 assistant 文本截成前缀，所以下游不需要猜。

一道精巧的校验（unheard_echo）：如果用户的打断语里出现了只存在于切点之后的内容（≥3 个汉字），说明用户"听到了还没播出的部分"，这条打断被拒绝。用户不可能引用他还没听到的话。

② 连续指令扩展

选一处干净轮次（排除被截断轮及其后一轮），插入 3–5 条指令。间隔由代码按哈希采样，与模型无关——保证同一份配置重跑得到同一批间隔。

每个指令块都强制同时包含"助手发声"和"助手不发声"两种情况，避免整批数据只有一种节奏。

③ 口语化

LLM 改写每一轮 user 文本，插入填充词。输入是带候选轮次的 JSON 对象（eligible_turn_idx），输出是等长的 users 数组。

④ 长停顿标记

与 ③ 同一次调用完成。LLM 只在候选轮里考虑放标记，且放不放由它判断——没有真正卡词的地方就不放。

模型若在非候选轮写了标记（比如连续指令轮），代码会在存储前剥掉。

提示词层面已经写入了完整的落点判据（检索对象检查、左侧完整性检查、检索价值检查、固定搭配不得拆开、若干绝对禁止的落点）。但这些判据目前只靠提示词约束，代码里没有对应的校验环节：stage2_oralize.py 里定义的禁用左侧字符表、禁用左侧词表、犹豫词表目前未被调用，唯一生效的是"非候选轮剥掉标记"。因此本批仍能看到把介词与宾语拆开的落点（如 比[600ms]对抗路）以及紧跟省略号的落点（如 又是……[800ms]从哪儿）。

⑤ 子句切分

LLM 拿到去掉停顿标记的 user 文本，输出每轮的子句列表。校验很严：子句拼起来必须逐字符等于原文。

⑥ 第三方事件

插入第三方插话、用户招呼、回应、重述。每个事件带一个 anchor 子串用于定位起声点，最终由后处理解析成字符下标。

八、音频侧怎么产生（TTS + Compose）

六步流水线。前三步需要模型，后三步是纯逻辑与 DSP。

collect    脚本 → 片段清单           纯逻辑
tts        片段 → 音频（带缓存）       模型
align      音频 + 文本 → 逐字时间戳    模型
pause      长停顿按两段式合成与摆放     模型 + DSP
plan       片段 + 时长 → 时间轴        纯逻辑
render     时间轴 + 音频 → 双声道成品  DSP

为什么先规划后渲染：时间轴的规划是纯逻辑（输入是各段时长与字跨度，输出是绝对时间轴），可以脱离 TTS 单独测试。渲染只按既定时间轴贴音频。

为什么必须用字跨度而不是音频墙钟时长：TTS 输出的头尾静音不稳定（经验 50–300 ms），按"上一段音频长度"累加会逐段累积误差。所有切点、起声点都由对齐得到的字级跨度推导。

合成与对齐分离：每段合成后再对齐，断点以中间产物为准——已有音频和跨度就跳过。改间隔或停顿处理只需重跑规划与渲染。

长停顿时为什么要拆成两段

一句话中途切开，左半句没有句末语调、右半句没有起音，中间再接一段零电平静音，听感是"信号掉了"而不是"人在想"。拆成两段独立合成后：

• 左段由 TTS 自然地给出非终句语调；
• 右段由 TTS 自然地给出起音；
• 中间铺一段同说话人最安静 hop 平铺的底噪，而不是绝对零。

代价是每处标记多一次 TTS 调用（本批 55/468 段带标记）。可听停顿会比标记值长 200–300 ms，但这不影响时间戳——timeline.json 记的是每段绝对起止秒。

底噪怎么来（compose 时算一次，非频谱建模）：

取材   同样本所有 slot == user 的波形（不用 backchannel / self_talk，不用 FA）
筛 hop 20ms 一帧算 RMS：
       ① |x| < 1e-6          丢掉（数字静音，含已插入的 N ms 零）
       ② RMS > -40 dBFS      丢掉（算作语音）
       ③ 余下取最小 RMS 为「底」，只留比它高不超过 8 dB 的 hop
拼接   合格 hop 首尾相接成模板，两端各 ≤5ms 淡化
       音量不抬不压，保持原 RMS
填充   在带 [Nms] 的 wav 里找连续近零且 ≥80ms 的区间
       np.tile 铺满，两端各 30ms 余弦淡入淡出
       无合格 hop 或零区不够长 → 保持静音

结果：底噪 = 同一说话人合成音频里"既不是零、也不像语音"的最安静一档波形，直接循环。

关键数值（当前）

音色与风格是两套参考

音色决定"谁在说"，风格参考决定"怎么说"。短插话（附和、自语）喂"呢喃"参考，招呼第三方喂"呼唤"参考；主话语和打断不喂风格参考。这样同一音色下，附和与正经回答的听感不同。

附录 · 术语