这是给谁的
一场谁提出了什么很要紧的市政会议。一场没有这个就读起来像一整段长文的圆桌讨论。必须分清提问和回答的采访。任何有一个以上说话人、又有人需要从中引用的录音。
怎么运作
- 1
你上传录音，并勾选要把声音分开。
- 2
在转写之前，整个文件会被听一遍找声音——整个文件，因为这才是让第 3 分钟的声音和第 40 分钟的声音属于同一个人的原因。
- 3
每一段讲话被归到某个声音，然后声音被归类。
- 4
转写回来时每段发言都带着说话人，字幕也带着。
你得到什么
- 每段发言都标明是谁说的。
- 文本、字幕和 JSON 里是同一套标签。
- 在字幕里每段发言标一次，而不是每一行都标。
- 找到了几个不同的声音。
- 它在整段录音上工作，而不是一块一块地做。
- 只收一次费，不管你要了多少种语言。
把话说明白： 在干净的录音上可能接近 85 %，而那是最好的情况，不是常态：有背景噪音或口音较重时会下降，下降多少，不听你的录音我们说不了。两个相近的声音会被弄混，两个同时说话的人混得更厉害。把它当成一份帮你省下打字的、很不错的初稿，而不是法庭记录。
问题
- 它知道人的名字吗？
- 不知道。它区分声音，按第一次开口的顺序叫作说话人 1、说话人 2，以此类推。给他们安上名字，是你做一次的查找替换。
- 能处理多少个声音？
- 它是为小规模场合设计的——一场圆桌、一次会议、一次采访。三十个人轮流发言的大厅不是它的用途。
- 如果两个人同时说话呢？
- 那正是它吃力的地方，也是所有人吃力的地方。重叠的语音是这个问题里最难的部分，我们不会假装不是。
- 会拖慢任务吗？
- 它会在开始转写之前，对整段录音多做一遍。一场十八分钟的会议，这一遍不到一分钟。
- 字幕里会带上吗？
- 会，当声音不止一个时。标签放在每段发言的第一条字幕上，而不是每一行都放，那会让屏幕塞满你已经知道的东西。
对一个文件还能做的事
同一个文件、同一个引擎、同一个积分钱包。几乎没人只需要其中一项：转写完一场会议，最后总会想知道是谁在说。