서울대학교 융합기술원의 MARG랩에서 나온 논문입니다. 저도 한때 관심있었던 분야라 저자분과 이야기를 좀 했습니다.
연구의 가정은 스팩트로그램에서 wideband로 분포한 성분이 곧 타악기 성분이라는 것 입니다.
실험에서는 Derry Fitzgerald, Ono의 논문과 비교를 하였습니다.
저자의 말씀에 의하면 실제로는 Derry Fitzgerald 방법보다 좋지가 못하다고...
기본적으로 이 논문은 주파수 축에서의 분포만을 모델링했는데, DF는 주파수축/시간축 두 방향에서 각각 타악기/하모닉 악기의 분포를 모델링했습니다. 즉, DF방법에 비해 실제로 나타나는 현상을 덜 반영한 모델에서 출발하였기 때문에 나오는 한계가 아닌가합니다.
[2] Understanding uses of commercial music services through personas
Jinha Lee 교수님의 논문입니다.
음악 서비스의 유저 그룹을 clustering하고 어떤 패턴을 보이는지 연구한 내용입니다.
그룹 수가 7개나 되는데 전체 실험자 수가 40명밖에 되지 않는 점이 좀 아쉽습니다만 내용은 아주 자세합니다. (반대로 생각하면 숫자가 적어서 다채로운 공통점을 찾기가 쉬웠던 것 일수도 있지요. 즉 몇명 없는 사람의 특징에 오버피팅된...) 7개의 그룹은 두가지 특징에 의해 결정됩니다. 하나의 축은 Companionship - 얼마나 소셜하게 음악을 듣는가: [상-중-하]==[소셜-중립-개인적], 이고, 또 하나의 축은 투자(Investment) - 얼마나 음악에 시간/돈을 투자하는가:[상-중-하]==[투자하는 편 - 중립 - 안한다] 입니다. 조합을 하면 총 9개가 나오게 되지만, 주로 소셜 측면이 [상] 인 경우에 투자 측면은 [상, 중]만 존재하고, 소셜이 [하] 인 경우에 투자가 [중,하] 만 존재한다고 하네요.
이와 관련해서는 그동안 (Jennings 2007) 이 주로 인용되었었는데, 앞으로 이 논문도 많이 참고가 되지 않을까 합니다.
Gracenote에서 소위 day-of-a-year, 즉 연중 각종 이벤트에 관련된 (temporal context) 사람들의 청취 패턴을 조사하였습니다. 데이타는 2012년 1년동안 스트리밍된 호ㅜ쑤이고, 크리스마스/할로윈/성 패트릭 데이 등에서 피크가 크게 나왔네요.
이번 여름에 제가 네이버 랩스에서 하려고 했었던 것과 유사한 가정을 하고, 그 가정을 점검하였습니다. 가정했던 내용이 어느정도 성립하는걸 보니 다행스럽기도 하면서 그 내용이 출판된걸 보니 아쉽기도 하고 그러네요.
우선 제목에서 semantic은 semantic web에서의 semantic으로 보시면 되겠습니다. 즉 db에 정리된 artist 관련 정보를 이용한 artist similarity measure를 제안한 것입니다. 예를 들어 멤버가 겹치는 밴드는 유사성이 높다든지 하는 내용입니다.
음악 신호와 딥러닝을 적용할 때 data augmentation을 어떻게 해야하는지에 대해 다룬 논문입니다. 이미지의 경우 rotation/flip등의 인위적인 왜곡을 통해 트레이닝 데이타 수를 늘리는데, 음악에서는 그동안 필요에 따라 소소히 쓰여왔지만 이에 대해 정리된 논문은 없었습니다. 안그래도 필요성을 느끼던 차에 이번에 이 포스터도 나왔고, Brian McFee는 오랄로 유사한 내용을 발표했습니다.
다만 두 논문 모두 그동안 흔하게 쓰여왔던 방식 - pitch shift/time stretch/loudness 정도를 제시하였는데 이 외에 좀더 좋은 방식이 없을까 하는 의문이 듭니다. 아, 그리고 gaussian noise를 더하는 방식도 있는데, 음성인식에서라면 모를까 음악과 관련된 머신러닝 작업에서 노이즈를 더하는 것은 일반적인 의미를 갖기는 어려워보입니다.
2015년 여름에 판도라에서 인턴을 한 Dawen Liang이 발표한 논문입니다. 내용 자체는 흔히 나오는, cold-start problem을 해결하기 위하 content-based recommendation입니다. 2014년 스포티파이에서 인턴을 한 Sander에 이어서 판도라에서도 유사한 접근을 하네요.
사실 너무 당연한 일인 것이, 그동안 판도라에서는 수십명의 음악 전문가가 곡을 하나하나 태깅해왔습니다. 그렇게 쌓인 곡이 대충 100만-200만정도 되는데, 문제는 전체 음악 DB는 3-4천만곡이라는 거죠. 당연히 머신러닝이 필요하구요.
논문에서는 MSD를 사용했는데, 판도라 내부에서도 그들의 데이타를 갖고 같은 작업을 했다고 합니다.
2015년 ICML의 워크샵에서 같은 저자가 발표한 논문과 사실상 같은내용이라고 슬금슬금 실토했습니다.
[10] Music boundary detection using neural networks on combined features and two-level annotations
위에서 소개한 data augmentation 논문과 같은 저자가 쓴 논문입니다. 소속 기관인 OFAI는 오시트리아의 국가연구소라고 합니다.
CNN을 통해 바운더리를 트레이닝 하였고, 트레이닝 방식은 바운더리를 포함한 부분에서는 1을, 바운더리가 없는 부분에서는 0을 라벨링하였습니다. 바운더리라는것이 그야말로 경계면이다보니 어떤 크기의 스펙트로그램을 어떻게 주어야 할지 좀 애매할 수 있는데, 여기서는 우선 그렇게 길지 않은 구간의 신호를 (예를들어 1-2초? 기억이 잘 안납니다만..) 사용하였고, 바운더리가 정확히 가운데에 있는 신호에 더 weight를 주었습니다.
바운더리를 찾기 전에 pre-processing으로는 harmonic-percussive separation을 사용하였습니다. 그렇게 할 경우에 채널이 2개 있는 이미지처럼 처음에 데이타를 사용 가능할텐데, 여기에서는 어떻게 했는지 모르겠네요.
흥미로워보여서 찍었습니다만 아직 안읽어봤습니다. City University에서도 딥러닝과 음악을 접목한 연구가 꾸준히 나오고있습니다. 다만 folk melody와 같이 지엽적인 (안타깝지만 서양 음악은 이제 서양만의 음악이 아니라는 사실은 인정해야합니다. 그렇다고 그 이외의 것들을 '제3세계'로 보는 관점에 동의하는건 아닙니다만.) 소재는 전 개인적으로 좀 별로...
2015년 *월 *일부터 *월 *일까지 약 *일간 * 뮤직 서비스에서 재생된 곡 중 상위 *곡. 중에서 가사가 존재하는 음원 *개를 분석했습니다.
국문/영어를 같이 처리했고 stop words는 이곳 저곳에서 구해서 합쳤는데, 내부적으로 사용하는 모듈에서 처리되는 부분도 있어서 정확한 목록을 밝히기가 애매하군요.
명사인 사랑과 동사형태인 사랑하다를 합치면 14000번이 넘게 나옵니다. 뜻 위주로 생각하면 love까지 더해도 될 것 같구요. 그러먼 무려 19000번! 압도적인 1위입니다.
그 외엔 일반적인 말뭉치(corpus)의 순위를 어느정도 따르지 않을까 합니다. 특이사항을 꼽자면 14위의 사람, 15위의 babi (baby, babi, babe 를 다 합친것같은데 파이썬의 normalization 코드를 다시 한 번 봐야 알 것 같네요), 20 마음, 21눈물, ... 29 세상 30 아프다 33 가슴 38 girl 48 기다리다, 등이 눈에 띄네요.
Recently I'm looking into lyrics before implementing music lyric processing codes.
There are many aspects that make song lyrics different from usual text, which are quite interesting and going to give me some pain. Few of them are introduced as below. Please enjoy!
Incomplete sentence
example:
Scars make us who we are
Hearts and homes are broken, broken
Far, we could go so far
With our minds wide open, open
example:
Love you forever and forever
Love you with all my heart
Love you whenever we're together
Love you when we're apart
In terms of grammar, it's easy to find some incomplete sentences. What makes them trickier is however, that they don't have proper punctuation marks. It would be okay for word-level processing (though there is still some issues such as negation..), but sentence-level processing would require a huge pre-processing. New-line character doesn't always indicate the end of the sentences, of course!
Use of arbitrary special characters
example:
사르륵녹은 그대를 보면 사랑을 느끼죠
oh so beautiful 사랑을 말해봐요
매일 너와 함께! ~~해!~~~
조금더 다가와줘
example:
다가와- 느껴봐 음-
It may be more about Korean speaker's writing habit. Korean (and Japanese) prefers to use '~' than '-'. In some cases, -- is automatically 'corrected' to –, a long dash, which makes the problem more complex. (Not that much, actually, since all of them should be just ignored as a stopword.)
Multiple languages
example:
簡単に
(칸탄니)
간단히
You make me happy
一言で
(히토코토데)
한마디로
夕べの すれ違い
(유우베노 스레치가이)
저녁때의 엇갈림
まだまだ 埋まってない
(마다마다 우맛테나이)
아직아직 채워지지 않아
So I'm waiting ソワソワ Oh
(소와소와)
안절부절
The example above is an extreme one, written with Korean, Japanese, and English (+Korean interpretation for Japanese sentences in parentheses). However, it's very common to use English words in Korean lyrics.
Corruption by other information
example:
[Chorus]
Yeah (yeah)
Shorty got down to come and get me [x2]
There are many non-lyric texts such as [Chorus] or [x2] to help the viewer, while giving me pain.
So many Yeah's and Oh's
There are so many Yeah's and Oh's in lyrics. I'm not sure what should I do with them.
To summarise, these are the lists that I think I should add to usual stopwords list to process lyrics.
Some special characters (which should be already included in stopwords list)
노래 가사를 텍스트로 보고 처리하는 과정에서 흥미로운 내용이 있어서 정리했습니다. 자연어 처리 관점에서 노래 가사를 다루니 일반적인 텍스트와 다른 점이 많이 보이네요.
구두점의 활용이 불명확함
예:
이런 그대를 믿으라고 했나요..
그 때 왜 나를 사랑한다 했나요..
그대가 바랬던 마음을 그려왔었던..
그 모습에 내가 많이 모자란 건가요..
예:
버리고 싶은 건 니가 아니었어
버려지는 건 내가 되어줄께
이렇게 그냥 버려둬 오지마
첫 번째 예는 문장 끝마다 '..' 을 붙였습니다. 반면 두 번째 예는 문장 끝에 마침표가 전혀 찍혀있지 않습니다. 결론적으로 노래 가사에서 마침표, 쉼표, 느낌표 등 모든 구두점은 전부 없애버리는 편이 처리하기에 수월해보입니다. 노래 가사는 일관된 규칙으로 작성하지 않으니까요.
자연어 처리를 단어 레벨에서 한다면 큰 문제는 없습니다. 다만 문장 레벨로 처리하려면 좀 곤란하겠죠.
특수문자의 활용이 다양하고 다채로움
예:
사르륵녹은 그대를 보면 사랑을 느끼죠
oh so beautiful 사랑을 말해봐요
매일 너와 함께! ~~해!~~~
조금더 다가와줘
예:
다가와- 느껴봐 음-
위의 예를 보시면 물결과 느낌표, 대쉬 기호가 같은 것을 의미합니다. 이 외에도 -, - - , ---, ~, 등 아주 다양합니다.
사용하는 언어가 다양하다
(극단적인) 예:
簡単に
(칸탄니)
간단히
You make me happy
一言で
(히토코토데)
한마디로
夕べの すれ違い
(유우베노 스레치가이)
저녁때의 엇갈림
まだまだ 埋まってない
(마다마다 우맛테나이)
아직아직 채워지지 않아
So I'm waiting ソワソワ Oh
(소와소와)
안절부절
무슨 노래인지는 모르겠지만 이 노래는 영어가사, 일본어, 일본어 발음, 한국어 해석이 적혀있습니다. 위의 예가 조금 특이한 경우지만 영어 단어/문장과 국문이 섞여서 나오는 가사는 아주 흔하죠.
각종 잡; 내용
예:
Simply just look at you
Why must I fall for you? Ooo-Ooo-Ooo
Or why I can't think of words when I,
Simply approach you
I don't know what to do, Ooo-Ooo-Ooo
^ㅅ^/
예:
[Chorus]
Yeah (yeah)
Shorty got down to come and get me [x2]
첫 번째 예는 잘 나가는데 가사 맨 끝에 왠 이모티콘을 넣어놨습니다. 두번째 예는 [chorus], [x2] 와 같은 부가적인 정보가 그대로 텍스트에 포함되어있습니다.
예 워 오 우
노래 가사에 yeah, oh, whoa, 예, 워, 예이예, 라라라, 워, 오, 오오, .... 가 아주 많이 나옵니다.
그 외에 나를 힘들게 하는 것들
예:
to moonn6pencefrom shootingstar
가사입력 papayeverte
[Jazz Instrumental]
가사 어쩌구저쩌구<br>가사 다음줄<br>가사 가사 <br>
from A-Zlyrics, ...
위의 내용을 다 보듬어 보면 아래와 같은 식의 Stopword를 추가해야 한다는 결론이 나옵니다. 물론 이외에도 많이 있겠죠.
- border_mode: full, valid가 있고 그 중간격인 same도 매트랩에선 지원합니다. 자세한 설명 생략. 컨볼루션 할때 이미지 끄트머리; 가장자리를 어떻게 처리할지 하는 내용입니다.
- (32, 3, 3, 3)에서 ...
- - 뒤의 3,3은 이미지 패치 사이즈입니다. 즉 (3, 3) 크기의 패치가 이미지를 쭉 훑고 다니게 됩니다.
- - 앞의 (32, 3)은, 3개 채널의 이미지 stack을 32개의 이미지 stack으로 만들어주겠다는 이야기입니다. 즉, 이 부분에서는 총 32개의 피쳐를 추출하게 됩니다. 그 추출은 (3x3)의 이미지 패치의 값 (=9개의 계수, weight parameter)를 learning하여 사용합니다. 따라서 이 과정을 거치면 32x32의 이미지(의 피쳐)가 32개가 쌓이게 됩니다.
- - 같은걸 (32, 32)로 또 해줍니다.
- - 이번엔 (32, 64)로 또 해줍니다.
- - 마지막으로 (64, 64)로 또 해줍니다. 이런 과정을 거쳐서 이미지는 Low-level feature (직선, 곡선 등의 단순한 피쳐)에서 high-level feature (눈 모양이 있는지, 얼굴 모양이 있는지 등등..)로 변환됩니다.
"그런데말입니다,"
중간에 Max-Pooling이 두 번 있었죠. 그래서 이미지의 크기는 (32x32)가 아니라 (8x8)이 됩니다.
여기까지를 feature learning이라고 생각할 수 있습니다.
파라미터 설명 ---절취선 이후---
여기서부터는 classification에 가까운 단계입니다.
앞서 convolutional layer를 여러 단계 거친 결과 8x8 이미지가 총 64개가 쌓여있게 됩니다. 즉 전체 데이타 포인트는 64*8*8=4096개가 됩니다.
Dense(64*8*8, 512) 에서는 입력 4096개, 출력 512개의 fully-connected 레이어를 추가합니다.
