Music Information Retrieval - 冠廷

====20081118====

這週的進度式開始實做上週所報告的Paper

依照上週所報告的Paper

Input為wav file

資料庫端為midi file

而雙方都需要轉成Chroma Vector

再以時間為index去做DTW比對

而資料庫端的midi file照paper所說

也可以先轉成wav檔再轉成Chroma Vector

所以下週就可以先跑一些結果出來了

這是一部分Chroma Vector的結果

左邊為12個Chroma Bin

顏色的深淺代表能量高低 越淺代表能量越高

PPT File

 

====20081125====

繼上週所做的事情

就把剩下的程式給寫完了

並且做了一些實驗

PPT File


====20081202====

這週跑了多個版本的命運交響曲的實驗

以及想了一個計算Chroma Vector距離所可能會發生的問題

PPT File

備註:

1. 要開始做對樂譜和onset detection的部分

2. 也許可以用HMM從Chroma Vector找出音的多條路徑,再拿這些路徑的變化量去做DTW(用以解決key shift的問題)


====20081209====

這週我報告了一篇ISMIR2007的Paper

Paper內容是在說將掃描進電腦的樂譜(圖檔)和音樂錄音(wav,mp3)做Synchronization

也就是對譜的動作

而他使用的方法則是用我之前所報告的Chroma Feature來做比對

在此,我更正一下

我在報告Paper中有提到一點

關於一開始的音高記號如果OMR辨識錯誤的話

我當時說:"Paper說還是可以對的上"

抱歉,這一點是我在報告時講錯了

是我記錯了

Paper並沒有對於這一點有特別的說明

只有說那些local的臨時記號就算多錯幾個還是對的上

PPT File

====20081223====

這週的進度是把老師上週要我做的事情

回去想了程式流程圖

並完成了一部分的程式

以下是程式的流程圖:

MIDI:

經由MIDI parser處理之後

得到event

再經過處理

將其轉成以tick為時間單位的資料

再轉成chroma feature

WAV:

做完FFT之後

直接轉成chroma vector

接下來要將時間單位統一

由tick合併(透過MIDI的tempo可以換算成時間)

接下來分段做DTW比對

由比對的結果即可知道MIDI的onset的位置是對到WAV的哪個位置

而對到的這個位置 就是WAV的onset的位置

再經由這個位置 可以寫回MIDI File

另外老師上週有問我一個問題

褐色的部分是midi的部分 三個音時同時發聲

而紅色是真正的情況(wav) 時間點上可能會有一點點誤差

而做過DTW之後 褐色onset的位置 只會對到一個紅色的位置

而藍色的地方就是拿對到的onset的位置調整後的結果

如果需要三個音找到更正確的onset位置

則需要拿對到的onset附近的幾個frame下去做分析

目前進度:

由於程式需要midi的一些資訊以及最後又要寫回midi file

為了讓我對midi format以及順便了解舊的midi parser原本的問題在哪邊

所以我就用C#重寫了一個midi parser

也順利的找到了原本midi parser的問題所在

再順利的把event取出來之後

順利的把它拆成以tick為時間單位的資料

PPTX File

PPT File

====20081230====

紫色字的部分是我上週的進度

紅色字的部分是我這週的進度

藍色字的部分是我未完成的進度

而這週有做了一個實驗

先去看MIDI的Chroma和MIDI合成Wav的Chroma有沒有可能對的起來

必須要先對的起來

這樣MIDI的Chroma才有可能和實際演奏的Wav對的起來

而在某些樂器中的Chroma會長的有點奇怪

有可能是FFT Size太小 則可能會被分在同一個Bin,

也有可能是FFT Size夠大,但因為泛音的頻率偏掉太多,造成離另一個音比較接近

可能的解決方法有:

1.增大FFT Size 但Hop Size不變

2.改用小波轉換

3.先經過一個Low Pass Filter 再轉Chroma

而在投影片最後 有兩張圖

分別為MIDI轉Chroma 以及 實際演奏轉Chroma 的圖

另外我有想了一個解決key shift的方法

過幾天我會整理補上

PPT File

PPTX File

====想法====

這個想法是用來解決Key Shift的問題

DOC File

DOCX File

想法：

去記錄音高變化的趨勢，從Chroma Feature再去做一次轉換。

首先，會有一個Base Semitone，這個Base Semitone為多少是由上一個Frame的Chroma Vector來決定，而目前Frame的Chroma Vector會依照這個Base Semitone來做位移(Shift)的動作，所以如何決定Base Semitone將會影響到呈現出來的結果。我想了很久，我覺得可以設一個Threshold，如果能量大於或等於這一個Threshold的Semitone且這個Semitone是目前Base Semitone加N個Semitone而N為最小且N>=0，就當作是新的Base Semitone。

而位移(Shift)的動作就是將Semitone – Base Semitone，值如果為負值就再加上12，看值為多少，就將其Semitone的能量移至此位置；也就是說，如果原本的Chroma Vector為[0,0,1,0,0,0,0,0,0,0,0,0]，若Base Semitone為1，則轉換的結果為[0,1,0,0,0,0,0,0,0,0,0,0]，而位移後的結果，可以視為目前Frame和上一個Frame的音高變化是原本的音高再提高一個半音，由此也可以推測出上一個Frame的Chroma Vector有可能是長這樣：[0,1,0,0,0,0,0,0,0,0,0,0]。

以下我將舉個例子來說明，原本的Chroma Vectors如下：

	0	1	2	3	4	5	6	7	8	9	10	11
11	0	0	0	0	0	0	0	0	0	1	1	0
10	0	0	0	0	0	0	0	0	0	0	0	0
9	0	0	0	0	0	0	0	0	0	0	1	1
8	0	0	0	0	0	0	0	0	0	0	0	0
7	0	0	0	0	0	0	0	1	1	0	0	0
6	0	0	0	0	0	0	0	0	0	0	0	0
5	0	0	0.6	0.6	0.8	0	0	0	0	0	0	0
4	0	0	0	0	0	0	0	1	1	0	0	0
3	1	1	0	0	0	0	0	0	0	0	0	0
2	0	0	0	0	0	0.8	0.8	0	0	0	0	0
1	0	0	1	1	0.7	0	0	0	0	0	0	0
0	0	0	0	0	0	1	1	0	0	0	0	0

縱軸代表12個半音，橫軸代表時間(Frame Number)，而每一個值代表能量(音量)，假設Threshold = 0.6，值為0的位置可以視為原本就沒有能量或者是能量小於0.6。

接下來將一步步的將每一個Chroma Vector做轉換，以下的編號可以視為處理第n個Frame的過程。

0.在一開始，因為還未決定Base Semitone，所以要先決定Base Semitone，找最接近第0個半音且能量有超過Throshold的半音當作Base Semitone，在這個例子中Base Semitone為3，而轉後過後的Chroma Vector為[1,0,0,0,0,0,0,0,0,0,0,0]。

1. 此時Base Semitone為3，原本的Chroma Vector為[0,0,0,1,0,0,0,0,0,0,0,0]經過轉換的結果為[1,0,0,0,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為3。

2. 此時Base Semitone為3，原本的Chroma Vector為[0,1,0,0,0,0.6,0,0,0,0,0,0]經過轉換的結果為[0,0,0.6,0,0,0,0,0,0,0,1,0]，再重新決定Base Semitone為5。

3. 此時Base Semitone為5，原本的Chroma Vector為[0,1,0,0,0,0.6,0,0,0,0,0,0]經過轉換的結果為[0.6,0,0,0,0,0,0,0,1,0,0,0]，再重新決定Base Semitone為5。

4. 此時Base Semitone為5，原本的Chroma Vector為[0,0.7,0,0,0,0.8,0,0,0,0,0,0]經過轉換的結果為[0.8,0,0,0,0,0,0,0,0.7,0,0,0]，再重新決定Base Semitone為5。

5. 此時Base Semitone為5，原本的Chroma Vector為[1,0,0.8,0,0,0,0,0,0,0,0,0]經過轉換的結果為[0,0,0,0,0,0,0,1,0,0.8,0,0]，再重新決定Base Semitone為0。

6. 此時Base Semitone為0，原本的Chroma Vector為[1,0,0.8,0,0,0,0,0,0,0,0,0]經過轉換的結果為[1,0,0.8,0,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為0。

7. 此時Base Semitone為0，原本的Chroma Vector為[0,0,0,0,1,0,0,1,0,0,0,0]經過轉換的結果為[0,0,0,0,1,0,0,1,0,0,0,0]，再重新決定Base Semitone為4。

8. 此時Base Semitone為4，原本的Chroma Vector為[0,0,0,0,1,0,0,1,0,0,0,0]經過轉換的結果為[1,0,0,1,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為4。

9. 此時Base Semitone為4，原本的Chroma Vector為[0,0,0,0,0,0,0,0,0,0,0,1]經過轉換的結果為[0,0,0,0,0,0,0,1,0,0,0,0]，再重新決定Base Semitone為11。

10. 此時Base Semitone為11，原本的Chroma Vector為[0,0,0,0,0,0,0,0,0,1,0,1]經過轉換的結果為[1,0,0,0,0,0,0,0,0,0,1,0]，再重新決定Base Semitone為11。

11. 此時Base Semitone為11，原本的Chroma Vector為[0,0,0,0,0,0,0,0,0,1,0,0]經過轉換的結果為[0,0,0,0,0,0,0,0,0,0,1,0]。

轉換的結果如下：

	0	1	2	3	4	5	6	7	8	9	10	11
11	0	0	0	0	0	0	0	0	0	0	0	0
10	0	0	1	0	0	0	0	0	0	0	1	1
9	0	0	0	0	0	0.8	0	0	0	0	0	0
8	0	0	0	1	0.7	0	0	0	0	0	0	0
7	0	0	0	0	0	1	0	1	0	1	0	0
6	0	0	0	0	0	0	0	0	0	0	0	0
5	0	0	0	0	0	0	0	0	0	0	0	0
4	0	0	0	0	0	0	0	1	0	0	0	0
3	0	0	0	0	0	0	0	0	1	0	0	0
2	0	0	0.6	0	0	0	0.8	0	0	0	0	0
1	0	0	0	0	0	0	0	0	0	0	0	0
0	1	1	0	0.6	0.8	0	1	0	1	0	1	0

 

接著，再依照這個結果，給予不同的Base Semitone，即能還原回原本的Chroma Feature，紅字粗體的能量所代表的Semitone為Base Semitone。

還原的過程如下所述，以下的編號可以視為還原第n個Frame的過程。

假設一開始的Base Semitone給予3，照理來說，結果會與原本的Chroma Feature一樣。

0. 此時Base Semitone為3，將[1,0,0,0,0,0,0,0,0,0,0,0]還原成[0,0,0,1,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為3。

1. 此時Base Semitone為3，將[1,0,0,0,0,0,0,0,0,0,0,0]還原成[0,0,0,1,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為3。

2. 此時Base Semitone為3，將[0,0,0.6,0,0,0,0,0,0,0,1,0]還原成[0,1,0,0,0,0.6,0,0,0,0,0,0]，再重新決定Base Semitone為5。

3. 此時Base Semitone為5，將[0.6,0,0,0,0,0,0,0,1,0,0,0]還原成[0,1,0,0,0,0.6,0,0,0,0,0,0]，再重新決定Base Semitone為5。

4. 此時Base Semitone為5，將[0.8,0,0,0,0,0,0,0,0.7,0,0,0]還原成[0,0.7,0,0,0,0.8,0,0,0,0,0,0]，再重新決定Base Semitone為5。

5. 此時Base Semitone為5，將[0,0,0,0,0,0,0,1,0,0.8,0,0]還原成[1,0,0.8,0,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為0。

6. 此時Base Semitone為0，將[1,0,0.8,0,0,0,0,0,0,0,0,0]還原成[1,0,0.8,0,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為0。

7. 此時Base Semitone為0，將[0,0,0,0,1,0,0,1,0,0,0,0]還原成[0,0,0,0,1,0,0,1,0,0,0,0]，再重新決定Base Semitone為4。

8. 此時Base Semitone為4，將[1,0,0,1,0,0,0,0,0,0,0,0]還原成[0,0,0,0,1,0,0,1,0,0,0,0]，再重新決定Base Semitone為4。

9. 此時Base Semitone為4，將[0,0,0,0,0,0,0,1,0,0,0,0]還原成[0,0,0,0,0,0,0,0,0,0,0,1]，再重新決定Base Semitone為11。

10. 此時Base Semitone為11，將[1,0,0,0,0,0,0,0,0,0,1,0]還原成[0,0,0,0,0,0,0,0,0,1,0,1]，再重新決定Base Semitone為11。

11. 此時Base Semitone為11，將[0,0,0,0,0,0,0,0,0,0,1,0]還原成[0,0,0,0,0,0,0,0,0,1,0,0]。

還原的結果如下：

	0	1	2	3	4	5	6	7	8	9	10	11
11	0	0	0	0	0	0	0	0	0	1	1	0
10	0	0	0	0	0	0	0	0	0	0	0	0
9	0	0	0	0	0	0	0	0	0	0	1	1
8	0	0	0	0	0	0	0	0	0	0	0	0
7	0	0	0	0	0	0	0	1	1	0	0	0
6	0	0	0	0	0	0	0	0	0	0	0	0
5	0	0	0.6	0.6	0.8	0	0	0	0	0	0	0
4	0	0	0	0	0	0	0	1	1	0	0	0
3	1	1	0	0	0	0	0	0	0	0	0	0
2	0	0	0	0	0	0.8	0.8	0	0	0	0	0
1	0	0	1	1	0.7	0	0	0	0	0	0	0
0	0	0	0	0	0	1	1	0	0	0	0	0

 

假設一開始的Base Semitone給予4。

0. 此時Base Semitone為4，將[1,0,0,0,0,0,0,0,0,0,0,0]還原成[0,0,0,0,1,0,0,0,0,0,0,0]，再重新決定Base Semitone為4。

1. 此時Base Semitone為4，將[1,0,0,0,0,0,0,0,0,0,0,0]還原成[0,0,0,0,1,0,0,0,0,0,0,0]，再重新決定Base Semitone為4。

2. 此時Base Semitone為4，將[0,0,0.6,0,0,0,0,0,0,0,1,0]還原成[0,0,1,0,0,0,0.6,0,0,0,0,0]，再重新決定Base Semitone為6。

3. 此時Base Semitone為6，將[0.6,0,0,0,0,0,0,0,1,0,0,0]還原成[0,0,1,0,0,0,0.6,0,0,0,0,0]，再重新決定Base Semitone為6。

4. 此時Base Semitone為6，將[0.8,0,0,0,0,0,0,0,0.7,0,0,0]還原成[0,0,0.7,0,0,0,0.8,0,0,0,0,0]，再重新決定Base Semitone為6。

5. 此時Base Semitone為6，將[0,0,0,0,0,0,0,1,0,0.8,0,0]還原成[0,1,0,0.8,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為1。

6. 此時Base Semitone為1，將[1,0,0.8,0,0,0,0,0,0,0,0,0]還原成[0,1,0,0.8,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為1。

7. 此時Base Semitone為1，將[0,0,0,0,1,0,0,1,0,0,0,0]還原成[0,0,0,0,0,1,0,0,1,0,0,0]，再重新決定Base Semitone為5。

8. 此時Base Semitone為5，將[1,0,0,1,0,0,0,0,0,0,0,0]還原成[0,0,0,0,0,1,0,0,1,0,0,0]，再重新決定Base Semitone為5。

9. 此時Base Semitone為5，將[0,0,0,0,0,0,0,1,0,0,0,0]還原成[1,0,0,0,0,0,0,0,0,0,0,0]，再重新決定Base Semitone為0。

10. 此時Base Semitone為0，將[1,0,0,0,0,0,0,0,0,0,1,0]還原成[1,0,0,0,0,0,0,0,0,0,1,0]，再重新決定Base Semitone為0。

11. 此時Base Semitone為0，將[0,0,0,0,0,0,0,0,0,0,1,0]還原成[0,0,0,0,0,0,0,0,0,0,1,0]。

還原的結果如下：

	0	1	2	3	4	5	6	7	8	9	10	11
11	0	0	0	0	0	0	0	0	0	0	0	0
10	0	0	0	0	0	0	0	0	0	0	1	1
9	0	0	0	0	0	0	0	0	0	0	0	0
8	0	0	0	0	0	0	0	1	1	0	0	0
7	0	0	0	0	0	0	0	0	0	0	0	0
6	0	0	0.6	0.6	0.8	0	0	0	0	0	0	0
5	0	0	0	0	0	0	0	1	1	0	0	0
4	1	1	0	0	0	0	0	0	0	0	0	0
3	0	0	0	0	0	0.8	0.8	0	0	0	0	0
2	0	0	1	1	0.7	0	0	0	0	0	0	0
1	0	0	0	0	0	1	1	0	0	0	0	0
0	0	0	0	0	0	0	0	0	0	1	1	0

而這個結果其實就是原本的Chroma Feature將音高移高一個Semitone的Chroma Feature，而要將其還原的原因並不是要證明這個結果是可以還原的，而是要證明說只要旋律相同，不論這個音樂是什麼調，經過轉換後的結果是一樣的。

但是這邊還有一個疑問，如果兩個來源轉換出來的Chroma Feature可能中間有一小段的不同，那經過轉換的結果又會有什麼不同呢？

經過部分變更的來源：

	0	1	2	3	4	5	6	7	8	9	10	11
11	0	0	0	0	0	0	0	0	0	1	1	0
10	0	0	0	0	0	0	0	0	0	0	0	0
9	0	0	0	0	0	0	0	0	0	0	1	1
8	0	0	0	0	0	0	0	0	0	0	0	0
7	0	0	0	0	0	0	0	0	1	0	0	0
6	0	0	0	0	0	0	0	0	0	0	0	0
5	0	0	0.6	0	0	0	0	0	0	0	0	0
4	0	0	0	1	1	0	0	0	1	0	0	0
3	1	1	0	0	0	0	0	1	0	0	0	0
2	0	0	0	0	0	0.8	0.8	0	0	0	0	0
1	0	0	1	0	0	0	0	0	0	0	0	0
0	0	0	0	0	0	1	1	0	0	0	0	0

轉換的結果如下：

	0	1	2	3	4	5	6	7	8	9	10	11
11	0	0	0	1	0	0	0	0	0	0	0	0
10	0	0	1	0	0	0.8	0	0	0	0	1	1
9	0	0	0	0	0	0	0	0	0	0	0	0
8	0	0	0	0	0	1	0	0	0	0	0	0
7	0	0	0	0	0	0	0	0	0	1	0	0
6	0	0	0	0	0	0	0	0	0	0	0	0
5	0	0	0	0	0	0	0	0	0	0	0	0
4	0	0	0	0	0	0	0	0	1	0	0	0
3	0	0	0	0	0	0	0	1	0	0	0	0
2	0	0	0.6	0	0	0	0.8	0	0	0	0	0
1	0	0	0	0	0	0	0	0	1	0	0	0
0	1	1	0	0	1	0	1	0	0	0	1	0

觀察這個結果與之前的結果，其來源是由原本的來源的第3、4、7個Frame修改後而成，而比對結果，與原本結果不同的為第3、4、5、7、8，其它地方還是相同的，所以只要這種不同的Frame不要太多，還是可以利用DTW來做對譜的動作。

 

====20090108====

這一週的進度取得了Onset的"大概位置"

接下來可能會用傳統的方式靠energy來取得比較正確的位置

接著我也會試著修改計算distance的方法

來試試看結果會不會比較好!

投影片中有一些解決Key Shift的資料

詳細的資料已在上方

其中學長有問說:為什麼我base semitone要一直改,不用同一個就好了

其實這問題我也想過

我meeting時回答的可能不好

我再重新整理一下

如何決定base semitone是一個問題

假設只以一開始決定base semitone就不更改的話

那有個先決條件

就是"這兩首歌的頭要對齊"

所以就不能用片段去對整首歌了

接著探討一下如果中間走音的話情況會如何

如果中間部分走音是shift一大段的pitch

那只以一開始的base semitone做調整的話

那這邊對過去可能會這一整片都有很大的distance (因為一整段走音 整個對不上)

但如果是用前一個frame的base semitone的話

那會有比較大distance的部分 會是"剛"走音的那幾個frame (影響範圍有限)

(如果之後又轉換回原本的pitch,那在剛轉換的那幾個frame的distance也會變大)

而整段走音的部分

因為變化趨勢還是一樣的

所以我認為distance不會變大

 

此外上週有一個Chroma Feature的圖

能量是集中在最上方的Chroma Bin

這是我寫程式的疏忽

把大於某個頻率的能量都分配到那根Bin

此Bug已解決

PTT File

PPTX File

 

====20090113====

這週的進度為

將由DTW比對後的結果 (概略的Onset位置)

在做一次調整

 

調整方法為

第i個frame的x音的能量比例 -  第i-1個frame的x音的能量比例

如果大於threshold的話 則可能為Onset所在

 

途中

1.老師有提到說可以參考其它同時發聲的其它音高的Onset位置

2.DNA有提到說threshold的假設可以說是

經由取斜率(微分)的結果 大部分都是0.3(假設) 所以才設為0.3

 

其實當時我還聽不懂取斜率(微分)是該怎麼做

後來問DNA後 才知道就是後面的frame和前面的frame做相減

哈哈 請恕我才疏學淺 沒反應過來

PTT File

PPTX File

====20090119====

本週做了一個小小的實驗

我修改了Midi和Wav計算距離的方法

 

主要是Midi轉Chroma後

同一個時間點通常只會有1~3個不等的Chroma elements有值

所以我的想法是只去比對這些有值的elements

而其它elements就先忽略

這個概念源自於阿扁講過的 "頭過身就過"

我就想說就只要比對這些有值elements就好了

而那些沒有值的elements如果去和wav比的話

反而會成為拉大distance的主因 !!

 

做了一個小實驗

以16秒的片段歌曲當做是input

去search完整的Midi file

共有五首片段歌曲

其中第五首是現場演奏

而前四首是Midi file而成出來的Wav file

 

因為樣本數太少

所以成功率的話..請各位看倌打個折扣

表格中的數字代表distance

越小代表越相近

 

而接下來會將input的Wav file加上reverb的效果

再跑一些實驗看看

PTT File

PPTX File

 

====20090224====

繼續之前做的

只針對Wav File取一段去搜尋MIDI File

方法依然為DTW配合Chroma Feature

修改距離的計算方法

由原本的

修改為

因為MIDI File可以知道哪些音高有能量

所以只針對有能量的音高做運算

所以假設只有A音高有能量

則計算過程為

若A音高和B音高有能量

則計算過程為

輸入的Wav File有原始音檔(MIDI File合成)取16秒

以及Reverberate後的Wav File

其中做Dark Hall後的音檔和原本的音檔差異不大 (耳朵要很仔細聽才聽得出來)

Large Empty Hall差異比較大 (波形差很多 耳朵馬上可以聽出來)

 

結果還不錯 表格中的數字為距離

越小代表越相似

但是因為樣本數有點少

真正的結果得等我跑完真正的大實驗才會知道

不過我預想效果應該不會太差 (純屬預想)

因為經過Reverberate後的音檔  每個音高的能量比例會變

依照原始的方法

如果原本是符合的 經過這個一變動  在距離的計算就會變大  (因為其它音高會跑出能量 拉大距離)

但如果只比對MIDI File有能量的音高 則照理說可以避免掉這個問題

 

PTT File

PPTX File

 

====20090227====

我整理一下週五和老師討論的內容

如果有理解錯誤的話 請指正

由於文森部分的Partial Tracking無法知道目前的F0到底是D4還是D5

所以我的部分相當於一個前處理的機制

在對完譜之後可以知道每一段對到譜上為哪些音 Ex: D4

所以可以把這個資訊告訴Partial Tracking的部分

這樣Partial Tracking就可以知道目前的F0是D4而不是D5

 

====20090303====

我整理一下我之前做的結果

不然可能有點亂

依照原本的方法

不管原本資料庫端或者輸入端是MIDI或Wav都無所謂

反正都可以直接轉為Chroma Vector再計算歐幾里得距離

 

但是假設其中一方一定是MIDI的話

則就可以知道目前是哪幾個音高為有能量的

所以可以針對那幾個有能量的音高去計算距離即可

這個方法可以避免掉reserb的影響

 

而我改善Key Shift的方法

則和原本方法一樣

不限制雙方為MIDI或Wav

 

如果資料庫端是MIDI  輸入端為Wav的話

做完DTW後所對到的結果

可以透過MIDI所給的資訊

找到Wav的Onset位置

而這個位置 可以再透過每個音框的音高的能量

去修正 找到更精確的Onset位置

 

但是如果要和其它paper比較的話

大多數的paper還是資料端和輸入端都是wav為主

 

而我這週做的就是把我之前所講的Key Shift的方法給實做

並且跑一些數據

卡農這首歌曲效果不彰的原因是

我取的那一小段歌曲在原音裡面的後段 就有經過移調然後重覆出現

 

我接下來會用最原始的方法測試經過reserb之後的音檔來搜尋會有多差

以及跑一下切巴哈無伴奏的結果

 

PTT File

PPTX File

 

====20090310==== 

我又要來推翻我所說的話了

果然沒做過實驗之前所講的話需要打50%的折扣

 

如果資料庫端和輸入端都是wav的話

資料庫端為原曲

輸入端為原曲取16秒後經過reverb處理

其中我試過的種類有

Full Reverb  (Medium Concert Hall (open))

Large Empty Hall Reserb

Shower Reverb

而音檔是使用Bach裡面的The Anna Magdalena Notebooks中的四首歌曲

anna-03 anna-04 anna-07 anna-10

以及Mozart的

Violin concerto No.1 in Bb, K.207 (Allegro moderato)   vck207-1

Violin concerto No.2 in D, K.211 (Allegro moderato)   kv211-1

Violin concerto No.3 in G, K.216 (Allegro)   kv216-1

做完實驗的結果其實並沒有想像中的差

(資料庫中如果是MIDI的話  直接與Wav做DTW結果本來就不好  再reserb的話會更亂)

雖然distance有變大

但是還是比其它歌曲小

表格中的數字為Distance

Distance越大 代表越不相似

縱軸為Input  橫軸為資料庫端

不管有沒有經過Reverb

輸入端的片段歌曲 都可以成功的找到原始歌曲

 

同樣的音檔把資料庫中替換為MIDI File

並且使用原本的方法來做Search

以及用改善的方法來做Search (改善的方法有po在上週)

其實總體來看 是會比較好的

但是有些結果卡在第二名的原因是

其中有一首MIDI 在某段是沒有聲音的

這會造成我在計算Distance時 給他為0

所以這首歌在計算Distance時 不管是跟哪一首歌計算

Distance的結果都是非常低

順便一提 這次我用的樣本在經過Reverb之後Search的排名都沒有變

 

這次的結果我有列出排名

而修改後的方法也有與修改前的方法比較排名 (上升or下降)

 

 

接下來說明一下 我和文森的部分該怎麼做整合

首先 我這部分 MIDI和Wav 經過DTW之後 會輸出一份Onset的時間點以及音高

而同樣的Wav經過Partial Tracking之後 會輸出

Partial的音高

開始時間

持續時間

能量

並且會標明是屬於哪個Group(F0)

 

我想的修正方法很簡單

總之Parial Tracking會先有一份答案

然後再以DTW的結果

去看Onset 時間點附近的有沒有起始時間差不多的Partial

如果有的話 則去比對音高(頻率)

若有找音高相同的Partial

則把這個Group的F0更新為找到的這個Parial (可能更新前後不會變)

若沒找到 則可能是有幾個問題

1.連音問題  (時間點附近都沒Partial,因為連音,Partial Tracking把它連起來了)

2.譜錯 或者是 彈錯了 (雖然時間點附近有Partial 可是音高卻不同)

我現在比較傾向於先把這些程式整合搞定了再來解決這兩個問題XD

 

而在修正之後的輸出結果 會是 F0的音高 開始時間 持續時間 能量

接著就可以做合成了!

 

PPT File

PPTX File

 

====20090324====

這一週測了幾首歌的Onset (利用MIDI和DTW)

但是由於MIDI的問題

所以目前只有一首歌找個還算不錯

這首歌是

Bach的Sonata No.1 in G-, BWV1001 (Siciliano)

由於Onset過多 我只取了幾個而已

結果請看投影片的圖!

PPT File

PPTX File

 

另外有一個正規化的問題

一種是向量除以vector norm

另一種則是把一個向量的值mapping到0-1

轉檔程式會將兩種都轉出來

並著名是n1或n2

 

====20090401====

開始著手研究文森的程式

取得我想要的資訊

但卻發現 一首歌要下去分析實在是太龐大了 (跑不動)

只好分段下去跑

目前的想法是

分段下去跑  假設每一段是5秒鐘

可是這分段的時間位置 不一定就是音高的起始/結束

所以分析完的結果 必須得另外做一個合併的處理

 

依照文森目前的程式

Partial的頻率

起始Frame Index

持續的Frame Number

能量

F0

都可以取得

但是還沒有分Group的動作

 

我所謂的分Group的動作是指

400Hz 600Hz 這兩條 跟200Hz這一條 會是同一個Group

 

而對於分段後合併的想法

我合併的想法很簡單

如果前面那一段的Group的結束時間 和 後面這一段的Group的起始時間接近

且F0相同

那就合併

 

====20090421====

很久沒來寫了=_=

我補一下之前的東西

 

對Onset這部分

我找了很久 雖然網路上有Bartok 的midi

但是沒有老師給我那片CD的曲目...

我曾經試過去找wav轉midi的轉檔軟體

但是效果很差...

我覺得似乎...花錢請專家做midi比較快 囧

 

再來就是之前修改學長合成程式的部分

我稍微記錄一下

一開始我先把學長程式內Filter的觀念搞懂

其實也沒什麼 就跟slim差不多

不過有差別的是

學長寫的Filter 不是 Multi Thread

這個我畫的圖

分別標明了程式執行的順序

 

在搞懂了Filter之後

我就去看了學長合成程式也哪些Filter

大概就是長這樣

我把Noise的部分關掉 所以有關Noise的部份我沒有理會

而我看了程式之後 真正要改的只有 標明紅色的三個Filter

 

fAPP負責傳送AbstractPara

AbstractPara 就是 F0 和 Amp

經過fAP2SPI長出20個partial的Amp (這樣是一個Sinusoid)

再透過fSI2RIA的addPartial()這個method處理

 

那些方法的細節 我就不多講了

因為都是學長寫的XD

我的修改方法只是將

fAPP傳送AbstractPara 改成 傳送AbstractPara []   <---就是一堆Fo和Amp

fAP2SPI傳送Sinusoid 改成 傳送Sinusoidp[] <---就是好幾組Sinusoid

這邊都ok 反正就是多加for迴圈下去跑

 

接著就是fSI2RIA

其實也沒改什麼

比較要處理的就是phase

注意不同音的phase要另外算就行了

 

但是!!!

其實學長的程式實在是博大精深了

所以我只好先延用他的button來跑我改的程式XD

並沒有加一個新功能在內

 

其實之前都是會錯意...原來f0和能量是每個frame都有...

所以又重畫了一張流程圖 應該是要長這樣!

DTW只輸出onset的frame index和音高

接著和Partial Tracking的結果做修正

但其實我覺得我修正的方法還很差...

我想這部分是可以改進的

我只是去找時間差不多近的那一條partial而已

但是其實可能會誤判

我想比較好的方法 應該是寫一個Application

最後讓使用者自己修正一下比較好

甚至也可以讓使用者任意修改F0 合成出來的結果就會不同XD

 

所以這邊修正完會輸出成F0和能量

當然一個Frame會有多個F0

接著再丟給合成程式

聲音就出來了XD

 

接著...我會邊轉CD...邊寫論文...邊養身體>"<

等口試後我會把程式重整一次...並且詳細的寫上"註解"

 

====20090423====

貝多芬 String Trio in C-, Op.9, No.2

我成功抓到wmv檔案  也有了MIDI FIle

我兩邊都抓取部分來對Onset 感覺還OK? (私心的自己覺得>"<)

Part1

 

Part2

 

當然合成的程式我也有跑

但是 結果似乎不太好

我用的partial tracking的程式是0309的那版 (最初版)

不過我想等文森那邊都完成的話 合成出來的結果會變很棒

原因我整理一下

1.連線中間斷掉

2.低頻的都找不到?  我用cool edit看頻譜其實很明顯一條 但是低於100hz

 

稍微記錄一下 我今天跟老師談的內容

論文

1.第一章 Introduction

把一堆相關paper都寫進去

也當reference

切記要寫張智星老師的paper進去XD

2.第二章 簡單介紹DTW和Chroma Feature

3.第三章 Partical Tracking + DTW + 合成  (onset要在這章?)

4.第四章

4-1 利用Partical Tracking 結果 加強Chroma Feature

4-2資訊檢索

5.第五章 實驗

 

====20090424====

利用Partical Tracking結果 加強Chroma Feature

讓那些音高更明顯

從Partical Tracking的結果輸出F0 List

並且轉成12個音階

利用這個結果 加強原本Chroma Feature

若Partical Tracking結果對應到Chroma Feature的音高

就加個權重 ex: 平方? 乘以2之類的

 

====20090428====

流程圖

我這邊Enhance的方法是把能量乘以2

以下是Enhance之後的結果

Part1

Enhance前

Enhance後

Part2

Enhance前

Enhance後

Part3

Enhance前

Enhance後

PPT File

PPTX File

====20090501====

我在Key Shift這邊，有一段解釋，是故意製造錯誤之後，再觀察經由Base Semitone轉換的結果

原文是這樣的:
觀察這個結果與之前的結果，其來源是由原本的來源的第3、4、7個Frame修改後而成，而比對結果，與原本結果不同的為第3、4、5、7、8，其它地方還是相同的，所以只要這種不同的Frame不要太多，還是可以利用DTW來做對譜的動作。

我後來發現...打這些字好像有誤導大家的嫌疑，因為我後來看，我也覺得我自己被我自己誤導了！所以要跟大家say sorry一下！

我今天報告後，想了很久，我想得在重新整理一下。

DTW除了計算Distance，還能取得Input和Reference的對應位置，至於對應位置的正確性，則就要看兩邊的時間(Index)上的內容，而DTW本來就能夠容忍部分的錯誤，至於容忍多少，要看那錯誤的片段有多長，以及那錯誤片段與原本正常片段的差距有多少(Distance)。

而我先前解決Key Shift的方法，有提到如果片段錯誤的話，那轉換的結果影響範圍有限，其實這點也只是保留原本Chorma的特性而已。

先看原本的Chroma，假設一首歌前半部的音高是錯的，而後半部的音高是對的，那轉成Chroma之後，自然也是呈現"錯對"的樣子。

而所以希望經過Base Semitone轉換之後的結果，也是跟原本的Chroma一樣，會是"錯對"的情況出現。

之所以提到這點，是因為當初在想轉換的方法時，都會想說只靠個某個Frame的某樣屬性做轉換，例如只靠第一個Frame的最高能量音高做轉換，但如果那個Frame剛好是的錯，那就慘了。假設有兩首一樣的歌，但是其中一首歌的第一個Frame是錯的，那兩首歌經過轉換後，會完全長得不一樣。

直接把例子套上以上的說法，原曲在Chroma上是"對對"的情況，而Query(假設前半部和原曲是不同的)在Chroma上是"錯對"的情況，如果靠著第一個Frame的某樣屬性做轉換，原曲依然是"對對"(我們假設他是對的，因為是放在資料庫)，而Query則會變成"錯錯"的情況(因為是依賴第一個Frame做轉換，但因為第一個Frame和原曲不同)，這個"錯錯"的情況意思是說，他跟原曲轉出來的不管是前半部還是後半部，都會長得不一樣。

而解決Key Shift也還有保留另一樣Chroma的特性，那就是從原曲任一時間點上擷取片段，和原曲整首直接轉再去擷取片段，不會有太大差異。(當然不可能完全一樣，從不同的sample點做FFT會有些微能量值的差異)

Chroma很直覺，擷取其中幾秒的歌曲片段，轉Chroma，會和將整首歌轉Chroma之後時間點相同的片段長的差不多。

所以希望新的轉換方法，也能有同樣的效果，不管我是擷取哪個時間點的片段做轉換，都希望能和原曲直接做轉換，接著看同樣時間點的片段的結果差不多。

很明顯Base Semitone的轉換方法有做到這一點，因為只參考前面一個Frame。

 

補充一下

如果"錯"的部分是key shift的話,那轉出來的結果,不會是"錯"的

 

====20090505====

Partial Convert to Chroma

F0 List + Chroma => Chroma  (上週弄的)

F0 List => Chroma (拿f0 detection的結果直接轉chroma)

F0 List + Partial List => 128 dimensional (將f0和partial轉成128維度的向量)

F0 List + Partial List => Chroma (將f0和partial轉成chroma)

 

因為時間的關係 我只跑了F0 List + Partial List => Chroma

本來也想跑F0 List + Partial List => 128 dimensional 看看

但是show圖的程式 我來不及改了XD

 

總之先看一下結果

FFT=>Chroma

F0 detection enhance 上一張圖

Partial Tracking=>Chroma

 

總覺得Partial Tracking的結果很漂亮

但跟原圖的時間點有小小的差異

應該是FFT Size取很大的緣故

 

再補兩張 Partial Tracking=>Chroma

有些地方有斷掉 那是因為Partial Tracking我跑的是舊版程式

所以沒有補點

還有少部分的斷掉是Partial Tracking沒有連起來

PPT File

PPTX File

 

====20090505====

paper pdf file

昨天睡覺前無意間發現一篇paper

結果因為某部分很重要的地方看不太懂 讓我輾轉難眠

我英文還是太差了 誤會了他敘述的意思

多謝了小明學長替我解惑

 

這篇paper某個部分和我先前講的 解決key shift的方法類似

其實了解了之後...也覺得他的想法很簡單

但是當初就是沒想到><

 

這一張圖是原音轉Chroma

這一張圖代表的是原圖的 第 n+1 個frame 和 第 n 個frame 位移幾個半音之後的相似度 (縱軸是位移幾個半音)

 

所以簡單來說 他就是去記錄 前後frame 之間 移調後的相似度

 

而我講的方法 則是去參考前一個frame的最大能量個半音 為何

去調整目前這一個frame 的 Chroma Vector

用上一個frame的最大能量半音 來紀錄目前這一個frame要移調幾個半音 並且記錄有多少能量

 

所以

兩個方法都有去參考前一個frame

在記錄一種走勢

 

老師問我說 那他們的方法可以還原成原本的Chroma嗎?

我想答案是不行的

因為只有C圖的話 那只記錄相似度

只能大概猜出frame的走勢

至於這個走勢是從哪幾個音高 或者是 幾個音 所造成的

那就不得而知了

 

不過他們的paper並不是只拿C圖當特徵而已

原本的A圖也有

比對方法不是用DTW

詳細部分我沒有看

我只看Chroma Feature而已

 

補充:

我講的方法其實不是看最大能量的音高

而是有設一個Threshold

講最大能量只是為了方便說明和想像

不取最大能量的原因是

因為音檔是多音的

從單一首歌同樂器同調來看的話

並不能確定不同演奏家都會演奏時 某個音高一定會能量最大

從單一首歌同演奏家不同樂器同調來看的話

並不能確定不同樂器演奏時 某個音高一定會能量最大

從單一首歌同演奏家同樂器不同調來看的話

能量多寡也不會單單是往上移幾個半音這麼簡單

 

其實有點亂XD 我也不知道我的想法對不對

有待實驗證明...

 

====20090512====

我把上面那篇paper講的feature實做出來

並且和我的方法做比較

PPT File

PPTX File

 

====20090519====

MIDI輸出的格式

目前我覺得可以用最流行的xml來紀錄

不然用一般的寫檔也是可以

 

輸出格式 以Track為單位

這邊的Track跟MIDI定義的Track不同

一個Track代表一條音

 

而時間的問題

我們討論的結果 決定弄一個統一的絕對時間

但是最小的單位時間 需要討論一下

另外頻率和音量 我們決定用陣列來存

因為希望這個格式 是一個統一個格式

而這個格式也能吃從文森程式output的結果

 

class Track

{

int 樂器id;

float[] 頻率;

float[] 能量;

int 起始單位時間;

int 持續單位時間;

Control[] control;

}

class Control

{

int type;  //紀錄 control種類, ex: vibrato 就填1

int subType;  //紀錄 是哪一個子類, ex: vibrato有三種,如果要第二種,就填2

string tablePath;  //如果type是user define, 會由使用者指定這個路徑

int 起始單位時間; //在這個Track的單位時間多少時發生

int 持續單位時間;

}

 

====20080609====

 

我覺得我之前search MIDI Database的公式有點不太合理

所以我做了一些修改

原本是MIDI 轉 Chroma 後 看有幾個音高有發音  就去計算那幾個音高的distance

所以如果MIDI 轉 Chroma 後的音高越多的話 那distance會越大

所以我將公式改為 在開根號之前 先除以n

n就是轉Chroma後有幾個音高

老師生日快樂

今天中午跟塞公去買了巴肥特推薦的"克林姆之宮"的千層蛋糕。 本來一進門要唱生日快樂歌的，大家實在是鳥掉了... 一群大男生還會拍謝...

加油，好嗎？


老師吹蠟燭~
老師切蛋糕 (老師彷彿知道我們有準備special的，今天穿的特別煙斗~)

老師交待小新要帶學妹做壓縮的部份，小新聽到要負責帶學妹開心的笑了~ 各位看官看小新比當壽星的老師還開心 !!!(疑，什麼是smallnew+呀？)

粗糙相機，當然沒有aaa的大炮好，照的不好請大家包涵啦 :D

8051 core - 品皓

====================6/15===========================
整個8051的debugging分成target 8051的debugging stub和host gdb for 8051兩端。
target端這邊，aaa把8051和rs232等電路都焊好了給我，用來download測試程式和debugging stub。目前是先從stub改起，正在參考gdb的範例sparc-stub和aaa之前做的stub。
host端，bbb覺得我對cross compile gdb不夠了解，所以建議我可以先看看現有的範例arm-elf-gdb怎麼編譯出來的。

====================6/02===========================
先大略了解gdb remote debug的部分，還有劃出gdb和8051的架構圖，
debugging stub的位子等。
投影片
====================5/22===========================
與bbb討論了一下關於gdb，gbd debug stub部分可以找aaa拿，
可是目前的gdb好像沒有支援對8051的debug功能。
我目前還在google這方面的問題，可能還要在找老師討論一下...
====================5/15===========================
目前在FPGA上塞入四顆8051 core，放在gary的bus上執行正確。

之前放在gary bus上出現的錯誤，簡單說是initial板子的問題。
因為我是修改以前bus與altera板子連接的程式，altera當時是一個版子一個8051 core，所以如果接兩個8051 core就需要set up兩個板子。當初是包在8051 class的初始化裡面，bus呼叫兩個core就initialize兩個8051，給個index變數判斷其差別。
然而現在xilinx上是一個版子有多個8051 core，只需set up板子一次，所以最後我是用if else去強制讓set up板子的動作只執行一次，改好後可順利執行，只是這方法不太好，我還在和宗胤討論怎麼改。
====================5/12===========================
目前我在FPGA上塞了兩顆8051 core，自己對任一顆做測試結果是正確的，
但是放到gary的bus上卻會出現錯誤，我目前還在找尋原因。

另外，之前關於降低選擇器的複雜度，老師希望能有選擇器 set up time 的數據。
投影片
====================5/05===========================
單顆8051 core已經與gary的bus接起來且執行正確。
====================5/03===========================
終於找到問題了，是8051 c code寫錯了
因為DCT的C程式中會對input data array的pointer作變動，而執行完後等待下筆DCT input data時沒有更新那pointer，導致第二次執行DCT時資料會算錯，然而reset卻又會正確的的情況。
把這問題解決後，DCT已經可以正常運作了。

接下來就是準備和gary的bus接起來。
====================4/27===========================
上禮拜訊號不穩的問題有了另一解，就是降低選擇器的複雜度。
interface在回傳數值的output port前會有一個選擇器，選擇取哪一個memory(ROM, RAM, xRAM)的output作為回傳的數值，降低其複雜度就可以了。

目前DCT程式可以部分正常運作。每處理一筆8x8的data完後，必須reset才可以處理下一筆。
不確定原因，還在debug。
====================4/20===========================
之前memory的資料可以寫入並讀出來，但是總是有部分讀取的數值錯誤，花了不少時間在處理這問題，因為不清楚是寫入時出問題還是讀取時出問題， 加上合成硬體很花時間，讓我debug速度變得好慢...

最後才發現是 xilinx memory的問題，利用xilinx core gen產生的memory，input options原本我是設定成non registered，這會造成write data時memory寫入的data不穩定，之後改成 registered就解決了部份讀取數值錯誤的問題了。

只是因此又多一個問題，input registered會造成讀取data delay一個cycle，也就是說input address後要等一個cycle才會output出對應的data。但是我的8051 core是設定成沒有那一個cycle delay的。

接下來要做的是處理8051 core因為memory delay而執行錯誤的問題。
====================4/12===========================
學長幫我看了一下架構，認為太複雜了
透過範例程式做修改，盡量不要動到其FSM和interface，也盡量不要修改到原本的控制訊號。

我將架構稍作修改後，目前可以將資料寫到memory並且讀出來。
接下來是測試P51的控制。====================4/11===========================
verilog code是寫好了，只是PC端要求回傳數據完全錯誤...。
我目前正在寫test bench，希望到時能由波形圖看出問題，不然我也不知道哪裡出問題。
====================4/6============================
這禮拜主要是熟析xilinx的FPGA和版子與PC端的溝通方式，還有修改我system controller的架構

原本的system controller，也就是altera的版子，是用一個function call與版子溝通，主要參數是兩個array (read data和write data) 和一個cycle數。
array的每一筆data都是按照cycle數的先後排列，write data array的第一筆data就是第一cycle時FPGA的data input，第二筆data就是第二cycle時FPGA的data input，之後以此類推。
read data array則是FPGA的data output，和write data一樣的方式排列。

現在的xilinx版子，是用多個function call對兩個FIFO讀寫，版子再從FIFO取值或者寫入。
PC端與版子的溝通訊號比較複雜，但由於有一個簡單的範例介面，所以我打算用那範例與system controller相接。
====================3/31============================
速度卡在FPGA的原因: 是一個DCT處理需要大約400k的cycle數跑完，
但是function call的限制是一次只能跑大約300 cycle就必須回傳給PC，
我目前設定是一個function call跑256 cycle，呼叫1700次，
這樣會造成時間全浪費在PC與FPGA的溝通上。

由於這是API的限制，所以後來學長給了我另一個FPGA和API就不會有這限制。
為了能使用新的API，目前正在改寫我的verilog code和PC端的程式。
====================3/30============================
目前整個jpeg encoder跑起來的結果是正確的，不過速度全卡在FPGA上，
一個200X200的圖需要大約30分鐘才能跑完。
增加FPGA數量其實並不能加速，因為systemC是單執行緒，所以多個FPGA也不能同時執行。

我接下來的工作主要有三個:
用systemC寫出8051的module，能在openESL上執行。
8051的toolchain，C program可以從keil直接到FPGA上。
Debugging的功能，尤其是能在FPGA上處理單步執行的能力。

其中對於toolchain，我說明一下我目前DCT是怎麼做的。
首先C code要經由keil的C51 compiler處理，需要對變數的宣告作修改
由於我是用xRAM作為share memory，所以讀取的input和計算的結果都必須指定其位值。
譬如將 short datain [64]; 宣告在type = xRAM的address = 0x10作為起始位值，
寫法就須改成absolute memory location的格式:
short xdata datain[64] _at_ 0x10;
如果不指定type和address，則由compiler和linker分配
無論是自己指定或者compiler分配，都可以在output file的Symbol Listing看到。

接下來是程式大小的問題，原本沒任何optimization，我的程式大約3k byte。
由於FPGA的memory大小和試用版的keil有其限制，在compiler設定上選擇適當的optimization
我把程式壓到小於2k byte。

最後compile後產生的output files，我是選擇用hex file作為下載到FPGA的input code，
因為hex的格式比binary還好理解。
hex file更進一步說明是Intel HEX file format，格式為
:llaaaatt[dd...]cc
: Intel HEX record的開頭.
ll 表示這行記錄了多少byte的data(dd).
aaaa 開始的address
tt HEX record type，我只知道00表示data record，01表示end-of-file
dd 就是程式碼了
cc checksum，將這行所有hex number，兩兩一組相加/256。
舉個例子 :10246200464C5549442050524F46494C4500464C33
表示有0x10 byte的data，data我用綠色的標起來了，
起是位值2462，是為data record，checksum = 33。

有了data和其相對應的address，就可以下載到FPGA了。
====================3/26============================
主要在與Gary的配合，和FPGA的記憶體的限制問題。
目前看來Gary的bus和FPGA的溝通沒問題。
至於FPGA的記憶體的限制問題，首先說明一下我目前8051的記憶體配置，
iRAM + SFR = 256*8 bit
ROM = 4096*8 bit (12 bit address)
xRAM = 1024*8 bit (10 bit address)
根據quartus編譯的結果，在FPGA上 total memory bit = 43,008 / 92,160 (47%)
之前這樣DCT程式就夠用了，xRAM也可以不用這麼大，可是如果要符合8051的規格，ROM和xRAM都需要65536*8 bit，很明顯FPGA一定不夠，所以目前就先維持這樣。

至於能不能在FPGA塞下兩個這樣restricked的P51，目前看起來好像可以，
total logic element 46%, total pins 40%, 所以我正在試。

====================3/22============================
關於ACALL指令執行後位子多跳了兩個，我對FSM做了修改。
我修改成PC晚一個ins cycle跳去ACALL的位值，也就是將conj這控制訊號晚一個ins cycle送出。
由於上傳波形圖會糊掉，所以更詳細一點的說明，我有舉範例在投影片裡。

目前跟Gary的TLM bus接起來結果正確，不過也只測試過一組資料。
我會在星期一和Gary多測試幾組。


====================3/17============================
老師點出我兩個處理方法並不正確，首先ACALL那邊，branch到的位值是正確的， 但是經過兩個ins cycle後(因為ACALL需要2 ins cycle)卻改變了。
不可直接對更新PC的地方做修正，因為branch到的位值是正確的。

第二是ALU carry，不應該多設一個暫存器，而是想辦法讓carry在正確的T時間計算。

開完會後的下午，我將ALU的carry問題修改了一下。
原本T=0時controller還沒設定ALU input，ALU就開始動作，計算出錯誤的carry，
同時也送出錯誤的ALU output，只是controller將他檔住。
我的作法是將ALU carry改的和ALU output一樣，只有在T=5的時候才會接收，
其他時間則擋住。

另一個問題是為什麼ModelSim模擬是正確的，然而下載到FPGA跑出的結果卻是錯誤的?
我將FPGA跑出的錯誤資料作紀錄，總覺得似曾相似......
才發現原來我verilog code弄錯版本了，拿成未修改的verilog code去下載到FPGA。

改完後，目前在FPGA板子上已經可以正常執行了，測試了幾個數據都正確。
====================3/13============================
這幾個禮拜主要是將DCT的C code，透過Keil轉成 8051 assemble code，放到FPGA上。
pre-sim階段，透過Keil debugger支援的單步執行，觀察wave的訊號。

這階段遇到的8051 Bug主要有兩個
一個是ACALL執行後位子多跳了兩個，目前的處理方法就是在更新PC的地方多加個-2。

第二個是ALU計算carry值的問題 ，在不正確的T值計算出carry。
T=0時controller還沒設定ALU input就開始動作，計算出錯誤的carry值用於T=4。
目前處理方法是多設了一個暫存器紀錄控制訊號送達ALU前的carry，用於T=4。

這兩個問題處理完後，pre-sim目前DCT測試結果正確。

CD-WAV-MP3-CHROMA-轉檔流程

foobar

轉CHROMA的程式

 

轉Chroma的程式已更新

解決了檔案名稱如果有很多"."所造成的問題

感謝皓鈞幫忙測試

 

注意事項:

1.安裝foobar時,請點完整安裝

2.如果foobar找不到那張專輯的tag,可以先不要轉那張專輯(因為需要手動輸入,會很麻煩)

3.麻煩大家將轉過的CD放在DNA後面的那個箱子(避免轉到重覆的專輯)

 

20090423 附註

1. FTP之前上傳中文檔名會亂掉,我已經修正,我把檔案編碼改成繁體中文,並且改成unicode,所以如果有上傳非英文檔名的檔案時,ftp client要有支援unicode

2. cool edit在處理某些太長的檔名時會有問題,請在Add Files之前,先點選Hide Path

 

我們的目的是將CD音軌擷取出來(WAV)

再將WAV轉成MP3(128kbps)再轉回WAV

而這兩個WAV都需要轉成CHROMA

所以一首歌會有兩個WAV

一個WAV會轉成兩個CHROMA

也就是一首歌會轉成四個CHROMA

 

首先放入CD光碟片後,請開啟foobar

點選 檔案 => 開啟音訊

點選所放入光碟片的光碟機

點選尋找

foobar會自動找到正確的標籤資料,點選更新檔

接著便可以注意到 原本的CD Trackx都變成歌名了!

請點選擷取!

編碼預設請點選WAV

新增DSP處理,選擇混合聲道到單聲

點選左下角的更多設定

輸出檔名中的單個檔案請改成

[%list_index%]_%artist%_%album%_%title%

接著請點選確定

選擇資料夾,就可以開始轉檔了!

轉檔中...

轉檔結果!

接著要將WAV轉成MP3(128kbps) 再轉回WAV

我們需要透過Cool Edit去做這件事情

因為foobar預設的基本功能 似乎無法精確的指定MP3的bps

請點選File => Batch File Convert

請點選Add Files

請點選剛剛那些從CD擷取出來的WAV File

請確認New Format中的Output Format為MP3

Format Properties為128kbps,44100Hz,Mono

請確認輸出的位置,接著請點選Run Batch

在轉檔成MP3之後,接著要將MP3轉回WAV

一樣的流程

Add Files點選剛剛轉好的MP3 File

Output Format點選WAV

Format Properties 44100Hz,16bit,Mono

Output Filename Template請修改為*_mp3.wav

中間有一個Delete source file if converted OK

如果您之後不需要MP3 File的話 可以點選

接著可以點選Run Batch開始轉檔囉!

請把WAV轉CHROMA的程式和剛剛的WAV File放在同一個資料夾內

接著點選 WavConvertChroma.exe

轉檔中...

轉檔完後會產生一堆CHROMA File以及一個FileList.txt

一個WAV File會轉換成兩個CHROMA File

FileList.txt的內容為剛剛所轉檔的檔案列表

這是為了日後要加這些標籤資料匯入資料庫要用的

請大家將FileList.txt重新命名為FileList_自己的ID_日期.txt

總之這個檔名上傳時注意一下不要和大家重複就好

最後請大家將WAV File、CHROMA File以及FileList_自己的ID_日期.txt上傳 就大功告成了!

 

Nas Server 我已經裝好設定好了

可以透過FTP連線

IP: 140.116.82.199

帳號: scream

密碼: 和186的密碼一樣

請上傳到Public這個資料夾中!

另外請以專輯名稱在Public資料夾內 再創一個資料夾

將專輯的檔案上傳至新建的專輯資料夾內

 

非常感謝大家!!!

Cell 介面

這篇是講BBB學長的graphGen所要用的介面
也是用之前的OpenESL介面來改

介面要修改的部分：

• repository的讀取
  • 不需要port type
  • 增加property (stateful, load)
  • 沒有版本控制 少一層資料夾與版本判別
• project存取
  • for component
    • 刪除input/output port、port type、id
  • for diagram
    • 增加兩個property : Core/Duplication
• diagram介面
  • 增加一個按鈕以供輸入Core/Duplication值

repository的部分 下面是我拿來測試的xml

  1: <?xml version="1.0" encoding="utf-8"?>
  2: 
  3: <Module name="IDCT" version="0.00001">
  4:     <!-- Input ports -->
  5:     <in_port type="data">in</in_port>
  6: 
  7:     <!-- Output ports -->
  8:     <out_port type="data">out</out_port>
  9:     
 10:     <property name="stateful" value="true"/>
 11:     <property name="load" value="400"/>
 12: 
 13: </Module>

比較有問題的是
如何在Yellow Dog Linux 6.1下安裝Eclipse
JAVA SDK的部分 我已經抓到IBM的for ppc64的版本了
Eclipse的安裝也照
http://www.yellowdog-board.com/viewtopic.php?f=29&t=4633
說的下載5個套件 去安裝
可是...裝的怪怪的 現在還打不開
我還要再看看到底裝對了沒

BBB學長看看有什麼地方不對 或是哪裡還要加東西的
再跟我說吧

-----------------------------------------------------------
090414

終於在YDL 6.1下面裝好Eclipse了
可是只有3.2版的
所以出現一些class找不到之類的問題
從897個problem改到現在
還剩4個 好像是新增的method 我再看看要怎麼改

現在是用按鈕來開啟對話框的方式 輸入整個project的"core num"跟"duplication"值 只是...找不到地方讓它顯示
變成說使用者到底有沒有輸入過這兩個值
在畫面上是看不出來的 怪怪的

附上在Yellow Dog Linux 6.1版安裝Eclipse的方法

• 先從YDL的【新增移除軟體】那邊安裝Eclipse
  除了SDK其他相關的都要裝
  開啟一次 讓他初始化
  
  
• 安裝 IBM JDK
  (因為sun沒有ppc版的 GCC的java又非常慢)
  到這裡 http://www-128.ibm.com/developerworks/java/jdk/linux/download.html
  要註冊一個IBM帳號
  找 "32-bit" iSeries/pSeries 版本。
  (雖然PS3是64bits 還是要裝32bits版的 不然會超級麻煩 有一些套件怎樣都找不到)
  抓 ibm-java2-ppc-sdk-5.0-9.0.ppc (69.4MB)
  安裝 再建立一個連結
    $ ln -s /opt/ibm/java-ppc-50/jre/bin/java /usr/local/bin
  用which java及java -version檢查 java路徑及版本是否正確
  
  
• 降版本安裝 Eclipse (3.2.2版)
  (搭配6.1的Eclipse有很多問題 很多功能都無法正常運作 所以要裝回6.0版用的)
  到YDL 6.0的repository http://ftp.yellowdoglinux.com/pub/yellowdog/yum/6/base/RPMS/ 抓下列檔案
      eclipse-ecj-3.2.2-14.ydl.1
      eclipse-rcp-3.2.2-14.ydl.1
      eclipse-cdt-3.1.2-3
      eclipse-jdt-3.2.2-14.ydl.1
      eclipse-platform-3.2.2-14.ydl.1
  用rpm移除6.1版的 (要忽略相依性)
    $ rpm -e --nodeps eclipse-ecj-3.2.2-14.ydl6.1
    $ rpm -e --nodeps eclipse-rcp-3.2.2-14.ydl6.1
    $ rpm -e --nodeps eclipse-cdt-3.1.2-3
    $ rpm -e --nodeps eclipse-jdt-3.2.2-14.ydl6.1
    $ rpm -e --nodeps eclipse-platform-3.2.2-14.ydl6.1
  再安裝6.0版的 (還是要忽略相依性)
    $ rpm -ivh --nodeps eclipse-ecj-3.2.2-14.ydl.1
    $ rpm -ivh --nodeps eclipse-rcp-3.2.2-14.ydl.1
    $ rpm -ivh --nodeps eclipse-cdt-3.1.2-3
    $ rpm -ivh --nodeps eclipse-jdt-3.2.2-14.ydl.1
    $ rpm -ivh --nodeps eclipse-platform-3.2.2-14.ydl.1
  
  
• 安裝GEF舊版本
  eclipse plug-in安裝法
  自己開資料夾把plug-in跟features裡的東西copy過去
  

Lab 相簿開張

The album is powered by Picasa

http://picasaweb.google.com.tw/wolfgang1791arwen

這個相簿在老師創立wolfgang帳號時就同時建好了，只是一直沒有公開。我發現實驗室的照片記憶已經停留在以前很久了，希望大家在離開這實驗室前都能留下些痕跡。

簡單來說，就是要大家今年別再讓 Lab 旅遊喇掉啦！