嗶譜嗶譜—最好的口琴曲譜庫送給最好的SCX64

　　口琴被稱為“口袋里的鋼琴”，便于攜帶，具有獨特的音色。我在機緣巧合之下喜歡上了吹口琴，并發(fā)現(xiàn)了je口琴吧。je口琴吧的成員主要是二次元口琴音樂的愛好者，大家普遍使用半音階口琴。一只十二孔半音階口琴具有三組的八度和完全的半音。用一只口琴就能演奏絕大部分的動漫歌曲。我目前所用的就是一把16孔的半音階口琴——SCX64。有的小伙伴會把自己喜歡的譜子扒下來，上傳到貼吧。但是由于貼吧的機制，并不適合譜子的保存和搜索。要想從大量水貼中找到自己想要譜子真可謂是難上加難。

　　在一次偶然的機會，我讀了一篇利用github的issue來儲存技術(shù)博客的文章。其作者詳細闡述了這么做的優(yōu)點。如：能夠在線編輯和預(yù)覽、支持粘貼屏幕截圖和拖拽添加圖片、帶有搜索和排序功能、可通過 Label 來對進行分類。我當(dāng)時就激動的叫了出來！天��！這些功能簡直就像是為曲庫量身打造的！

　　issue有自己的Label系統(tǒng)，能夠?qū)ψV曲按照首字母等標簽進行分類，方便查找

　　曲庫建立之初，我進行了不少探索。自己用markdown寫了一套譜子上傳模板。然后自己一個人開始搬運je吧一些比較有名的譜樓和自由神社的譜子。為了推廣我的曲庫，我用vue框架做了兩個網(wǎng)站，一個是pc端的，一個是自適應(yīng)的。我還制作了詳細的譜子上傳教程發(fā)到j(luò)e吧。這樣，我的曲庫終于有了第一批用戶，同時也是第一批譜子上傳者。在后來一段時間里，隨著譜子數(shù)量的增多，一些問題逐漸暴露出來，經(jīng)過大家的討論，曲庫2.0版本應(yīng)運而生。

　　在2.0版本中，我們對曲庫定位為一個單純的數(shù)據(jù)庫，去除了譜子模板中僅僅為了美觀加入的徽章代碼。同時，我們對曲庫進行了去標簽化。不再使用github issue的label標簽功能對譜子進行分類。在1.0版本中，我們將同一個作品的譜子放在一個issue里面，隨著譜子數(shù)量的增加，用戶找譜子的體驗嚴重下降。為此我們在2.0中將每個譜子作為一個單獨的issue進行存放，不再強迫用作品將其分類。同時，我們我還成立了核心開發(fā)組，著手移動端和網(wǎng)站新版本的開發(fā)。

　　1月份，我們順利開發(fā)了嗶譜嗶譜網(wǎng)站以及安卓客戶端。網(wǎng)站新功能中的譜冊功能也是對之前曲庫2.0中去標簽化的一種延續(xù)。我們把將譜子分類的權(quán)利交給用戶，讓用戶能夠創(chuàng)建一些獨一無二的譜冊。就有點類似于網(wǎng)易云音樂的歌單。個性化，定制化。這也是我們開發(fā)譜冊功能的初衷。

　　關(guān)于嗶譜嗶譜的技術(shù)棧，我們選擇的是JavaScript語言的vue框架，后端選擇的是go語言的gin框架，數(shù)據(jù)庫mysql，服務(wù)器選的是阿里云。

　　目前前端主流的框架有，F(xiàn)acebook的react.js，國人尤雨奚開發(fā)的vue.js，還有Google維護的angular.js。之所以選擇vue，是因為vue是一款很輕量的漸進式框架，有著詳細中文文檔和社區(qū)。為什么選擇go語言作為后端而不是Java或者node.js呢？當(dāng)然不是因為今年是狗年。主要是因為核心開發(fā)組中后端的成員公司新業(yè)務(wù)開始使用go，而這個語言確實好，它對于高并發(fā)具有先天的優(yōu)勢，同時自帶垃圾回收機制，能夠快速編譯。因為我們這個項目是一個開源的項目，大家都是基于興趣來進行網(wǎng)站開發(fā)，我們暫時無法給予大家經(jīng)濟上的回報，所以我們只能說在項目中多多使用一些比較新的東西，鼓勵大家學(xué)習(xí)一些新的語言，給大家一些鍛煉和實踐的機會。

　　上圖中這些一個個小的知識點，像跨域，nginx配置，數(shù)據(jù)庫和接口設(shè)計，移動端的開發(fā)也都是我們在網(wǎng)站開發(fā)過程中實際遇到的問題，不過都通過查閱相關(guān)資料或者和開發(fā)組的各位相互請教最終順利解決。特別是第三方登錄的實現(xiàn)讓我對前后端分離后相互之間的配合有了更加深刻的理解。

　　截至今年3月份，曲庫現(xiàn)有譜子數(shù)量已經(jīng)達到了490個，相比于最初的39首有了巨大的進步。同時越來越多的搬運工加入了我們，截至到目前為止，除了我以外，還有10名曲庫的元老級貢獻者持續(xù)為曲庫義務(wù)上傳譜子。同時，我每個月我們都會收集大家對我們曲庫的建議以及奇思妙想，并且通過討論決定是否添加或修改相應(yīng)的功能。另外，觀實科技目前以股份的形式投入經(jīng)費用來維持網(wǎng)站服務(wù)器的正常運行。

　　這其實也是我第一次在Github上自己負責(zé)一個開源項目。讓我感受最深的就是開源貢獻者之間不一樣的合作。為什么說是不一樣的團隊合作呢？因為首先我們是一個開源項目，是非盈利的。大家都是處于對口琴的熱愛才參與到這個項目當(dāng)中來。項目成員的背景多元，所以思路和點子也很多元。其中有初中生，大學(xué)生，也有華為，新浪等各個公司的員工。大家平時都有自己的事要做，不可能在這個項目上花太多時間。所以我就要負責(zé)協(xié)調(diào)，還有進度管理（催進度）。

　　魯迅說，不對。。。古人說：凡事預(yù)則立，不預(yù)則廢。我發(fā)現(xiàn)真的就是這樣。所以必須要定一個網(wǎng)站施工計劃表，這樣才能相對有效提高網(wǎng)站開發(fā)的進度。同時這個項目也讓我有機會接觸網(wǎng)站開發(fā)的全過程，讓我知道了前端和后端之間是如何配合來實現(xiàn)一些業(yè)務(wù)的，充分滿足了我的好奇心。

　　因為本科畢設(shè)做過一個基于融合特征的行人再識別問題，其中用到了幾個公共行人數(shù)據(jù)集。于是我就想，能否將我們曲庫也作為某個機器學(xué)習(xí)的數(shù)據(jù)集呢？

　　目前貼吧的小伙伴們主要都是靠自己的耳朵或者用一些輔助軟件將音頻轉(zhuǎn)換成頻譜來進行扒譜，這樣需要花費不少精力。我們是否能夠研究出一款輸入為音頻文件，輸出為譜子的機器學(xué)習(xí)算法呢？

　　我閱讀了幾篇國外關(guān)于樂譜識別的論文，其中有一篇就是將音頻文件進行Constant Q transform常數(shù)Q轉(zhuǎn)換。從而將音樂中的音符檢測轉(zhuǎn)換為圖像識別問題，然后通過cnn網(wǎng)絡(luò)訓(xùn)練樣本。但是識別率不太理想，相關(guān)研究還有很大空白。

　　常數(shù)Q轉(zhuǎn)換（ConstantQtransform）與短時傅立葉轉(zhuǎn)換一樣為重要時頻分析工具，這個轉(zhuǎn)換產(chǎn)生的頻譜最大的特色是在頻率軸為對數(shù)標度而不是線性標度，且窗口長度會隨著頻率而改變。由于它與音階頻率具有相同的指數(shù)分布規(guī)律，因此在音樂信號的音調(diào)檢測中有著獨特的優(yōu)勢。但是目前CQT存在的一些問題：無非常有效的CQT快速算法，如果借助fft來進行計算則會喪失一部分cqt變換獨有的性質(zhì)。

　　值得一提的是，je吧常用的數(shù)字譜并沒有標出節(jié)奏（這造成了一定的不便，但也造就了這樣的簡譜非常便于搬運和轉(zhuǎn)調(diào)的優(yōu)勢）相比于五線譜和簡譜，數(shù)字譜數(shù)據(jù)更容易處理。所以我覺得對于樂譜識別的研究來說，數(shù)字譜可能會是一個很好的切入點。

　　通過和平安科技深度學(xué)習(xí)組的專家交流，目前直接提取準確的數(shù)字譜還有難度。但是他提供了另一種思路，可以先研究一種能夠提取一段音樂中的主旋律的算法，這樣就算再用耳朵扒譜也容易得多。同時，這個算法也可以作為樂譜識別算法中的音頻預(yù)處理，提高準確率。

　　因為研究生階段也會從事圖像檢測和大數(shù)據(jù)方向相關(guān)研究，所以我覺得或許可以將以后的職業(yè)和興趣結(jié)合一下。于是，我提出了一個大膽的，以曲庫為核心的嗶譜嗶譜小生態(tài)。一來，希望能夠充分發(fā)揮曲庫的價值，看能否為機器學(xué)習(xí)領(lǐng)域的發(fā)展做一些貢獻。二來，看看自己有沒有能力在樂譜識別的研究方面有所突破。

　　我們也和許多人氣UP主達成合作，為嗶譜嗶譜引入了許多優(yōu)秀的口琴相關(guān)內(nèi)容。

　　當(dāng)然這個生態(tài)圈，目前還只是不成熟的設(shè)想。希望能通過大家后續(xù)的共同完善與修改，把最好的口琴曲譜庫送給最好的你們！

　　其實寫之前糾結(jié)了一下到底在什么平臺上寫這篇文章比較合適？知乎？掘金？還是簡書？

　　所以趁機打一波廣告：不管你是口琴、二次元音樂的愛好者，還是對前后端或ML感興趣的程序猿，亦或是對我們很感興趣，我們JE曲譜庫核心組這個大家庭都歡迎您的加入！群內(nèi)技術(shù)交流氛圍良好，希望大家多多參與討論。在把嗶譜嗶譜做好的同時，也希望群里的每個人都能有所收獲！