[20110223]
‧DTW path onset selection 一個midi frame對多個wav frame的問題
1. midi的ADSR之A第一個值不從零開始，改成0.1。(也許是因為0對noise太敏感)
2. midi onset frame定為A state的中間。
‧MATLAB記憶體不足的問題
1. use memory defragmentation (因為MATLAB需要連續的記憶體)
2. frequency domain用其他的scale
3. others...
‧目前的Cakewalk舊版讀MAPS的midi會有錯
[20110217]
W partial之外的bin設為0的方法。請和2/9的圖來比較。
[20110210]
schedule:
deterministic harmonic constraint -> temperal smoothnese -> spectral smoothnese
[20110209]
同樣是 Friedrich Gulda 的 K 281 - Andante Amoroso
抓了一個低音域的連續八度音片段
但是實際上它的能量真的很小，且看的出來三倍頻能量比基頻大許多。
後來去看西班牙鋼琴資料庫的一些低於100Hz左右的單音頻譜，
發現也有某些二三倍頻的能量大於基頻許多的例子。
[20110126]
All is 440Hz.
piano : wav
[20110125]
P mask, tone model, if else.
[20110120]
Midi note envelope:
Otherwise, S and R can be scaled.
K281.Andante - 2 bar
1. 將第1、2個template除外的其他template (3rd~13th)，給之inital H，
而W的部分先用原本gaussion的initial partial方式來training ，如下圖。
結果：
兩者好像差不多...
[20110119]
harmonic bands寬度: 一個半音->半個半音
Mean of all onset difference (Midi synthesized-G Air-2 bars)
0 garbage = 0.057472555 -> 0.057610769
1 garbage = 0.167695353 -> 0.087274952 (!)
對付實際演奏的音檔，應該還是需要garbage template的存在，
所以以後把bandwidth設成半個半音來做實驗好了。
因此將garbage template 個數1，半個半音的bandwidth為參數，
改變midi envelope為ADSR，如下圖：
Mean of all onset difference : 0.087274952 -> 0.400023036
結果每個onset都變糟了！
以template #14: 440Hz為例，共有三個note，
左圖是簡單的梯形envelope，Diff = ( 0, 0.053333333, 0.022358277 )
右圖是新的ADSR envelope，Diff = ( 0, 0.152018141, 0.376462585 )
看圖，如果把onset的位置像老師說的定在A stage的中間，那麼應該會準一點吧！
[20110118]
Friedrich Gulda - Mozart Piano Sonata K 281 - 2. Andante Amoroso - 3 bars
Mean of all onset difference (Midi synthesized-G Air-2 bars)
0 garbage = 0.057472555
1 garbage = 0.167695353
[20110114]
套一個衰減較快的簡單envelope似乎效果比較好一點
[20100112]
今天大家討論之後發現好幾個問題將midi note的能量套一個簡單的envelope，如圖：
目前發現有兩個地方因此有所改進：
1. 對於同時出現的pitch音，在DTW時有了改善，以440為例，在第二小節後半的部分第一聲部和第二聲部同時出現。
原本：
後來：
可以看出在2500的附近path有找到第二個peak。
2. 90度的dtw path 會有 midi frame 一對多個 wav frames 的情況，因此我們需要要訂立一個規則去選擇那一個frame是我們要的，onset部分看起來都是選第一個 frame是最好的，所以假設規則是選最前面的frame，但是在offset的時候卻可能差很多，如下圖。
原本：
[20110106]
todo :
1. midi中音符的地方能量改成"梯形"。
2. training一次後，使用initial W : 在某個時間點沒有其八度音的音，initial H : DTW的結果。
貼一下結果圖：
[20101230]
今天大家討論之後發現好幾個問題
1. 音檔比譜高了八度音
2. partial filter bands 忘記inverse
3. 音檔本身高頻就沒有能量
4. 左手應該是Do mi so，比譜多了一個E5。
(實際用鋼琴測試了一下，應該是有彈mi)
5. 多音可以用garbage template來解決，
少音卻可能會發生那個template吃掉別人的partial能量的現象。
更正一下結果圖：
‧λ=100的harmonic的效果不夠好，右邊的才有比較好的效果，
其中第一個template的第二根peak就是 Mi (E5)的基頻。
‧partial數很少是因為音檔本身的問題。
‧目前的五個template是代表 C5、G5、C6、E6、G6
可以發現八度音和五度音的問題確實會影響很大...
[20101229]
Input : (performance wav , piano )
使用鋼琴的演奏音檔，觀察頻譜發現這個樂器的特性不是f0能量最大而是partial 1。
NMF的結果，對照initial template的圖可以很明顯的發現partial跑掉了，將harmonicity cost function的 λ 加大也沒什麼效果..
[20101227]
Input data：First bar of "Back - Air on the G String" (wav synthesized by MIDI )
Only initial：# partial = 10, Gaussion distribution ( σ = 1)
With additional harmonic cost function (by hanyo)：λ = 0.02
The mean of aboutsolute difference between the above two :
W = 1.0837e-007
H = 9.2215e-004
Initial template放了對的頻率之後，有沒有使用harmonicity cost function的結果看起來是差不多的。分的結果看起來不錯，但，也許是因為input是由Midi合成的關係？
[20101221]
論文報告
Parallelism in Dynamic Time Warping for Automatic Signature Verification
平均差異值來看好像PSD好上一點，但PSD遇到長音感覺比較容易出錯，且chroma的異常值比較少。chroma在第344個錯誤可能真的是因為那個音的onset的能量太小。
但是在兩個paper中，有一點比較不一樣的地方是在DTW三個方向的weight。
PSD : (w0, w45, w90)=(1,2,1)
Chroma : (w0, w45, w90)=(1,1,1)
有點trick的是，因為是比min，(1,1,1)這樣的weight會比較傾向於走45度角，應該要讓它大一點畢竟走的距離是比較大的，可以看DTW path右上角的小小方區塊，一個走水平方向一個走斜對角方向，可能是此原因造成的差異，也許兩種都改成(1, sqrt(2), 1)會是比較公平的比較。
[20101112]
經由DTW path反推出alignment onset，與之前標的比較。圖為和alignment之後得到的onset與groundthruth onset比較的difference。
另外，因為使用的是typeI的DTW (0, 45, 90度)，所以有可能會有一個midi frame對多個wav frame的情形，下圖分別是取中間frame、第一個frame、最後一個 frame來做為比較的差。
The mean of aboutsolute difference between the above two :
W = 1.0837e-007
H = 9.2215e-004
Initial template放了對的頻率之後，有沒有使用harmonicity cost function的結果看起來是差不多的。分的結果看起來不錯，但，也許是因為input是由Midi合成的關係？
[20101221]
論文報告
Parallelism in Dynamic Time Warping for Automatic Signature Verification
[20101216]
將NMF的template設為只能是譜上出現的音+額外具有特殊功能的template，update時加上harmonic的限制。
假設在NMF的結果不錯的原則上，
有兩種方法：
1. 整首歌會出現的pitch都有一個自己的template，得到結果之後，再做單音對單音的 alignment。每個H row，分別去對那個pitch的score，得到自己的alignment。所以音檔裡總共有幾個pitch就會做幾次DTW。
2. 判斷那一個時間點有哪些音，template的個數和其代表的pitch會隨之改變。不做DTW，直接將H的值來分析結果。
[20101213]
● 純MATLAB code的加速：
本來程式是依照這樣的公式寫，很直覺的就是用for loop針對matrix的每一個element去做計算。
後來依照我11/23所報的第一篇paper上面的公式，他把它寫成更矩陣的形式。
[ref. Accelerating Non-negative Matrix Factorization for Audio Source Separation on Multi-core and Many-core Architectures]
改寫後在matlab上跑，參數：frame size = 8192，hop size = 256，# of templates = 10， # of frames = 769。
只計算update部分的時間，iteration = 100次。
origin : 297.644882 (sec)
modified：28.522258 (sec)
speedup：10.4355倍
竟然差了十倍，看來在matlab上真的要盡量用矩陣運算來取代for loop寫法！
● 在MATLAB上使用CUBLAS library的SGEMM(Single-precision GEneral Matrix Multiply)：
矩陣相乘維度參數 m x k x n
假設 C=A*B，A : m x k，B：k x n，C：m x n
每一列的意思：
左邊的參數會這樣設是仿造目前的參數W*H 來的，但這樣使用CUDA反而比MATLAB還要慢；右邊的實驗是想說資料維度大一點或許就會比MATLAB來的快，結果也如我想的。
接下來如果真的要使用mex & CUDA，應該不能一次矩陣相乘就呼叫一次，因為這樣資料要轉換型態、記憶體allocate還要搬好幾次，不划算。應該要寫一個把整個NMF過程都包含進去的API，最好是整個NMF都在GPU memory上面運作就好。
猜想11/23報的第一篇paper會比後面兩篇speedup來的小的原因是因為，他把每個operation拆開，每一個都寫成一個kernel function去執行，而後面兩篇可能是一次把事情做掉吧。
[20101206]
A Guide to Using NVMEX tool
可能因為os、matlab、vc版本不同，在這邊會出現一些錯誤。
首先，我使用的是VC9，但範例中是VC8，因此需要修改一下nvmexopts.bat的一些路徑，
怎麼修改請看此pdf中的第6點 (連結)。
再來出現的錯誤
nvcc fatal : Unknown option 'oC:\Users\Vivian\AppData\Local\Temp\mex_F9gfIA\test.obj'
看的出來因為路徑前面多了一個o所以找不到所需要的檔案。
只好去看一下nvmex.pl，把perl中的一些變數印出來看，發現是
$name_arg = $NAME_OBJECT . smart_quote($target_name);
$NAME_OBJECT這個變數的關係。
解決方法是把nvmexopts.bat中，
set NAME_OBJECT=-o 改成 set NAME_OBJECT=
也就是不給它值，就不會被干擾哩。
之後再compile，會發現會出現很多錯誤訊息，
google之後找到nvidia forums 有人和我有相同的問題！ (連結)
將 nvmexopts.bat 中，
set COMPFLAGS=-c -D_WCHAR_T_DEFINED -Xcompiler "/c /Zp8 /GR /W3 /EHsc /Zc:wchar_t- /DMATLAB_MEX_FILE /nologo"
"/Zc:wchar_t- " 改為 "/Zc:wchar_t"，也就是把"-"去掉，這樣雖然會出現一些warning，但是就可以compile過了！
感謝討論串中的eigma大大。
最後小小測試 fft v.s cufft，speed up大概是1.5~2.5左右。
[20101123]
報告
Frame size = 8192，hop size = 2048，DTW使用type I，與PSD的一樣。將NMF的template設為只能是譜上出現的音+額外具有特殊功能的template，update時加上harmonic的限制。
假設在NMF的結果不錯的原則上，
有兩種方法：
1. 整首歌會出現的pitch都有一個自己的template，得到結果之後，再做單音對單音的 alignment。每個H row，分別去對那個pitch的score，得到自己的alignment。所以音檔裡總共有幾個pitch就會做幾次DTW。
2. 判斷那一個時間點有哪些音，template的個數和其代表的pitch會隨之改變。不做DTW，直接將H的值來分析結果。
[20101213]
● 純MATLAB code的加速：
本來程式是依照這樣的公式寫，很直覺的就是用for loop針對matrix的每一個element去做計算。
後來依照我11/23所報的第一篇paper上面的公式，他把它寫成更矩陣的形式。
只計算update部分的時間，iteration = 100次。
origin : 297.644882 (sec)
modified：28.522258 (sec)
speedup：10.4355倍
竟然差了十倍，看來在matlab上真的要盡量用矩陣運算來取代for loop寫法！
● 在MATLAB上使用CUBLAS library的SGEMM(Single-precision GEneral Matrix Multiply)：
矩陣相乘維度參數 m x k x n
假設 C=A*B，A : m x k，B：k x n，C：m x n
- MATLAB : 使用matlab指令A*B
- myAPI：我寫的matlab函式，透過MEX-file得到matlab的參數，因為matlab是double-presicion，要先轉換型態之後，再去使用cublas library，之後再把值傳回。
- Speedup：MATLAB time / myAPI time
- only CUBLAS：myAPI中，不去計算matlab矩陣轉換到cuda矩陣的時間。
- only cublasSgemm：only CUBLAS中，不去計算allocate cuda memory和搬運的時間，只計算lib中矩陣相乘函式cublasSgemm的時間。
左邊的參數會這樣設是仿造目前的參數W*H 來的，但這樣使用CUDA反而比MATLAB還要慢；右邊的實驗是想說資料維度大一點或許就會比MATLAB來的快，結果也如我想的。
接下來如果真的要使用mex & CUDA，應該不能一次矩陣相乘就呼叫一次，因為這樣資料要轉換型態、記憶體allocate還要搬好幾次，不划算。應該要寫一個把整個NMF過程都包含進去的API，最好是整個NMF都在GPU memory上面運作就好。
猜想11/23報的第一篇paper會比後面兩篇speedup來的小的原因是因為，他把每個operation拆開，每一個都寫成一個kernel function去執行，而後面兩篇可能是一次把事情做掉吧。
[20101206]
在Matlab上使用CUDA，可以參考Nvidia提供的pdf。
White Paper - Accelerating MATLAB with CUDA™ Using MEX Files
如果只要使用cuda提供的library，(ex. cufft)...等，那麼只需寫成.c檔就好了。
>> mex filename.c -IC:\CUDA\include -LC:\CUDA\lib -lcudart -lcufft
成功的話就會被compile成MEX-file(.mexw32)。
如果需要自己寫kernel function，要寫成cuda特有的.cu檔案才行，之後交給nvcc去compile。
White Paper - Accelerating MATLAB with CUDA™ Using MEX Files
如果只要使用cuda提供的library，(ex. cufft)...等，那麼只需寫成.c檔就好了。
>> mex filename.c -IC:\CUDA\include -LC:\CUDA\lib -lcudart -lcufft
成功的話就會被compile成MEX-file(.mexw32)。
如果需要自己寫kernel function，要寫成cuda特有的.cu檔案才行，之後交給nvcc去compile。
這時候需要使用一些plugin tool。
A Guide to Using NVMEX tool
可能因為os、matlab、vc版本不同，在這邊會出現一些錯誤。
首先，我使用的是VC9，但範例中是VC8，因此需要修改一下nvmexopts.bat的一些路徑，
怎麼修改請看此pdf中的第6點 (連結)。
再來出現的錯誤
nvcc fatal : Unknown option 'oC:\Users\Vivian\AppData\Local\Temp\mex_F9gfIA\test.obj'
看的出來因為路徑前面多了一個o所以找不到所需要的檔案。
只好去看一下nvmex.pl，把perl中的一些變數印出來看，發現是
$name_arg = $NAME_OBJECT . smart_quote($target_name);
$NAME_OBJECT這個變數的關係。
解決方法是把nvmexopts.bat中，
set NAME_OBJECT=-o 改成 set NAME_OBJECT=
也就是不給它值，就不會被干擾哩。
之後再compile，會發現會出現很多錯誤訊息，
google之後找到nvidia forums 有人和我有相同的問題！ (連結)
將 nvmexopts.bat 中，
set COMPFLAGS=-c -D_WCHAR_T_DEFINED -Xcompiler "/c /Zp8 /GR /W3 /EHsc /Zc:wchar_t- /DMATLAB_MEX_FILE /nologo"
"/Zc:wchar_t- " 改為 "/Zc:wchar_t"，也就是把"-"去掉，這樣雖然會出現一些warning，但是就可以compile過了！
感謝討論串中的eigma大大。
最後小小測試 fft v.s cufft，speed up大概是1.5~2.5左右。
報告
NMF on CUDA
[20101115]
實作chroma方法on MATLAB，依照Multi-pass...那一篇paper。
平均差異值來看好像PSD好上一點，但PSD遇到長音感覺比較容易出錯，且chroma的異常值比較少。chroma在第344個錯誤可能真的是因為那個音的onset的能量太小。但是在兩個paper中，有一點比較不一樣的地方是在DTW三個方向的weight。
PSD : (w0, w45, w90)=(1,2,1)
Chroma : (w0, w45, w90)=(1,1,1)
有點trick的是，因為是比min，(1,1,1)這樣的weight會比較傾向於走45度角，應該要讓它大一點畢竟走的距離是比較大的，可以看DTW path右上角的小小方區塊，一個走水平方向一個走斜對角方向，可能是此原因造成的差異，也許兩種都改成(1, sqrt(2), 1)會是比較公平的比較。
[20101112]
經由DTW path反推出alignment onset，與之前標的比較。圖為和alignment之後得到的onset與groundthruth onset比較的difference。
difference error (seconds):
以下以取中位數frame的情況來分析，數字代表音符的index；
如果說去除大於1.5秒的那3個值，重新計算difference平均 = 0.0937 s，大約是兩個frame 。第344個音符是BWV1007這曲子中，中間長音之後的第一個音符，在演奏的音檔中，這個音符的onset音量很小。
而第655、656個notes是曲子的結尾，是長音。
接下來有點想要在matlab上實作一次chroma的方法，比較一下這兩種方法對於BWV1007的結果如何。
[20101108]
Implement 6月7號所報告的論文，使用Matlab...令人感動的方便許多。
Implement 6月7號所報告的論文，使用Matlab...令人感動的方便許多。
Midi parser的部分感謝這個網站與它的主人
依然是先使用Bach BWV1007 prelude做實驗，wav是2分44秒，共656個notes。
圖中藍色線為spectrum，綠色線為band filters。上圖是wav的第2個frame vs midi的第2個frame，distance較小；下圖是wav的第10個frame vs midi的第220個frame，distance較大。
圖中藍色線為spectrum，綠色線為band filters。上圖是wav的第2個frame vs midi的第2個frame，distance較小；下圖是wav的第10個frame vs midi的第220個frame，distance較大。
論文中的hop size為256，所以有5.8ms的resolution。
可是如果這樣的話，matlab記憶體會不夠，因為矩陣變得相當大；且論文中提及他實驗的一首兩分半的巴哈小提琴獨奏，就需要2GB的記憶體，但筆電的RAM也才2GB...
所以先使用frame size = 8192，hamming window，hop size = 2048。
左邊是distance的矩陣，顏色越深代表越相似；右邊紅色線是DTW找出來的對應路徑，0度, 45度, 90度的 typeI，weight=[1,2,1]，頭對頭、尾對尾；此外記錄一下一些參數 thetaD = 0.5, thetaS = 0.5, ss = 1, sd = 1。
可以發現結果和左邊用肉眼看出的由distance小的element所那條組合成的線很相近，不過這也只能說是DTW找出來的path和最小cost真的很符合而已。
要知道結果好不好，還是要和ground truth（之前用cool edit標的）比較，下一步應該要把cue的資訊弄進matlab計算正確率。
[20100608]
Q:
我有一個spectrum，已知裡面的某一個f0，想要知道它是不是單音且為harmonic ？
A:
1. filter : 因為知道f0，在每個倍頻上用 gaussian 去 model 每個 peak
2. 計算 : spectrum 的總能量 - spectrum 經過 filter 後的能量
3. 如果是單音且為harmonic，那麼剩下的能量應該會很小。
除了之前看的chroma feature，也有好一些人是使用這篇論文提出來的方法。這篇論文是2001年publish的，它提出了一個名為 Peak Structure Distance(PSD) 的 feature，這個Distance用來當作DTW中的local distance使用，相對於之前我們的作法就是用來取代Euclidean distance。
PSD簡單來說，就是去算score frame與 audio frame 的peak的相似度，越相近distance越小。另外它還model了一個note的開始 (attack model) 與 結束 (silence model) 。
它做了很多仔細的實驗和數據，結果看起來不錯，感覺上還蠻值得參考的。下次會看也是由Ircam在2003年發表的paper，關於這個方法提出的改進。
[20100604]
以 Mozart piano sonata K.545 的前四小節為測試曲子，修改 midi 來合成測試的 wav。
Midi 合成 wav 軟體 : WinGroove
目前ground truth : Calkwalk 看 event list -> Cool Edit 人工標記
（未來：不執著於要存到wav裡的cue，用另外的檔案代替儲存。）
新增輸出 onset error 詳細資料的 html table。
測試了合成時有無reverberation、某個時間點譜不只一個音出現但audio其中一個音比譜晚出現半拍的情況。
進度投影片
link由於想了解DTW在一些特定的情況之下會有怎樣的行為，因此我用midi式的chroma feature來作實驗，測試了比原本的 chroma 多音、少音、平移幾個半音，對於兩種 type 的 DTW 會有怎樣的結果。
另外也測試了 piano 與 trumpet 的片段。
進度投影片
link[20100503]
論文報告
Handling Asynchrony in Audio-score Alignment
投影片
[20100430]
現在的目標，是讓score alignment夠準，然後能自動截取audio中每個音的起始時間，還有結束時間，它的f0和partials的frequency、amplitude，來做合成使用。
論文報告
Handling Asynchrony in Audio-score Alignment
投影片
[20100430]
現在的目標，是讓score alignment夠準，然後能自動截取audio中每個音的起始時間，還有結束時間，它的f0和partials的frequency、amplitude，來做合成使用。
新增輸出 cue 詳細資料的 html table、輸出 alignment 結果所對應的midi、wave 之 frame、second 的 html table。
程式有bug待修。
程式有bug待修。
進度投影片
link
[201003022]
論文報告
GPU ...
[20100204]
兩件事情：解決讀midi的bug、score alignment的onset時間 v.s 人工標記的onset時間。
1. 讀midi的bug : 在某些時候會少讀了一些長度
發現依然是讀檔時，byte轉換發生的問題，java的byte是signed，所以當值大於127它就會變成負的，再去做排列就會錯。這個問題之前也發生在讀wav的時候，用一樣的方式解決就好了。
更正一下上次po的圖，BWV1007前兩小節(點圖可放大)
midi :
wav origin :
wav considering partials :
2. score alignment 結果的onset時間 v.s 人工標定的onset時間
FFT frame size : 4096
hop size (兩個frame起始位置間隔) : 512
表格裡面的值 (秒) :
|score alignment 結果 - 人工標定的onset時間| / 總共onset個數
可以發現前四組結果，有考慮partials的方法會比沒有考慮來的好一些，
但是如果是整首BWV1007來做比對，兩者結果都變差許多，而且有考慮partials的方法結果還變得比沒有原始的方法差。
對於整首的這組結果來觀察，發現平均值增大的原因可能是因為有幾個onset的差異比平均大許多，大概一秒鐘左右。而有考慮partials的方法差異大的onset比原始方法的這種情況還要多。
新方法大約310-343+後面24個onset誤差較大，原始方法大約323-343+後面20個onset誤差較大所致。第343個onset對於BWV1007剛好是歌曲的段落，是一個長音，而且BWV1007這首歌除了中間和最後的兩個音是長音，其它都是16分音符，不曉得是不是因為這個原因讓判斷變差。
[20100120]
論文報告
Music Score Alignment and Computer Accompaniment
投影片
[20091221]
首先是解決冠廷學長之前沒處理到的部分：由於 map 到每個 pitch class 的 bin 數量不會一樣，所以要做一次 normalize 的動作。
左邊圖片是原本的，右邊是有加上取平均。(也就是傳統chroma)
1. white noise
2. BWV1007-15s
之後就作新加的部分，要往上加 partial 能量，也加上了 normalize 取平均的步驟。
以 BWV1007 前 15s 為例：
1. original
2. 每個 bin 從 frequency domain 中找最接近的partial's bin，加總其能量並取平均。
3. 每個 pitch 從 frequency domain 中找最接近的 partial's bin，加總其能量並取平均。(花較少時間)
目前以第三個方法為主。
上面三個圖之間似乎沒有很大的變化，
第二個比較稍微不一樣一點，第一個圖和第三個圖只有些微差距。
令人在意的是第二個音，譜是 RE，但是卻是五度音的 LA 能量較強，用了新的方法依然沒解決這個問題，這蠻出乎意料的。後來印出一些資料來看，發現可能是threshold設太小的問題。
這個threshold是用於判別這個bin是不是目前基頻的partial：
| (bin frequency/基頻) - ((bin frequency/基頻)最接近的整數) | <= threshold 所以我試著將 threshold 從0.001 調整為 0.1，第二個音 RE 就出現了！
對譜的結果也比之前的好
[20091217]
論文報告
Audio Thumbnailing of Popular Music Using Chroma-Based Representations
投影片
[20091216]
與老師討論了一下，以後可能有兩個方向可以走。
1. 假設 midi 是對的。
我們可以經由 DTW 的 cost 去調整 partial 的比例，也可以說是 chroma template 的 weighting 參數，以貼近現在樂器的特性。
比如說現在這把大提琴第三個partial的能量會特別高，希望可以經由 DTW cost feedback 來調整我們的 chroma template 的參數。
2. 假設知道是什麼樂器，而且只適用在這首歌只有一種樂器上，但是這樂器可以是多音。
(1) 把 midi 經由這樂器的音色庫，合成出符合這樂器的 wav，轉成 chroma 後再進行對譜。
(2) 由 wav 來建 instrument model，藉由這個來讓 chroma 更準確。
[20091211]
看了老師的回應，和小明學長討論了一下，預計的做法是：
FFT(4096) -> map 2048個bin到最接近的 pitch -> 每個pitch從frequency domain中找最接近的partial's bin，加總其能量，取平均。
這樣應該會減少一些計算量。
[20091209]
為了解決五度音等partial重疊導致能量貢獻給別的音名的問題，但是又想要維持使用chroma，也不想要在這裡使用pitch detection等較複雜的演算法。經過討論之後，決定現在多一個步驟的做法：讓每個頻率往上找它的partial，把其能量加起來到自己身上，這樣重疊的partial能量就會貢獻到可能是它的f0的身上。
流程 :
FFT (size:4096) → Map 每個 bin 到最接近的 pitch frequency → 每個 bin 往上找倍頻的能量並加到自己本身 → 每個 bin 分配到 chroma vector
我們使用的pitch frequency table是參考wiki的音高頻率表
另外就是這個演算法花的時間很久...
結果:
發現最下面那條Do的pitch class的能量一直非常大。
後來發現是因為第一個bin大約是10.7666Hz左右，然而第一個bin一定是所有bin頻率的因數，對照pitch frequency table，10.7666Hz最接近的是C0(DO)，因此它的能量因此會最大。
忽略了第一根bin的結果:
發現變成是往上數第六條的能量最大，對照音名是FA。這是因為第二根bin也是好多bin們的因數，第二根bin頻率大約是21.5332Hz，對照表最接近的是F0，因此得知。
後來和小明學長討論發現了另一個問題，都是關於應該需要去取平均的地方。
1. 冠廷學長做Chroma的方式，如果是採用每根bin就map到跟它頻率最接近的那個音之後加起來，那麼事實上他可能忽略了一個問題，低頻的部分兩根bin中間可能有好多的音在那個範圍，在高頻的部分可能在兩個音的範圍中間會有好多根bin，因此會有每個音所擁有的bin會不同數量的問題，我們實驗用white noise當作input，真的發現chroma的顏色並沒有分布的很均勻。所以應該要讓每個音除以它所擁有的bin的個數，取平均。
2. 在我們新加的方法中，低頻的bin會有較多的partial，所以能量加到自己身上之後，應該也要除以partial的個數來取平均。雖然這樣當能量懸殊的時候還是會造成彼此相對的差異減少，不過總是比沒有做normalize來的正確一些。
[20091201]
用BWV1007前四小節去跑，發現wav chroma錯誤了。
1. 前兩個音SO(低)、RE的部分，推論是因為五度音的關係，f0相差1.5倍，因此倍頻重疊了，RE的部分能量被認為是 SO 的。
2. 後面四個音也錯了，變成都是LA，推測是因為frame size不夠大，造成 fft 後頻率域的resolution不夠高。
origin frame size : 2048
frame size : 4096
frame size : 8192
可以看出增加frame size以增加frequency的解析度，結果準確許多。
不過第二個音 RE 的部分為什麼chroma顯示出來是 LA 的能量最強呢，是因為 RE 和 LA 是五度音嗎？
但是觀察spectrum，發現440 Hz左右真的有一條能量強的partial，所以不只是 RE 和 LA 第一個重疊的倍頻880Hz所分配給 LA 的部分。
[201003022]
論文報告
GPU ...
[20100204]
兩件事情：解決讀midi的bug、score alignment的onset時間 v.s 人工標記的onset時間。
1. 讀midi的bug : 在某些時候會少讀了一些長度
發現依然是讀檔時，byte轉換發生的問題，java的byte是signed，所以當值大於127它就會變成負的，再去做排列就會錯。這個問題之前也發生在讀wav的時候，用一樣的方式解決就好了。
更正一下上次po的圖，BWV1007前兩小節(點圖可放大)
midi :
wav origin :
wav considering partials :
2. score alignment 結果的onset時間 v.s 人工標定的onset時間
FFT frame size : 4096
hop size (兩個frame起始位置間隔) : 512
表格裡面的值 (秒) :
|score alignment 結果 - 人工標定的onset時間| / 總共onset個數
可以發現前四組結果，有考慮partials的方法會比沒有考慮來的好一些，
但是如果是整首BWV1007來做比對，兩者結果都變差許多，而且有考慮partials的方法結果還變得比沒有原始的方法差。
對於整首的這組結果來觀察，發現平均值增大的原因可能是因為有幾個onset的差異比平均大許多，大概一秒鐘左右。而有考慮partials的方法差異大的onset比原始方法的這種情況還要多。
新方法大約310-343+後面24個onset誤差較大，原始方法大約323-343+後面20個onset誤差較大所致。第343個onset對於BWV1007剛好是歌曲的段落，是一個長音，而且BWV1007這首歌除了中間和最後的兩個音是長音，其它都是16分音符，不曉得是不是因為這個原因讓判斷變差。
[20100120]
論文報告
Music Score Alignment and Computer Accompaniment
投影片
[20091231]
BWV 1007前2小節對譜全圖 (點圖可放大)
BWV 1007前2小節對譜全圖 (點圖可放大)
沒加新方法的 wav :
有往上加 partial 的 wav :
midi :
可以看出，有加了往上疊加 partial 能量方法的對譜效果比較好，
最後面的部分沒對好，是因為 midi parser 那部分有些問題，最後面少讀了一些音。
所以接下來要幫 midi parser 的部分code debug。
→ check 完學長原本的 c# 程式應該是對的，所以可能是改到 java 的時候不知道哪裡改錯了... (20100105)
→ check 完學長原本的 c# 程式應該是對的，所以可能是改到 java 的時候不知道哪裡改錯了... (20100105)
[20091221]
首先是解決冠廷學長之前沒處理到的部分：由於 map 到每個 pitch class 的 bin 數量不會一樣，所以要做一次 normalize 的動作。
左邊圖片是原本的，右邊是有加上取平均。(也就是傳統chroma)
1. white noise
2. BWV1007-15s
之後就作新加的部分，要往上加 partial 能量，也加上了 normalize 取平均的步驟。
以 BWV1007 前 15s 為例：
1. original
2. 每個 bin 從 frequency domain 中找最接近的partial's bin，加總其能量並取平均。
3. 每個 pitch 從 frequency domain 中找最接近的 partial's bin，加總其能量並取平均。(花較少時間)
目前以第三個方法為主。上面三個圖之間似乎沒有很大的變化，
第二個比較稍微不一樣一點，第一個圖和第三個圖只有些微差距。
令人在意的是第二個音，譜是 RE，但是卻是五度音的 LA 能量較強，用了新的方法依然沒解決這個問題，這蠻出乎意料的。後來印出一些資料來看，發現可能是threshold設太小的問題。
這個threshold是用於判別這個bin是不是目前基頻的partial：
| (bin frequency/基頻) - ((bin frequency/基頻)最接近的整數) | <= threshold 所以我試著將 threshold 從0.001 調整為 0.1，第二個音 RE 就出現了！
對譜的結果也比之前的好
[20091217]
論文報告
Audio Thumbnailing of Popular Music Using Chroma-Based Representations
投影片
[20091216]
與老師討論了一下，以後可能有兩個方向可以走。
1. 假設 midi 是對的。
我們可以經由 DTW 的 cost 去調整 partial 的比例，也可以說是 chroma template 的 weighting 參數，以貼近現在樂器的特性。
比如說現在這把大提琴第三個partial的能量會特別高，希望可以經由 DTW cost feedback 來調整我們的 chroma template 的參數。
2. 假設知道是什麼樂器，而且只適用在這首歌只有一種樂器上，但是這樂器可以是多音。
(1) 把 midi 經由這樂器的音色庫，合成出符合這樂器的 wav，轉成 chroma 後再進行對譜。
(2) 由 wav 來建 instrument model，藉由這個來讓 chroma 更準確。
[20091211]
看了老師的回應，和小明學長討論了一下，預計的做法是：
FFT(4096) -> map 2048個bin到最接近的 pitch -> 每個pitch從frequency domain中找最接近的partial's bin，加總其能量，取平均。
這樣應該會減少一些計算量。
[20091209]
為了解決五度音等partial重疊導致能量貢獻給別的音名的問題，但是又想要維持使用chroma，也不想要在這裡使用pitch detection等較複雜的演算法。經過討論之後，決定現在多一個步驟的做法：讓每個頻率往上找它的partial，把其能量加起來到自己身上，這樣重疊的partial能量就會貢獻到可能是它的f0的身上。
流程 :
FFT (size:4096) → Map 每個 bin 到最接近的 pitch frequency → 每個 bin 往上找倍頻的能量並加到自己本身 → 每個 bin 分配到 chroma vector
我們使用的pitch frequency table是參考wiki的音高頻率表
另外就是這個演算法花的時間很久...
結果:
發現最下面那條Do的pitch class的能量一直非常大。後來發現是因為第一個bin大約是10.7666Hz左右，然而第一個bin一定是所有bin頻率的因數，對照pitch frequency table，10.7666Hz最接近的是C0(DO)，因此它的能量因此會最大。
忽略了第一根bin的結果:
發現變成是往上數第六條的能量最大，對照音名是FA。這是因為第二根bin也是好多bin們的因數，第二根bin頻率大約是21.5332Hz，對照表最接近的是F0，因此得知。後來和小明學長討論發現了另一個問題，都是關於應該需要去取平均的地方。
1. 冠廷學長做Chroma的方式，如果是採用每根bin就map到跟它頻率最接近的那個音之後加起來，那麼事實上他可能忽略了一個問題，低頻的部分兩根bin中間可能有好多的音在那個範圍，在高頻的部分可能在兩個音的範圍中間會有好多根bin，因此會有每個音所擁有的bin會不同數量的問題，我們實驗用white noise當作input，真的發現chroma的顏色並沒有分布的很均勻。所以應該要讓每個音除以它所擁有的bin的個數，取平均。
2. 在我們新加的方法中，低頻的bin會有較多的partial，所以能量加到自己身上之後，應該也要除以partial的個數來取平均。雖然這樣當能量懸殊的時候還是會造成彼此相對的差異減少，不過總是比沒有做normalize來的正確一些。
[20091201]
用BWV1007前四小節去跑，發現wav chroma錯誤了。
1. 前兩個音SO(低)、RE的部分，推論是因為五度音的關係，f0相差1.5倍，因此倍頻重疊了，RE的部分能量被認為是 SO 的。
2. 後面四個音也錯了，變成都是LA，推測是因為frame size不夠大，造成 fft 後頻率域的resolution不夠高。
origin frame size : 2048
frame size : 4096
frame size : 8192
可以看出增加frame size以增加frequency的解析度，結果準確許多。
不過第二個音 RE 的部分為什麼chroma顯示出來是 LA 的能量最強呢，是因為 RE 和 LA 是五度音嗎？
但是觀察spectrum，發現440 Hz左右真的有一條能量強的partial，所以不只是 RE 和 LA 第一個重疊的倍頻880Hz所分配給 LA 的部分。
→ 440Hz是這裡的 RE(146.83Hz) 的三倍頻沒錯，之前誤以為是它的高八度 RE(293.66Hz) ，而它的三倍應該是880Hz，所以才會疑惑為什麼會有440Hz的強能量。(20091202)
(按圖可放大)
另外，SO 的能量一直很強，造成餘音的效果。雖然譜上看起來是單音的樂曲，但是實際上是多音。可能是因為樂器的特性，第三個partial的能量特別強。
目前把頻率域的值map到chroma gram的方法是，準備一個10個八度音的frequency tabel，然後就去對和哪個pitch最接近，再map到chroma vector。
這樣的方法，五度音的partial能量會分配給兩者頻率較高的那一個。ex. RE (293.66Hz)的第三個partial、LA(440Hz)的第二個partial，大約是880Hz，而880Hz對照frequency tabel是LA。
但是學長也提到，如果採用傳統f0 detection的投票方法，那麼五度音的重疊partial能量會分配給兩者頻率較低的那一個音。
學長建議，接下來有兩條路。
第一條路，去解決五度音在chroma vector上表現的問題。
另一條路就是略過五度音的問題，找個沒有五度音的片段，往下找DTW在對譜時所展現的特性，也就是找DTW在對錯譜前後的參數變化情況。
[20091128]
把DTW 的matrix印出來。
本來是要印成文字檔，但是實在不好觀察，所以就做了另一個可以輸出成HTML的版本，這樣可以用簡單的方式去讓印出來的tabel上色和排列。
不過table真的很大，光是一分多鐘的dtw table的txt檔案，就可以達到450MB左右。
以下是用BWV1007前四小節的結果。
type 1 :
type 2 :
粉紅色底的格子是代表dtw找出來的path。
[20091124]
標音檔的SOP(手稿)
工作畫面
上方是cool edit，左邊是cue list(Desc欄寫pitch)，下方是catwalk，主要是拿來顯示譜。
[20091122]
標好了巴哈無伴奏大提琴BWV 1007 Prelude，大約兩分五十秒，655個音，655個cue。
每個cue我都給他一樣的長度(4096個sample)，因為要抓住那個音是哪個瞬間出現的有點難，所以後來決定去抓換音的瞬間，因為換音耳朵比較好辨認，所以我想起頭音的時間點就設cue的中點。
小筆記：
1. 20小節的地方音檔或譜似乎有錯，
音聽起來是do# la mi fa so mi fa so
譜是do# la do re mi do re mi
觀察DTW的時候可以注意一下這地方。
(應該是midi錯，因為去找過youtube上面的影片聽過跟wav是一樣的)
2. 發現mi不知道為什麼波形amplitude都比較大
3. 同一個音連續出現的話有點難聽出onset，所以是看波型來標。
之後，用之前的java程式去跑跑看，在作DTW一直出現例外 java.lang.OutOfMemoryError: Java heap space，有試著逐步幫JVM加大他的記憶體，但是還是出現一樣的例外。
所以我就想知道這樣的長度DTW到底需要多大的記憶體，就用學長之前的C#程式去跑，發現DTW大概吃掉1.5G左右的記憶體。可是給JVM這麼大的記憶體參數，會顯示無法建立的訊息。
目前wav的frame size是沿用學長的2048 overlap 512，想改成4096 overlap 2048，這樣可以減少frame的數量。此外midi是用一個tick當作一個frame，所以frame的數量很大。因此兩者所構成的DTW matrix使用的空間是很大的。
[20091112]
論文報告
An Efficient Multiscale Approach to Audio Synchronization
投影片
[20091023]
讀cue的程式寫好了，用 java去改寫，因為想說之前的chroma部分也是用java來做。
結果大概如下圖，測試的是原本語音的檔案。
因為我們的目的是要知道onset，所以對於cue來說，我們需要的就只是某個cue的起始時間。所以學長建議我，在幫音樂wav標onset的時候，cue的長度用很短就可以了。
現在我先著手標記巴哈無伴奏BWV1007的onset，因為它是單一樂器，而且它的節奏不會很快，可能會比較容易。現在覺得有個問題就是...要抓住並判斷音出現的那瞬間真的有點難@@
[20091006]
為了可以在wav上面標記出正確的onset作為比對資料，和小明學長去了吳老師實驗室詢問了一下，知道了可以用cool edit直接在wav檔裡面記錄cue list，方法很簡單，就是用滑鼠選取這個cue的範圍，然後按下F8就可以了。
學姊也給了一隻他們之前寫的程式給我，是用VC6+MFC環境寫的關係，還有它的output有用到資料庫，我的電腦上執行不起來，所以想說自己來改寫一個。
[20090924]
論文報告
Polyphonic Audio Matching and Alignment for Music Retrieval
投影片
[20090924]
學長的程式已經轉換到java完畢。
以前的程式架構，是每個步驟都是分散手動進行。
然後我現在把它整合在一起。
Improvement :
1. 整合、連貫各個project的功能。
2. 自行從GUI選擇讀取的檔案，不再受限於固定名稱。
3. draw onset frames
4. 可以使上下兩個scroll bar同步移動方便對照
程式畫面和流程 :
[20090908]
[20090831]
比起最之前的寫法，是多了把在smaple裡的lower byte & 0xff 這個步驟，因為這樣可以先確保他會先轉換成是一個positive的int，再轉換成short，這樣值就不會錯。如果直接轉換的話，他可能會認為byte值是負的然後就轉換到一個不正確的short，之後higher byte再往左移8 bit之後合併數值會有問題。之後也確認了這個方法與MATLAB的值一致。
另外，SO 的能量一直很強，造成餘音的效果。雖然譜上看起來是單音的樂曲，但是實際上是多音。可能是因為樂器的特性，第三個partial的能量特別強。目前把頻率域的值map到chroma gram的方法是，準備一個10個八度音的frequency tabel，然後就去對和哪個pitch最接近，再map到chroma vector。
這樣的方法，五度音的partial能量會分配給兩者頻率較高的那一個。ex. RE (293.66Hz)的第三個partial、LA(440Hz)的第二個partial，大約是880Hz，而880Hz對照frequency tabel是LA。
但是學長也提到，如果採用傳統f0 detection的投票方法，那麼五度音的重疊partial能量會分配給兩者頻率較低的那一個音。
學長建議，接下來有兩條路。
第一條路，去解決五度音在chroma vector上表現的問題。
另一條路就是略過五度音的問題，找個沒有五度音的片段，往下找DTW在對譜時所展現的特性，也就是找DTW在對錯譜前後的參數變化情況。
[20091128]
把DTW 的matrix印出來。
本來是要印成文字檔，但是實在不好觀察，所以就做了另一個可以輸出成HTML的版本，這樣可以用簡單的方式去讓印出來的tabel上色和排列。
不過table真的很大，光是一分多鐘的dtw table的txt檔案，就可以達到450MB左右。以下是用BWV1007前四小節的結果。
type 1 :
type 2 :
粉紅色底的格子是代表dtw找出來的path。
[20091124]
標音檔的SOP(手稿)
工作畫面
上方是cool edit，左邊是cue list(Desc欄寫pitch)，下方是catwalk，主要是拿來顯示譜。
[20091122]
標好了巴哈無伴奏大提琴BWV 1007 Prelude，大約兩分五十秒，655個音，655個cue。
每個cue我都給他一樣的長度(4096個sample)，因為要抓住那個音是哪個瞬間出現的有點難，所以後來決定去抓換音的瞬間，因為換音耳朵比較好辨認，所以我想起頭音的時間點就設cue的中點。
小筆記：
1. 20小節的地方音檔或譜似乎有錯，
音聽起來是do# la mi fa so mi fa so
譜是do# la do re mi do re mi
觀察DTW的時候可以注意一下這地方。
(應該是midi錯，因為去找過youtube上面的影片聽過跟wav是一樣的)
2. 發現mi不知道為什麼波形amplitude都比較大
3. 同一個音連續出現的話有點難聽出onset，所以是看波型來標。
之後，用之前的java程式去跑跑看，在作DTW一直出現例外 java.lang.OutOfMemoryError: Java heap space，有試著逐步幫JVM加大他的記憶體，但是還是出現一樣的例外。
所以我就想知道這樣的長度DTW到底需要多大的記憶體，就用學長之前的C#程式去跑，發現DTW大概吃掉1.5G左右的記憶體。可是給JVM這麼大的記憶體參數，會顯示無法建立的訊息。
目前wav的frame size是沿用學長的2048 overlap 512，想改成4096 overlap 2048，這樣可以減少frame的數量。此外midi是用一個tick當作一個frame，所以frame的數量很大。因此兩者所構成的DTW matrix使用的空間是很大的。
[20091112]
論文報告
An Efficient Multiscale Approach to Audio Synchronization
投影片
[20091023]
讀cue的程式寫好了，用 java去改寫，因為想說之前的chroma部分也是用java來做。
結果大概如下圖，測試的是原本語音的檔案。
因為我們的目的是要知道onset，所以對於cue來說，我們需要的就只是某個cue的起始時間。所以學長建議我，在幫音樂wav標onset的時候，cue的長度用很短就可以了。
現在我先著手標記巴哈無伴奏BWV1007的onset，因為它是單一樂器，而且它的節奏不會很快，可能會比較容易。現在覺得有個問題就是...要抓住並判斷音出現的那瞬間真的有點難@@
[20091006]
為了可以在wav上面標記出正確的onset作為比對資料，和小明學長去了吳老師實驗室詢問了一下，知道了可以用cool edit直接在wav檔裡面記錄cue list，方法很簡單，就是用滑鼠選取這個cue的範圍，然後按下F8就可以了。
學姊也給了一隻他們之前寫的程式給我，是用VC6+MFC環境寫的關係，還有它的output有用到資料庫，我的電腦上執行不起來，所以想說自己來改寫一個。
[20090924]
論文報告
Polyphonic Audio Matching and Alignment for Music Retrieval
投影片
[20090924]
學長的程式已經轉換到java完畢。
以前的程式架構，是每個步驟都是分散手動進行。
然後我現在把它整合在一起。
Improvement :1. 整合、連貫各個project的功能。
2. 自行從GUI選擇讀取的檔案，不再受限於固定名稱。
3. draw onset frames
4. 可以使上下兩個scroll bar同步移動方便對照
程式畫面和流程 :
[20090908]
學長的MidiParser專案轉換到java已完成，得到的結果也和學長的一致。bug仍然是出在byte的問題，不過由於上次的經驗，這次解決就快多了。
這個專案的功用是：讀取midi file並分析，得到midi的chroma，也輸入了上個步驟得到的wav chroma，將兩個chroma做DTW，最後輸出onset的資料。
另外發現學長midi的delta-time(variable-length quantity)算法好像有些錯誤。這部分還需要find out。
→ 學長沒有錯，是我誤解code的意思。 (20090909)
[20090831]
首先確定JAVA和C的input stream對於wav值都是使用同樣排列方法。
使用上次說的網站的方法去做會有問題，因為它這樣出來的值全部都會是正數，這樣不是我們想要的結果。所以我們要偵測第二個byte的highest bit是0還是1，如果是1的話，代表這是一個負數，所以我們在幫int的最高和第二高的byte補上1。
由此得到的int就是我們要的sample。和MATLAB的值對照過，兩者是相同的。
另外這是如果我們每一個sample想用short去存的方法。(最初是用short)
最後使用的是網路上找的java FFT code，學長使用的FFT code的結果，虛部會差一個正負號，但是因為我們用的是能量值所以不會影響到chroma。不過我不確定我找的那個是不是open source，能否自由使用...
能解決這個問題感謝DNA與小明學長的幫忙。接著我開始來改MIDI Parser的部分，找到了java有提供javax.sound.midi這個package，試看看能不能拿來在這個部分使用。
[20090824]
把兩邊程式的FFT結果印出來，發現值真的不同，著手改寫冠廷學長使用的c# FFT sourse code改成JAVA，錯誤還是存在。後來小明學長建議用MATLAB裡的wavread還有fft function去做，把從MATLAB得到的wav還有fft值分別和C#、JAVA讀到的wav之後用MATLAB fft做的結果去比較。
結果是發現JAVA的是在讀取wav檔的值就有錯了，每一個frame裡錯誤的個數、index都不一定，錯誤的element值和正確的值相差的都是256的倍數，目前測試結果最大可差別到256*8=2048。猜想可能是overflow之類的問題。
Google到這個網址，Reading and Writing Wav Files in Java，它說因為JAVA不像C語言，沒有unsigned type的設計，都是two's Complement，所以使用java的File-IO得到的資料還要經過處理，他提供的解法是比如說2 bytes的short 就用4 bytes的int來代替，int用long來代替。這個可能就是我們的問題所在，會用此方法來試試看。
[20090818]
與冠廷學長交接之後，開始著手改寫程式從C#轉到JAVA，這是為了將來可以使用在authoring tool上。目前改寫至可以運作的部分有：
1. Read wav file → FFT → Chroma Vector
2. Music Library
但是比對我的程式和學長的程式對同一個wav檔案所轉出來的chroma，發現能量最高(=1, because of normalization) 的地方在某一時間區段是不同的，後來覺得只比對能量=1的地方好像不是很好，所以以下是用圖片來呈現。發現c#的結果乾淨許多…
c#
java
由於學長程式的FFT是使用c#的open source code，我目前java的版本也是先使用外面找的java code，所以推測可能是在FFT這步驟出現不同所以導致結果不一致。老師建議把先FFT的結果印出來作驗證。
[20090714 by SCREAM Lab, NCKU, Taiwan. 位於 下午 6:08]
在MIREX2008裡面有一個比賽項目叫做Score Alignment, 網址如下:
MIREX2008 Score Alignment or Score Following
其實就是冠廷學長的論文其中的一部分. 冠廷用的是Chroma Feature, 其論文我們過一陣子再Post出來, 但是我們一貫的討論可以在下面看到:
冠廷的Polyphonic Music Information Retrieval
這個問題對我們很重要, 不過一般的Score Alignment做的要是能從頭Follow到尾, 也就是冠廷做的. 研究上當然是要如此完整, 但是假如以短時間內能用到我們要做的應用, 那麼是可以有一些妥協的. 比如說, 我們可以讓使用者把一段Wave框起來, 在讓它來對Target的譜子, 而且一次只要對一部分的譜就好, 例如四小節, 八小節, 長短就看我們的演算法的好壞.
這個串今天由我來起個頭, 接下來就由小聽來接續. 我建議可以將冠廷學長的方法先弄起來, 然後找其他人的論文來Implement, 久了後, 相信會越做越好, 也許有一天我們也可以去參加比賽.
另外就是Score Alignment會是Authoring tool的一部分.
