Thursday, September 14, 2017

튜토리알 논문을 하나 썼습니다.

"Music information retrieval을 위한 딥러닝"이라는 제목으로 튜토리알 논문을 하나 썼습니다. 어제 아카이브에 올라왔네요.  논문 링크 | 코드 링크
핵심만 쉽게 설명하려고 애를 많이 썼습니다. 재미있게 읽어주세요.


Sunday, August 27, 2017

저널 논문, 리뷰, 스페셜 이슈

오늘은 잡담을 좀 하고싶네요. 박사과정에서 지금 중요한 때라서요.

제가 있는 학교에서는 학교나 학과에서 박사학위에 특별히 SCI저널이라든지 하는 조건이 없습니다. 특히 컴공에서는 점점 이런 추세로 바뀌고있죠. 그렇지만 제 지도교수는 저널 논문을 나름대로 조건으로 따지는 편입니다. 예외인 경우가 무지하게 많지만요.

특히 저는 펀딩 기간보다 빨리 졸업하려고 하다보니 이런 조건을 무시하고 졸업 논문을 작성하겠다고 설득하기가 어려웠죠. 요즘 이 분야가 사람들이 학위과정 졸업이나 프로젝트 실적, 테뉴어 심사같은 이유가 아니면 굳이 저널 논문을 쓰질 않아서 저는 좋은 저널 논문이 어떤건지도 잘 모르는 상태에서 저널 논문을 썼습니다.

그런데 어쩌다보니 주제 두개를 억지로 묶은 이상한 논문이 나왔고, 스페셜 이슈라 제출일/심사종료/발간 등 날짜가 정해진 곳에 제출을 했습니다. 며칠 전, 예정보다 일주일가량 빠른 리뷰를 받았는데 불안했던 예감대로 Major revision and resubmit -- in 2 weeks 라는 결과가 나왔네요.

저널 논문은 즉시 수락/minor revision/major revision/reject 정도로 결과가 갈립니다. 바로 수락되는 경우는 거의 들어본 적이 없고, minor revision이면 리뷰어가 언급한거만 조금 고치거나 하면 수락되죠. reject은 말 그대로 이 연구는 우리 저널에선 실릴 가능성이 없다는 거구요. 제가 받은 major revision은 고칠게 많지만 리젝주긴 미안하고 약간의 희망은 있다, 는겁니다.

그런데 이게 스페셜이슈를 만나면 조금 달라집니다. 스페셜 이슈는 정해진 날짜에 논문집이 나와야하니 편집자나 리뷰어도 논문이 넘치는 상황이 아닌다음에야 가급적 희망의 불씨를 살려두고싶어하죠. 그래서 major revision이라도 잘 고치면 한번쯤 더 minor revision을 하고 수락이 된다는 시나리오가 실현되길 바라고있습니다.

Major revision이면서 2주밖에 시간을 안주는건 좀 이상한건데 이것도 스페셜이슈 발간 일정때문에 그런것으로 생각합니다.

제가 받은 리뷰는 공통적으로 동떨어진 주제 두개가 논문 하나에 있는것이 이상하다는 내용입니다. 물론 저도 인정하구요. 그래서 급하게 전체 11페이지 분량에서 3페이지를 삭제하고 남은 내용을 발전시켜보고있습니다. 2주 안에 다시 낼 수 있을것 같긴 한데, 잘 될지 모르겠네요.

여기까지입니다. 나중에 저 읽으라고 쓰는 글이지만 공개로 작성합니다. 

Wednesday, July 5, 2017

유학 준비 - 자기소개서와 연구계획서 작성법

간결하게 쓰겠습니다.
  • 자기 소개서
    • Q. 자기 소개서에 쓸 내용이 너무 없어요.
      • A. 자기 소개서에 쓸 내용을 만들었어야합니다. 공부를 했다면 그 내용을 정리해서 인터넷에 올리세요. 연구를 도운게 있다면 공저자로 이름이 들어있겠죠? 그걸 사용하세요. 뽑는사람 입장에서는 이 사람을 뽑았을 때 혹시나 깽판치거나 완전 말아먹을수도 있다는 걱정을 항상 하게됩니다. 따라서 그런 불안감을 줄여주려면 근거 없는 경험을 나열하는게 아니라 신뢰할 수 있는, 권위 있는 사람이나 소속이 연관된 뭐라도 하셔야합니다.
      • 지금까지 한게 없으면 지금부터라도 하세요. 1달이라도 의미있는걸, 그리고 문서화할 수 있고 설명이 가능한걸 뭐라도 하고 그걸 적으세요. 만일 수 개월의 시간이 있다면 분명 의미있는 활동을 할 수 있습니다. 
    • Q. 자기 소개서를 교수가 읽나요?
      • A. 읽는다고 가정하고 쓰세요. 
    • Q. 주의사항
      • A. 본인이 참여한 프로젝트나 기관을 너무 열심히 설명하지 마시고 본인이 참여한 이유, 맡은 역할, 배운 내용을 쓰세요. 즉 본인이 뭘 하셨는지를 적으셔야합니다. 자기소개서는 내 예전 직장 소개서가 아닙니다.
  • 연구계획서
    • Q. 전 아는게 없는데 연구계획서를 어떻게 쓰죠? 
      • A. 연구계획서를 쓸 수 있도록 해당 분야의 논문, 서적, 발표자료 등을 면밀히 찾아보시길 바랍니다.
    • Q. 대학원 다니는 동안 연구계획서대로 진짜 연구를 수행해야 하나요?
      • A. 아뇨, 실제로 연구하는 내용은 엄청나게 바뀔겁니다. 그렇지만 현 시점에서 최대한 노력해서 쓰셔야합니다.
    • Q. 연구계획서를 교수가 읽나요?
      • A. 읽는다고 가정하고 쓰세요.
  • 그 외
    • 자기소개서에서는 본인의 과거를 소개합니다. 어지간하면 최근 몇 년만 적으세요.
    • 연구계획서에는 본인이 미래에 - 향후 몇 년 간 - 뭘 할지 적습니다. 
    • 따라서 두 문서는 내용이 겹치거나 같은 말을 반복하지는 마세요. 그러나,
      • 과거에 나는 이런이런걸 했고, 이건 나의 어떠한 면을 보여주며, 내 관심 분야를 이렇게 공부해왔고,
      • 미래에도 이걸 계속하고 싶으며 이러이러하게 열심히 잘 할것이니 뽑아달라.
    • 로 일맥상통해야 합니다.
    • 연구계획서에 적힌 연구 내용은 당연히 지원하는 학교와 잘 맞아야합니다. 교수의 논문 목록을 찾아보시면 최근 관심분야가 나오겠죠.
    • 자기소개서나 연구계획서가 당락을 가르는지 관심갖지 마세요. 그냥 열심히 준비하세요. 교수마다 다르고, 학교마다 다르고, 기분따라 다릅니다. 남들이 어떻게 하는지, 어떻게 했는지는 전혀 중요하지 않습니다.

Wednesday, June 14, 2017

음성/음악신호+머신러닝 초심자를 위한 가이드 [4편]

음성/음악신호+머신러닝 초심자를 위한 가이드 전체 게시물은 여기를 클릭하세요.

데이터 수집

이번엔 데이터 수집을 주제로 글을 쓰겠습니다.

기존 데이터셋 사용

음악 데이터 셋은 http://www.audiocontentanalysis.org/data-sets/ 여기에 잘 정리되어있습니다.
오디오 관련 데이터셋은 좀 더 중구난방인데, 
- Urbansound8K by Justin Salamon
- AudioSet by Google, 2017 (유튜브 주소만 제공하고 직접 크롤링해야함. 어떻게? Fuel, YouTube-dl)
- DCASE audio detection by Queen Mary University of London
- Bird Audio Detection by Queen Mary University of London

이 정도가 생각나네요.

데이터 수집

살다보면 힘들고 험한 길을 가야할 때가 있죠.
freesound에서 직접 크롤링해서 뭔가 할 수 있지 않을까? 하는 희망을 한번쯤은 품어볼 필요가 있습니다.
아래 코드를 참고하세요. 주소는 여기





데이터 정리

데이터를 모으는게 다가 아니죠. 일단, 키워드로 검색을 했으니 특정 소리가 들어있는 음악 파일을 잔뜩 받았다고 해봅시다. 뭘 해야할까요?


  • Normalisation
import numpy as np
import librosa

x = librosa.core('event1.mp3', sr=None, mono=True)
x = x / np.max(np.abs(x))

  • Trimming
앞뒤에 조용한 구간이 있다면 싹둑 잘라주는편이 좋겠죠. 이건 어느정도 대애충 감으로 하는게 편할것같네요. 저라면, hann window같은걸 씌우고, 각 윈도에서 평균 에너지를 구해서 (np.mean(np.abs(windowed_source_x) ** 2)), 그 윈도 별 평균 에너지를 기준으로,아무런 음향 이벤트가 안일어나는 첫 N개의 윈도와 마지막 M개의 윈도를 날리겠습니다.

  • Augmentation
데이터가 부족하면 뻥튀기를 하고싶겠죠? 방법은 여러가지가 있습니다. 적당한 구간에서 pitch shift / time expanding을 하시면 무난할테고, 다른 잡음을 적당히 섞어주는것도 좋겠죠 (x = x + gain * noise). 이 정도만 해도 벌써 10배이상 데이터가 늘어날 것 같네요. 


  • 주의사항
음원이 매우 길다거나해서 여러 개의 학습 데이터 샘플로 쪼개서 쓰는 경우에, 같은 음원에서 나온 샘플 여러개가 training/validation/test 셋에서 섞이지 않도록 주의합시다.


이상입니다.

Monday, June 5, 2017

WWDC 2017 - Apple Music, MusicKit API

Apple Music 관련 몇 가지 뉴스가 나왔네요.
  • 애플 뮤직이 런칭한게 약 2년 전입니다. 2015년 6월 30일에 서비스를 시작했군요. 1년 반이 2016년 12월에 유료 구독이 2천만명을 넘었다고 기사가 나왔었고 오늘은 2천 7백만명이 넘었다고 발표했습니다. 업계 1위인 Spotify가 5천만명을 발표했죠. 둘 다 여전히 성장을 하고 있습니다. 
    • 참고로 Spotify는 아직까지 적자 기업이지만 음악 비즈니스 전체의 파이가 커지고 있는 것 등을 감안하면 미래가 그렇게 어둡지는 않아보입니다. 
    • 역시 사견입니다. Spotify는 광고 기반 무료 감상때문에 적자인건데, 이게 음악 시장 전체를 악화시킨다고 생각합니다.
  • MusicKit 이라는 새 API를 발표했군요. iOS 11의 신기능입니다. 이걸 쓰면 애플 뮤직 유저의 각종 정보 - 라이브러리, 개인화 추천 등에 접근이 가능하다고 하네요. 애플 뮤직은 안드로이드에서도 있으니 안드로이드용 API도 나오면 좋을텐데 딱히 언급은 없었습니다.
  • 역시 Spotify포함 기존 서비스에 많이 있는거죠. 소셜 기능을 추가했네요. '친구' 맺은 사람이 뭐 듣는지 나오고 그런거라고 하네요. 자세한 언급은 없었지만 연락처에 있는 목록 / 페북 친구 등등으로 연계해서 나올거같습니다.

국내 스트리밍 서비스도 재미있는 API를 많이 열면 좋겠습니다만, 경제적인 유인이 적으니까 안하는것이겠죠. 연구자, 종사자 및 음악을 좋아하는 사람으로서 매우 아쉬운 면입니다.

Friday, June 2, 2017

블로그를 하십시오.

독자가 컴공 대학원생이라고 가정하고 글을 쓰겠습니다. 아닌분들이 더 많겠죠? 본인의 상황에 맞는 조언인지 생각해보면서 읽으시면 되겠습니다.

블로그를 운영하면 생각보다 많은 사람들이 와서 봅니다.
그리고 연구는, 더군다나 취직은, '장사'의 속성을 지니고 있습니다.
아시다시피 그리고 컴공 분야 종사자들은 컴퓨터를 엄청 오래 합니다.

블로그에 논문을 설명해놓으면, 더 많은 사람들이 효율적으로 당신의 연구를 이해하게 됩니다. 그럼 더 많이 읽고 더 많이 인용하겠죠.
블로그의 좋은 글을 보면서 당신이 누군지 알게되고, 당신의 연구와 논문에 관심을 갖고 더 신뢰하게 됩니다.
블로그를 보면 독자는 당신의 연구 분야와 능력을 알게 되고, 더 낮은 기회비용으로 당신을 고용하려고 하겠죠.

모두 실제로 제게 일어난 일입니다. 저는 국문 블로그(여기), 영문 블로그, 깃헙 저장소 등으로 열심히 '영업'을 합니다. 지금보다 훨씬 영업할 껀덕지가 없을때부터 그랬습니다. 이건 제가 박사과정 시작하고 갔던 첫 번째 학회에서 (현재 DeepMind에서 일하는, AlphaGo와 Wavenet 논문의 저자) Sander Dieleman이 조언해준 덕분입니다. Sander도 Spotify x Convnet 게시물이 엄청난 인기를 끌어서 유명해졌고 그 결과로 딥마인드에서 면접 오퍼를 받았습니다. 저는 그런 스타급 연구자가 아니지만 현재 일하고있는 스타트업(버즈뮤직)에서도 제 블로그를 보고 연락을 줬고, 자문역으로 일하기 시작한 제이마플도 마찬가지입니다. 멜론에서도 연락이 왔었군요. 제가 런던에 있으니 더 용이한 것도 있겠지만 Mixcloud나 Kantar Media에서도 비슷한 연락을 받았습니다.

아마 제가 블로그/깃헙을 안했다면 아무 일도 일어나지 않았을 것입니다. 여러분, 블로그를 하세요. 엄청난 도움이 됩니다. 남들도 하루종일 웹서핑 하거든요.

Wednesday, May 17, 2017

두괄식 글쓰기: 영어 논문을 'Poor English'로 리젝 당하지 않는법

요즘 저랑 같은 사무실 쓰는 친구들이 학회를 준비중입니다. 최근에 리뷰가 끝났고 이제 통과/탈락 Acceptance/Rejection을 정하는 회의를 하더군요. 그리고 그럭저럭 재밌는 연구를 했지만 논문 작성 - 글쓰기를 매우 못해서 모든 리뷰어에게 낮은 점수/Rejection을 받은 논문을 보여주더군요.

인터넷에서 논문 리뷰 가이드를 찾아보면 '글쓰기'보다 연구 내용을 보고 평가하라고 써있곤 합니다. 그렇지만 현실에서는 영어 또는 글쓰기 이슈로 점수를 많이 깎이고 결과적으로 억셉될수도 있었던 논문이 리젝되는 슬픈일이 일어나곤합니다.

사실 억울하죠. 서양애들은 영어가 모국어가 아니더라도 한국어 화자가 얼마나 영어로 말하고 글쓰기가 어려운지 몰라요. 그렇지만 현실이 냉정하니 생존할 방법을 논의해봅시다. 저도 많이 부족하지만 제가 깨달은 몇가지를 이야기해보도록 하겠습니다. 

몇 가지 이야기를 할건데, 핵심 키워드는 "두괄식" 입니다. 

두괄식으로 초록 쓰기

오늘 제가 리젝당한걸 지켜본 논문의 시작은 두 문단으로 되어있습니다. 대략 이런식으로요. (제가 작성한 예제입니다.)

The development of parallel-computing hardware and optimisation techniques have been helped research on deep neural networks since 2000s when .. blahblah (중략)
This work present a music classification based on deep convolutional neural network. ... (후략)

즉, 첫 문단에 이 연구의 배경 설명을 소개하고 두 번째 문단에서 본격적으로 이 논문의 내용을 소개하는겁니다.

결론부터 이야기하면, 서양식 글쓰기에서 첫 번째 문단은 완전 불필요한 잉여문단입니다. 저런 소개를 빼고 조금도 어색하지 않아요. 리뷰어는 이미 해당 분야의 배경 지식을 갖고있습니다. 저런 소개는 잉여인데다가 리뷰어의 집중력을 흐트려놓습니다. 그리고 논문의 시작에서 강렬하고 좋은 인상을 주지 못하면 이미 "이 논문 뭐야? 어디꺼야?"이러면서 부정적으로 보게 되고 최악의 경우엔 제대로 읽지도 않아요. 부당하지만 현실.

게다가 영어 실력이 조금 떨어져서 쓸데없는 내용을 담은 이상한 문장이 나왔다면? 리젝률이 막 올라가는거죠. 오늘 본 논문이 딱 이랬어요. 

즉, 부족한 영어실력 * 두괄식이 아닌 글쓰기 = 리젝. 따라서 일단 두괄식으로 초록을 쓰세요. 초록 첫 문장에서 바로 강펀치를 빵! 날리셔야합니다.

두괄식으로 본문 쓰기

마찬가지 내용입니다. 각 문단의 첫 문장만 모아놓으면 자동으로 개요가 되어야한다고 생각하면 편합니다. 문단의 첫 문장은 그 문단의 가장 중요한 내용을 요약해야합니다. 만일 중요한 내용이 두 개가 나온다면 문단을 나누세요.

두괄식으로 문장 쓰기

논문에서는 'we'가 아니라 수동태로 문장을 작성하라고 배우죠. 그런데 보면 종종 we로 시작하는 문장도 있어요. 이걸 더 자세히 설명해볼게요.

1. Audio signals are converted into short-time Fourier transform.
2. Short-time Fourier transform is adopted to represent audio signals.
3. We use short-time Fourier transform to represent audio signals.

언뜻 보면 같은 내용을 다르게 표현한것 같지만 논문 글쓰기를 하는 경우에는 저 셋을 구별해서 사용해야합니다.

일단, 1과 2는 소위 수동태고 3은 능동형 문장이네요. 그럼 어떤 차이가 있을까요?

1. 주어가 Audio signals로 되어있네요. 이 경우엔 오디오 신호를 어떻게 처리하는지가 제일 중요한 상황입니다.
2. 주어가 Short-time Fourier transform이네요. 이 맥락에서 다른 방법 (CQT, Mel-spectrogram, ...)이 아니라 STFT를 사용했다는 사실이 중요한거죠.

사실 1과 2는 그렇게 다르진 않습니다. 독자가 읽기에도 별 차이 없는 경우가 대부분일거에요. 그러나 3은 아주 다릅니다.

3. 상황에 따라 "We used short.."로 쓰는게 나을수도 있어요. 아무튼, 왜 논문인데 능동형이냐! 이 문장은, 제안한 방법이 꼭 STFT를 써야하는건 아니고 다른것도 가능한 상황, 즉 알고리즘 내부에서 STFT를 쓰건 다른걸 쓰건 큰 차이가 없고, 이 논문에서 보고하는 실험은 STFT를 썼다는걸 명시하는 경우에 쓸 수 있는 문장입니다. 반대로, STFT를 (거의) 반드시 써야하는 상황이라면 1이나 2처럼 쓰는것이 더 적합하겠죠.

결론

초록도, 본문의 문단도, 문장도 모두 두괄식으로 써야합니다. 한국인의 대화/글쓰기 사고방식이 두괄식이 아니라 두괄식으로 쓰려고 맘먹어도 자꾸 잊을거에요. 그래도 계속 이걸 잊지말고 계속 쓰고 고치다보면 훨씬 좋은 글이 나올거에요. 그럼 다들 좋은 논문 쓰길 바랍니다.