推測VOCALOID系列的運作原理

http://recognition.web.fc2.com/synthe/
初音ミクとかの音声合成のしくみ

作者:井原健紘先生

根據這邊的推測,VOCALOID的設計是使用HMM合成法,VOCALOID2則是使用聲元(資料庫)接續法。
所以HMM合成本身是類似FM、VL的參數合成法,需要運算量;聲元合成法則需要存放資料庫的記憶體、尋址合成的時間。
不過原則上來說,資料大規模但是種類不多(根據VOCALOID2的資料,日文約五百種左右),所以查表應該會比運算快….這也反映在VOCALOID2和VOCALOID1的CPU usage上。

題外話:

1. リボルテックフロイライン 初音ミク
http://homepage2.nifty.com/aimat/etc/e003/e003.html
把リボルテックフロイライン的遠坂凜改造而來,頗有樣子XD
不過拜託出個公式版….

2. Comment問題新解
http://vocaloid.blog120.fc2.com/blog-entry-691.html

如果是為了可讀性的話有很多做法啊….
比方說啟動comment同步卷軸(再生に合わせてスクロールする),目前看起來就算是有彈幕,可讀性仍然很充足。

3. 授權機制FAQ登載
http://vocaloid.blog120.fc2.com/blog-entry-713.html
閱讀原文需要正式購買的user之故,所以只好從轉載推測之。
不過我想底下有人的回應應該很清楚了:曲子的作者必須自己掌控著作權(要信託、或者要自己打理等等),而不能以ミク當成artist。
至於能不能用feat. 初音ミク的部分則有待解明….

[EDIT]
http://b-chief.org/archives/2008/0210-2313.php

上述FAQ內文:
http://piapro.jp/a/help/#q_copyright13

簡單講就是真的非做不可的話,請送給Crypton他們看看….
也就是去年的「未來のキミと、すべての歌に」就是標準範本:事前送審查、內容安全所以pass、只能在C73上販賣、不能通販與委託。
照理來說,他們比較注重的是遊戲內容對角色形象的影響,其次是Vocaloid2引擎資料和遊戲的關聯性。(不能對Vocaloid Editor進行破解、尤其不能直接access Vocaloid Library)
此外,目前來說RipSync等工具(VSQ檔案內容解析)目前都是灰色地帶,但是因為使用到的作品已經不少了,其實應該可以詢問看看。

Intel Canmore小感想

http://pc.watch.impress.co.jp/docs/2008/0109/ces09.htm
2008 International CES Intel基調講演レポート
CanmoreとMenlowで家電とモバイルに攻勢をかける

Canmore是個x86 + GPU 的SoC,可以單獨作用,可以處理1080p的視訊。
基本上看到就立刻會想到一個東西就是AppleTV….

不過有個疑問是,這玩意兒做為x86的理由其實很薄弱。
因為以產品開發為觀點來說,這種家電產品其實完全不需要是x86,用x86的理由基本上只有Windows….而Linux已經打進embedded市場了。

這個產品的對手應該是Ti的DaVinci、還有Panasonic的UniPhier….而這兩個對手都已經上市相當久了。
而ISSCC08上,SONY也另外發表了一個image processor「FIESTA」,500MHz下512Gops,250MHz下115Mops/mW,65nm CMOS製程,有辦法做1080/60p的畫面處理。

http://www.watch.impress.co.jp/av/docs/20071204/ti.htm
TI、フルHD/H.264トランスコード対応の新DSP
-「DaVinci」プラットフォームの新モデル

http://www.watch.impress.co.jp/av/docs/20070619/pana.htm
松下、フルHD 2画面デコード対応の新世代「UniPhier」
-機器間のネットワーク化を促進。45nmプロセスで量産

靠x86還能打進所有市場嗎?很讓人懷疑….

GUNDAM00 18….

這次依靠機體性能的GUNDAM駕駛員其實不少,所以應該很多人期待這一刻:終於有人開量產機打贏GUNDAM了。雖然本話”剛講完”是偽物,馬上就發作….這是現世報啊XD

太陽爐沒有因為洩漏資料而被copy,只是額外洩漏而已;反正只是要一個”是偽物”的理由而已,其實不必深究….17話的片頭一開始到18話這個發展是預想之中;總之已經確立三國和CB對偽CB的態勢了,接下來就是一吐怨氣。_A_

現在主要的問題是CB應該本身就是個內藏分裂的組織,畢竟80年前草創期就已經埋著問題因子。只是因為目前出場的角色數量與配置的關係,會變成”現在本來存在的都是好人、出現的都是壞人”的二元論問題….不過這設計應該也是為了收視年齡層的關係;但是這次角色設計直接放入第一線角色受到戰爭波及又是很重大的挑戰….或許應該說staff幹得好嗎。

過去富野時代的做法大多是捲入戰爭=參與戰爭,這其實不是個很好的做法,但是卻是成本問題:動畫能使用的時間是固定的,把劇情講清楚的同時如何有辦法拉出一定時間的成本來描寫這種一般人的觀點?

2ch上面會有人提到サジ參戰的可能性,基本上就是對GUNDAM這部作品最大的諷刺:嘴巴講是反戰片,其實一直都是在助戰-以眼還眼、自保等等的觀點,結果肯花成本來寫這塊,才是真的達到這部作品提升的作用:直到這回00才真正的有踏入這種”被留下來的人”、”被波及的無辜人”的部分,這才算是在寫戰爭帶來的傷痛啊。(雖然理由只是為了營造惡役這點很可惜就是)

Star Wars Ep01之前的Star Wars都只有宇宙的騎士時代這點,Ep01上映之後才算是以更完整的觀點來補完了Star Wars作品的SF要素。希望GUNDAM-00這部作品也能夠給整個GUNDAM系列達到本質上的提升作用。

—-
話說題外話,雖然一開始很多人埋怨機設,但是看到目前為止對戰鬥場景的運鏡,細長的機體看起來的確會很有動感…. 結果就是UNION和AEU的量產機非常討人喜歡XD

HD2000影片硬解封印?

http://www.tomshardware.tw/1396,review-1396-7.html
難以忽略的2400 PRO與8400 GS影片播放怪癖

我們向ATI詢問這個問題時,該公司表示是他們刻意限制2400PRO等速度較慢的顯示卡的輸出畫面大小,因為他們擔心HD影片會超過這類顯示卡的負荷。

コラコラ。

7.10其實沒有這個問題,也就是說有足夠的理由假設是為了HD3000中低階產品的推出…._A_
當然NVIDIA也做過這種事情就是了,讓8600GTS可以跑得比7900GTX快;當然等9600GT推出的時候就沒有這個必要,但是G84就只好等著山積了。

Tukwila概要公布

http://pc.watch.impress.co.jp/docs/2008/0208/kaigai418.htm
Intel最大のモンスターチップ「Tukwila」の概要が明らかに

這個65nm製程、電晶體數2050M、die size 700mm^2的超級大怪物,是IA-64第一個native Quad-Core。
但是有趣的是,以後藤老爹畫的圖來說,離開了IA-64 CPU core之後,外面的記憶體控制器、Inter-connection等等,就幾乎和Nehalem如出一轍。

IA-64在Tukwila之前都還是南北橋、記憶體控制器外掛的設計;這次核心沒有大變化,但是透過記憶體控制器內建、QPI實作的機會,一口氣把I/O性能大幅提升,記憶體頻寬大了六倍,總共有4channel的FB-DIMM(4.8Gbps x 4);值得注意的是Nehalem-EX似乎也是這樣實作,只是在主機板上裝了Mill Brook晶片(memory buffer chip),把FB-DIMM的介面轉回DDR3 RDIMM。由於Mill Brook是每個晶片2ch,Nehalem-EX會變成8ch DDR3的大怪物。

Tukwila也是第一個實作QuickPath Interconnect(QPI)的CPU產品,總共實做了4條full-width、2條half-width的QPI,只是時脈只設定在規格半速的4.8Gbps;看這些後藤老大推算的數字來說,會發現Tukwila的對外界面不僅全面序列化,並統一在4.8Gtps的數字上,由於system logic的運作時脈是2.4GHz的關係,這樣整體同步會比較簡單;在die photo上的大小大約是123mm^2、電晶體數是39M,幾乎就接近兩個CPU核心的規模,也就是說,CPU上I/O成長的速度比CPU要大上許多….這點GPU也不例外。

後面後藤老大分析了Tukwila的設計走向曲折過程,簡單地講,Tukwila維持ILP強化的路線,沒有透過縮減CPU core規模來增設更多CPU的方式強化性能、也就是避開了強化TLP的路線,主要的原因是為了現有的軟體資產,所以Intel以強化傳統IA-64結構上的弱點,也就是I/O面上,來做整體的強化,因而造就了超巨大的CPU;當然這是Server市場的產品,其實成本就算是200~300usd,CPU本身一賣就是兩千美金,其實也沒差….

這點則和CELL、G80等針對TLP強化的晶片有所差異。
一概而論本來就不適合沒錯,不過其實好像也可以這樣簡化地看:

CELL沒有過去軟體的包袱,設計其實是偏向一個輕易可擴充的DSP系統(還包含了省電元件的採用、自動迴路設計等等方針),所以朝向TLP的方向走;GPU主要的軟體資源由於透過API虛擬化的關係,所以底層的設計細節可以有一定程度的掩蔽,G80更利用這個方式,透過CUDA的架構,把SIMD的結構隱藏在Scalar的表層底下;而CPU大概就不容易這樣走….

但是不管核心的怎麼性能強化,I/O沒有跟著強化自然是快不起來….

偏偏I/O強化就會遇到先前45nm CELL的時候討論到的問題:analog相關的部分在製程上縮小比其他部分困難,結果就是I/O周圍的成本比例上提升得會比其他的數位邏輯部分、或者是記憶體快。

然後就看到這個….
http://www.fudzilla.com/index.php?option=com_content&task=view&id=5605&Itemid=1

基本上G80和R600相比,記憶體頻寬明明比較小,但是記憶體控制器從hotball老大的心得來看,和CELL SPE的MFC/DMA contorller一樣可以吃非常多的outstanding request,延遲雖然明顯拉長(G8x約500cycle前後、CELL約1000cycle前後),但是透過結構(multi-threading or 大量register)可以吸收掉。

如果考慮分支的大小(32pixel per warp,但是執行卻是以half-warp為單位),G80的ALU很可能是double-pumped,8個SP很可能其實是double-pumped的4D,整個G80就變成只有”64個1D shader”了。從這角度來看,ALU占的規模很小,吃的主要還是register file和內部的fabric…..然後G80做得比R600徹底,剩下的就是倍速shader帶來的差異了。

所以如果RV770真的要在最小變更下把RV670給加快,可能就只有加上倍速shader了吧….不過NVIDIA目前下一代(G100? GT200?)似乎還是打算做超強的單晶片,這和宣稱要用四個RV770拼起來的R780似乎又有一點路線上的差距;另外一個敵人是從HPC市場圍堵GPU往GPGPU發展的Larrabee,這邊大概規模也小不下來。

總之超大型晶片現在是越來越難生了….

ISSCC08:45nm CELL

http://pc.watch.impress.co.jp/docs/2008/0206/kaigai416.htm
ISSCCに次世代Cell B.E. 45nm版が登場
~6GHz動作、電力を30%以上削減

電力消耗減很多(65nm,SPE和PPE本身的大小都有縮減(45nm SPE剩下90nm版的43.9%、65nm版的58.5%;45nm PPE剩下90nm版的42.1%、65nm的57.7%),從後藤老爹的對比圖來看,EIB的分布也有變化。

但是FlexIO和XDR的I/O邊沒辦法減,結果變成die size有浪費的空白部分….
這就是CELL的die size沒有顯著變化(45nm版縮小到90nm版的48%)的理由_A_

而且這種傾向也有在其他晶片上看到:總之就是analog、I/O部分很麻煩。