+ − ⋅ − = nfnf nfnf Sim 2 4

5.VI.2006
Jacek Wołkowicz
Pracownia Problemowa II
„Analiza utworów fortepianowych róŜnych kompozytorów zapisanych w plikach MIDI”
1. Cel pracy
Celem pracy będzie usprawnienie metody klasyfikowania i umoŜliwienie
indeksowania dokumentów muzycznych MIDI poprzez analizę dataminingową i statystyczną
profili kompozytorów (wytłumaczone później).
Metody analizy utworów MIDI są zastosowane takie jakimi analizuje się teksty pisane
w Information Retrieval czy Text Data Mining. Prace tego typu nie były dotychczas
prowadzone.
Główny nacisk informatyka kładzie dziś na przetwarzaniu tekstów, głównie przez
ogrom danych na globalnej sieci, oraz przez to, Ŝe tekst jest bliski kaŜdemu człowiekowi
(wszyscy umiemy czytać, nie wszyscy znamy się na muzyce) oraz to, Ŝe tekst niesie ze sobą
główną informację. Rola muzyki sprowadza się w zasadzie tylko do wywierania wraŜenia,
choć dla badaczy i muzykologów jest równie cenna jak tekst. Podobnymi cechami cechuje się
przetwarzanie obrazów.
JednakowoŜ zajmowanie się przetwarzaniem danych muzycznych jest waŜne, moŜe
głównie przez to, Ŝe znajomość muzyki nie jest powszechną umiejętnością a, jak twierdzę, w
pewien sposób da się ją zaimplementować i wyposaŜając komputery we właściwe narzędzia –
wspomóc człowieka w jego pracy z muzyką.
Dodatkową cechą muzyki podobną do tekstu, a róŜniącą ją od grafiki jest
symboliczność – zapis nutowy moŜemy przetwarzać jak język naturalny, podobnie jak tekst.
Obrazy nie mają takiej symbolicznej reprezentacji, moŜemy je próbować kwantować, ale to
cały czas są dane „analogowe” w sensie zawartości.
2. Klasyfikator plików MIDI
Badaną klasyfikacją będzie analiza statystyki n-gramów w utworach fortepianowych
zapisanych w formacie MIDI. Najprostszy klasyfikator powstał juŜ pół roku temu. Jego
zadanie polega na robieniu statystyk występowania słów – n-gramów – kolejnych n-nutowych
fragmentów. W badaniach wyszło na jaw, Ŝe najlepszą wielkością n jest 7. Następnie przy
pomocy uzyskanych profili kompozytorów stosowane jest porównanie do profilu badanego
utworu i na tej podstawie – wyliczany werdykt. Jako miarę podobieństw profili wybrałem
daną zaleŜność:
  2 ⋅ ( f (n ) − f (n ))  2 
1
2
 
Sim = ∑  4 − 

(
)
(
)
f
n
+
f
n
n∈ profile
2
 
  1
Gdzie podobieństwo profili jest sumą podobieństw wszystkich jego składników a f1(n)
i f2(n) są częstością (ilością wystąpień) danego słowa w profilach.
1/9
Do badań uŜyłem korpusu 251 utworów 5 kompozytorów:
Liczba
utworów
J.S.Bach
Ilość róŜnych
n-gramów
Pojemność
n-gramy
melodyczne
n-gramy
rytmiczne
109
963kB
59932
45451
11584
L. van Beethoven
44
1399kB
54299
48076
12836
F.Chopin
58
1052kB
38508
33711
9341
W.A.Mozart
17
448kB
16554
13981
5345
F.Schubert
23
1116kB
27311
24560
7217
251
4978kB
189494
149364
37297
Suma
3. Profile kompozytorów i ich analiza
Produktem ubocznym powyŜszej analizy jest macierz utwór-sekwencja – podobna do
macierzy document-term znanej z IR. W ramach projektu wykonałem 2 typy analizy na tych
danych jedną metodę typu „unsupervised” a drugą „supervised”.
Wszystkie programy analizujące zostały napisane w języku PERL a program
wizualizacyjny i analizator MIDI – w OpenGL + C++.
a) analizator – program w C++ o składni wywołania ./preprocessor plik.mid generuje
plik result.mtxt w którym dane zapisane są w postaci
channel 1 [liczba nut]
[zmiana rytmu1][zmiana melodii1]
[zmiana rytmu2][zmiana melodii2]
[zmiana rytmu3][zmiana melodii3]
…
channel [nr kanału] [liczba nut]
[zmiana rytmu1][zmiana melodii1]
[zmiana rytmu2][zmiana melodii2]
[zmiana rytmu3][zmiana melodii3]
Które następnie mogą być przetwarzane przez perlowe programy
b) program treningowy train.pl
Program w Perlu który zbiera informacje z pliku wejściowego .mid i zapisuje
profile w bazie danych gdbm. Składnia programu ./train.pl <kompozytor>
<plik.mid>[…]. Program korzysta z preprocesora przy parsowaniu pliku. Po
nauczeniu wszystkich utworów obecne są 3 katalogi – profiles,
melodicprofiles,
rhythmicprofiles. Posiadają one profile rytmiczne,
melodyczne oraz kombinowane dla kaŜdego kompozytora:
torch: ~$ ls *profiles
melodicprofiles:
bach.gdbm
beeth.gdbm
chopin.gdbm
mozart.gdbm
schub.gdbm
profiles:
bach.gdbm
chopin.gdbm
mozart.gdbm
schub.gdbm
beeth.gdbm
2/9
rhythmicprofiles:
bach.gdbm
beeth.gdbm
chopin.gdbm
mozart.gdbm
schub.gdbm
c) program extract.pl i addstat.pl do wypełniania macierzy document-term:
Program extract.pl pobiera dane o wszystkich n-gramach i tworzy listę
unikalnych słów dla wszystkich kompozytorów wpisując je w kolejności od
najczęściej uŜywanego, do najrzadziej tworząc pliki profiles.xlsdata,
melodicprofiles.xlsdata i rhythmicprofiles.xlsdata program addstat.pl
(składnia ./addstat/pl […lista plików .mid]) dodaje statystyki dla kaŜdego
pliku muzycznego.
Wyjściowe pliki są bardzo duŜe ( w KB):
torch: /tmp/jacek$ du -ks *data
110472 profiles.xlsdata
77312
profilesmelody.xlsdata
20800
profilesrhythm.xlsdata
Te macierze mogą juŜ być przetwarzane przez dalsze algorytmy.
4. Prawo Zipfa dla utworów muzycznych
Zanim zastosujemy metody odpowiednie do tekstów, zbadajmy, czy dane muzyczne
spełniają fundamentalne prawo Zipfa dla tekstów, które jest podstawą narzędzi badania
tekstów. Mówi ono o liniowej zaleŜności logarytmu częstości występowania słowa, do
logarytmu rangi słowa w korpusie. Dla tych danych jest to spełnione:
combined – słowa rytmiczno-melodyczne.
melody – słowa melodii
rhythm – słowa rytmu
5. Dekompozycja SVD
Analiza SVD (Singular values decomposition) zwana w informatyce pod nazwą PCA
(Partial component analysis) polega na przeniesienie danego przekształcenia (macierzy) do
3/9
nowej bazy tak, aby wartości kolejnych wymiarów były moŜliwie jak najmniejsze.
Najogólniej, przy prawie 200tys cech dla 250 utworów wystarczyłoby 250 wymiarów, by
dokładnie rozpoznać kaŜdy utwór ale my chcemy jeszcze bardziej to uprościć. Innymi słowy
– kaŜdy następny wymiar przynosi coraz mniej informacji więc moŜna arbitralnie obciąć
część wymiarów pogarszając jakość danych, ale teŜ móc spróbować wizualizować te dane,
np. w 3-wymiarowych przestrzeniach.
Metoda ta jest typu „unsupervised” czyli nie potrzebuje wiedzieć, która kolumna
naleŜy do którego kompozytora. Ma to duŜo zalet, gdyŜ jeŜeli się powiedzie, moŜna załoŜyć,
Ŝe przy dodaniu nowych utworów i nowych kompozytorów – wynik będzie zbliŜony, tzn. Ŝe
poprawnie rozpozna pojawienie się nowego kompozytora. Wadą jest to, Ŝe nie przekazujemy
programowi prawie nic – musimy liczyć na jego intuicję, Ŝe uda mu się rozpoznać poprawnie
przypisać cechy.
Na macierzy profiles.xlsdata (ogólnej) przeprowadziłem dekompozycję SVD
programem svd(.exe) wczytujący macierz z pliku M.txt i generujący macierze U, W i V
takie, Ŝe M=UWV gdzie W jest macierzą diagonalną wartości własnych M (wskazuje na
waŜności nowych wymiarów) a U i V – odwzorowaniami dokumentów i n-gramów w nowej
przestrzeni. Program jest własny, jednakowoŜ przy implementacji algorytmu wsparłem się
implementacją SVD z ksiąŜki „Numerical Receipes In C”. Wykonując mnoŜenie UTM
uzyskujemy proporcjonalne współrzędne dla nowej przestrzeni tym razem 251 wymiarowej,
gdzie najistotniejsze są początkowe wymiary.
Wyniki przeprowadzonej analizy nie satysfakcjonują jednak – okazuje się, Ŝe
kompozytorskość nie jest pierwszorzędową cechą. MoŜe wydawać się to oczywiste –
najbardziej liczą się takie rzeczy, jak forma, tryb, tempo utworu i to one powinny wyjść w
analizie.
Poza tym – wiele wymiarów, nie tylko pierwsze 2, 3 niosą duŜo informacji – oto
wykres „waŜności wymiarów”:
800
700
600
500
400
300
200
100
0
Wartość własna
0
20
40
60
80
100
120
140
160
180
200
220
240
Ten wykres pokazuje, Ŝe całkiem sporo informacji niosą nam wartości własne do 20.
zatem wizualizacja w 3 wymiarach nie moŜe dać nam wiele.
4/9
O tym, Ŝe te wartości zachowują się monotonicznie (we współrzędnych
logarytmicznych) świadczą poniŜsze dwa wykresy:
Program show.exe wykorzystuje OpenGL do wizualizacji punktów w przestrzeni 3D. Program
ładuje współrzędne punktów z pliku points.dat we wszystkich wymiarach i prezentuje
pierwsze 3. Sterując klawiszami 0-9 przestawiamy widoki między wymiarami.
Poszczególne kolory oznaczają róŜnych kompozytorów:
Wymiary (0,1,2): (nie pokazują one niczego szczególnego)
Wymiary
(4,6):
(wyraźne
zielonym(Beethovenem))
rozróŜnienie
5/9
między
czerwonym(Bachem)
a
Wymiary (4,7,8): (wyraźna grupa czerwona (Bach))
Wnioski:
Metody „unsupervised” jak dekompozycja SVD nie nadają się do określania autorstwa
utworów muzycznych. Jest to wynikiem tego, Ŝe za przynaleŜność do konkretnego autora
odpowiadają dosyć subtelne cechy tak, Ŝe bez określenia grupy treningowej – nie moŜna
rozpoznać autorów. Co prawda – pewne grupy da się zauwaŜyć, ale ujawniają się one dopiero
po odkryciu autorstwa, co mija się z celem metod bez nauczyciela.
6. Badanie Entropii
W ogromie ilości danych naleŜałby znaleźć metodę do usunięcia zbędnych danych –
informacji, które nic nie wnoszą, które zaszumianą sytuację, które wręcz zmylają klasyfikator.
6/9
Cecha która dobrze klasyfikuje powinna charakteryzować się duŜą entropią wewnątrz
grupy utworów jednego kompozytora, a małą entropią entropii wszystkich grup
kompozytorskich, innymi słowy – powinna często występować wśród jego utworów i rzadko
– gdzieindziej.
Miarą dobroci informacyjnej słowa jest R (definicja):
Oznaczmy H(i,k) jako informację jaką niesie słowo ‘i’ w grupie kompozytora
‘k’ (‘k’ zmienne od 1 do ‘N’). Ustalam, Ŝe entropia samych zer jest równa 0.
Ranga cechy ‘i’ – R(i) oznaczam jako:
(
R (i ) = max (H (i, k ) ) log 2 N − H (i )
k ∈1.. N
k
)
Czyli ranga cechy jest proporcjonalna do informacji jaka niesie o kompozytorze na
którego wskazuje i proporcjonalna do informacji, jak ta cecha wyróŜnia tego kompozytora w
danej grupie.
Program calc.entropy.pl liczy rangi dla kaŜdego słowa i zapisuje je na wyjście.
NajwaŜniejsza część programu – obliczająca rangę:
#oblicznie entropii w grupach kompozytorskich
foreach my $c (@composers) {
entropies{$item}{$c}=entropy(@vals[($composers_ranges{$c}[0])..($composers_ranges{$c}[1])]) ;
}
#obliczanie rang na podstawie powyŜszych entropii
$rank{$item}=max(values %{$entropies{$item}})*
( log(scalar @composers)/log(2)- entropy(values %{$entropies{$item}}) );
Następnie listę entropii (wraz z Zipf’owską rangą kaŜdego słowa) przetworzyłem
przez program entropy.plot.pl, który zliczał w oktawach rank Zipf’owskich ilość
wystąpień następujących grup słów:
1) grupa słów o R(i)>2.322 (‘key words’)
2) grupa słów o 2.32<R(i)<2.322 (‘ones’)
3) grupa słów o 0<R(i)<2.32 (‘stop words’)
4) grupa słów o R(i)=0 (‘noise words’)
Pierwsza grupa to słowa niosące nam najwięcej informacji o ręku autora. Druga grupa
wskazuje nam granicę między wiedzą a zmylaniem. Wartość R(i)~2.321 mają n-gramy o
strukturze H(i,k)k=1..N=(0,….,0,1,0,….,0) przy N=5. Mówią nam one, Ŝe powtórzenie n-gramu
w innym utworze tego samego kompozytora było jednokrotne, zatem moŜemy twierdzić, Ŝe
przypadkowe, a szanse na to były jak 1/N, czyli ta cecha na 1/N wskazuje na właściwego
kompozytora (zakładając losowość wystąpienia cechy) czyli działa jak klasyfikator losowy.
Trzecia grupa nie wnosi niewiedzy, po prostu moŜe mieć trochę inną strukturę, ale uznałem,
Ŝe to są juŜ słowa które bardziej zamydlają oczy niŜ przynoszą informację. Czwarta grupa to
słowa, które mają maksymalnie jednego reprezentanta w kaŜdej grupie – zerowa przydatność.
Dodatkowo program zipf2.pl oblicza jaki procent zajmują do tej pory
przeanalizowane słowa w całym korpusie.
Oto wykresy proporcji liczności tych grup do liczności przedziału (2i) dla słów
rytmiczno-melodycznych. Linie oznaczone ‘%’ stanowią o zajętości korpusu
dotychczasowymi słowami (max 412868 słów):
7/9
1
rozkład słów w korpusie
0.9
0.8
I
0.7
II
III
0.6
IV
%
0.5
0.4
0.3
0.2
0.1
przedział (log(Zipf's rank))
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Dla słów melodycznych:
1
rozkład słów w korpusie
0.9
0.8
I
0.7
II
III
0.6
IV
%
0.5
0.4
0.3
0.2
0.1
przedział (log(Zipf's rank))
0
0
1
2
3
4
5
6
7
8
Oraz rytmicznych:
8/9
9
10
11
12
13
14
15
16
17
1
rozkład słów w korpusie
0.9
0.8
I
0.7
II
III
0.6
IV
%
0.5
0.4
0.3
0.2
0.1
przedział (log(Zipf's rank))
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
Wnioski:
ZauwaŜam, Ŝe pierwsze 16-64 (24-26) słów to wyłącznie ‘stop words’ – słowa
powszechnie uŜywane przez wszystkich kompozytorów – nie pomagają one nam rozróŜnić
kompozytorów od siebie a jedynie wprowadzają bałagan. Jak moŜna zaobserwować stanowi
to kłopot obliczeniowy wyłącznie przy profilach rytmicznych gdzie stanowią one ok. 65%
wszystkich słów (dwa na trzy słowa są nimi). Przy profilach melodycznych jest to ok. 5%
zawartości. Następnie we wszystkich profilach następuje okres nasilania występowania ‘key
words’, gdzie nawet co drugie słowo ma duŜe znaczenie dla danego kompozytora. We
wszystkich profilach okres ten pochłania 20-25% całej masy słów. Przy 1000-2000 słowie
(210-211) zaczynają dominować ‘noise words’ i ‘ones’ – przypadkowe potknięcia – raz, dwa
razy uŜyte frazy – nic nie wnoszące. Potkniętych rytmów jest stosunkowo mało (ok. 5-10%) o
tyle ‘przypadkowe melodie’ mogą stanowić ok. 70% całej masy papieru, na której zostały
wydrukowane.
Ostatnia konkluzja mówi nam, Ŝe utwory muzyczne składają się najczęściej z
unikalnych fraz nawet w ramach jednego utworu, nie do podrobienia Ŝadną metodą. Zatem
próby statystycznego generowania utworów muzycznych muszą oprzeć się na innej metodzie.
7. Podsumowanie, wnioski
Swoją analizą potwierdzam podatność danych muzycznych na analizę podobną tej,
znanej z IR czy TDM. Utwory muzyczne oporne są jednak na analizę metodami bez
nauczyciela, zdecydowanie preferowane byłyby metody ‘supervised’. Pozytywnie dziwi
skupienie słów kluczowych w środku przetwarzanej logarytmicznej skali problemu.
Świadczyłoby to o podatności na indeksowanie a potem wyszukiwanie w takim zbiorze
klasycznymi metodami Information Retrieval. To, co teraz moŜna udoskonalić, to próba
zwiększenia skuteczności klasyfikatora poprzez obcięcie ‘noise words’ i ‘stop words’ z
przetwarzanego korpusu. Pozwoliłoby to 4 krotnie zmniejszyć ilość przetwarzanych danych i
100 krotnie zmniejszyć wymagania profilowe.
9/9