音樂情緒研究問卷

偶然看到台大電信所的研究生在 PTT 徵求進行音樂情緒問卷, 因為對 yihsuan ( Perosnal Blog, 但是很少更新) 這個名字有點印象(後來發現他是 [1] 的首位作者, 之前實驗室有同仁報過這篇 paper, 難怪有點印象), 加上之前實驗室也有同仁在做音樂情緒相關研究, 就特意點進去看看.

問卷網站有點慢, 同時是 IE Only, 我還特地開 Virtual Box 來連 = =

問卷分成幾個大部分, 首先是 Introduction 進行一般音樂情緒說明,


不太確定分類是如何決定的, 但是根據之前聽過數次同仁的 presentation, 猜想應該跟 R. E. Thayer 的 AV Emotion Plane [2] 有相關.

第一階段是直接用聽的請 Visitor 給分數, 很單純的從悲傷到開心的分數. 至於分數怎樣對應到 AV Emotion Plane 就不知道了.


第二階段
使用了一個 Tournament 來讓使用者從不同音樂的比較中給予相對的情緒關係分數 ( 比對本身可以算是一種分數 ).


這個手法感覺比較有意思, 跟 男女糾察隊 London Hearts 的節目中使用的 臉蛋好壞球 (顔面どストライク) 很像, 之前在看 Paper [1] 時我也有想過把 臉蛋好壞球 搬到 Music 領域來玩玩看 :p

底下來個上戶彩的作參考 (取用自這裡 -- Orz 有沒有這麼巧, 隨便找一下連到的居然是緯來當家美女主播的 Vlog ) :


最後一個階段則是對於使用者標示音樂情緒的一般性調查, 不過我覺得裡面出乎我意料地缺少相當多對於使用者 Context 的調查, 換句話說上面的音樂情緒標定是無法根據使用者的個人背景以及目前的情緒, 環境工作等等作進一步解析的. 這對 Data 的 Reliability 我認為是一種傷害, 特別是 Music Emotion 這種在判定時會受到相當多 Factors 影響的東西.


其實我對於音樂情緒一直不太相信, 最主要的原因即在於 Emotion 這種東西的判定 Variation 太大, 而音樂的創作又跟相當多的 Factors 有關, 有時候創作者是因為環境, 有時候是因為故事, 有時候是因為其他的音樂, 不確定加上不確定實在沒辦法讓我相信會變成一個確定. 而 Emotion 的 Variation 太大也導致多數的 Researches 都停留在諸如 Kate Hevner [4] 的八個分類, 或是 [1] 使用的 AV Emotion Plane 上, 但是這麼粗的分類感覺實在不實用.

另外就是音樂情緒的應用, 實驗室的學弟做的 [3] 是跟 Music Therapy 有關, 在 Therapy 上音樂可能有用這個我就相信, 但是很多 Papers 都會提到利用音樂情緒對於大量的音樂作自動分類判定 -- OK, 我相信可以自動分類, 但是為什麼我們要自動利用音樂情緒分類大量音樂 ? 到底誰會是使用者, 誰需要對於大量音樂進行音樂情緒的自動分類 ? 這個問題我一直想不透阿, 也許這也跟我本身有關, 我會留著的音樂大多是自己聽過喜歡的, 但是卻不會刻意去區分所謂的音樂情緒.

我想, 如果同樣的問卷是詢問使用該音樂的情境, 應該會比較有用吧, 很多時候我們想找音樂是希望配合目前的 Context 來用, 雖然說也可以透過情緒的轉換去作 Matching, 但是為什麼要如此麻煩呢 ?

P.S. 在閱讀 [1] 時我覺得其實內容很 Tricky, 主要是在 Data Collection 的地方做了大量的 Assumptions, 這讓我很不舒服 (Feel Uncomfortable), 另外歌詞的影響也被計量在內, 作為 Music 的一部分, 雖然說得通, 但是就讓我很不舒服, 對於我個人來說, 當你聽的懂歌詞時, 往往歌詞的影響力跟 Music 本身會不相上下, 這樣一來究竟你是在辨認 Music Emotion 或是 Lyric Emotion 就很難說了.


References

[1] Y.-H. Yang, Y.-C. Lin, Y.-F Su, and H.-H. Chen, “A Regression Approach to Music Emotion Recognition,” IEEE Transactions on Audio, Speech, and Language Processing, vol. 16, no. 2, pp. 448-457, Feb. 2008.

[2] R. E. Thayer, The Biopsychology of Mood and Arousal, New York Oxford University Press, 1989

[3] Yin-Kai Wu, Discovering Musical Features for Automatic Emotion Classification in Music Therapy, Master Dissertation, NCKU, 2008

[4] Kate Hevner, Experimental Studies of the Elements of Expression in Music, American Journal of Psychology, Vol. 48, pp. 246-268.

Manage Correlated Data Across Services ?

利用不同的 Services 來存放不同的 Data, 然後在一個統一的 Blog 展示是目前 BSP 系統的標準設計模式. 然而 BSP 對於整體 Data 的管理策略可能還有值得討論的地方.

無名的例子來說, 進行 Blogging 的使用者可能同時利用他的網路相簿跟網路影音服務, 但基本上該兩項服務的 Data 跟 Blog 本身是分開的, 只是在 Blog 上提供可以存取該 Data 的介面. 有時候使用者如果因為特殊原因要暫時關閉該 Blog, 原則上相關的 Data 應該也無法取得才對.

例如無名的 tiger302 這個 Blog, 因為某些理由被使用者關閉, 因此相關的相簿影音等資料也無法取得. 但是如果你從 無名影音 進行搜尋的話, 事實上還是找的到相關的 Index, 只是連結進去後一樣是無法讀取.


然而, 雖然無法透過尋常的 Blog 或是搜尋介面看到影片資料, 如果有心人在 Blog 開放時留下影片連結的話, 居然是可以直接看到理應被禁止存取的影片 Data, 例如同樣是 tiger302 上傳的這隻影片 :


顯然地, 無名是利用禁止某些 Service 被執行, 來達到禁止 Data 被取得, 但是這樣作就會產生上面的這種漏網之魚 -- 也就是某些公開的 Service 還是可以取得該資料.

同樣的情況在其他的 BSP 上也可能出現, 如果 BSP 沒辦法讓使用者把相關的資料都綁在一起作管理的話, 就可能出現文章被禁止存取了, 圖片跟相關影片卻還是可以被取得的情況. 然而, 以使用者的角度來說, 文章就包含了圖片跟影片, 而非只有文字而已. 因此相關 Data 都應該被禁止存取.

在無名的例子中對於此問題還算好解決, 只要 BSP 願意多花點心思調整一下 Data Model 或是 Access Model, 提供給使用者在發表文章時作選擇即可. 然而當這個問題是跨服務 (Across Services) 時就會複雜許多.

在幾年前的台灣 BBS 也存在類似的問題. 當時全台灣大大小小的 BBS 可能有上千個, 透過 Mailing List 原本的機制, 彼此轉信變成一種風潮. 但是轉信的看板之間卻出現一種問題, 當有使用者錯發文章, 或是不恰當的文章要被刪除時, 只有原本的發信站做了刪除, 其他收信站還需要該站或看板的管理者再做一次判斷. 造成垃圾文章需要花費大量的人力管理刪除. 後來的 BBS 發展出 control.cancel 協定, 只要支援該協定, 可以透過轉信機制自動刪除在發信站已被刪除的垃圾文章.

但這要在不同的 Services 之間, 支援共同的 Protocol 似乎難度大的許多, 況且允許的動作也不是簡單的刪除而已.

Pixnet 出包的第七天

從 8/19 晚上 Pixnet 停機更換新架構, 進行資料轉移, 預計 8/20 重新上線, 但因為資料轉移所需時間預估錯誤, 因此僅部份功能可以使用, 直到 8/21 仍舊一片混亂, 管理後台無法正常使用, 文章編輯有問題, 無法進行迴嚮, 部份資料疑似遺失, 使用者的部份草稿文章會被公佈 ( 這點我覺得很嚴重 ), 還有其他一堆問題等等.

iThome 也進行了相關的報導 : Pixnet 改版出包 恐重演無名用戶出走潮 .

Ptt Blog 版發起的回報活動, 可以看到究竟已被發現了多少 Bugs :

如此多的問題, 讓人懷疑究竟新架構決定上線前, Pixnet 的工程師是怎樣進行必要的 Testing 的.

雖然說期間每天都有公告說明進度狀況, 但是顯然整個新架構所導致的問題百出.
即便中間有無數使用者建議暫時改為舊版 ( 請參考 kunghc 的 給Pixnet總經理李俊廣的公開信: 這是你展現危機管理最重要的時刻 ), 讓使用者可以正常使用, 等新版完全測試成功再重新上線, 但是 Pixnet 似乎不為所動, 直到今天, 8/27, 算是第七天了, Pixnet 還是堅持要玩 Bug Online 嗎 ? User Community 不是 Debugging Community 阿 = = ( 話說 Ptt 也開始討論搬家的方法了)

不是要幸災樂禍, 不過這真是一個好的 Case Study, 真希望有機會可以知道整個內部的來龍去脈. 從這個 Case 可以想到的幾個延伸問題 :
  1. 除了 Testing 的問題以外, 是否 Pixnet 工程師也沒有考慮過會出問題的可能, 新系統沒有任何 Backward Compatibility 考量, 導致現在不是 Pixnet 不想回復舊版, 而是根本回不去 ? Online Software/Service 的 Backward Compatibility 有哪些東西要考量 ?

  2. 個人資料被 BSP 或 Web Applications 綁架的議題, 在無名及 Pixnet 相繼出問題之後, 是否會浮上檯面呢 ?

  3. 提供服務的 BSP 或 Web Applications 背後的工程師素質顯然也相當重要, 但是一般使用者基本上不會去注意這點--直到出大問題之前, 這種情況是否會有所改變 ? 如何評估 BSP 的安全可信度 ( Security Reliability ) ?

  4. 我們會有定期的防空演習, 是否提供服務的軟體公司應該進行類似的演習 ? ( 可能是由內部的 QA 小組製造狀況, 或是有專門的外部公司介入, 就跟 CMMI 驗證一樣, 這跟單純的 Software V&V 不同 )

Joomla 1.5.x 重大密碼漏洞, 需升級至 1.5.6

8/12 發佈的 patch (Core - Password Remind Functionality), Joomla! 台灣則是 8/13 刊登此消息, 不過我知道的有點晚了, 剛剛才注意到這個問題, 回頭去檢查系網頁發現密碼已經被改掉了 == , 有沒有這麼快阿 orz

幸好網頁內容沒有被作大量修改, 不然要回覆備份就有點麻煩.

補救的方法請到 Joomla 官方網站下載 upgrade patch 檔案 (請指明官方網站), 注意相對的升級版本, 然後解壓縮蓋掉原本的程式就好了 (擔心的話就先備份一下再蓋掉). 我從 1.5.1 升級到 1.5.6 在頁面上基本沒有甚麼需要再進行修改的地方.

至於被改掉的密碼, 如果你的 1.5.x 沒有辦法在登入的地方直接透過寄回信箱的方式, 那可能就要到 database 進行修改. 利用 phpmyadmin 的話很方便, 找到 jos_users 資料表, 點選要修改密碼的使用者資料,


在 password 欄位選擇 MD5 編碼, 然後在右側的 password 密碼內容直接改寫為你想要設定的密碼, 然後拉到最下方進行儲存. 雖然填寫的時候是明碼, 但是在儲存過後 phpmyadmin 會自動利用 MD5 進行編碼, 這也是 Joomla 預設的密碼編碼.

這樣就大致修正完畢啦.資料沒毀損真是不幸中的大幸.

這是誰的問題 ?

前幾天重新在找一些 CloudAV 相關的文章資料時, 意外注意到一個讓我想不透的搜尋結果.

當我之前的文章 Will the AntiVirus Cloud Works ? 寫完後不久(8/10), 如果使用 CloudAV 進行查詢, 是可以在 Google 上找到的, 而且如果只鎖定繁體中文網頁, 基本上相關的網頁不多, 只有四個網頁分布於三個網站.


但是就在我再度查詢的那天(約兩天之後, 8/12), 當再次查詢時, Will the AntiVirus Cloud Works ?的文章卻不會在 Google 上出現了.


為此我特意把原本的文章發表時間做了修改, 改成比較新的時間(8/12)重新發表一次, 大約過了半小時, 於是文章又重新出現了. 結果就跟第一張圖一樣.

然而在過了一天後的今天(8/13), 文章又從查詢結果裡消失了, 而且這次連另外一個網站也消失了, 只剩下 Only Perception 的網站文章可以被查到.


如果使用 AntiVirus Cloud 作為關鍵字組也會是一樣的情況.

如果說是因為搜尋結果量多, 導致被過濾掉或是排到後幾頁去, 我可以理解文章會從搜尋結果中消失, 或是移到後幾頁去, 但是當搜尋結果極少時 ? 而且是才 post 沒幾天的文章, 也出現了這樣的情況 ?

我真的很好奇為什麼會這樣 @@

Will CloudAV, the AntiVirus Cloud Works ?

( 修改一下發表時間以及Title 進行實驗 )

根據 Computer World 的一篇報導 : Researchers look to cloud computing to fight malware, 密西根大學的幾位學者 ( Jon Oberheide, Evan Cooke, and Farnam Jahanian ) 嘗試利用不同的 AntiVirus Softwares 利用 Cloud Computing 概念結合來防範 malware, 所打著的算盤當然是截長補短, 讓 virus 或是 malware 需要克服更多的難關. 這跟趨勢最近在講的 Cloud Computing 應用 ( 前幾期的財訊在訪問趨勢某人時有提到比較多, 不過內容同樣不甚具體 ), 應該是不同的方向.

這項計畫稱為 CloudAV ( 應該是 Cloud AntiVirus 之意吧 ? ), 相關網站在這, 同時有電子論文可以抓取. ( 以下圖片均取用自 [1] ) 基本上可疑的 File 會傳送到 ClondAV 所提供的 Network Service 作檢驗, 這跟早期的網路掃毒類似.

看起來最終的決定是採用類似 Voting 的機制, 透過許多 AntiVirus 的結果, 決定是否該 File 是有問題的.

我在去年修 Embedded Middleware 作 Final Project 時有提過類似但不相同的想法 ( 我要集合的不是 AntiVirus Softwares ), 最終是卡在系統本身的 Security 問題, 以及 Privacy 問題. 針對 Privacy 問題, 在 [1] 中 Section 3.1 花了一小段說明, 但是也不算正面回答, 只是透過把 CloudAV 的應用環境作限制, 來降低 Privacy 的影響.

除了 Privacy 之外, 對於 CloudAV 是否能成功, 我還有另一個商業上的疑慮, 雖然 Paper [1] 內有談論了實驗本身所使用的 Software 的 License 問題, 但是在商業應用上不知道是否防毒軟體大廠會同意這樣的使用方式, 或是願意加入這樣的服務團體. 這裡就牽涉到商業利益的問題, 也可能給防毒效益不好的公司帶來更大的壓力.

不過, 往好的方面想, CloudAV 可以克服以往我們幾乎無法在一套系統內裝設兩套防毒軟體的效能問題, 以及 Mobile Device 不方便把資源用來跑 AntiVirus Software 的問題, 同時又能帶來更好更可靠的服務, 只要防毒軟體大廠願意進行類似的合作, 那麼就良性競爭以及防毒技術的進步來說應該是正面的. 這樣的 AntiVirus Cloud 似乎也跟我之前認為 Cloud Computing 會帶來軟體產業的二次分工相關.


References

[1] Jon Oberheide, Evan Cooke, and Farnam Jahanian, "CloudAV: N-Version Antivirus in the Network Cloud," Proc. of the 17th USENIX Security Symposium, July 2008

Bookmark Mindmap

前幾天在 RWW 上有一篇文章, 介紹了可以幫助 Bookmark Favorite Images 的三個 Sites : 3 Cool Sites to Bookmark Your Favorite Images on the Web. 昨天在看到一篇與 Cloud Computing 相關的文章, 並把他利用回應的方式附加到我之前的文章時, 忽然想到, 往往我們在 Web 上會看到跟之前一些想法相關的資料, 包含文章圖片影像動畫等等 -- 姑且稱為 Web Materials 好了 -- 是否可以有很容易的方法來蒐集組織他們呢 ?

之前用過 Google Notebook, 在蒐集上是很方便, 但是後端的組織就比較弱. 這種類似的系統由於缺乏比較系統化的組織工具, 因此容易出現蒐集了一堆, 後續處理反而麻煩的情況.

如果我們把自己的 Blog 視為表達紀錄自己知識的媒介, 那麼其實可以把這種組織的行為以 Blog 文章為中心作連結, 等同於以 "Adding" 的方式連結別人的知識到自己的知識上, 同時這是屬於個人式的知識累積. 很直覺的會想到利用 MindMap 來作整理. 借用 FreeMind 作個假想圖 :


利用 "Bookmark MindMap" 在 Google 做了一下搜尋, 發現有一些類似的 Tools, 例如有人替 Del.icio.us 作了 Delicious Mind Map Maker, 可以吃進你的 Del.icio.us 資料, 製作出 MindMap 來.


另外 DeliciousMind 也同樣是幫助把 Del.icio.us 上的資料以 MindMap 形式作整理與呈現的工具, 他利用了 FeeeMind. ( 這裡有額外的介紹跟 Examples )


不過這些都跟我想要的還是有一段距離. 我認為一張 MindMap 應該是以一篇 Post 為中心, 而往外擴展關係, 然而整個網站未必要是多張獨立的 MindMap, 這樣會讓 Blogger 整理到死. 相對的, 一個 Blog 本身是 Personal Knowledge Web, 而以單一 Post 為中心可以得到一個以上的 MindMaps. 這也跟之前 Library 2.0 的討論有相關之處.

The Connected OS and Midori from Microsoft

Microsoft 在 Windows 7 之後的繼任者已浮現雛型 ?

Ray Ozzie, CTO of MS, 在最近 MS 的年度 Financial Analyst Meeting 會議中提到 (原始內容在 MS.com 上面有刊載) :

We believe in a future, again, in many ways analogous to Xbox LIVE, in which Windows Live acts as a strategic extension to both Windows on the PC and Windows Mobile on the phone. You can think of this as the connected OS, Windows beyond the level of a single device or PC. How the OS connects to services and how it synchronizes with other devices are key. Your PC's config settings, your apps and their settings, your files and folders, are transparently synchronized across a mesh of PCs and other devices by Windows.
再加上最近查詢度很高的 Midori OS, 讓人不把這兩者想在一起都難 :p

但我相信 Ray Ozzie 真正要說的 Key 應該還是對於 Resources 的管理與需求, 而不是單純的 Service Connection 以及 Device Synchronization. 恐龍本一開始就把 OS 的目的跟主要工作寫得很清楚了, 只是在未來 -- 也許是 Cloud Computing 的未來 -- Resource 的型態也許會跟現行的 Computer Resource 會有很大的差異, 例如 Memory Service Resource, Computing Service Resource 之類的, 同時可能會再異化出更多的 Resource 種類出來, 與單純在硬體上的 CPU/Memory Resource 搶奪大不相同.

但對於 Operating System 的需要以及定義, 我想基本上還是相同的.

Designed by Posicionamiento Web | Modified by seLain | Bloggerized by GosuBlogger | Blue Business Blogger