【吐槽向】论UTAU设计之烂

负壹、前言
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=音节=基元的概念，给之后的多音高、多音子拼接的实施带来困难。

我是来对吐槽吐槽的【
零-一 有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做的事情做完就可以了，进一步发展肯定是建立在更紧密结合的自己设计的系统上。

http404 发表于 2014/9/2 14:11
我是来对吐槽吐槽的【
零-一 有resampler.dll模式不过虽然接口文档我还没看到过
零-二 √

吐槽之吐槽之吐槽：

零-一 有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……

Zleepwalking 发表于 2014/9/2 19:10
吐槽之吐槽之吐槽：

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

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

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

http404 发表于 2014/9/2 19:42
吐槽之吐槽之吐槽之吐槽：

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

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

http404 发表于 2014/9/2 14:11
我是来对吐槽吐槽的【
零-一 有resampler.dll模式不过虽然接口文档我还没看到过
零-二 √

吐槽一下

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

分开的连接方式让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调教去【

Zleepwalking 发表于 2014/9/2 19:10
吐槽之吐槽之吐槽：

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

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

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

rgwan 发表于 2014/9/3 13:24
吐槽一下
分开的连接方式让resampler无法得到更加详细的信息，无法带入语境中。用特别的调教技巧来对付这 ...

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

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

rgwan 发表于 2014/9/3 13:24
吐槽一下
分开的连接方式让resampler无法得到更加详细的信息，无法带入语境中。用特别的调教技巧来对付这 ...

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

strong920326 发表于 2015/6/24 00:55
確定用Qtractor(?)那個介面,我沒很認真用過,可是那個介面,比UTAU還可怕,跟V1有得比,而且還要添加參數以及 ...

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