【吐槽向】论UTAU设计之烂

原文链接 作者：Zleepwalking, http404, rgwan, strong920326

作者: Zleepwalking 时间: 2014/9/2 07:38

本帖最后由 Zleepwalking 于 2014/9/7 22:12 编辑

负壹、前言

2014.9.7 此文的确易造成认为是贬低对手提升自己的嫌疑。因此才会发到这个半个月没来个人的子版。只望从这些缺陷中找到可以作反面参考的地方。若有更好的专用于技术讨论之处，请回帖于此以提醒，我将转移此贴。 对于那些对语音合成(Speech Synthesis)，尤其是对以下技术领域不具备基本常识的人，此贴言论可能看似极为激进。请自行规避。

  • 语音合成(Speech Synthesis)
  • 频谱音频处理(Spectral Audio Signal Processing)
  • 数字信号处理(Digital Signal Processing)
  • 语音学(Phonetics)
  • 计算机科学(Computer Science)

对于极度死拥UTAU的调教者，若不退散，请自行参考其它合成系统与UTAU进行比较，方显出后者之劣势。可参考Festival和HTS。

对于GUI和resampler的算法我不吐槽。此文针对UTAU作为一个合成框架的设计缺陷。望今后的拼接合成(Concatenative Synthesis)引擎吸取教训，不要重蹈覆辙。 * 此列表或将持续增长。

零、缺陷之于整体

一、进程创建

  1. 创建进程以传参、合成消耗大量系统资源、过度依赖操作系统（CreateProcess <-> fork+exec）。
  2. 过长的参数。假如某些shell最长传递256字节，怎么办？

二、临时文件

  1. 临时文件存放于硬盘，拖慢合成速度，加快硬盘损耗。
  2. 资源同时占用问题。不利于多线程合成的实施。
  3. 临时文件为wav时域信号直接拼接效果一般不好。临时文件/数据至少是语音的某种中间表示，例如谐波+噪声，或LPC系数等。另重复量化，精度下降。

三、分离resampler和wavtool

  1. 这导致resampler对基元进行的操作全部与语境隔离（发音协同？音素长度？辅音长度？基频过渡？），故UTAU制品的拼接感几乎无法避免。

壹、缺陷之于数据结构

一、oto冗余

  1. 为什么需要Left Bound和Right Bound？做音源库时把左右切掉不就得了？
  2. Overlap存入oto是不合理的，因为其时长与语境关系过于紧密。

贰、缺陷之于接口

一、resampler参数传递

  1. 传参目标时长为整个音节的时长，而preutterance指定的是时长修改前发声起始点(VOT)的位置，那么势必造成时长修改后对不上节奏的情况。左端平稳点参数的确防止了大多情况下对齐被偏移的情况，然而这个设计造成的诸多不便缺无法挽回。例如——辅音时长不能增加、极短时长的发音时间错误。
  2. 通过创建进程合成、传递参数。
  3. 无需把oto中已有的信息传入resampler。例如preutterance。

二、wavtool参数传递

  1. 为什么wavtool既要拼接又要加包络？为什么包络这种基元级别的操作不交给resampler？
  2. 为何包络只有固定数量的控制点？包络使用何种方式插值？

叁、缺陷之于拼接及基元选择

一、多音高语料库

  1. 基元音高的选择仅参考起始频率。试想一个C4到C5的滑音，选择的会是C4的基元而不是C5。更好的做法是将基元选择的工作扔给resampler。（这同时也是resampler接口的设计错误）

二、双音子、三音子（即所谓“连续音”）拼接

双音子拼接合成(diphone synthesis)是一种已存在的技术，尽管我本人不赞成此做法，我仍需指出UTAU在此方面的缺陷。

  1. 双音子的选择直接由用户指定，而不是resampler。（参考叁.一、贰.一）

三、小结

UTAU设计初期决定了note=音节=基元的概念，给之后的多音高、多音子拼接的实施带来困难。

作者: http404 时间: 2014/9/2 14:11

我是来对吐槽吐槽的【

零-一 有resampler.dll模式不过虽然接口文档我还没看到过

零-二 √

零-三 前后隔离问题是存在的。连接感问题，可能还需要用更多高质量的音库实验（比如金坷垃（？））。所谓连接感的失败是有很多方面共同作用的，要修复必先清楚了解各个细节，各个掌握少不了一些调教实验与练习。

壹-一-1 波形复用的情况其实是不少的，多对一有各种不同用法，留一个这个没问题。

壹-一-2 存的都是基础值，几乎所有东西都会随语境变化，由调教者来决定。一些不完全无声化就是节奏对齐点向后拖，拖到最后不放开就是完全无声化，而此时前面的overlap也拖到原本的节奏点了什么的。

贰-一-1 的确是个坑，不过这个坑不好解决，尤其是要允许自接引擎的情况下。这需要很成熟的协议，对utau单人作者要求比较高了。实际上由于辅音速度调整造成的节奏偏离bug在v/pocaloid2中都存在，只要把一连续段首个音符的vel调小，这一段的位置就整个跪了，pit的位置又是对的，结果是谜の转音。

贰-一-2 同上有dll，期待这个接口会在更加改善之后才发布吧】

贰-一-3 其实本身oto系统就该由resampler大系统来管不是么（。）的确是个分工细节的问题，分得细限制就大，分得粗需要很多时间实现，可能打击开发积极性，也就丧失了开放接口的意义。

贰-二-1 同上分工问题

贰-二-2 捂脸

叁-一-1 部分是分工问题，部分也是引擎问题，vocaloid也存在这个特征。

叁-二-2 因为一开始是基于文件名的，然后增加别名支持，要再增加自动词典以及resampler间通用的表示法规定什么的才行，这一坨处理又要划给resampler，整个得高度结合，要有协议支持，一开始的架构在这里就比较把自由交给用户，所以可以理解。

叁-三 感觉RUCE把基础的UTAU想让resampler做的事情做完就可以了，进一步发展肯定是建立在更紧密结合的自己设计的系统上。

作者: Zleepwalking 时间: 2014/9/2 19:10

吐槽之吐槽之吐槽：

零-一 有resampler.dll模式不过虽然接口文档我还没看到过

没有wavtool.dll。

零-二 √ 零-三 前后隔离问题是存在的。连接感问题，可能还需要用更多高质量的音库实验（比如金坷垃（？））。所谓连接感的失败是有很多方面共同作用的，要修复必先清楚了解各个细节，各个掌握少不了一些调教实验与练习。

这种分离的结构造成了太多麻烦。难道我要让resampler和wavtool通过临时文件整合？调用顺序怎么办？或者干脆在运行时hack掉bat？

壹-一-1 波形复用的情况其实是不少的，多对一有各种不同用法，留一个这个没问题。

oto.ini限定死了拼接和音渡方式。事实上只有preutterance是大多参数预测方式都需要的。

壹-一-2 存的都是基础值，几乎所有东西都会随语境变化，由调教者来决定。一些不完全无声化就是节奏对齐点向后拖，拖到最后不放开就是完全无声化，而此时前面的overlap也拖到原本的节奏点了什么的。

同上。如果UTAU从根本上打算把一切扔给调教者，那就没什么可吐槽了，或者当作反面教材？

贰-一-1 的确是个坑，不过这个坑不好解决，尤其是要允许自接引擎的情况下。这需要很成熟的协议，对utau单人作者要求比较高了。实际上由于辅音速度调整造成的节奏偏离bug在v/pocaloid2中都存在，只要把一连续段首个音符的vel调小，这一段的位置就整个跪了，pit的位置又是对的，结果是谜の转音。

目测Vocaloid不会犯这么愚蠢的错误吧……【祈祷】

贰-一-2 同上有dll，期待这个接口会在更加改善之后才发布吧】 贰-一-3 其实本身oto系统就该由resampler大系统来管不是么（。）的确是个分工细节的问题，分得细限制就大，分得粗需要很多时间实现，可能打击开发积极性，也就丧失了开放接口的意义。

对。如果要兼备开发积极性和可艹性，不如把吐槽的所有内容挖出来，作为一个“便捷开发”子系统存在，同时允许第三方开发与此系统平行的实现。

贰-二-1 同上分工问题 贰-二-2 捂脸 叁-一-1 部分是分工问题，部分也是引擎问题，vocaloid也存在这个特征。

Vocaloid没这个问题。参考VOICE PROCESSING AND SYNTHESIS BY PERFORMANCE SAMPLING AND SPECTRAL MODELS 之3.1节之 Modeling the Vowel Space。

We approximated their voice model as the linear interpolation between the notes with closest pitches.

叁-二-2 因为一开始是基于文件名的，然后增加别名支持，要再增加自动词典以及resampler间通用的表示法规定什么的才行，这一坨处理又要划给resampler，整个得高度结合，要有协议支持，一开始的架构在这里就比较把自由交给用户，所以可以理解。

同壹.一.2、贰.一.3。

叁-三 感觉RUCE把基础的UTAU想让resampler做的事情做完就可以了，进一步发展肯定是建立在更紧密结合的自己设计的系统上。

让我想起GNU/HURD和GNU/Linux……

作者: http404 时间: 2014/9/2 19:42

本帖最后由 http404 于 2014/9/2 19:46 编辑

吐槽之吐槽之吐槽之吐槽：

零-一 有resampler.dll模式不过虽然接口文档我还没看到过

没有wavtool.dll。

系统发送了一个兵库北

零-二 √ 零-三 前后隔离问题是存在的。连接感问题，可能还需要用更多高质量的音库实验（比如金坷垃（？））。所谓连接感的失败是有很多方面共同作用的，要修复必先清楚了解各个细节，各个掌握少不了一些调教实验与练习。

这种分离的结构造成了太多麻烦。难道我要让resampler和wavtool通过临时文件整合？调用顺序怎么办？或者干脆在运行时hack掉bat？

bat的确是个坑

壹-一-1 波形复用的情况其实是不少的，多对一有各种不同用法，留一个这个没问题。

oto.ini限定死了拼接和音渡方式。事实上只有preutterance是大多参数预测方式都需要的。

的确，这个就是他一开始设计的最大支撑的模型，所以要从模型上下手只有自己搞新的。

壹-一-2 存的都是基础值，几乎所有东西都会随语境变化，由调教者来决定。一些不完全无声化就是节奏对齐点向后拖，拖到最后不放开就是完全无声化，而此时前面的overlap也拖到原本的节奏点了什么的。

同上。如果UTAU从根本上打算把一切扔给调教者，那就没什么可吐槽了，或者当作反面教材？

根本上就是扔给调教者的，但是同时还有插件接口可以自动化地对音符做修改，让用户自己去调用。

贰-一-1 的确是个坑，不过这个坑不好解决，尤其是要允许自接引擎的情况下。这需要很成熟的协议，对utau单人作者要求比较高了。实际上由于辅音速度调整造成的节奏偏离bug在v/pocaloid2中都存在，只要把一连续段首个音符的vel调小，这一段的位置就整个跪了，pit的位置又是对的，结果是谜の转音。

目测Vocaloid不会犯这么愚蠢的错误吧……【祈祷】

系统又发送了一个兵库北【的确P2上就是这么悲剧，V2没实地验证过，V3也还没验证过不过应该修好了吧，再不修好是要挨屁鼓的

贰-一-2 同上有dll，期待这个接口会在更加改善之后才发布吧】 贰-一-3 其实本身oto系统就该由resampler大系统来管不是么（。）的确是个分工细节的问题，分得细限制就大，分得粗需要很多时间实现，可能打击开发积极性，也就丧失了开放接口的意义。

对。如果要兼备开发积极性和可艹性，不如把吐槽的所有内容挖出来，作为一个“便捷开发”子系统存在，同时允许第三方开发与此系统平行的实现。

有这么蛋疼开发力的人很少了【

贰-二-1 同上分工问题 贰-二-2 捂脸 叁-一-1 部分是分工问题，部分也是引擎问题，vocaloid也存在这个特征。

Vocaloid没这个问题。参考VOICE PROCESSING AND SYNTHESIS BY PERFORMANCE SAMPLING AND SPECTRAL MODELS 之3.1节之 Modeling the Vowel Space。

We approximated their voice model as the linear interpolation between the notes with closest pitches.

v里面规则间隔地放很多个同发音音符，音高递增，你是可以明显听出每个音高采样管的边界的，经过边界的时候音色变化很明显。（至少P2是这样的，V3还没刻意没做过实验）单独音符都没有插值，不知道文章是不是口胡。真正插了值的我只知道cevio，不仅音高能插音色都能插（

叁-二-2 因为一开始是基于文件名的，然后增加别名支持，要再增加自动词典以及resampler间通用的表示法规定什么的才行，这一坨处理又要划给resampler，整个得高度结合，要有协议支持，一开始的架构在这里就比较把自由交给用户，所以可以理解。

同壹.一.2、贰.一.3。

叁-三 感觉RUCE把基础的UTAU想让resampler做的事情做完就可以了，进一步发展肯定是建立在更紧密结合的自己设计的系统上。

让我想起GNU/HURD和GNU/Linux……

其实……我觉得他还是留了这个全给我们自己管的后路的：我们可以写个插件代替他的播放按钮【插件被调用的时候就是收到所选择的所有的音符信息【

作者: Zleepwalking 时间: 2014/9/3 11:42

本帖最后由 Zleepwalking 于 2014/9/3 11:43 编辑

所以Rocaloid开发组早就打算尽早扔掉UTAU这个巨坑了。 V的音高边界，应该只是插值的时间作用范围太短了。

作者: rgwan 时间: 2014/9/3 13:24

吐槽一下

零·三：前后隔离问题是存在的。连接感问题，可能还需要用更多高质量的音库实验（比如金坷垃（？））。所谓连接感的失败是有很多方面共同作用的，要修复必先清楚了解各个细节，各个掌握少不了一些调教实验与练习。

分开的连接方式让resampler无法得到更加详细的信息，无法带入语境中。用特别的调教技巧来对付这个问题，只能说是减轻，但是杜绝，还得让resampler得到更详细的信息。不论怎么说……对于我这种比较懒的家伙【，这绝对是个大问题。

贰-一-1 的确是个坑，不过这个坑不好解决，尤其是要允许自接引擎的情况下。这需要很成熟的协议，对utau单人作者要求比较高了。实际上由于辅音速度调整造成的节奏偏离bug在v/pocaloid2中都存在，只要把一连续段首个音符的vel调小，这一段的位置就整个跪了，pit的位置又是对的，结果是谜の转音。

V2确实有这个问题，但是UTAU严重到需要flags校准或者是后期的时候校准，也许是我录制音源方式不对？不论如何节拍混乱实在让人有点头疼啊。

其实关于Library接口这一类的……UTAU又不开放出来，基本上有就和没有一样了，除非有人愿意去继续hack。其实我个人比较赞成另外一种接口方式，类似FastCGI的方式。UTAU可以后台开个engine进程，然后IPC丢数据出去，再IPC拿回wave data。

关于Rocaloid目前只能使用UTAU/Cadencii这类的编辑器，比较让人觉得郁闷。不过开发组目前正在修改Qtractor作为前端，自己的编辑器出来也不远了吧。最近写了个Lyric MIDI文件的读取程序，有时间的话加上RUCE后端吧，然后用DAW调教去【

作者: rgwan 时间: 2014/9/3 13:27

呃……我们要吸取Hurd烂尾的教训啊。不论如何UTAU这类框架真得扔，不仅开发有点麻烦，初学者使用困难，合成方式纠结。真会影响效果和使用体验。

作者: http404 时间: 2014/9/4 21:36

节拍不对肯定是你自己搞糊了……这个最终位置是辅音速度、stp、preutterance三个东西是一起作用的，如果不对的话，去掉stp去掉覆盖参数值，重来重新交叠优化，节拍至少是不会有问题的……

调金坷垃经常要调辅音速度的【

作者: strong920326 时间: 2015/6/24 00:45

本帖最后由 strong920326 于 2015/6/24 20:47 编辑

拼接合成（PSOLA）中間會不自然,然而UTAU rocaloid都是這樣,vocaloid降低接点的数量是透過vcv cv vc以洛天依為例,她是一款三音录制中文vc cv与vcv辅助连续音源，采样大约为7600个,是连续音的采样方式,CeVIO是一個波型透過標註,再丟入hts_engine引擎

作者: strong920326 时间: 2015/6/24 00:55

確定用Qtractor(?)那個介面,我沒很認真用過,可是那個介面,比UTAU還可怕,跟V1有得比,而且還要添加參數以及歌手切換,還有windows用戶要怎麼辦?難到要弄成像MUTA不用調教?

作者: Zleepwalking 时间: 2015/6/25 21:10

我们试着给Qtractor的音符加上歌词编辑功能，最后放弃了，问题倒不是在于界面太难看，而是代码结构不很适合修改。此后我们决定自己开发编辑器。