1. No category

Master’s Thesis
Human Beatboxing: generering af
trommespor og automatisk
effektprocessering
Mikkel Gravgaard Nielsen
(20043246)
Vejleder:
Ole Caprani
September 2010
Datalogisk Institut
Aarhus Universitet
Indhold
Forord
4
Resume
5
English abstract
6
1 Indledning
1.1 Motivation . . . . . . . . . . . .
1.2 Teknisk motivation . . . . . . .
1.3 Lignende værktøjer og projekter
1.4 Metoder . . . . . . . . . . . . .
1.5 Resultat . . . . . . . . . . . . .
2 Brugsscenarier
2.1 Involvering af brugere . . . .
2.2 Skitse til trommespor . . . .
2.3 Musikalsk samtale . . . . . .
2.4 Live-beatboxer . . . . . . .
2.5 Beatboxing Hero . . . . . .
2.6 Realisering af brugsscenarier
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Analyse af human beatboxing
3.1 Afgrænsning af lydmateriale . . . . . . . . . .
3.2 Overordnet struktur af systemet . . . . . . . .
3.3 Indsamling af testdata . . . . . . . . . . . . .
3.4 Segmentering . . . . . . . . . . . . . . . . . .
3.4.1 Kobling mellem onsets og lydsegmenter
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
7
8
9
10
10
.
.
.
.
.
.
12
12
13
14
14
16
18
.
.
.
.
.
19
19
21
22
23
24
3.5
3.6
3.7
Klassificering . . . . . . . . . . . . . . . . .
3.5.1 Træning med Perceptron-algoritmen
3.5.2 Flere end to klasser . . . . . . . . . .
3.5.3 Præprocessering . . . . . . . . . . . .
3.5.4 Valg af features . . . . . . . . . . . .
3.5.5 Reduktion af dimensionalitet . . . . .
3.5.6 Klassificeringsalgoritme . . . . . . . .
Testmetode og resultater . . . . . . . . . . .
3.6.1 Overfitting . . . . . . . . . . . . . . .
3.6.2 Resultater . . . . . . . . . . . . . . .
Test og virkelighed . . . . . . . . . . . . . .
4 Design af prototype
4.1 Umiddelbar og forsinket respons . . . . . .
4.2 Audioprocessering med umiddelbar respons
4.2.1 Sammenkobling af signalvektorer .
4.2.2 Ydeevne . . . . . . . . . . . . . . .
4.3 Implementering af prototypen . . . . . . .
4.3.1 Onset-detection og segmentering . .
4.3.2 Præprocessering og klassificering .
4.3.3 Kobling til brugsscenarier . . . . .
4.3.4 Brugerflade . . . . . . . . . . . . .
4.4 Afrunding . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
26
27
28
28
30
33
34
36
36
36
38
.
.
.
.
.
.
.
.
.
.
39
40
40
41
42
44
44
45
47
48
49
5 Brugertests
50
5.1 Sammenfattende brugerrespons . . . . . . . . . . . . . . . . . 52
6 Konklusion
53
7 Fremtidige udvidelsesmuligheder
7.1 Forbedring af klassificering . . .
7.2 Hurtigere processering . . . . .
7.3 Lignende trommelyde . . . . . .
7.4 Understøttelse af groove . . . .
7.5 Plugin til lydprogram . . . . . .
56
56
56
57
57
58
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Litteratur
59
A Vedlagt cd
A.1 Lydmateriale .
A.2 Kildekode . . .
A.3 Prototype . . .
A.4 Videooptagelser
61
61
61
62
62
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B Onset-detection
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
63
3
Forord
Da jeg i dette speciale udover datalogiske discipliner vil beskæftige mig med
musikproduktion og lydprocessering, vil jeg indledningsvist redegøre for min
musikalske baggrund og erfaring, samt for mine forudsætninger indenfor signalbehandling og lydbearbejdelse.
Jeg har sideløbende med min gymnasieuddannelse taget den treårige uddannelse Musikalsk Grundkursus1 på Århus Musikskole. I dette forløb har
jeg fået undervisning i bl.a. sammenspil, musikteori, komposition samt instrumentalundervisning. Uddannelsen har givet mig et musikalsk fundament
samt givet mig mulighed for, både dengang som nu, at arbejde sammen med
mange forskellige musikere.
I forbindelse med min datalogiuddannelse har jeg haft fagpakken Multimedieproduktion på Ingeniørhøjskolen i Århus. Her har jeg arbejdet med
teorien bag signalbehandling samt konkretiseret teorien ved at implementere
lydeffekter og andet lydprocessering.
De nævnte forløb har i sammenhæng med datalogiuddannelsen givet inspiration til ideen bag specialearbejdet. Forløbene har hjulpet mig til at vurdere projektets musikalske perspektiv, samt gjort mig i stand til at anskue
de tekniske implikationer for projektarbejdet.
Stor tak til Martin Albrekt og Kristoffer Thorning for at have stillet
deres human beatboxing-evner til rådighed, og for deres kreative input til
projektet.
Mikkel Gravgaard Nielsen,
Århus, 1. september 2010.
1
http://www.aarhuskommune.dk/sitecore/content/Subsites/
aarhusmusikskole/Home/MGK.aspx
4
Resume
Vi undersøger i dette speciale muligheden for at benytte human beatboxing
til generering af trommespor, samt til at automatisere effektprocessering af
human beatboxing afhængigt af trommetypen. Motivationen er et ønske om
at understøtte tilvejebringelsen af musik med human beatboxing som redskab, både ved musikkomposition og live-fremførelser.
Til formålet opstiller vi konceptuelle og konkrete brugsscenarier. Ud fra
disse fastsætter vi en række krav, som danner grundlag for en analyse af
human beatboxing samt en prototype. I analysen arbejder vi med inddeling
af human beatboxing-optagelser i enkelte trommelyde, hvorefter vi eksperimenterer med forskellige teknikker indenfor signalbehandling til at udtrække
meningsfulde kendetegn for lydene. Vi træner data ved hjælp af perceptronalgoritmen samt principal component analysis, og vi benytter lineær klassificering samt nearest-neighbour-klassificering til at genkende tre forskellige
typer trommelyde: storetromme, lilletromme og hi-hat. Resultaterne fra analysen benytter vi til at implementere en prototype, som kan anvendes af musikere i praksis. Efterfølgende har vi afprøvet prototypen i begrænset omfang
med en række brugere. Gennem kvalitative interviews med brugerne har vi
undersøgt, hvorvidt prototypen opfylder forventningerne om at understøtte
musikalsk tilvejebringelse. Vi finder, at selvom prototypen ikke understøtter
brugernes endelige behov, belyser projektet potentialet med at bruge human
beatboxing som et musikalsk redskab, og vi mener at vores resultater kan
understøtte udviklingen af lignende værktøjer, som benytter human beatboxing.
5
English abstract
In this thesis, we examine the possibility of using human beatboxing for
generating drum tracks, and to automate the effects processing of human
beatboxing, depending on the type of drum. The motivation is a desire to
support the creation of music with human beatboxing as a tool, both in the
case of music composition and live performances.
For this purpose, we outline conceptual and concrete scenarios. Based on
these scenarios, we establish requirements that form the basis of an analysis
of human beatboxing and a prototype. In the analysis, we work with segmentation of human beatboxing sound recordings into individual drum sounds.
Afterwards, we experiment with different signal processing techniques, in order to extract meaningful characteristics of the sounds. We train the data
using the perceptron algorithm and principal component analysis, and we
use linear classification and nearest-neighbour classification for recognizing
three different types of drum sounds: bass drum, snare drum and hi-hat.
The results from the analysis lead to the implemention of a prototype, which
can be used by musicians in practice. Subsequently, we do limited testing of
the prototype together with a group of users. Through qualitative interviews
with the users, we examine whether the prototype fulfills the expectations of
supporting the creation of music. We find that although the prototype does
not fully support the requirements of the users, the project illustrates the
potential of using human beatboxing as a musical tool, and we believe that
our results can support the development of similar tools that utilise human
beatboxing.
6
Kapitel 1
Indledning
En musiker kan benytte sin stemme til at udtrykke en umiddelbar, musikalsk
ide. Musikeren kan med stemmen understøtte det musikalske udtryk, således
at en melodisk strofe for eksempel synges med diskant stemmeleje og vibrerende toner, som om den frembringes af en guitar, eller et tungt bas-groove
frembringes med dyb stemme og stød på de enkelte toner for at markere den
rytmiske fornemmelse.
Ved at bruge stemmens klanglige nuancer kan musikeren altså formidle
sin ide til andre eller lydliggøre ideen for sig selv, også selvom han ikke har
instrumentet ved hånden.
På samme måde kan en trommerytme også udtrykkes med stemmen. Her
er fokus på de rytmiske detaljer samt frembringelsen af trommernes individuelle klang. At frembringe en trommerytme med stemmen betegnes også som
human beatboxing1 , en diciplin som ikke blot benyttes til at frembringe en
midlertidig skitse, men også som endeligt musikalsk materiale, enten solo eller i sammenspilssammenhæng. Derved er human beatboxing en anderkendt
form for musik-udøvelse.
1.1
Motivation
En primær motivationsfaktor i dette speciale er netop human beatboxings
hyppige anvendelse i forskellige musikalske sammenhænge, koblet med behovet for at mindske afstanden mellem den musikalske ide og en konkret skitse
til et tromme-lydspor. Ønsker en musiker på sin computer at komponere et
trommebeat ud fra en ide, han så at sige har i hovedet, kan det forstyrre
1
http://en.wikipedia.org/wiki/Beatboxing, besøgt 9/8 2010
7
Figur 1.1: Beatboxeren D.R.E.S. under en performance i Atlanta.
det kreative flow, hvis han er nødt til først til at finde de ønskede lyde til
de enkelte trommer for derefter at plotte dem ind med tromme-pads eller
musen afhængigt af, hvad der er tilgængeligt. Tanken er, at computerens
analyse og fortolkning af human beatboxing kan mindske denne kløft mellem
musikerens egen rytmiske og klanglige fornemmelse af trommesporet og den
endelige skitse. På denne måde kan en musiker bruge human beatboxing som
et musikalsk værktøj.
Samtaler og afprøvninger af projektet med andre musikere har yderligere
bidraget til motivationen samt medvirket til at udvide anvendelsesmuligheder
samt konkretisere og specificere brugssammenhænge.
1.2
Teknisk motivation
Den tekniske realisering af projektet er motiveret af eget forhåndskendskab og
erfaringer inden for områderne musikkomposition og produktion, signalpro-
8
Figur 1.2: Voice Band til iPhone fra WaveMachine Labs, Inc.
cessering og mønstergenkendelse. Derpå er inddraget artikler som konkret
beskæftiger sig med segmentering af trommelydspor samt klassificering af
trommelyde. Artiklerne har dannet teoretisk udgangspunkt for valg af metoder, og disse metoder er efterfølgende implementeret og efterprøvet i praksis
med indspillet lydmateriale af erfarne beatboxere.
1.3
Lignende værktøjer og projekter
Der findes eksisterende værktøjer, som lader en musiker benytte sin stemme
som en form for digital trommestik:
Programmet Voice Band2 til iPhone imødekommer behovet for at kunne
komponere musik i realtid uden at skulle interagere med touch-skærm ved
at lade musikeren hovedsageligt bruge sin stemme for at lave den musiske
notation. I Voice Band optages trommerne to ad gangen. Således kan man i
ét take indspille hhv. store-/lille tromme eller lukket/åben hi-hat ved at lave
svage og kraftige lyde med den ønskede rytme.
BillaBoop3 er et plugin til musikprogrammer som laver klassificering af
trommetypen på baggrund af de første millisekunder af hver enkelt slag i et
2
3
http://www.wavemachinelabs.com/voiceband/
http://www.iua.upf.edu/~ahazan/BillaBoop/
9
human beatbox-lydspor.
Fælles for Voice Band og BillaBoop er, at de laver klassificering af de enkelte stemmefrembragte lyde. Programmerne forsøger altså at automatisere
notationen af det rytmiske udtryk, specifikt hvornår de enkelte slag optræder, og hvilken type tromme det er (storetromme, lilletromme ...). De to
programmer adskiller sig ved den brugssammenhæng de er tænkt til. Ud fra
demonstrationsvideoen til Voice Band, fremgår det at programmet er tænkt
til skitsering af et musiknummer med hel instrumentbesætning i form af trommer, bas og guitar. Fokus er ikke så meget på detaljerne i indspilningen af
de enkelte instrumenter, som på at sammensætte de forskellige instrumenter
i et arrangement.
BillaBoop er beskrevet i [Hazan, 2005a] som et generisk plugin til musikprogrammer. Specifikke brugsscenarier nævnes ikke, men der lægges vægt
på responstid, så mekanismen kan bruges i realtidssammenhænge. Samtidigt
omhandler artiklen også expressiveness som en vigtig parameter, således at
BillaBoop i højere grad end for eksempel Voice Band giver mulighed for at
detaljere trommeindspilningen.
1.4
Metoder
For at få undersøge, hvorvidt vi kan understøtte de musikalske ideer og brugsmæssige behov, som har været motiverende for projektet, vil vi benytte os
af følgende metoder:
• Udformning af en række brugsscenarier.
• Specificering af krav som udgangspunkt for en prototype på baggrund
af brugsscenarierne.
• Analyse af human beatboxing-materiale samt eksperimenter med segmentering og klassificering.
• Implementering af en prototype, som har en praktisk anvendelighed.
• Afprøvning af prototypen sammen med brugere for at undersøge, om
de musikalske ideer og brugsmæssige behov bliver understøttet.
1.5
Resultat
Specialearbejdet har resulteret i en implementation af en prototype, som er i
stand til at segmentere og klassificere indsungene human beatbox-optagelser i
10
tre overordnede trommetyper: storetromme, lilletromme og hi-hat. Klassificeringen sker på baggrund af udtrækning af relevante kendetegn for lydene. Vi
har undersøgt prototypens anvendelsesmuligheder inden for to overordnede
brugsscenarier:
• Omdannelse af indspillede human beatboxing-optagelser til trommenotation
• Automatisk effektprocessering af human beatboxing ved live-fremførelse
Prototypen er i begrænset omfang testet af brugere. Igennem kvalitative
interviews med disse brugere har vi undersøgt, om prototypen opfylder de
indledende ambitioner for projektet om at understøtte musikalsk tilvejebringelse ved hjælp af human beatboxing.
Endelig er overvejelser om fremtidige udvidelsesmuligheder medtaget.
Det benyttede audiomateriale, kildekode til prototypen samt køreklare
versioner af prototypen kan findes på den cd, som er omtalt i bilag A samt
på specialets hjemmeside, http://cs.au.dk/~grav/speciale.
11
Kapitel 2
Brugsscenarier
2.1
Involvering af brugere
Den oprindelige udgangspunkt med at udpege og erstatte trommelyde i human beatboxing er blevet forelagt en række musikere for at få respons samt
ideer til videreudvikling.
Freelance-producer Martin Albrekt, som ofte laver musik med trommespor
som udgangspunkt, kunne genkende beskrivelsen af kløften mellem at have
en umiddelbar idé til et trommespor og få nedfældet en skitse. Da Martin selv
beatboxer, var han positivt indstillet overfor ideen med at fremføre en skitse med human beatboxing. Martin lagde desuden vægt på at computerens
tolkning af et human beatboxing-optagelser skal understøtte groovet i den
oprindelige fremførelse, således at amplituden samt varigheden af de enkelte
anslag medtages.
En samtale med sanger og beatboxer Kristoffer Thorning gav anledning
til en anden vinkel på projektet. Kristoffer er som beatboxer ikke som udgangspunkt interesseret i at frembringe musik ved at bruge computeren som
instrument. Efter at være blevet bekendt med muligheden for at få en computer til at genkende de enkelte lyde i et human breakbeat, så Kristoffer i stedet
teknologien som en potentiel måde at understøtte og fremhæve detaljer i livefremførelse af beatboxing. Han nævner konkret, at det ved live-opførelse med
en enkelt mikrofon kan være svært at indstille lydniveauerne, så “bunden”,
dvs. basfrekvenserne, fremhæves bedst muligt i storetrommen, samtidigt med
at lilletromme- og hi-hat-lydene fremhæves i mellem- og top-frekvenserne.
For at gøre elementerne i den oprindelige ide samt forslagene fra de to
musikere mere eksplicitte, og samtidigt undersøge muligheden for teknisk set
at realisere forslagene, har vi konstrueret en række brugsscenarier. Brugssce12
Figur 2.1: Efter at musikeren har indspillet sin beatboxing på computeren (trin
1), analyseres og omsættes lyden til musik-notation, f.eks. trommenoder (trin 2).
Omsætningen skal ikke nødvendig vis være umiddelbar, da kompositionen typisk vil
foregå skridt for skridt.
narierne kan karakteriseres som en blanding mellem konceptuelle og konrete
scenarier, som de defineres i [Benyon et al., 2005]. Hvert scenarie indledes
med en konceptuel beskrivelse af systemet og brugssituationen for at få en
forståelse af kravene til systemet. Herefter følges op med en række mere konkrete overvejelser om den tekniske realisering.
2.2
Skitse til trommespor
En musiker er i færd med at komponere eller producere et stykke musik foran sin computer. Musikeren har en ide til et trommespor i tankerne, som
han gerne vil have omsat til en skitse på computeren. Musikeren beat-boxer
en sekvens ind i en mikrofon. Sekvensen omsættes til musik-notation, som
musikeren herefter har mulighed for at arbejde videre med i sit vante musikprogram. Hvis musikeren ønsker det, kan han også få forslag til rigtige
trommelyde, som “minder om” dem, musikeren har frembragt med munden.
13
Realisering
Den optagede sekvens deles op i enkelte lyde, hvorefter disse lyde klassificeres. Herefter omsættes sekvensen til en form for musik-notation (MIDI)
inkluderende tromme-type, tidspunkt og eventuelt anslagskraft for hvert enkelt anslag.
Hvis musik-notationen skal omsættes til en sekvens med nye lyde, kan
klassificeringen benyttes i sammenhæng med et bibliotek af trommelyde, således at de enkelte dele af lydoptagelsen erstattes med det bedste match i
lydbiblioteket, baseret på forskellige parametre.
2.3
Musikalsk samtale
En bruger forsøger at lave en “musikalsk samtale” med computeren. Brugeren beat-boxer en strofe mens computeren lytter, og holder derefter en pause.
Computeren svarer nu brugeren med et forsøg på at imitere strofen ved at
gengive den med lyde der “ligner”. Det kan være rigtige trommelyde eller blot
en sekvens der har samme klangmæssige og rytmiske fornemmelse. Herefter
er det brugerens tur igen, og på den måde opstår en slags improvisationssituation, som når bassisten og trommeslageren i et jazz-orkester laver en
chase.
Realisering
Brugerens beatboxing skal opdeles og klassificeres. Denne analyse resulterer muligvis i en pause, før computeren svarer, hvilket måske kan minde om
betænkningstid og få samtalen til at virke mere realistisk. Resultatet af klassificeringen kan kobles til andet end blot trommelyde, og der kan indføres en
grad af tilfældighed for at give mere afveksling.
2.4
Live-beatboxer
En musiker ønsker under en koncert at lave et underliggende groove med
human beatboxing. Groovet skal være et rytmespor, som skal gentages under
nummeret for at understøtte de andre musikalske elementer i fremførelsen.
Musikeren starter ud med at markere sekvensens begyndelse med et tryk
på en pedal. Herefter beat-boxer han sit groove ind i computeren og markerer
til sidst sekvensens afslutning med pedalen.
14
Figur 2.2: I “den musikalske samtale” skiftes brugeren og computeren til at ytre
sig musikalsk. Brugeren indleder, og computeren svarer efter lidt betænkningstid.
Groovet afspilles nu gentagende, men “bunden” i storetrommen er forstærket og komprimeret, så den fremstår mere “punchy”, hi-hat’en er mere distinkt, og lilletrommen har fået tilsat rumklang, så den klinger mere
og længere. Således er flere aspekter forstærket og fremhævet, så human
beatboxing-groovet i sin helhed fremstår mere som et “rigtigt” trommespor
og derved bærer resten af nummeret.
Realisering
For at kunne understøtte dette scenarie, skal den optagede sekvens inddeles
i de enkelte trommeslag, så de kan klassificeres. Herefter indsættes hvert
enkelt trommeslag til den oprindelige tid i et nyt spor alt efter klassificering.
Sporene effektprocesseres enkeltvist, mixes sammen og afspilles gentagende.
15
Figur 2.3: Live-beatboxerens trommelyde bliver hver for sig processeret så lydene
bedre kommer ud over scenekanten. Umiddelbart efter at beatboxeren har afsluttet
sin strofe, skal computeren overtage afspilning med effektprocessering.
Afspilningen af sekvensen med effekter skal påbegyndes umiddelbart efter at
beatboxeren er færdig med sin strofe.
2.5
Beatboxing Hero
Inspireret af spillet Guitar Hero1 skal spilleren i dette scenarie lave et underliggende trommespor til et rap-nummer ved at beatboxe. Spilleren kan høre
bas- og rap-spor samt observere en symbolsk repræsentation af trommesporet køre forbi på skærmen. Spilleren forsøger at beatboxe trommesporet, og
computeren registrerer lydene, afspiller eventuelt nogle rigtige trommer eller
professionelle beatboxing-trommer og bedømmer, hvor godt spilleren rammer
den rigtige tromme på det rette tidspunkt.
1
http://www.guitarhero.com
16
Figur 2.4: Skitse til skærmbillede fra “Beatboxing Hero”. De tre instrumentspor
nederst viser, hvornår hvilke trommer skal beatboxes. Figuren øverst spiller rigtigt,
hvis spilleren beatboxer godt nok.
Realisering
Spilleren benytter sin stemme som spilcontroller i stedet for f.eks. en guitar
med knapper som i Guitar Hero. Hvis spilleren skal have omgående respons på
sin præstation, både grafisk og lydmæssigt, er det essentielt at klassificeringen
også foregår omgående.
17
2.6
Realisering af brugsscenarier
Muligheden for at genkende forskellige typer trommer i human beatboxing er
den tekniske fællesnævner for brugsscenarier. I det følgende afsnit vil vi derfor
beskæftige os med at opsplitte human beatboxing-optagelserne og derefter
klassificere de enkelte trommelyde.
Der er forskel på, hvor hurtigt denne klassificering skal foregå. Den ene
yderlighed er det første scenarie, hvor komposition af musik er en trinvis proces som tillader pauser, mens computeren bearbejder musikerens indspilning.
Den anden yderlighed er computerspillet, hvor spilleren hele tiden er “på” for
at vinde spillet og omvendt også forventer hurtig respons på sine handlinger. Vi vil diskutere realiseringen af brugsscenarierne ud fra denne vinkel i
kapitel 4.1.
18
Kapitel 3
Analyse af human beatboxing
I dette kapitel vil vi analysere human beatboxing og eksperimentere med
i første omgang at opdele en lydoptagelse i de enkelte dele, en proces vi
vil benævne segmentering, [Bello, 2005]. Dernæst skal de enkelte segmenter
klassificeres. Målet med analysen er at få overblik over, hvorvidt de tekniske
enkeltdele af systemet kan hænge sammen og udgøre et funktionsmæssigt
grundlag for brugsscenarierne. Det benyttede testmateriale til analysen er
begrænset i omfang, og dermed hverken formår eller ønsker vi at lave en
udtømmende analyse af human beatboxing eller en generel metode til klassificering.
Eksperimenterne med segmentering og klassificering er foregået i en iterativ proces med afprøvning af forskellige parametre, dernæst test af resultaterne og tilsidst justering af parametrene. Matlab1 har i denne sammenhæng
været et meget anvendeligt værktøj til hurtigt at implementere processeringen og dernæst teste resultaterne ved visualisering, afspilning samt kvantitativ vurdering. I afsnit 3.6 beskrives de testmetoder, som løbende er benyttet
til den kvantitative vurdering af resultaterne.
3.1
Afgrænsning af lydmateriale
Først vil vi afgrænse den type lydmateriale, som systemet skal kunne behandle.
Da en musiker, som fremfører human beatboxing benytter munden, er
human beatboxing ligesom sang oftest monofonisk, således at kun én lyd
fremføres af musikeren ad gangen. I forhold til rigtige trommespor, hvor flere
1
http://www.mathworks.com/products/matlab/
19
Figur 3.1: Human beatboxer.
trommer kan slås an på samme tid, kan vi derfor nøjes med at separere et
beatboxing-spor i tidsdimensionen, under antagelse af, at vores lyddata er
monofonisk.
Som ved et rigtigt trommespor dannes den grundlæggende rytme af storetrommen, lilletrommen samt hi-hatten. Selvom der inden for human beatboxing ofte eksperimenteres med efterligning af vidt forskellige lydeffekter,
vil vil vi nøjes med at betragte disse tre trommeklasser for at simplificere
genkendelsen.
Vi forsøger her at beskrive fællesnævnere for, hvordan beatboxere ofte
frembringer lydene:
• Storetromme: Lavfrekvent lyd, kommende fra beatboxerens bryst og
hals. Ofte stød af luft gennem læberne for at give fornemmelse af anslag.
Andre gange uden stød for at understrege de dybe frekvenser.
• Lilletromme: Stød af luft gennem tænder og læber, brug af mere luft
end ved storetrommen for at gøre lyden mere højfrekvent.
20
• Hi-hat: “TS”-agtig lyd, tungen sættes mod mundens “loft” og luft stødes
gennem tænderne. Mere højfrekvent end lilletrommen.
Ud fra disse beskrivelse har alle lydene en vis klangmæssig adskillelse.
Denne adskillelse vil grundet de fysiske rammer for den menneskelige stemme
være mindre end ved rigtige trommer. Samtidigt er det naturligvis subjektivt,
hvorledes en beatboxer frembringer de nævnte trommer, og der vil i realiteten
være overlap mellem typerne. Beatboxerens intention vil dog i forbindelse
med dette projekt være at opnå genkendelse af deres beatboxing, og derfor vil
vi tage det positive udgangspunkt, at beatboxerne ved fremførelsen forsøger
at differentiere de forskellige typer trommer.
Hvis vi således insisterer på, at de forskellige trommetyper adskiller sig
klangmæssigt, kan vi nøjes med at klassificere lydene på baggrund af deres
klang og ignorere deres tidsmæssige placering.
3.2
Overordnet struktur af systemet
Hermed har vi indrammet den type lyddata vi ønsker at bearbejde, nemlig optagelser af human beatboxing, bestående af lyde som er tidsmæssigt
afgrænsede, og som ud fra trommetypen adskiller sig klangmæssigt.
Ud fra denne ramme kan en model af det ønskede systems overordnede struktur konstrueres. Indledningsvist skal lyddata opsplittes i segmenter,
således at hvert segment kun indeholder den enkelte trommelyd, vi ønsker
at klassificere. For at finde de enkelte anslag i lyddata kan en teknik kaldet onset-detection, [Bello, 2005], benyttes. I den sammenhæng tages afsæt i
et tidligere projekt omkring onset-detection i human beatboxing, baseret på
[Bello, 2005]. Rapporten fra dette tidligere projekt findes som bilag B.
Efter segmentering kan trommetypen for et enkelt lydsegment bestemmes
ved hjælp af en klassificeringsalgoritme. Et vigtigt aspekt i denne sammenhæng er, hvilke kendetegn for lydsegmentet vi som udgangspunkt for klassificeringen vælger i præprocesseringsfasen, også kaldet feature extraction. I
[Herrera et al., 2002] og [Herrera et al., 2003] eksperimenteres med feature
extraction på rigtige trommelyde, og resultaterne herfra vil vi benytte som
basis for præprocessering i dette projekt.
Afhængigt af brugsscenariet kan vi herefter benytte segmenteringen og
klassificeringen til at processere den optagede lyddata eller generere ny lyd.
Et diagram over systemets struktur kan ses i figur 3.2.
21
Lydoptagelse
Onsetdetection
Segmentering
Præprocessering
Klassificering
Storetromme
Lilletromme
Hi-hat
Brugsscenarie
Figur 3.2: Systemets overordnede struktur. Human beatboxing-optagelsen processeres trinvist, og det endelige resultat af klassificeringen benyttes i brugsscenariet.
3.3
Indsamling af testdata
De nævnte artikler, som i dette projekt benyttes som grundlag for onsetdetection og klassificering, er skrevet ud fra empiriske undersøgelser med forskellige typer lyddata som f.eks. rigtige trommeoptagelser. Artiklerne er altså
ikke specifikt orienteret mod human beatboxing, og det er således nødvendigt
at indsamle human beatboxing-testdata, så implementationen af algoritmerne kan målrettes human beatboxing.
Indsamlingen af testdata har konkret bestået i at optage human beatboxere lave en række selvvalgte fremførelser af human beatboxing. Her ses
en oversigt over de optage-sessioner, som er benyttet til analysen:
• “martin”: optagelser af Martin Albrekt. Optaget i dæmpet kælderrum,
post-processeret med equalization og compression for at fremhæve især
de dybe frekvenser.
• “session1”: optagelser af Mikkel Gravgaard med laptop og indbygget
mikrofon i et 10 kvm. værelse.
22
• “session2”: optagelser af Mikkel Gravgaard i et dæmpet rum med Røde
NT1-mikrofon, ingen post-processering.
• “stoffer”: optagelser af Kristoffer Thorning i et dæmpet rum med Røde
NT1-mikrofon, ingen post-processering.
Optagelserne kan findes på den vedlagte cd, omtalt i bilag A samt på
specialets hjemmeside, http://cs.au.dk/~grav/speciale.
Lydforhold og optageudstyr er medtaget i listen ovenfor. Der vil i realiteten være forskel på omstændighederne med hensyn til optageudstyr, rum og
processering afhængigt af brugssituationen. En musiker siddende isoleret i et
lydstudie har større kontrol over lydforholdene end en live-musiker på en scene. Disse forskelle vil bidrage til kompleksiteten af den videre processering,
og de viste optagelser afspejler i nogen grad de skiftende omstændigheder
forskellige brugssituationer måtte byde på.
De musikere, som indspillede lydoptagelserne, blev som nævnt bedt om
at fremføre human beatboxing. En sådan fremførelse har en varighed på et
helt antal takter, som i princippet kan gentages vilkårligt og på den måde
fungere som underlægning til et musiknummer. Dermed har hensigten været
at få lydoptagelserne til at svare til, hvad man ville forvente i forbindelse med
scenarierne, til forskel fra isolerede beats (trommeslag). Da human beatboxing
som beskrevet i afsnit 3.1 oftest er monofonisk, er det forventeligt at de
enkelte trommeslag frembragt i sammenhæng med en hel optagelse vil være
anderledes begrænset i den klangmæssige udfoldelse og tidsmæssige varighed,
end hvis de blev fremført enkeltvist. Et eksempel på en optagelse af human
beatboxing ses i figur 3.3.
3.4
Segmentering
For at opsplitte en human beatboxing-optagelse i de enkelte lyde, vil vi starte
med at identificere anslagene i optagelsen ved hjælp af onset-detection. Til
dette formål tages udgangspunkt i et tidligere projekt til onset-detection i
human beatboxing. Rapporten til dette projekt kan findes som bilag B.
“Onset”, som kan oversættes med “anslag”, er i [Bello, 2005] defineret som
det tidspunkt, hvor det såkaldte attack for en lyd begynder. Attack’et er den
tidsmæssige periode, hvor energien i lyden stiger indtil den er på sit højeste.
I trommelyde er dette attack forholdsvist kort, da det maksimale udsving på
et trommeskin sker ved sammenstødet mellem trommestikken og trommen.
Ved human beatboxing er attack’et typisk er længere, da beatboxeren lægger
23
Recording "stoffer01.wav"
1
0.8
0.6
Amplitude
0.4
0.2
0
−0.2
−0.4
−0.6
−0.8
−1
0
2
4
6
Time (seconds)
8
10
12
Figur 3.3: Human beatboxing-optagelse, fremført af Kristoffer Thorning. De enkelte beats er tydeligt adskilt i tid, hvormed lyden kan betegnes som monofonisk.
an til lyden, og i projektet arbejdedes derfor mere med at finde tidspunktet
for det rytmiske anslag, dvs. det punkt, hvor attack’et slutter. I dette projekt
vil vi karakterisere dette punkt som et onset. Fordelen ved denne definition
i forbindelse med dette projekt er, at vi i flere af de nævnte brugsscenarier
ønsker at detektere tiden for det rytmiske anslag. Derudover vil det vise sig
at vi, givet det rytmiske anslag, forholdsvist nemt kan finde tidspunktet for
attack’ets begyndelse.
3.4.1
Kobling mellem onsets og lydsegmenter
Forudsat at vores algoritme til onset-detection fungerer, kan vi gå ud fra,
at antallet af onsets svarer til antal af lydsegmenter i human beatboxingoptagelserne. Lad os derfor starte med at definere en simpel form for seg-
24
Onset Detection with HFC
signal
detection
thresholding
onsets
envelope
0.5
0.4
Amplitude (normalized)
0.3
0.2
0.1
0
−0.1
−0.2
−0.3
−0.4
80
100
120
140
160
180
Position (sample)
200
220
240
260
280
Figur 3.4: Illustration af onset-detection med HFC-algoritmen. Det oprindelige
signal (gul) processeres trinvist, således at de enkelte onsets (stiplet rød) fremkommer.
mentering af vores lydoptagelse, hvor segment0i varer fra det tidspunkt, hvor
onseti blev detekteret, til det tidspunkt, hvor onseti+1 blev detekteret
Denne simple metode medfører dog flere problemer: de detekterede onsets
svarer som beskrevet ovenfor til det tidspunkt, hvor de forskellige anslag i rytmen ligger, f.eks. det tidspunkt hvor en trommestik rammer trommeskindet. I
human beatboxing er der typisk et længere, hørbart attack, hvor beatboxeren
lægger an til lyden. Da det er ønskeligt at medtage de enkelte lydes helhed til
videre behandling, skal segmenteringen gerne medtage dette attack. Der er
ofte en hørbar pause mellem én lyds slutning og en andens begyndelse. Denne
pause består af data der i bedste fald ikke er relevant for klassificeringen, så
det er også væsentligt kun at medtage selve trommelyden og ikke pausen i
et segment.
For at imødekomme disse problemer, kan vi fastsætte tærskler for, hvornår energien er tilpas høj til at lydsegmentet begynder, og tilpas lav til at
segmentet ophører. Vi vil benytte energy envelope, [Peeters, 2004], som er
en indhyldningskurve for energien af et signal. Energy envelope beregnes ved
hjælp af root mean square (rms) på frames (øjebliksbilleder) af et signal.
Givet et udsnit af et signal, x = (x1 , x2 , . . . , xn ), beregnes rms således:
25
r
xrms =
x21 + x22 + ... + x2n
.
n
Vi kan nu konstruere en energy envelope for et segment ved at sammensætte rms-værdier, beregnet på alle frames i segmentet. En frame-størrelse
kan eksempelvis være på 100 ms, hvilket svarer til at lavpas-filtrere med en
cut-off-frekvens på 5 Hz, [Peeters, 2004, p. 3].
Givet et lydsegment, segment0i , fastsætter vi nu en tærskel α1 på eksempelvis 5% af den maksimale værdi for segmentets energy envelope. Herefter
vælger vi stopi til at være det første tidspunkt efter onseti , hvor segmentets
energy envelope er lavere end α1 .
Herefter kan vi, igen på baggrund af den maksimale værdi for energy
envelope af segment0i , fastsætte endnu en tærskel α2 for, hvornår segmentets
energy envelope er høj nok til, at et lydsegment begynder. Vi betragter nu
energy envelope for den del af signalet, der ligger mellem stopi−1 og onseti , og
definerer starti til at være det seneste tidspunkt, hvor energy envelope ligger
under tærsklen α2 . Det endelige lydsegment, segmenti lader vi nu starte ved
tidspunkt starti og slutte ved tidspunkt stopi .
Med denne fremgangsmåde har vi opnået, at vores lydsegment både medtager en trommelyds attack, hvilket har betydning for lydens klang, samtidigt
med at vi også bevarer information om lydens rytmiske anslag. Fremgangsmåden er illustreret i figur 3.5.
3.5
Klassificering
Som nævnt i afsnit 2.6 ønsker vi at give brugeren et indtryk af, at de enkelte
trommelyde i hans human beatboxing bliver genkendt, da genkendelsen er et
centralt element i brugsscenarierne. Til dette formål vil vi benytte klassificering.
Klassificering er en applikation af machine learning, hvor målet er at
placere input-data i én ud af et endeligt antal diskrete klasser. I [Bishop,
2006] udtrykkes machine learning-algoritmer som en funktion eller model,
som “formes” i en træningsfase ved hjælp af et træningssæt af data. Den
resulterende funktion eller model skal herefter kunne kategorisere ny data
korrekt, vel og mærket data som ikke er indeholdt i træningssættet. Målet er
dermed en generalisering af modellen, så den kan benyttes til data, der ikke
er set før. Ved supervised learning, [Rojas, 1996, p. 78], er træningsdata på
26
Segments
onsets
signal rms
Energy
segment i
alfa2
alfa1
onset i−1
stop i−1
start i
onset i
stop i
onset i+1
Position
Figur 3.5: Illustration af, hvordan et lydsegment defineres ud fra onsets og energy
envelope.
forhånd manuelt klassificeret. I træningsfasen justeres modellen afhængigt
af, om et nyt input klassificeres korrekt af modellen.
Lineær klassificering kan benyttes, hvis klasserne er lineært separable, således at en lineær diskriminantfunktion kan adskille klasserne. Klassificering
med en lineær diskriminantfunktion og to klasser er defineret som:
y(x, w) = wT x,
hvor x er en input-vektor, og w er en vægt-vektor, som er ortogonal med
diskriminantfunktionen y. w justeres ved træningsfasen, så diskriminantfunktioen bedst muligt inddeler træningsdata i to klasser, således at x tilhører
klasse C1 hvis y(x, w) ≥ 0 og klasse C2 ellers.
3.5.1
Træning med Perceptron-algoritmen
Et eksempel på en metode til træning er Perceptron learning, hvor alle datapunkter inddeles i to mængder, P og N . Et punkt x ∈ P hvis vektorproduktet w · x > 0, og x ∈ N ellers. Træningsfasen går nu ud på at justere
w, således at alle punkter i P tilhører klasse C1 , og alle punkter i N tilhører
klasse C2 . Algoritmen er som følger: Vægtvektoren w1 inialiseres tilfældigt.
27
Ved iteration i vælges et punkt x tilfældigt. Hvis x ∈ P men tilhører klasse
C2 , sættes wi+1 til wi + x. Hvis x ∈ N , men tilhører klasse C1 , sættes wi+1
til wi − x. Intuitionen er, at vægtvektoren på denne måde roteres væk fra
et datapunkt, hvis punktet “fejlagtigt” ligger i P , hvormed punktet i næste
iteration er mindre tilbøjeligt til at ligge i P . Omvendt nærmes vægtvektoren
et datapunkt, hvis det “fejlagtigt” ligger i N , hvorefter det i næste iteration
er mere tilbøjeligt til at ligge i P .
Hvis træningsdata er lineært separable, vil w konvergere med ovenstående algoritme, hvilket bevises i [Rojas, 1996]. I vores tilfælde nøjes vi dog
med at finde en løsning, der er “god nok” til formålet. Dette kan vi gøre
ved ind imellem at stoppe algoritmen midlertidigt og teste den resulterende
vægtvektor. Vi berører testmetoder i afsnit 3.6.
3.5.2
Flere end to klasser
Hvis vi ønsker at skelne mellem flere end to klasser, kan en Decision Directed Acyclic Graph (DDAG), beskrevet i [Platt et al., 2000], benyttes. Med
N forskellige klasser indeholder denne graf N (N − 1)/2 såkaldte 1-versus-1
classifiers. Disse classifiers skelner hver mellem to klasser, og kan eksempelvis være diskriminantfunktioner, trænet ved hjælp af perceptron-algoritmen.
I vores tilfælde med tre klasser, storetromme (BD), lilletromme (SD) og hihat (HH), ser DDAG’en ud som vist i figur 3.6.
3.5.3
Præprocessering
For at opnå lineært separable klasser kan vi præprocessere vores input ved
ved hjælp af en mængde af basisfunktioner, her benævnt φ:
y(x, w) = wT φ(x).
Ønsker vi eksempelvis at klassificere et lydsignal x = (x0 , x1 , ...xN −1 ), kan
vi præprocessere signalet med et sæt af basisfunktioner φ = (φ1 , φ2 , ..., φK ),
som tilsammen danner en K-punkts diskret fourier-transformation (DFT):
φk (x) =
N
−1
X
n
xn e−i2πfk N ,
n=0
hvor fk betegner frekvensen for den k’te koefficient.
Således kan vi lave klassificering på baggrund af vores lyddatas frekvensspektrum i stedet for de spatiale egenskaber. Denne præprocessering kaldes
28
BD vs HH
Ikke HH
Ikke BD
SD vs HH
BD vs SD
Ikke SD
BD
Ikke BD
Ikke HH
SD
SD
Ikke SD
HH
Figur 3.6: Klassificering med tre klasser ved hjælp af en Decision Directed
Acyclic Graph. Hver cirkel repræsenterer en lineær diskriminantfunktion, trænet
med perceptron-algoritmen.
også feature-extraction, da applikationen af φ resulterer i et sæt af features.
Præprocesseringen kan vælges eksperimentelt ud fra viden om, hvilken form
for input-data vi forventer. I [Herrera et al., 2002] og [Herrera et al., 2003]
eksperimenteres på baggrund af viden inden for signalbehandling med forskellige sæt af features til klassificering af trommelyde. Erfaringerne fra disse
artikler er benyttet i dette projekt til at udvælge enkelte features. Anvendeligheden i forhold til human beatboxing-lyde er efterprøvet med tests.
Problemet med at benytte en metode baseret på eksperimenter er, at vores
præprocessering ikke bliver så generel, at vi uden problemer kan benytte den
i andre sammenhænge. Ønsker vi eksempelvis senere at kunne genkende flere
typer trommer end de tre, vi valgte som udgangspunkt i afsnit 3.1, vil den
præprocessering, vi eksperimenterer os frem til, sikkert ikke være tilstrækkelig til at adskille hver klasse af data tilstrækkeligt, fordi variationen i vores
data er forøget. Vi er derfor nødt til at starte forfra med eksperimenterne. I
tilfældet med dette projekt er målet for klassificeringen hovedsageligt at understøtte brugsscenarierne. Sammenholdt med, at den tilgængelige mængde
testdata er forholdsvis begrænset til at understøtte mere generelle metoder,
29
har vi derfor valgt at eksperimentere os frem med præprocessering og valg af
features.
3.5.4
Valg af features
Mel Frequency Cepstrum-koefficienter
Mel Frequency Cepstrum-koefficienter (MFC-koefficienter eller MFCC) er typisk blevet benyttet inden for talegenkendelse, men anvendeligheden inden
for musik er demonstreret af blandt andet [Logan, 2000].
MFC benyttes til bidder af lyd (frames), hvor frekvensspektret er forholdsvist statisk, og tager udgangspunkt i en diskret fourier-transformation
(DFT). Derudover tilføjes elementer, som er fordelagtige ved analyse af lyddata. MFC opererer med logaritmen af frekvensspektrets amplitude, da mennesker opfatter lydstyrken af et signal omtrendt logaritmisk. Desuden ignoreres signalets fase ud fra en betragtning af vigtigheden af denne inden for lyd.
Da den menneskelige hørelse også opfatter pitch (tonehøjde) ikke-lineært2 ,
benyttes mel-skalaen, som oprindeligt er lavet ud fra eksperimenter med folks
opfattelse af tonehøjde. En populær approksimation, [Sigurdsson et al., 2006],
som konverterer f hertz til mel mel er:
mel = 2595 log10 (
f
+ 1).
700
Hvis fremkvensområder i lydbilledet med lige stor afstand i mel-skalaen
analyseres, tages derved hensyn til, at de enkeltvise dybe frekvenser er perceptuelt vigtigere end de enkeltvise høje for den menneskelige hørelse.
Amplituden af signalets frekvensspektrum transformeres også om til det
såkaldte cepstrum. Denne transformation tjener som en dekorrelering, og typisk beregnes indledningsvist 40 koefficienter af signalets spektrum ved hjælp
af DFT, hvorefter 13 koefficienter beholdes ved transformation til signalets cepstrum. Til dekorrelering benyttes ofte diskret cosinus-transformation
(DCT) ud fra en antagelse om at det er en god approksimering til en optimal dekorrelering inden for lyd. Da vi i dette projekt benytter flere features end blot MFC, har vi dog valgt at lave dekorrelering efter komplet
feature-extraction (omtalt i afsnit 3.5.5), hvorfor vi ikke transformerer til
mel-cepstrum.
Vi har i projektet benyttet ISP-implementationen fra [Sigurdsson et al.,
2006] af MFC til skalering af tonehøjde, som beror på en såkaldt Mel-filterbank.
2
Ekspempelvis defineres addering af tolv halv-toner (et oktav-spring) til at være en
fordobling af frekvensen.
30
Filterbanken kan opfattes som en funktion H(k, m), som angiver, i hvor høj
grad den m’te mel-komponent korresponderer til den k’te komponent i frekvensspektrets amplitude.
Vi har i projektet haft de bedste resultater med en frame-størrelse på 128
samples. Vi benytter en sample-rate på 44100 samples pr. sekund, som svarer
til cd-kvalitet og er mindstemålet inden for musikproduktion. Dermed kan
den dybeste frekvens, vi kan repræsentere, beregnes som:
44100 samples/sek
= 345 Hz.
128 samples
At lige netop en frame-størrelse på 128 giver de bedste resultater kan altså
hænge sammen med at lydindspilningerne fra vores træningsdata ikke går dybere end 345 Hz. Frame-størrelsen på 128 samples resulterer i en øvre grænse
på 64 komponenter grundet Nyquist-frekvensen. Antallet af mel-komponenter
er sat til 13, som er den typisk benyttede værdi, [Herrera et al., 2003]. Givet
disse parametre er vores filterbank afbilledet i figur 3.7.
For at finde mel-spektret for den m’te mel-koefficient X 0 (m) ud fra frekvensspektrets amplitude |X(k)| benyttes følgende formel:
!
K−1
X
0
X (m) = ln
|X(k)| · H(k, m) ,
k=0
hvor K er antallet af komponenter i vores frekvensspektrum. Ved hermed at
benytte Mel-filterbanken samt logaritmen af amplitude, tages der hensyn til
den ikke-lineære opfattelse af tonehøjde og lydstyrke.
MFC-koefficienterne for et segment bestående af L frames beregnes slutteligt ved hjælp af midling over alle frames:
L
1X 0
X (m),
M F Cm =
L l=1 l
hvor Xl0 (m) er den m’te mel-koefficient for den l’te frame.
I [Herrera et al., 2002] benyttes endvidere også den empiriske varians for
MFC-koefficienterne som features, hvilket vi også har eksperimenteret med i
projektet:
N
1 X 0
2
(Xn (m) − M F Cm ) .
V arm =
N − 1 n=1
Med 13 mel-komponenter opnår vi derved i alt 26 features for MFC. I
figur 3.8 er de enkelte dele af processen til generering af MFC-koefficienterne
opsummeret.
31
Mel Filter Bank H(k,m)
60
0.9
0.8
50
Frequency bin (k)
0.7
40
0.6
0.5
30
0.4
0.3
20
0.2
10
0.1
2
4
6
8
10
12
0
Mel bin (m)
Figur 3.7: Plot af filterbanken H(k, m), som angiver, hvor meget den m’te melkomponent korresponderer til den k’te komponent i frekvensspektrets amplitude.
Banken består af et antal triangulære filtre, hvor filtrene for de højere mel-bins er
“bredere” og derved medtager flere frekvenskomponenter, svarende til den menneskelige opfattelse af tonehøjde.
Spektrets form
En række features, som vedrører den geometriske form af frekvensspektrets
amplitude, benyttes ofte til genkendelse af trommetyper. I dette projekt har
vi med held benyttet spectral centroid. Denne feature beskriver spektrets massemidtpunkt og beregnes ud fra amplituden af signalets frekvensspektrum
som et gennemsnit, vægtet med frekvensen af komponenterne i amplituden,
fk :
P
k fk · |X(k)|
Sc = P
.
k |X(k)|
32
Lydsegment
Inddeling i
frames
DFT-analyse
Logaritmen af
amplitudespektret
Mel-skalering og
beregning af
koefficienter
Gennemsnit og
varians over alle
frames
MFC-koefficienter
Figur 3.8: Beregning af MFC-koefficienter, dog endnu uden dekorrelation ved
transformation til cepstrum.
Som ved MFC-koefficienterne er spectral centroid beregnet per frame, og
både midling og den empiriske varians er medtaget.
3.5.5
Reduktion af dimensionalitet
Vi har således et udvalg af i alt 28 features, omfattende middelværdi og varians for både MFC og spectral centroid, og vi ønsker at beregne dem for
hvert segment. Disse features bestemmer som udgangspunkt dimensionaliteten vores data, men som vi antydede i afsnit 3.5.4, vil der være en grad
af korrelation imellem de forskellige koefficienter i vores data. Dermed kan
vi nedbringe dimensionaliteten gennem dekorrelation, hvilket er ønskeligt, da
dimensionaliteten typisk vil være en gældende faktor i udførselstiden af vores
klassificeringsalgoritme.
I [Logan, 2000] benyttes en diskret cosinus-transformation til dekorrelering af MFC-koefficienterne med henvisning til dens popularitet inden for talegenkendelse. DCT er dog kun en approksimering til en teoretisk set optimale dekorrelation. Vi har i dette projekt benyttet en sådan i form af Principal
Component Analysis (PCA). PCA kan defineres som en ortogonal projektion
33
af data til et nyt vektorrum af mindre dimensionalitet, således at variansen
af de projicerede data maksimeres. Det vil altså sige, at uanset hvor få dimensioner D vi vælger for det nye vektorrum genereret ud fra PCA, vil vores
data have størst mulig varians for det givne D. Dette giver os mulighed for,
på enkel vis at eksperimentere med at mindske antallet af features.
Til dette projekt har vi benyttet Matlabs indbyggede funktion til beregning af PCA. En implementation af Oja’s algorithm til at finde principal
components, samt et bevis for algoritmens korrekthed kan findes i [Rojas,
1996, p. 116].
3.5.6
Klassificeringsalgoritme
Da PCA ordner vores nye basis efter graden af varians, kan vi også udnytte
dette til at danne et geometrisk førstehåndsindtryk af data ved at lave en visualisering af de “vigtigste” komponenter. I figur 3.9 er projektionen af vores
test-data på de tre første principal components illustreret parvist. Som det
fremgår, er der en grad af sammenklumpning, således at to typer af trommer
generelt er adskilt i enten den ene, den anden eller den tredje dimension. Men
som det fremgår, er der især blandt store- og lilletrommelydene en grad af
sammenblanding, og der er ikke tale om en lineær adskillelse mellem disse
klasser. Selvom dette førstehåndsindtryk kun er baseret på de tre første principal components, har vi på baggrund af denne visualisering i første omgang
fravalgt lineær klassificering.
Klassificering med nearest-neighbour
I stedet for lineær klassificering har vi benyttet K-nearest-neighbour-algoritmen,
[Bishop, 2006, p. 124]. Denne algoritme er valgt ud fra den implementationsmæssige enkelthed samt den intuitive virkemåde. Hvert datapunkt fortolkes
som et punkt i et M -dimensionelt euklidisk rum. Når klassen for et nyt datapunkt, x skal bestemmes, beregnes afstanden (L2-normen) til alle andre
punkter t i træningsdatasættet:
v
uM
uX
dist(x, t) := t
(xm − tm )2 .
m=1
For K-nearest-neighbour udvælges de K nærmeste punkter fra træningssættet, hvorefter x’s klasse afgøres ved votering blandt de udvalgte punkter.
Som det beskrives i [Bishop, 2006], bestemmer K graden af smoothing, således at lavere værdier af K giver flere, mindre regioner af samme klasse. Ved
34
Features: x=1, y=2
Features: x=1, y=3
4
3
2
2
y
y
1
0
0
−2
−4
−4
−1
−2
0
2
x
Features: x=2, y=3
−2
−4
4
−2
0
x
2
4
3
2
Bassdrum
Snaredrum
Hihat
y
1
0
−1
−2
−4
−2
0
x
2
4
Figur 3.9: De tre første principal components plottet parvist viser sammenblanding
mellem store- og lilletrommelydene (de røde og grønne punkter) og problematiserer
derved lineær klassificering.
K = 1 (blot kaldet nearest-neighbour) vælges et nyt punkts klasse simpelthen ud fra det nærmeste punkt. I dette projekt har K = 1 givet de bedste
resultater - muligvis på grund af den førnævnte grad af sammenblanding.
K-nearest-neighbour adskiller sig fra lineær klassificering ved ikke at lave
en generel model for klassificeringen. I stedet er den instansbaseret og således afhængig af, at alt træningsdata er tilstede i modellen, hvorved hukommelsesforbruget for modellen samt udførselstiden for klassificeringen stiger
med størrelsen af træningsdata. Ved den naive implementation af K-nearestneighbour er udførselstid og hukommelsesforbrug derved O(nm), hvor n er
instanser i træningsdatasættet, og m er antallet af features.
35
1.
2.
3.
4.
Figur 3.10: 4-fold cross-validation med skiftende valg af testdata, markeret med
grå.
3.6
3.6.1
Testmetode og resultater
Overfitting
Ved supervised learning, hvor der på forhånd eksisterer en korrekt klassificering, kan “overfitting”, [Rojas, 1996, p. 145], være et problem. Gøres modellen
for kompleks, for eksempel ved at vælge for mange features, kan resultatet være, at modellen kan klassificere netop træningsdata korrekt men ikke er i stand
til at generalisere. Ved en instansbaseret algoritme som nearest-neighbour vil
vi ligefrem konsekvent få 100% hitrate, hvis vi tester på vores træningsdata,
da hver testinstans naturligvis vil være et perfekt match på sig selv.
En metode til at verificere, at der ikke forekommer overfitting er at benytte “cross-validation”. Ved k-fold cross-validation benyttes (k − 1)/k af den
tilgængelige data til træningsdata, hvorefter de resterende 1/k dele benyttes til test. Data deles indledningsvist op i k lige store mængder, og testen
gentages for alle k valg af testdata. Et eksempel er angivet i figur 3.10.
3.6.2
Resultater
For at teste klassificeringen har vi kombineret de i afsnit 3.3 nævnte datasæt.
Alle optagelser fra datasættene er blevet segmenteret med metoderne beskrevet i afsnit 3.4, hvilket har tilsammen har resulteret i 798 segmenter. Herefter
er de udvalgte features fra afsnit 3.5.4 blevet beregnet for hvert enkelt segment og transformeret til det rum, som dannes ved hjælp af deres principal
components, som beskrevet i afsnit 3.5.5. Endelig er hvert enkelt segment
36
Classification using 1−Nearest Neighbour
0.9
0.85
Correct classification (hitrate)
0.8
0.75
0.7
0.65
0.6
0.55
0.5
0.45
0.4
1
5
10
15
Number of features
20
25
28
Figur 3.11: Allerede ved 4 principal components opnås en hitrate på over 80% og
stabiliseres på omkring 87% efter de første 7 principal components.
ved aflytning manuelt klassificeret som enten storetromme, lilletromme eller
hi-hat.
Vi kan nu teste, hvor godt vores klassificering fungerer ved forskellige
valg af antallet af principal components. Ved at blande træningsdata og lave 10-fold cross-validation får vi et tal for graden af korrekt klassificering,
også benævnt hitrate. Dette er gjort 10 gange for alle valg af dimensionalitet (1, 2, . . . , 28), hvorefter gennemsnittet er beregnet. Resultatet er vist i
figur 3.11.
Som det fremgår af figur 3.11, opnår vi ingen væsentlig forbedring ved at
bruge mere end en fjerdedel af de tilgængelige features. Dette kan forklares
med en høj grad af korrelation mellem de enkelte MFC-koefficienter. Men omvendt viste senere tests, at en reduktion af antallet af MFC-koefficienter gav
et noget dårligere resultat. En anden forklaring på, at flere dimensioner ikke
37
forbedrer klassificeringen væsentligt er den såkaldte curse of dimensionality,
som i [Bishop, 2006] intuitivt forklares ved, at i et rum af høj dimensionalitet
vil det langt størstedelen af en kugles volume ligge i en tynd skal nær kuglens
overflade. Ved klassificering med nearest-neighbour betyder dette, at mængden af træningsdata for vores instansbaserede model skal stige kraftigt med
antallet af dimensioner, hvis vi skal undgå “tomme huller” i vores søgerum,
som ellers vil udvande grupperingen af data inden for samme klasse.
3.7
Test og virkelighed
Det er værd at overveje, hvordan vores isolerede tests af klassificeringen forholder sig til de virkelige brugsscenarier. Selvom vi med cross-validation har
forsøgt at undgå overfitting, har vi alligevel en begrænset mængde data til
rådighed, som er optaget under fire forskellige forhold med tre forskellige
beatboxere. Hermed har vores testdata en vis grad af ensartethed, som vi
ikke har ved reelt brug. Til de valgte brugsscenarier vil vi dog under alle
omstændigheder betegne en hitrate på over 80% opfylder vores ambition om
at give brugeren en fornemmelse af, at hans human beatboxing rent faktisk
bliver genkendt.
38
Kapitel 4
Design af prototype
I forrige kapitel opbyggede vi et teknisk fundament for realiseringen af brugsscenarierne. Vi ønsker nu at inddrage brugere for at undersøge, hvorvidt systemet er praktisk anvendeligt i de tiltænkte brugssituationer. Vi har udvalgt
to af brugsscenarierne som grundlag for prototypen, “Skitse til trommespor”
samt “Live-beat boxer”. Begge beskæftiger sig med samme ide, som var motiverende for projektet, nemlig human beatboxing som musikalsk værktøj. Som
beskrevet i afsnit 2.1 er disse to udvalgte brugsscenarier samtidig tilblevet
under samtaler med musikere. Da vi gerne vil fastholde brugerinvolveringen,
vil vi implementere en hi-fi-prototype, [Benyon et al., 2005, p. 254]. En hi-fiprototype er til forskel fra lo-fi-prototyper en reel software-implementation,
og dermed vil den ofte også give brugeren et indtryk af, at den afspejler det
endelige system, og at et sådant system rent faktisk kan implementeres. Vi
har derfor opstillet følgende krav til prototypen:
• Musikeren skal få et indtryk af, at systemet rent faktisk virker, ved
at hans human beatboxing bliver genkendt, og giver et resultat som
beskrevet i brugsscenariet.
• Brugeren skal kunne påvirke parametre for systemet gennem en let
tilgængelig brugerflade og få hurtig respons på resultatet.
• Brugerfladen er ikke det primære i systemet. Den skal derfor kunne
strikkes forholdsvist hurtigt sammen og være så simpel, at den i mindre
grad virker som det endelige produkt.
Til implementation af prototypen har vi ud fra ovenstående krav valgt
det grafiske programmeringsmiljø Max/MSP1 . Max/MSP indeholder et standardbibliotek til signalbehandling, samt et programmeringsinterface til Java,
1
http://cycling74.com/products/maxmspjitter/
39
kaldet Java Externals. Og gennem Java kan vi i princippet bruge den eksisterende implementation af human beatboxing-analysen i Matlab.
Max/MSP giver mulighed for at koble grafiske brugerflade-komponenter
såsom drejeknapper og fadere til signalbehandlingsobjekterne, hvormed brugeren af programmet let kan ændre på parametre og eksperimentere med
programmet.
Da Max/MSP arbejder med små bidder af lyd ad gangen, får brugeren forholdsvis hurtig respons på de parametreændringer, han laver. Denne metode
til processering af lyd har betydning for, hvordan vi implementerer analysen.
Vi vil i det følgende afsnit kigge nærmere på systemer til audioprogrammering, som tillader hurtig respons, samt redegøre for de tekniske udfordringer
ved at koble analysen af human beatboxing sammen med et sådant system.
4.1
Umiddelbar og forsinket respons
I eksperimenterne med segmentering og klassificering i forrige kapitel har vi
som nævnt benyttet Matlab til at afprøve parametre, lytte og måle på resultatet og dernæst justere parametrene. Med denne arbejdsmetode påbegyndes
processeringen først, når den komplette human beatbox-optagelse er tilstede,
og omvendt får vi også først respons på processeringen, dvs. resultat af klassificeringen, når analysen af hele human beatbox-optagelsen afsluttet. Denne
form for processering vil vi benævne som forsinket respons.
Som vi diskuterede i afsnit 2.6, er det forskelligt, hvilken type respons de
forskellige scenarier kræver. I scenariet “Skitse til trommespor” vil det som
nævnt ikke bekymre brugeren, hvis der optræder en mindre pause, inden
han får den færdige skitse. I andre scenarier er det derimod nødvendigt, at
brugeren ikke skal vente for længe på respons. Eksempelvis kræver brugeren
i “Live-beat boxer”, at afspilningen af den processerede human beatboxingoptagelse begynder, så snart han er færdig med at indspille den. Denne form
for processering vil vi benævne som umiddelbar respons.
4.2
Audioprocessering med umiddelbar respons
Systemer til audioprocessering med umiddelbar respons, såsom Max/MSP,
modtager og behandler løbende audio-buffere, som hver består af en række
samples. I Max/MSP kaldes denne audio-buffer en signalvektor, og den kan
efter behov varieres i størrelse og dermed tidslængde. En musiker vil typisk
være interesseret i en så lille buffer som muligt ved live-brug, da størrelsen
40
har indvirkning på, hvor hurtigt han får respons på sine handlinger, så som
at spille toner eller ændre på effekt-parametre. Typisk ligger en tolerabel
responstid på maksimalt 10 millisekunder2 , hvilket giver en bufferstørrelse
10
sek = 410 samples.
på 44100 samples/sek · 1000
I praksis har vi altså en “bid” lyd til rådighed ad gangen i form af en
signalvektor. Dette giver os udfordringer på flere fronter. Hvis vi ønsker at
benytte vores analyse af human beatboxing, er vi først og fremmest nødt til at
kunne abstrahere væk fra de enkelte signalvektorer. Derudover skal ydeevnen
for vores processering være tilpas hurtig til, at vi løbende kan modtage og
processere nye signalvektorer.
4.2.1
Sammenkobling af signalvektorer
For at finde en passende måde at abstrahere væk fra signalvektorer vil vi
prøve at anskue det materiale, som vi ønsker at processere, ud fra en niveauinddeling: På øverste niveau har vi en human beatboxing-optagelse, som er
defineret ud fra et helt antal takter. Efterfølgende har vi de enkelte segmenter,
eller beats, som er defineret ud fra onsets. Når et segment analyseres, inddeles
det i frames, hvor længden af en frame definerer den laveste frekvens (dvs.
længste periode), vi kan måle.
De signalvektorer, som vi arbejder med, er muligvis længere end de frames, vi ønsker at processere i eksempelvis beregningen af MFC-koefficienter.
Men når vi modtager en signalvektor, ved vi endnu ikke, om den givne signalvektor indeholder en frame, som igen er en del af det næste niveau, et
segment. Derudover har vi ikke decideret “travlt” med at processere, da vi
ikke kan outputte noget meningsfuldt, før vi har analyseret et helt segment.
Vi vælger derfor at sammensætte de enkelte signalvektorer til et helt segment,
hvilket er illustreret i figur 4.1.
Metoden, vi vil benytte til at samle indholdet af en række signalvektorer
til et segment, kan beskrives således: de optagede signalvektorer samles i
en buffer og analyseres samtidigt ved hjælp af onset-detection. Når et onset
registreres, sendes det til segment-bufferen, som på baggrund af metoden
beskrevet i afsnit 3.4.1 beregner hvornår et helt segment er modtaget. Derpå
kan vi fortsætte med den videre processering på samme måde som beskrevet
i afsnit 3.2. Metoden er illustreret i figur 4.2.
2
http://en.wikipedia.org/wiki/Latency_(audio), besøgt 9/8 2010
41
Varighed
Human beatboxing-loop
Buffering til analyse
Segmenter
Frames
Buffering i audio-programmer
Signalvektorer
Figur 4.1: Niveau-inddeling af audiodata. For at abstrahere væk fra de enkelte
signalvektorer benytter vi en buffer til at opsample et helt segment.
Lydinput (signalvektorer)
Segment-buffer
Onset-detection
Videre processering
Figur 4.2: De optagede signalvektorer samles i en buffer, og kombineres derpå til
et lydsegment på baggrund af onset-detection.
4.2.2
Ydeevne
Hvis processeringen i et system med umiddelbar respons ikke går tilpas hurtigt, vil systemet ikke være klar til at modtage en ny signalvektor, da den
forrige stadig behandles. Denne situation resulterer i, at den nye signalvektor
smides væk, hvilket manifesterer sig i skarpe “klik” i den lyd, som sendes ud
af højttaleren, da lydsignalet afbrydes og genoptages abrupt. Ved lydoptagelse i realtid, som når en musiker beatboxer ind i mikrofonen, vil dele af
lyden svarende til de ignorerede signalvektorer mangle. En lydoptagelse vil
42
amplitude
a) Oprindeligt signal
b) Optagelse
c) Afspilning
1
1
1
0.8
0.8
0.8
0.6
0.6
0.6
0.4
0.4
0.4
0.2
0.2
0.2
0
0
0
−0.2
−0.2
−0.2
−0.4
−0.4
−0.4
−0.6
−0.6
−0.6
−0.8
−0.8
−0.8
−1
0
1
2
samples x 104
−1
0
1
2
samples x 104
−1
0
1
2
samples x 104
Figur 4.3: Problemer med ydeevne og manglende signalvektorer. I a) ses det oprindelige signal. Hvis signalet optages, udelades stumper af lyden (markeret med
rødt i a) i det optagede signal, som vist i b), hvorved lyden forkortes. Ved afspilning
af det oprindelige signal opstår abrupte pauser og hørbare “klik” som i c).
altså blive forkortet, hvorved lyden forvrænges og den rytmiske fornemmelse
ændres. En illustration af problemerne ved optagelse og afspilning ses i figur
4.3.
Vores analyse i form af onset-detection, segmentering, præprocessering
og klassificering skal altså køre tilpas hurtigt, for at resultatet bliver korrekt.
Størrelsen på signalvektorne har stor betydning for systemets ydeevne, da
der er et betydeligt overhead for processeringen af hver signalvektor. Da små
signalvektorer samtidigt er en fordel for den responstid, musikeren oplever,
skal vi finde en balance mellem en signalvektor, der er lang nok til at mindske
overhead’et tilpas meget, og kort nok til at resultere i en tilpas lav responstid.
43
4.3
Implementering af prototypen
Vi stødte under forløbet med implementeringen af prototypen på forskellige udfordringer, relateret til processering med umiddelbar respons. Vi vil i
dette afsnit beskrive disse udfordringer samt redegøre for, hvordan vi fik løst
problemerne.
4.3.1
Onset-detection og segmentering
Implementering af segmentbuffer
I prototypen har vi indledningsvist implementeret segmentbufferen for derved at kunne abstrahere væk fra de enkelte signalvektorer. Til dette vil vi
benytte Max/MSP’s Java Externals. Konkret foregår dette ved at indsætte objektet mxj∼ i et Max/MSP-program. Dette objekt fungerer som en
bro mellem Max/MSP’s vanlige C-API og en Java-klasse, som nedarver fra
MSPPerformer-klassen, en del af Max/MSP’s Java-API. Når mxj∼-objektet
modtager en signalvektor, kaldes den nedarvende klasses perform-metode
med vektoren. I vores implementation af segmentbufferen føjer vi i denne
metode den indkommende signalvektorer til en buffer. Samme signalvektor
er samtidigt undergået onset-detection, som delvist er implementeret med
objekter fra Max/MSP’s standardbibliotek, og delvist med Java Externals.
Resultatet af denne onset-detection sendes også videre til segmentbufferen,
og når vi har modtaget både et onset for det aktuelle segment, samt et onset
for det næste, kan vi indramme hele segmentet ved at bruge analysen fra
afsnit 3.4, og dernæst sende segmentet videre til præprocessering og klassificering.
Downsampling ved onset-detection
Implementation af onset-detection afstedkom problemer med ydelsen. Specifikt var Java-implementationen af median-funktionen for langsom for systemet. Vi benytter median-funktionen til at udglatte et udsnit af signalet,
og adaptivt udregne en tærskel for onset-detection på dette udsnit. For hver
beregning flyttes udsnittet af signalet et sample, hvorved vi i den nuværende
implementation bruger tid O(n), hvor n er sample-længden på vinduet, til
at placere det nye sample korrekt for at kunne beregne medianen på ny. Muligvis er denne lineære faktor årsagen til ydelsesproblemerne. Løsningen var
umiddelbart at reducere opløsningen, og dermed sample-længden på vinduet,
for det signal, som undergår onset-detection ved at downsample signalet. Vi
44
kan tillade os dette, da vi først lavpas-filtrerer signalet, men en downsampling
kan muligvis have indflydelse på præcisionen af onset-detection.
En mulig optimering af median-beregningen involverer brug af et selfbalancing binary search tree til opbevaring af det sorterede udsnit af signalet.
Ved hver node i træet angives antallet af descendants. Når vi skal søge efter
medianen, vælger vi stien ned igennem træet alt efter hvor mange descendants vi afskærer. Denne traversal er O(log n). Opdatering af træet, inklusiv
rebalancering er også O(log n) ved eksempelvis AVL-træer. Herved kan vi
opnå sublineær udførselstid for beregning af medianen.3
4.3.2
Præprocessering og klassificering
Sammenkobling med Matlab
I første omgang benyttede vi til præprocessering og klassificering den eksisterende implementation i Matlab for på den måde at kunne afprøve segmentering og onset-detection. Matlab kan kommunikere med sin egen Java
virtuelle maskine (JVM), mens Max/MSP’s Java externals kører i en separat
JVM. Kommunikation mellem to JVM’er kan ikke foregå direkte, men ved
hjælp af API’en matlabcontrol4 kan man over TCP udveksle data mellem et
mxj∼-objekt og Matlab. Med denne løsning bliver den benyttede toolchain
som vist i figur 4.4. Løsningen indebærer samlet set et anseeligt overhead, både ved mxj∼-bridge’en, ved serialiseringen over TCP, samt ved Matlabs eget
Java-interface. Det var derfor ikke uventet, at løsningen ikke kunne processere lydindspilninger direkte. I dette tilfælde kom den faktiske optagelse til at
mangle stumper af lyden, som vi så det illustreret i figur 4.3 b. I stedet blev
prototypen sat til at processere forhåndsindspillede beatboxing-optagelser.
Dette imødekommer problemet med at stumper udelades, men under processeringen opleves pauser i lyden, som illustreret i figur 4.3 c. Selvom denne
første implementation altså ikke havde nogen egentlig anvendelighed over
den første implementation i Matlab, fungerede den som en slags “proof of
concept” for, at segmentbufferen virker som tiltænkt.
Optimering af præprocessering og klassificering
Næste etape af prototypen indebar implementering af præprocessering og
klassificering i Java. Selvom de hastighedsproblemer, som vi oplevede med
implementationen i Matlab fra forrige afsnit, var knapt så tydelige, måtte
3
4
http://en.wikipedia.org/wiki/Selection_algorithm, besøgt 9/8 2010
http://code.google.com/p/matlabcontrol/
45
Matlab
Java Matlab Interface
JVM
TCP
matlabcontrol
JVM
mxj~ bridge
Max/MSP
Figur 4.4: Toolchain ved første implementation af prototypen. Max/MSP står delvist for onset-detection, mens segmentering sker med Java externals via en mxj∼bridge. Med API’en matlabcontrol overføres segmenterne via TCP til en Java virtuel maskine (JVM) som kører sideløbende med Matlab, hvorefter datastrukturen
konverteres til Matlab-typer ved hjælp af Java Matlab Interface.
Matlab
Java
Præprocessering Nearest-Neighbour
26.5
2.6
8.0
0.2
Lineær klassificering
0.2
Tabel 4.1: Udførselstid i sekunder for de enkelte dele af analysen. De to klassificeringsalgoritmer er i praksis lige hurtige for vores datasæt, mens præprocesseringen
står for langt størstedelen af udførselstiden. Implementationen af præprocessering
og klassificering i Java medfører væsentlig reduktion i tidsforbruget i forhold til
Matlab-implementationen.
vi dog stadig benytte bufferstørrelser på mere end de maksimale 10 millisekunder, som vi beskrev i afsnit 4.1. Vi forsøgte også med implementation af
lineær klassificering, som beskrevet i afsnit 3.5 i håb om at forbedre ydeevnen,
hvorved kompleksitet som nævnt ikke afhænger af mængden af træningsdata. Dette havde dog ingen praktisk betydning for udførselstiden, hvilket også
viste sig ved isolerede hastighedstests af de enkelte dele af human beatboxinganalysen. I tabel 4.1 vises udførselstiden for henholdsvis præprocessering og
klassificering af det samlede datasæt på 798 instanser i både Matlab og Java.
46
Flertrådet implementering
Den endelige løsning blev at køre præprocessering og klassificering i sin egen
tråd. Når vi i den enkelt-trådede version registrerer et helt lydsegment, blokeres perform-metoden i mxj∼-objektet, mens vi processerer segmentet. Da vi
langt fra registrerer et segment for hver enkelt signalvektor, giver det derfor
god mening at lade denne processering foregå i sin egen tråd. Med udgangspunkt i scenariet “Live-beatboxer” ønsker vi først at benyttet resultatet af
analysen af et segment, når vi igen skal til at afspille segmentet, hvilket giver
os rigeligt med tid til at færdiggøre analysen. Med denne flertrådede løsning
var det muligt at optage human beatboxing mens processeringen foregår,
uden at vi oplever de førnævnte problemer med udeladte stumper af lyden.
4.3.3
Kobling til brugsscenarier
Analysen kører dermed tilfredsstillende med umiddelbar respons, og vi kan
nu sætte resultatet af klassificeringen ind i de tænkte brugssammenhænge. Vi
har valgt at koble de to brugsscenarier sammen, således at prototypen både
kan benyttes til at generere et nyt trommespor som i “Skitse til trommespor”
og effektprocessere en human beatboxing-optagelse som i “Live-beatboxer”.
Skitse til trommespor
Til en skitse kan lydene til store-, lilletromme og hi-hat defineres af brugeren. Når en optagelse er færdiggjort bliver disse lyde på rette tidspunkt
afspillet gentagende ved hjælp af Max/MSPs sfplay∼-objekt. Som et forsøg
kan prototypen også automatisk udvælge lyde, der minder om dem, brugeren
har beatboxet. Dette er implementeret ved at behandle et lydbibliotek med
præprocesseringen fra afsnit 3.5.3. Når et nyt segment detekteres, præprocesseres det, og ved hjælp af nearest-neighbour-algoritmen erstattes segmentet
efterfølgende af den lyd fra lydbiblioteket, der ligger nærmest.
Live-beatboxer
Når beatboxing-optagelsen er afsluttet, afspilles den gentagende. Ud fra klassificeringen af de enkelte segmenter, routes optagelsen ved hjælp af Max/MSP’s
gate∼-objekt skiftevis ud af tre lydudgange, en til storetromme, lilletromme
og hi-hat. Brugeren kan nu route disse udgange videre til andre lydeffekter i
Max/MSP og dermed effektprocessere som han ønsker det.
47
Figur 4.5: Brugerflade til prototypen. Brugeren kan vælge en forudindspillet human beatboxing-optagelse eller lave en ny optagelse. Brugeren har mulighed for at
slå rigtige trommelyde til og fra (sample vol), effektprocessere human beatboxingoptagelsen (delay og reverb), samt afspille lignende trommelyde (similar sounds).
4.3.4
Brugerflade
Prototypens brugerflade er lavet i Max/MSP’s grafiske designmiljø. Et Max/MSPprogram er i sig selv en grafisk brugerflade, men den såkaldte presentation
mode giver mulighed for at gemme programstruktur væk og derved skjule
kompleksitet. Vi har valgt at benytte presentation mode, således at brugeren
lettere kan benytte systemet uden at skulle assisteres af os som udviklere, hvilket vi formodede ville blive nødvendigt ved brugertests på grund af
geografiske omstændigheder. For at brugeren skal kunne benytte prototypen
direkte, er der i forvejen koblet effekter til hi-hatten og lilletrommen, ligesom lydene til trommespors-skitsen er foruddefinerede. Brugerfladen er holdt
simpel med et enkelt vindue, for at give brugeren mulighed for at kunne overskue og tilgå alle funktioner på en gang. Et skærmbillede af brugerfladen ses
i figur 4.5.
48
4.4
Afrunding
Hermed har vi bygget en prototype, som vi mener kan understøtte brugsscenarierne. Brugeren kan få en oplevelse af den grundlæggende funktionalitet
til klassificering, og han har mulighed for at udnytte resultatet af klassificeringen og arbejde videre med lyden på enkel vis. Med den flertrådede
implementering har vi opfyldt kravet om umiddelbar respons, således at brugeren også kan benytte prototypen i en live-situation, hvor det musikalske
flow skal bevares.
49
Kapitel 5
Brugertests
Vi har lavet brugertests med et tre brugere. To af brugerne, Kristoffer Thorning og Martin Albrekt, har haft brugerscenarierne som som udgangspunkt,
da de som beskrevet i afsnit 2.1 har været involveret i den indledende ideudvikling. Den sidste bruger, Bo Magnussen, har fået forelagt prototypen uden
en bestemt kontekst, så han kunne udforske den på eget initiativ.
Vi har lavet en række kvalitative interviews for at få brugernes umiddelbare reaktioner. Desuden har en bruger, Kristoffer, lavet skærmoptagelser,
hvor han benytter prototypen. Disse optagelser kan findes på den cd, som er
omtalt i bilag A samt på specialets hjemmeside, http://cs.au.dk/~grav/
speciale.
Kristoffer Thorning
Kristoffer optræder med human beatboxing i koncertsituationer. Han er derigennem vandt til at arbejde og eksperimentere med software som skal fungere
i en live-sammenhæng. Kristoffer har benyttet prototypen til at loope en human beatboxing-optagelse med nye lyde og lydeffekter, lige efter at han har
indspillet den, som beskrevet i brugsscenariet “Live-beatboxer”.
Kristoffer har problemer med at få optagelsen til at loope tilfredsstillende. Han ønsker at bruge systemet i live-situationer, så det er vigtigt at
det musikalske flow ikke forstyrres. I video 1 får han efter nogle forsøg et tilfredsstillende resultat, men han foreslår selv at systemet bør kunne detektere
rytmefornemmelsen og automatisk skære optagelsen til.
Kristoffer har benyttet en dynamisk Beta 58-mikrofon samt den indbyggede mikrofon på hans bærbare computer. Han vurderede at have bedre held
med genkendelse af lilletrommerne, når han benyttede den indbyggede mikrofon. Når han benyttede Beta 58-mikrofonen, forveksledes lilletrommerne
50
ofte med storetrommer. Han mente selv dette kunne skyldes at Beta 58mikrofonen vægter de dybe frekvenser højere end den indbyggede mikrofon.
Han kunne kompensere for dette ved at bruge mere højfrekvent “s”-lyd på
lilletrommerne. Video 2 viser problemerne med korrekt klassificering, hvor
lilletrommer og storetrommer ofte forveksles.
Video 3 viser en smule problemer med ydeevnen, hvilket resulterer i at
lyden “hakker”. I sidste ende lykkes det at få ydeevnen og loopet til at fungere,
hvorefter Kristoffer kan eksperimentere med de forskellige parametre.
Kristoffer finder, at prototypen har et potentiale og fungerer nogenlunde.
Dog mangler han interoperabilitet med sine nuværende værktøjer, og han
efterspørger en form for plugin, således at programmet kan indgå i andre
sammenhænge.
Martin Albrekt
Martin oplever, at han skal prøve sig frem, før genkendelsen af hans human
beatboxing fungerer tilfredsstillende. Han skal give sin lilletromme en bestemt
klang, som han mener mere svarer til et kantslag1 , hvormed han således er
nødt til at arbejde på prototypens præmisser. Han ser ikke dette som et
direkte problem, når der kun skelnes mellem de tre trommetyper, det kræver
blot at han øver sig inden brug. Martin savner også mulighed for at lave en
såkaldt “lagkageoptagelse”, hvor man kan lægge flere lag af trommelyde oven
i hinanden.
I prototypens nuværende udformning mangler Martin flere muligheder
for at arbejde videre med lyden. En så simpel funktion som at kunne gemme
resultatet som en lydfil ville gøre det muligt at rette resultatet til rytmisk i
et andet program og bruge det i sammenhæng med noget andet musik.
Martin har i øvrigt prøvet funktionen til at finde “lignende lyde”, som han
fandt underholdende og inspirerende. Han fik dog de bedste resultater når han
selv frembragte underlige, rytmiske lyde, som ikke han ikke vil karakterisere
direkte som human beatboxing.
Bo Magnussen
Bo finder at programmet er sjovt og en “tidsstjæler”. Han har som Kristoffer
problemer med at få alle sine lilletrommer genkendt som lilletrommer, men
hvis programmet havde muligheden for at gemme et resultat, ville han godt
1
Ved et kantslag rammes lilletrommen på metalkanten i stedet for på trommeskindet,
hvilket giver en skarpere, mere metalisk klang.
51
kunne bruge det til at lave musik. Bo foreslår i øvrigt, at programmet får
en metronom eller på anden vis hjælper brugeren på vej med den rytmiske
fornemmelse ved indikation af tempo.
5.1
Sammenfattende brugerrespons
Samlet set giver prototypen brugerne et indtryk af, at genkendelsen af deres
human beatboxing virker, men at der er plads til forbedringer. Brugerne ser
et perspektiv i prototypens nuværende funktionalitet, men prototypen er i
sin nuværende udformning umiddelbart ikke noget, brugerne kan bruge til et
endeligt musikalsk resultat.
52
Kapitel 6
Konklusion
Opsummering
Vi har i dette speciale arbejdet med human beatboxing som en form for
musikalsk værktøj. Vi har som udgangspunkt set human beatboxing som
en enkel og umiddelbar musikalsk udtryksform, og vi har brugt dette som
inspiration til et redskab, som kan hjælpe musikere med at mindske kløften
mellem en musikalsk ide og den endelige fremførelse.
For at konkretisere vores ideer, har vi konstueret brugsscenarier, som
både beskriver brugssituationen som et koncept, og samtidigt er tilpas konkrete til at vi kan udlede specifikke, tekniske krav til realisering. Ud fra disse
brugsscenarier fandt vi, at brugsscenarierne som fællesnævner havde kravet
om opsplitning af hele human beatboxing-optagelser i de enkelte trommelyde samt klassificering af disse. Derudover noterede vi os, at de forskellige
brugsscenarier havde forskellige krav til, hvor hurtigt responsen og dermed
klassificeringen skulle foregå.
I vores analyse af human beatboxing har vi eksperimenteret med segmentering af human beatbox-optagelser og klassificering af trommelyde for at
danne os et indtryk af, hvorvidt de tekniske enkeltdele af systemet kan hænge sammen og udgøre et grundlag for en funktionel prototype. Indledningsvist
arbejdede vi med lineær klassificering, men visualisering af træningsdata pegede ikke umiddelbart retning af, at denne metode til klassificering ville være
fyldestgørende. I stedet forsøgte vi os med nearest-neighbour-klassificering,
hvilket i vores eksperimenter gav en hitrate på vel over 80%. Trods det umiddelbart gode resultat holdt vi os for øje, at vores eksperiment blev udført
med en begrænset mængde testdata, som har en vis grad af ensartethed, og
at vi ikke nødvendigvis kan regne med samme resultater i en rigtig brugssituation. Dog fandt vi resultatet godt nok til en funktionel prototype, som kan
53
give testbrugere et indtryk af, at hans human beatboxing bliver genkendt og
påvirker resultatet på en musikalsk vis.
Vi har implementeret en prototype, som benytter resultaterne fra analysen, samtidigt med at vi også har opfyldt kravet om umiddelbar respons,
således at prototypen potentielt set understøtter de udvalgte brugsscenarier.
Gennem brugertest af prototypen har vi undersøgt, om prototypen kan fungere som et værktøj, der gavner brugernes musikalske proces og understøtter
deres behov. Igennem kvalitative interviews har vi fået brugernes umiddelbare reaktioner. Samlet set er brugerne positivt indstillet overfor resultatet,
og selvom de ikke kan benytte prototypen direkte i deres musikalske proces,
ser de et musikalsk potentiale i prototypen, og deres umiddelbare reaktioner
bærer præg af engagement en lyst til at arbejde videre med projektet.
Overvejelser omkring prototyper
Generelt savner brugerne interoperabilitet med deres eksisterende værktøjer,
men de er engagerede i forhold til videreudvikling og kommer gerne med ideer til, hvordan koblingen med deres eksisterende værktøjer kunne foregå. I
sammenhæng med at prototypens tekniske funktionalitet til en vis grad er på
plads, vil det i en fremtidige udviklingsproces være fornuftigt i endnu højere
grad at rette opmærksomheden mere mod den kontekst, som programmet
indgår i. En metode til at designe mere på brugernes præmisser er participatory design, [Benyon et al., 2005], hvor brugerne er med til at tage beslutninger omkring et design. Dette foregår blandt andet gennem lo-fi-prototyper,
[Benyon et al., 2005, p. 255], som kan produceres hurtigt i samarbejde med
brugeren, samt use-cases, [Benyon et al., 2005, p. 198], som beskriver den
konkrete interaktion mellem brugeren og systemet.
Man kan argumentere for, at vi tidligere i projektet skulle have lagt mere
vægt på brugerinvolvering igennem metoder som ovenfor frem for at have
implementeret en hifi-prototype. Under designet af prototypen gjorde vi eksempelvis nogle teknologiske valg, som krævede, at vi måtte reimplementere
store dele af analysen fra kapitel 3, og en fremtidig funktionel prototype kan
gøre endnu en reimplementation nødvendig. Havde vi istedet lagt vægten på
brugerinvolverende design med lo-fi-prototyper, var vi måske tidlige blevet
beviste om, at brugerne gennemgående have et krav om kobling med deres
nuværende værktøjer, og vi kunne have udskudt og baseret teknologivalgene
på dette resultat. Omvendt har den nuværende prototype ladet os eksperimentere med at understøtte umiddelbar respons, som ikke blev berørt i
analysen. Og på trods af at brugerne på ikke mener, de kan benytte den
nuværende prototype i deres endelige, musikalske arbejde, finder vi at både
54
interviews samt videooptagelserne afspejler en glæde hos brugerne over de
musikalske resultater, de dog er istand til på egen hånd at frembringe med
prototypen. Vi mener derved ikke, at prototypen står i vejen for musikaliteten, men nærmere understøtter den. Dermed finder vi, at vi igennem dette
projekt har belyst mulighederne for at bruge human beatboxing som et musikalsk redskab, og vi mener at resultaterne fra dette projekt kan understøtte
udviklingen af lignende værktøjer, som benytter human beatboxing.
55
Kapitel 7
Fremtidige udvidelsesmuligheder
7.1
Forbedring af klassificering
Selvom en hitrate på over 80% er fyldestgørende i tilfældet med prototypen, afspejler dette succeskriterie ikke virkelig brug, som omtalt i afsnit 3.6.
En alternativ tilgang til klassificering benyttes til programmet BoomClap1 ,
som er en kommerciel opfølgning til BillaBoop, [Hazan, 2005a]. Her trænes
systemet umiddelbart inden det skal benyttes af brugeren selv, hvorved klassificeringen målrettes den konkrete brugssituation. Denne metode giver altså
mulighed for større præcision, men kræver dog, at brugeren gennemgår en
træningsfase før brug.
Endelig kunne man også forestille sig en kontekstafhænig analyse af sekvenser af trommer. I [Gillet and Richard, 2004] benyttes Hidden Markov
Models (HMM) til transkription af trommespor. HMM bruges her til at finde
typiske sekvenser af trommer. Da storetrommen eksempelvis ofte optræder
på et- og tre-slaget i en 4/4-takt, og lilletrommen på to- og fire-slaget, vil
en analyse med HMM af hele takter af trommespor formodentligt afspejle
dette, og derved understøtte korrekt klassificering.
7.2
Hurtigere processering
Vores brugerscenarier tillod os at udskyde klassificeringen til vi i det mindste
havde modtaget et helt segment. Hvis vi ønsker endnu hurtigere respons,
eksempelvis i forbindelse med brugsscenariet “Beatboxing Hero”, beskrevet i
afsnit 2.5, er vi nødt til at kunne klassificere endnu hurtigere. I [Hazan, 2005b]
1
http://billaboop.com/en/boomclap
56
benyttes kun den første frame, fundet ved onset-detection, til klassificering for
at holde responstiden nede. Den benyttede frame-størrelse er 11 ms, hvilket
potentielt set kan give langt hurtigere respons end vores system, men omvendt
kan den begrænsede mængde data til rådighed for præprocesseringen muligvis
også være problematisk for klassificeringen.
7.3
Lignende trommelyde
Den indledende, forsøgsvise funktion til at finde rigtige trommelyde, som
ligner dem, beatboxeren har indspillet, kan forbedres på flere måder. Den
nuværende implementation beregner som nævnt det samme sæt af features
for både beatbox-lydene og de rigtige trommelyde. Problemet med denne
fremgangsmåde kan dog være, at de klangmæssige kendetegn for eksempelvis
en human beatboxing-storetromme ikke nødvendigvis er de samme som for
en rigtig storetromme. I afsnit 3.5.4 fandt vi, at vores testdatas frekvensspektrum naturligt var begrænset af den menneskelige stemme, hvilket ikke
er tilfældet for rigtige trommelyde.
En mulig løsning kunne være at vægte de ekstreme frekvensområder i
human beatbox-lydene højere i erkendelse af den menneskelige stemmes begrænsninger i forhold til rigtige trommer. Man kunne også forestille sig, indledende at klassificere de rigtige trommelyde, og derpå medtage klassificeringen
som en ekstra feature, således at en human beatbox-storetromme oftere ville
matche en rigtig storetromme ved brug af nearest-neighbour-algoritmen.
I [Hazan, 2005b] benyttes resultatet af præprocesseringen af human beatboxlyde til at parametrisere effektprocessering af de rigtige trommelyde. Eksempelvis benyttes spectral centroid, som vi omtalte i afsnit 3.5.4, til at styre
cutoff-frekvensen på lilletrommen. Tanken må således være, at en “mørk”
human beatbox-lilletromme gør den rigtige trommelyd tilsvarende mørk.
7.4
Understøttelse af groove
Som nævnt i afsnit 2.1 foreslog en af de involverede brugere, Martin Albrekt, indledningsvist at systemet skulle understøtte groovet i beatboxingoptagelsen, således at amplituden samt varigheden af de enkelte anslag medtages, når det rigtige trommespor genereres. En ide til at understøtte dette
kunne være at vægte lydstyrken af de rigtige trommelyde med forholdet mellem energien for den optagede human beatbox-lyd og den gennemsnitlige
energi for den relevante klasse af human beatbox-trommer. På samme må57
de kunne længden af de rigtige trommelyde varieres afhængigt af forholdet
mellem den optagede human beatbox-lyd og gennemsnitslængden for den
relevante klasse af trommer.
7.5
Plugin til lydprogram
Den nuværende prototype består af et køreklart program, som giver brugeren for, umiddelbart at få et indtryk af systemets funktionalitet. I faktiske
brugssituationer vil et generisk plugin, det vil sige en programstump som skal
fungere i sammenhæng med et større lydbehandlingsprogram, være mere relevant. Plugin’et kunne for eksempel generere MIDI eller audio som output,
som kunne viderebehandles i lydbehandlingsprogrammet. MIDI-data kunne
frembringe en trommelyd, og audio-data kan routes ud i effekter, begge dele
afhængigt af klassificering. Et plugin ville dermed være mere fleksibelt, og
ville kunne tilpasses bedre til brugssituationen. Eksempelvis kunne man som
bruger gøre brug af quantization, hvor der rettes op på rytmefornemmelsen
ved at justere den enkelte anslag ind efter et skelet, en funktion de fleste
programmer til musikkomposition allerede har.
58
Litteratur
Juan Pablo Bello. A tutorial on onset detection in music signals. IEEE
Transactions on Speech and Audio Processing, 13(5):1035–1047, 2005.
David Benyon, Phil Turner, and Susan Turner. Designing Interactive Systems
- People, Activities, Contexts, Technologies. Addison-Wesley, 2005.
Christopher M. Bishop. Pattern Recognition and Machine Learning (Information Science and Statistics). Springer-Verlag New York, Inc., Secaucus,
NJ, USA, 2006. ISBN 0387310738.
Olivier Gillet and Gaël Richard. Automatic transcription of drum loops. In
IEEE International Conference on Acoustics, Speech, and Signal Processing, 5 2004.
Amaury Hazan. BillaBoop: Real-time voice-driven drum generator. In Audio
Engineering Society Convention 118, 5 2005a.
Amaury Hazan. Performing expressive rhythms with Billaboop voicedriven drum generator. In 8th Int. Conference on Digital Audio Effects
(DAFx’05), 2005b.
Perfecto Herrera, Alexandre Yeterian, Re Yeterian, and Fabien Gouyon. Automatic classification of drum sounds: A comparison of feature selection
and classification techniques. In Proceedings of 2nd International Conference on Music and Artificial Intelligence, pages 69–80. Springer, 2002.
Perfecto Herrera, Amaury Dehamel, and Fabien Gouyon. Automatic labeling
of unpitched percussion sounds. In Proceedings of the Audio Engineering
Society, 114th Convention, 2003.
B. Logan. Mel frequency cepstral coefficients for music modeling. In Int.
Symposium on Music Information Retrieval, 2000.
59
Geoffroy Peeters. A large set of audio features for sound description (similarity and classification) in the CUIDADO project. Technical report, Ircam,
Analysis/Synthesis Team, 2004.
John C. Platt, Nello Cristianini, and John Shawe-taylor. Large margin DAGs
for multiclass classification. In Advances in Neural Information Processing
Systems, pages 547–553. MIT Press, 2000.
Raúl Rojas. Neural Networks - A Systematic Introduction. Springer-Verlag,
1996.
Sigurdur Sigurdsson, Kaare Brandt Petersen, and Tue Lehn-Schiøler. Mel
frequency cepstral coefficients: An evaluation of robustness of mp3 encoded music. In Proceedings of the International Symposium on Music
Information Retrieval, 2006.
60
Bilag A
Vedlagt cd
Den vedlagte cd indeholder det beatboxing-lydmateriale som er blevet benyttet til analysen såvel som kildekoden til Matlab-, Max/MSP- og Javaimplementationerne. Desuden findes også køreklare versioner af prototypen
til Mac og Windows. Materialet fra cd’en kan også findes på specialets hjemmeside, http://cs.au.dk/~grav/speciale.
A.1
Lydmateriale
De benyttede datasæt i form af lydfiler findes i mapperne sound/martin
(Martin Albrekt), sound/stoffer (Kristoffer Thorning), sound/session1 og
sound/session2 (Mikkel Gravgaard). Alle lydfiler er i WAV-format, mono,
16 bit, 44100 samples/sek.
A.2
Kildekode
Den indledende analyse er implementeret i Matlab. Kildekoden hertil findes
i mappen matlab.
Prototypen er implementeret i Max/MSP 5.1 samt Java 1.5. Max-patchen
findes i mappen maxmsp. Java-kildekoden findes i mappen java.
For at kunne afvikle prototypen i Max/MSP, skal stien til de kompilerede Java-klasser tilføjes til filen max.java.config.txt, som ligger sammen med Max/MSP-programmet. Derudover er Java-klasserne afhængige af
Jama-biblioteket til matrice-beregninger. Dette bibliotek findes som JARarkiv i mappen javalib og skal også tilføjes til max.java.config.txt.
61
A.3
Prototype
Prototypen findes i en køreklar version til Mac og Windows. Mac-versionen
er testet på OS X 10.5 (Leopard). Windows-versionen er testet på Windows
XP SP 3 med Java 1.6.
Programmerne findes i hhv. prototype/mac og prototype/windows og
kan køres direkte fra cd’en.
A.4
Videooptagelser
Videoklip, som viser en brugssituation med prototypen, kan findes i mappen
video.
62
Bilag B
Onset-detection
Følgende bilag er en rapport fra et tidligere projekt omkring onset-detection
i human beatboxing-optagelser.
63
1
Project Report: Onset Detection
Mikkel Gravgaard Nielsen - 20043246
June 15, 2010
Contents
1 Introduction
2
2 About Onset Detection
2.1 Definition of onsets . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Audio material . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Choice of parameters . . . . . . . . . . . . . . . . . . . . . . .
3
3
3
3
3 Time-based onset detection
3.1 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
5
4 High Frequency Content method
4.1 Short-Time Frequency Transformation . . . . . . . . . . . . .
4.2 Implementation . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
6
6
7
5 Post-processing and
5.1 Low-pass filtering
5.2 Thresholding . .
5.3 Peak-picking . .
9
9
9
9
Peak-picking
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . .
Introduction
This project report deals with the work of a studies group under Ole Caprani
regarding onset detection algorithms. The domain of the project is the implementation and analysis of algorithms for onset detection in audio signals.
More specifically, the audio signals are recordings of so-called human beatboxing, which can be descibed as human imitations of drumbeats using the
voice.
The article “A Tutorial on Onset Detection in Music Signals”[1] is used
as a basis for the project. This article lists different methods for onset
detection, and two of these methods are implemented in this project. One
method deals solely with the temporal features of the signal. The choice of
this method is motivated in the concluding section of [1]: “If the signal is very
percussive (e.g., drums), then time-domain methods are usually adequate.”
The other method, High Frequency Content, is motivated by its description
in [1] as being “successful at emphasizing the percussiveness of the signal”.
The different methods of onset detection have various parameters. The
argumentation for the choice of parameters is given, and the results of the
different methods are compared to a manual detection and evaluated. It
seems that distinctive approaches for low-pitched and high-pitched sounds
are required, which is what the HFC method does very well. However, the
time-based method of onset detection might work better, if the signal was
first filtered into seperate band and then processed with different threshold
values.
The tool used for implementation of the algorithm is mainly the development environment Matlab. The idioms of Matlab encourage processing
of entire vectors for each programming statement. This limits its use for
real-time processing of audio, but has been useful for rapid prototyping and
tweaking of the applied algorithms in the project.
The sound material used in the project and the Matlab source code for
the implementation can be found on the homepage,
http://daimi.au.dk/~grav/onset.
6 Quality measurement
10
6.1 Quality measures . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7 Conclusion
13
1
2
2
2.1
About Onset Detection
Definition of onsets
It is of course appropriate to define onsets in order to detect them. In [1],
an onset is defined as the moment the amplitude of a note starts to increase
(the attack). The concept of transients is also informally described in [1] as
“short intervals during which the signal evolves quickly in some nontrivial
or relatively unpredictable way”.
In the context of this project, a note is a single “mouth beat”, eg. the
imitation of a single hi-hat or bass-drum beat. Such percussive sounds
tend to have a short attack, so its onset will coincide with the start of the
transient.
2.2
Choice of parameters
The detection methods can be parameterized in several ways, eg. time and
amplitude thresholds, cut-off frequencies etc. The choice of the different
parameter values comes from experimenting and doing ad hoc listening tests
with different human beats.
To finally determine the success of the implementation, the two detection
algorithms are used for finding the onsets of the different human beats, with
the same parameters being used for all beats. The result of the automated
detection will be compared to the result of a manual detection process.
Of couse, as with automated fitting of parameters, there is the problem
of overfitting, when using the same material for training and testing, and the
result would of course be better in general with access to more and seperate
testing and training data.
3
Time-based onset detection
For the time-based method for finding onsets in sound, the general idea is to
look at increments in rectified amplitude or energy (squared amplitude) as
seen in [1] eq. 1 and 2, and simply recognize onsets as values above a certain
threshold. However, the “beat” of a note in music consists of several small
peaks in energy, so a kind of averaging is needed. In [1], subsampling (which
can be consideret a crude kind of averaging) is mentioned without detailing
the ratio, together with smoothing which consists of cross-correlating with a
windowing function. This result in a low-pass filtering, since, if a symmetric
window is used, cross-correlation is mathematically the same as convolution,
ie. filtering in the time-domain.
3.1
Audio material
The audio material being used is recordings by Martin Albrekt. The material
has been processed using dynamic range compression in order to accentuate
the quiet sounds.
2.3
3
Implementation
For the time-based method, the signal was downsampled 4 times. The resulting samplerate of 11025 Hz should allow reasonably high-pitched sounds
such as hi-hats to be represented.
The simplest low-pass filter is a square of height 1/N , where N is the
length of the filter. A better solution is to use a windowing function, eg.
hamming, since this will reduce the ripples created by the filter.
Naturally, the larger the window, the more averaging is going on, resulting effectively in a lower cut-off frequency of the low-pass filter. No window
type or size is mentioned in [1]. A hamming-window was selected, since it is
very standard, and a window-size of 150 ms was chosen by experimenting.
The time-based method was at first implemented using only averaging.
In the listening tests, it seemed that the detected onsets were “late” compared to the conceived onsets. This is illustrated in figure 1.
The energy of a note might still be slowly increasing even after the attacktime. This means that the peak of energy might not correlate with what is
conceived as the onset. If the derivative of the energy is analyzed, we are
effectively considering the change of energy, and a sudden change will have
a higher value, better corresponding to the conceived onset.
Using the derival of the signal (ie. the difference between samples in the
discrete case), the onset detection sounded more accurate.
As mentioned in [1] p. 1038, sound is thought to be perceived logarithmically. In the experiments, it did seem easier to choose a good threshold
for several different signals when considering the logarithm of the different
sound signals.
As a side note, it is in practice important to post-process the signal before
taking the logarithm, since any 0-valued samples will yield -Inf, resulting
in NaN-values when differentiating. Additionally, the logarithm of small
positive values yield large negative values. Therefore, a constant of 1 is
added to the signal before taking the logarithm in order to avoid NaN-values
4
Time−based detection
Original recording
Detecion function
Thresholding
Onsets
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
−0.1
−0.2
0
2000
4000
6000
8000
10000
12000
14000
16000
Figure 1: Delayed onsets using time-based method
and loss of precision.
3.2
Figure 2: Spectrogram of an entire human beat
Evaluation
The use of the logarithmic, differentiated signal gives good results in the
listening tests. However, from the listening tests, the time-based method
yields a dilemma with avoiding too many onsets in the low notes (ie. bass
drums) and still detecting the high notes (ie. hi-hats). If the threshold is
set such that the onset of high-picthed notes are detected, a single low note
often results in several falsely detected, consecutive onsets. Even though a
good threshold may be obtainable for one signal, the same threshold might
not work for another signal.
4
High Frequency Content method
As mentioned in the previous chapter, considering only the time domain of
a signal yields a dilemma between getting correct detection of low-pitched
and high-pitched notes. A simple method is suggested in [1] that considers
the frequency domain called High Frequenct Content (HFC), which gives
greater weight to the higher frequencies.
4.1
Short-Time Frequency Transformation
To get spectral information of the signal as a basis for HFC, a Short-Time
Frequency Transformation (STFT) is used in [1]. This process time-slices a
signal and calculates the frequency spectrum for each slice. The energy of
frequency vs. time is often visualized with a spectrogram. The recording
’human4.wav’ is visualized with a spectrogram in figure 2.
4.2
Implementation
Choosing a window-size for the time-slices of N samples yields N/2 useful
coefficients or frequency bins. If the window-size is increased in order to
increase the number of coefficients, timing information is lost. Therefore,
5
6
it is important to choose a window-size that is small enough to distinguish
between the different onsets of notes and large enough for the frequency
weighing to be useful.
As a basis for choosing the window-size and hop-size, the assumption
in [1] is that the human ear cannot distinguish between two transients less
than 10 ms apart. A window-size of 512 samples, which equals approx. 12
ms was chosen for the project together with an overlap of 8 ms. This should
allow for enough timing accuracy in the detected onsets.
In [1] eq. 3, the STFT is parametrized by the window-size (N ) and the
hop-size (h). Matlab’s function spectrogram uses a parameter, noverlap,
which defines the number of samples that are overlapped from one window
to the next. This parameter is calculated from the hop-size as simply:
noverlap = windowsize − hopsize
(1)
In [3], the two lowest frequency bins are discarded to “avoid unwanted
bias from the DC component” which can occur if the analysis window is
shorter than the lowest frequency. In this project, only the first bin was
discarded, since a window-size of 12 ms allows for frequencies around 80 Hz,
which is well below what the human voice can produce.
In [1] eq. 4, the sum of a linear weighing of the frequency bins (ie. bin
k getting weight k) is used as detection function for HFC. However [3] goes
further and defines in eq. 5.3 the detection function as:
M oTr =
HF Cr
HF Cr
∗
HF Cr−1
Er
Figure 3: Bass drum using the throat having little high-frequency energy
(2)
1
4.3
Evaluation
The HFC method does seem to solve the problem with choosing a good
threshold for both high and low frequenced notes.
One problem that was found with the implementaion method in [1] was
however that so-called “throat” drums, eg. bass drums made with the throat
went undetected. The explanation might be that these drum sounds lack the
hard attack (high frequenced transient) of sounds made with the lips, which
the HFC method favours. Spectrogram of the two types of bass drums are
visualized in figure 3 and 4.
Motivated by the detection function in [3] and the results of the timebased method, the results regarding “throat” drums were improved by using
the differentiated HFC, ie. the distance between each frame of the summed
frequency bins.
7
0.9
Normalized Frequency (×π rad/sample)
where r is the frame number. In this way, the ratio between each frame of
the HFC is considered. In the project, the difference between frames is used,
motivated by the results of the time-based method.
0.8
0.7
0.6
0.5
0.4
0.3
0.2
0.1
0
500
1000
1500
2000
Time
Figure 4: Bass drum using the lips having more energy in the higher frequencies
8
5
Post-processing and Peak-picking
The process of determinating the onsets is not yet just a matter of finding
local maxima of the detection function. [1] argues that noise can still be
masking the onsets, and that some peaks are nonevent-related. To solve the
noise-issue, smoothing is yet again applied, following a thresholding process
to remove certain peaks.
5.1
Thresholding
To eliminate nonevent-related peaks, [1] suggests using both a constant and
an adaptive threshold. The adaptive thresholding is in a sense yet another
low-pass filter, but [1] suggests using a median filter, which prohibits very
large peaks from masking small peaks. This feature of the median filter is
also exploited in image processing to remove so-called salt-and-pepper noise
without blurring the image too much [2]. The median was calculated for a
window of 100 ms as suggested in [1].
In [1], several values of constant threshold were tested, however in this
project one constant value was chosen for each method. The reasoning is
that the performer, the recording equipment and the processing of the drum
beats is the same for all beats, so the listening tests should yield a good
overall value for this constant threshold parameter.
5.3
Quality measurement
6.1
Peak-picking
After post-processing, if the result is adequately smoothed, then the determination of onsets, or peak-picking, is reduced to finding the local maxima
of the resulting signal.
9
Quality measures
In order to get a quality estimate of the algorithm, the following measures
are used:
• True Positive: A detected onset that is within tolerance of a real onset.
• False Positive: A detected onset that is not within threshold of any
real onset.
Low-pass filtering
The chosen 2nd order low-pass filter is implemented according to [4], table
2.2. The lowpass-filtering following the detection function especially seems
to make sense when using differentiation in connection with the detection
function, as has been the case for the two methods used, since differentiation
amplifies the high frequencies, giving birth to many local maxima.
For the non-differentiated, time-based detection function, a cut-off frequency of 4000 Hz seemed to yield the best results in the listening tests.
With the differentiated signal, a cut-off frequency of 500 Hz seemed to do
the trick. 500 Hz can seem very low, considering the frequency range of
instruments, but it is important to remember that the signal processed is
far away from the original and has little to do with eg. hi-hats and bass
drums at this stage.
For the differentiating HFC method, a low-pass frequency of 8000 Hz
was used..
5.2
6
• False Negative: All undetected, real onsets.
• True Negative: This factor is not considered, since it is in a sense
always infinite.
A value for each measure is given by dividing the measure with the
number of real onset.
As threshold, a distance of 50 ms to both side is used in [1], with the
argument “to allow for the inaccuracy of the hand labeling process”.
If a more accurate hand-labeling could be achieved, it should give a good
idea of the accuracy of the automatic detection.
In the case of this project, the sound files to be hand-labeled were limited
to 8, all with percussive material. Therefore, the manual detection of onsets
is easier than with a broad range of sound material as in [1], so it should
be possible to do a more precise hand-labeling. A tool constructed for the
purpose of aiding the labeling was used1 .
6.2
Results
In table 1, the hit-rates of two detection method using different values of
distance tolerance is presented. The differentiating version of both methods
was used.
At 30 ms the rate of true positives for the time-based method is quite low.
As seen in figure 5, the rate increases with the threshold, suggesting that the
onsets are simply detected “late”, even when using the differentiated version
of the algorithm. Even with a large ratio of true positives at threshold 80
ms, the number of false positives is rather high (0.43). This might have
to do with the problem described in section 3.2 that low-pitched notes may
result in several falsely detected, consecutive onsets. Also, if the signal is not
smooth enough, several small valleys will result in several very close onsets.
This problem is evident in figure 1, where the 9th and 13th are actually
several consecutive onsets. The problem could be avoided with some kind
of “grace” period where no detection is done.
1
manualonset.m and removemanual.m
10
Threshold
30 ms
40 ms
50 ms
60 ms
70 ms
80 ms
Method
Time-based
HFC
Time-based
HFC
Time-based
HFC
Time-based
HFC
Time-based
HFC
Time-based
HFC
True Positives
0.13
0.69
0.21
0.83
0.38
0.91
0.61
0.92
0.75
0.93
0.83
0.93
False Positives
1.13
0.27
1.04
0.14
0.87
0.06
0.64
0.05
0.50
0.04
0.43
0.04
False Negatives
0.87
0.31
0.79
0.17
0.62
0.09
0.39
0.08
0.25
0.07
0.17
0.07
Onset Detection Accuracy
1
0.9
Table 1: Method Measures
True Positives Rate
The HFC method performs somewhat better. At thresholds from 50 ms
and beyond, the rate is reasonably stable, as seen in figure 5, which points
towards correlation with the manual detection.
0.8
0.7
0.6
Time−based
HFC
0.5
0.4
0.3
0.2
0.1
0.2
0.3
0.4
0.5
0.6
Distance Threshold
0.7
Figure 5: Onset Detection Accuracy
11
12
0.8
0.9
7
Conclusion
References
Consideration of the frequency domain seems appropriate, even with fairly
homogeneous and narrow-banded material, as used in the project. In that
way, the HFC method works well. The time-based method might work
better, if the source signal was first split up in a few seperate frequency
bands. In this way a different threshold could be selected for each band.
Matlab has shown to be a good tool for prototyping the algorithms,
when the idioms of processing whole vectors of data are understood and
used. Also, a lot of the procedures and algorithms needed, such as creating
spectrograms and finding local maxima, are included in Matlab, and their
implementation details fairly well documented.
[1] Juan Pablo Bello. A tutorial on onset detection in music signals. IEEE
Transactions on Speech and Audio Processing, 13(5):1035–1047, 2005.
13
14
[2] Gonzalez and Wood. Digital Image Processing. Prentice Hall, 2008.
[3] Paul Masri. Computer Modelling of Sound for Transformation and Synthesis of Musical Signals. PhD thesis, University of Bristol, 1996.
[4] Udo Z¨
olzer, editor. DAFX - Digital Audio Effects. Johnny Wiley &
Sons, 2002.