Musik afspiller Michael Frøstrup Andersen

Transkript

1 Musik afspiller Michael Frøstrup Andersen Professionshøjskolen University College Nordjylland Professionsbachelor i softwareudvikling University College Nordjylland 1

2 Teknologi og Business Professionsbachelor i softwareudvikling psue0213 Bachelorprojekt Projektdeltagere: Michael Frøstrup Andersen Vejleder: Mogens Holm Iversen Afleveringsdato:

3 Abstract Ved fester er der mange mennesker der gerne vil høre nogle bestemte sang, da det ikke er muligt for værten at have alle sange bliver der ofte brugt youtube, problemet med at bruge youtube er at den normale afspilningsliste bliver afbrudt, og måske aldrig startet igen, dette kan forårsage at der ikke bliver afspillet noget musik i et stykke tid. For at prøve at løse dette problem er der blevet udviklet en løsning af en musikafspiller som kan afspille både youtube links og audio filer. Dette skaber dog nogle problemer da youtubes API er meget begrænset, dog kunne der godt udvikles en løsning. Denne løsning har dog selv sine begrænsninger igen på grund af youtubes api. 3

4 Table of Contents Abstract... 3 Introduktion... 7 Problemformulering... 8 Fag der bliver indraget... 9 Systemudviklingsmetoder Vandfalds modellen Konklusion/ulemper/positive sider Spiral model Konklusion/ulemper/positive sider V-shaped model Konklusion/ulemper/positive sider Iteration model Konklusion/ulemper/positive sider Unified Process Konklusion/ulemper/positive sider Extreme Programming Konklusion/ulemper/positive sider SCRUM Konklusion/ulemper/positive sider Valg af systemudviklingsproces User stories Risk management ingen forbindelse dårlig forbindelse produktet var for stort helbredsmæssige problemer projektet er mere komplex end forventet computerfejl Valg af lydfiler Feature list Arkitektur af programmet SOA

5 Strukturen i projektet Communication between app and computer app point-to-point publish-subscribe channel datatype channel guaranteed delivery Dette Projekt Tidsplan Hvorfor v2 af youtube api i stedet for v Normalisering Metoder for normalisering Hvordan skal det gøres? Asynkron design AKADEMISK ARTIKEL Introduction Wav file format MP3 file format Re-quantization I. Re-quantization in MP I. Normalizing MP3 and Wav I. How it can be done II. Conclusion References Test: Introduktion Resourcer Hvad skal testes? Hvad bliver ikke testet? Risks Schedule Udgivelses kriterier Hvorfor nåede projektet ikke det der var forventet?

6 Hvad var planen med det der ikke blev nået Konclusion References Bilag Bilag 1 (feature list, prioritering og estimering.) Bilag 2 (tidsplan)

7 Introduktion Når man er til private fester så bliver der nogle gange afspillet musik via en computer, når dette sker bliver gæster ofte fristet til at finde en youtube sang på computeren fordi afspilningslisten på computeren ikke har alle sange, dette kan godt blive træls i længden når der er mange folk der gerne vil høre mange forskellige sange, på grund af dette bliver der ofte skiftet sang mellem musikafspiller og youtube. Denne rapport vil beskrive et produkt som er blevet lavet sammenhæng med denne rapport. Dette produkt vil fjerne problemet med at skifte mellem youtube og musikafspiller da dette produkt er en musikafspiller der kan lave en afspilningsliste, som består af både audio filer og youtube links. Samtidig med at denne computer applikation skulle kunne afspille youtube videoer og audio filer, så skal appen også have mulighed for at normalisere audio filerne. Ud over dette beskriver rapporten også omkring en mobilapplikation som skulle kunne sætte sange i kø, så flere folk kan sætte sange i kø. 7

8 Problemformulering Dette projekt består af flere dele der skal arbejde sammen, dog skal der være mulighed for at bruge pc applikationen uden mobil applikationen, På grund af dette kan der bruges SOA 2.0 som er blevet lært i system integration. den første del er en applikation til en computer som skal være en musikafspiller, der skal kunne lave en afspilningsliste som kan blive oprettet ved at inputte lydfiler, mp3 og wav filer samt youtube links. Der skal samtidig være mulighed for at kunne begrænse den maksimale lyd som kan laves af en sang, og der skal derfor enten laves en normalisering af lydfilerne, eller der skal laves en limiter på dem, dette er et område som uddannelsen ikke er kommet ind på og vil derfor blive skrevet om i den akademiske artikel. Applikationen skal samtidig også kunne modtage både mp3 filer og youtube links fra den anden applikation, disse mp3 filer og youtube links skal derefter indsættes i afspilningslisten, og afspilles som den næste sang i rækken, til dette kan der bruges et messaging system som er blevet lært i system integration. dette skal applikationen kunne gøre mens den fortsat afspiller sange fra afspilningslisten på grund af dette skal dette gøres på en asynkron måde som er blevet lært i development of large scale system, da den ene process ikke skal vente på den anden. Den anden del er en applikation til en mobil som skal bruges til at sende mp3 filer og youtube links til den første applikation for at sætte diverse sange i kø, der skal være mulighed for flere mobil applikationer kan sende mp3 filer eller youtube links til pc applikationen på samme tid. Til dette kan der som skrevet tidligere bruges et messaging system som er blevet lært i system integration. Der skal samtidig laves test på begge dele af programmet, dette kan inkludere user tests, unit tests samt andre, der kan også inkluderes en test plan og der kan samtidig snakkes om hvilke tests der skal laves, hvorfor de er nødvendige samt hvorfor de burde laves frem for andre, dette er der blevet undervist i, i test. 8

9 Fag der bliver indraget SOA 2.0 (System Integration, lektion 13): I faget messaging system blev der undervist i SOA, og dette koncept er også et koncept der kan bruges i dette projekt, dette skal bruges til at implementere messaging systemet der skal snede beskeder mellem computer programmet og mobil applikationen, dette koncept bliver brugt til at lave et event driven koncept på programmet. Den event drevet del af programmet bliver kommunikationen mellem computeren og mobil appen, da computer appen skal vente på at få en besked ind, hvorefter den skal bearbejde den besked, så behøver mobil applikationen ikke at få noget svar tilbage når den er færdig. På denne måde får man også et mere løst program hvor selv hvis mobil applikationen ikke bliver brugt, eller ikke er tilstede, så vil der stadig være et computerprogram der kan udføre sine andre roller uden at det ville skabe problemer. messaging system (system integration, lektion 6-12) I faget messaging systems blev der lært at lave messaging systemer som kunne bruges til at kommunikere mellem flere programmer og endda nogle forskellige sprog, for at inddrage dette fag i projektet blev der planlagt at lave en mobil applikation som kunne kommunikere med et computer program. For at sørge for at dette fag blev inddraget mere blev der valgt at planlægge en java applikation til android mobiler, og en C# applikation som så skulle bruge det der var lært i lektionerne til at kommunikere, Messaging systemet der var planlagt til dette projekt. Dog på grund af tidsmangel blev dette fag dog ikke brugt til noget praktisk, så dette fag blev kun udnyttet til teoretisk planlægning af systemet. Asynchronous design (development of large scale systems, lektion 11) I faget development of large scale systems, blev der blandt andet undervist i asynkront design, dette er relevant for dette projekt, da dette projekt skal afspille musik mens det skal gøre andre ting. I lektion 11 i development of large scale systems, blev der snakket om hvordan et asynkront design kunne gøre programmet hurtigere, og derfor ville det være godt i store programmer der bliver nødt til at arbejde meget hurtigt, i dette projekt, bliver det brugt til at have flere features til at køre i baggrunden. Dette fag, og denne lektion skal bruges til at lave normaliseringen, så det kan køre i baggrunden, mens musikafspilleren stadig spiller musik. Dette fag skal også bruges til at sørge for at messaging systemet ikke får musikken til at holde pause når der bliver modtaget en besked, og den besked så skal behandles. Test (Test, lektion 1-13) I faget test er der blevet brugt nogle forskellige ting. En af disse ting er en testplan, der er blevet valgt at lave en testplan til dette projekt for at sikre sig at tingene bliver testet, der bliver samtidig brugt viden omkring forskellige typer tests, og der bliver taget stilling til hvilke af disse tests der skal laves i dette projekt. Der vil 9

10 også blive taget stilling til hvilke tests der skal laves som whitebox teste, og hvilke test der skal laves som black box tests, ifølge den viden som der er blevet undervist i, i faget test. Systemudviklingsmetoder når der skal vælges udviklingsmetode er der meget at tage stilling til, der er mange project management modeller at vælge imellem og mange udviklingsmetoder, i dette afsnit vil der blive forklaret omkring nogle forskellige project management modeller og nogle udviklingsmetoder som kan bruges til at udvikle et projekt. Der vil samtidig blive lavet en lille konklusion til hver enkelte udviklingsmetode og management model for at snakke om hvilke fordele og ulemper de forskellige metoder har. Vandfalds modellen Vandfalds modellen er en projektmanagement model til at lave software, hvor software udviklingen betragtes som konstant flydende nedad (som et vandfald). Denne bevægelse sker, oftest, gennem følgende faser: Figur 1 Overblik Vandfald At følge vandfaldsmodellen vil sige at gå fra én fase til den næste strengt sekventielt. For eksempel afslutter man først skrivning af kravspecifikationen helt, sådan at det efter kravspecifikation fasen er fuldstændig klart hvad systemet skal kunne. En kravspecifikation for Wikipedia kunne være "Wikipedia skal tillade at anonyme kan rette i artiklerne; wikipedia skal give folk mulighed for at søge efter information", men realistiske specifikationer vil være meget mere komplekse og detaljerede. Når og kun når kravene er fuldt beskrevet går man videre til design. I designfasen laves en "arkitekttegning" som programmørerne skal følge - dette design skal være en plan for, hvordan man implementerer kravene fra kravspecifikationen fasen. Når og kun når designet er lavet færdigt, implementeres designet af programmører. Når alle dele af systemet er lavet sætter man dem sammen i integrationsfasen. For eksempel kan et team have lavet webside komponenten af Wikipedia og et andet team har lavet server komponenten af Wikipedia. Disse komponenter skal så sættes sammen i integrationsfasen for at lave det samlede system. 10

11 Efter implementations- og integrationsfaserne er færdige laves afprøvning og fejlfinding af softwaren; fejl, der stammer fra tidligere faser, fjernes i afprøvningsfasen. Derefter installeres softwaren og senere laves vedligeholdelse, hvor ny funktionalitet kan introduceres og fejl kan fjernes. Således siger vandfaldsmodellen, at man kun skal gå til næste fase når den foregående fase er færdig og perfektioneret. Faserne i vandfaldsmodellen er således diskrete, og man hopper aldrig frem og tilbage mellem faser eller har overlappende faser. Der er dog forskellige modificerede vandfaldsmodeller, der kan indeholde mindre eller større variationer af denne proces. Konklusion/ulemper/positive sider Fordelene ved vandfaldsmodellen er, at den er meget udbredt, og nemt at forstå. Det er drevet af dokumentation, og forstærker dermed gode vaner. Modellen er afhængig af, at man har veldefinerede milepæle, for at man kan bevæge sig videre til næste fase. Der er dog også ulemper ved modellen. Den er meget idealiseret med hensyn til dokumentation af krav tidligt i processen, og er ikke god til at håndtere ændringer, da man bevæger sig slavisk frem mellem faserne. Dette gør også leveringen problematisk, da der er risiko for først at opdage kritiske fejl sent i processen. Spiral model Spiral modellen består af fire faser, som henholdsvis er planlægning, risikoanalyse, implementering og evaluering. Et projekt gennemgår disse fire faser flere gange i iterationer, som kaldes spiraler. Man begynder med den første spiral, som også kaldes baseline spiral. Alle efterfølgende spiraler bygger på baseline spiral. De fire faser indeholder følgende: Planlægning: Der indsamles krav. Risikoanalyse: Denne fase går ud på at finde risici, og evt. alternative løsninger. Til sidst i denne fase, laver man en prototype. Implementering: Fasen består af kodning og test heraf. Evaluering: Kunden vurderer og evaluerer resultatet, før det går videre til næste spiral. Modellen består af mange af de samme faser som vandfaldsmodellen. Der produceres dokumentation efter behov, og er derfor ikke fast defineret hvornår i processen dette sker. 11

12 Figur 2 Overblik Spiral model Konklusion/ulemper/positive sider Der er både fordele og ulemper ved denne model. Fordelene er at der er meget risikoanalyse, der produceres software tidligt i projektet. Det benyttes ofte på store og forretningskritiske systemer. Ulemperne er at det kan være en bekostelig metode, risikoanalysen kræver erfaring og ekspertise. Det er ikke en optimal metode til mindre projekter. V-shaped model V-modellen kan ses som en slags udvidet vandfaldsmodel. Som i vandfaldsmodellen, arbejdes der i v-modellen også i step-by-step form, det vil sige at en fase skal afsluttes før en ny fase kan begynde. Den største forskel her er, at der efter implementeringen følger testfaserne, dvs. vejen nedad holdes nu til analyse og designet, mens vejen opad igen er knyttet til test og integrationer. Figur3 Overblik V-model 12

13 Billedet viser tydeligt, hvordan der først analyseres og designes, og dette afsluttes med kodningen. Her sker så udvidelsen til vandfaldsmodellen, kodningen bliver efterfulgt af unit test, som er påbegyndelsen af testfasen. I testfasen bevæger man sig igen opad med en række test som er tilpassede til de nedadgående faser; f.eks. kodning og unit test eller Software Requirements og acceptance testen. Først når alle faser er testet, eller bedre sagt produktet er testet og det passer til den fase(trin) den står på, så er produktet færdig. Skulle en test fejle, ved man hvilken trin det gik galt på, dermed også på hvilken trin i analysen det gik galt. Konklusion/ulemper/positive sider Ligesom vandfaldsmodellen er V modellen en dyr og ufleksibel model. V-modellen har dog fordele overfor vandfaldsmodellen i forhold til succes, og fungerer godt til mindre projekter. På samme måde som vandfaldsmodellen, er den meget ufleksibel, hvilket også gør den meget dyr. Det er en ulempe at den ikke benytter sig af prototyper, og modellen giver heller ikke nogen løsningsforslag på problemer under testfasen. Iteration model I et iterativt forløb vil projektet i stedet gennemløbe en række faser, der i princippet omfatter det samme, nemlig hver for sig en miniudgave af vandfaldsmodellens faser. Der er ikke nødvendigvis lige så meget arbejde at udføre på hvert af punkterne i en iteration. En iteration tidligt i forløbet vil ofte have mest fokus på de første punkter, mens en iteration sent i forløbet måske kun omfatter programmering og test. Figur 4 Overblik Iteration Konklusion/ulemper/positive sider At lave iterationer indenfor softwareudvikling indeholder både fordele og ulemper. Fordelene er at man fanger fejl tidligt i processen. Ulemper er at man kan bruge meget tid på fejlfinding, og at man kan sidde fast i sine iterationer, uden at få defineret hvornår man er færdig. Altså sidder man nærmest fast i et loop. Mange nyere systemudviklingsmetoder er iterative, og det iterative element kobles ofte med inkrementel udvikling. Eksempler på disse metoder er Unified Process og Extreme Programming. 13

14 Unified Process UP er en populær iterativ og traditionel project management model. Men UP er også en fælles udviklingsmetode for udviklingsprocessen, som kan tilpasses de enkelte problemområder, organisationer, kompetenceniveauer og projektstørrelser. UP`s kendetegn er at den er komponentbaseret, dvs. at den sigter efter at udvikle software systemer, der består af komponenter, som kommunikerer via veldefinerede interfaces. UP benytter UML (Unified Modelling Language) gennem hele processen, et standardsprog til primært visuelle modeller af et software system. Det der især adskiller UP fra andre metoder, er de tre fundamenter, metoden er baseret på. Disse tre fundamenter er, at den er use case drevet, arkitektur centreret og iterativ og inkrementel. Begrebet use case drevet betyder, at use cases bruges til planlægning og kontrol af al fremdrift i udviklingsarbejdet fra de indledende krav overvejelser til koden. En arkitektur er den fundamentale organisering af et system som en helhed, dvs. fundamentet som systemet skal hvile på (nogle kalder det også for et overordnet design). Iterationerne resulterer i en trinvis fremgang af produktet og stadig en mindskning af risici på projektet. Denne model er optimal for de store projekter med et stort udviklingshold. Figur 5 Overblik UP Konklusion/ulemper/positive sider UP forudsætter en velstruktureret, gennemtænkt og detaljeret plan. UP benyttes ofte i lange projekter. UPs største fokus ligger på selve processen og er plan drevet, dvs. at udførelsen af projektet og kommunikation mellem faserne sker via dokumenterne. Det er god systemudviklingsproces til store projekter, hvor der er mange involverede, da den bygger på meget og god kommunikation. Dog er dette et problem ved projekter hvor der forekommer en masse ændringer. Extreme Programming XP er også både en projektmanagement model og en udviklingsmetode for udviklingsprocessen. XP benytter planning game, som er fordelt I 3 trin: exploration, commitment og steering. Hvis vi skal forstå hvad der skal ske, er vi nødt til at forstå hvordan man vil håndtere de 3 koncepter, som er kravspecificering, estimering og release og iterationsplanlægning. I exploration skriver kunder user stories, udviklerne estimerer, kunden opdeler evt. i mindre stories, og eksperimenter (spikes) ved ukendte områder bliver vurderet. I commitment fasen vælger kunden omfang og dato for den næste release, og i steering fasen sker en opdeling i iterationer og en regulering, hvor omfang af opgaver bliver estimeret igen. Denne model er optimal for små til mellemstore projekter, men kræver meget kommunikation mellem kunde og udviklingsteam. 14

15 Figur 6 Overblik XP Konklusion/ulemper/positive sider XP har gode metoder der passer godt til små og mellemstore projekter. Pga. stor kommunikation skabes der et godt samarbejde i teamet. Det er testbaseret hvilket vil sige at der er stor fokus på kvalitetssikring, og generelt i XP er der stor fokus på det endelige produkt. Dog er XP ikke optimalt at bruge til store projekter hvor der er meget dokumentation. Flere af værktøjerne, som f.eks. test first er en svær og specialiseret ekspertise. SCRUM SCRUM er en agil projekt management model, der giver mulighed for at fokusere på at levere det ønskede produkt på kort tid. Det tillader at inspicere hurtigt og gentage det aktuelle produkt (hver anden til fjerde uge). Kunden prioriterer og udviklingsholdet organiser selv den bedst mulige vej til at aflevere de højest prioriterede dele af programmet. Hver anden til fjerde uge kan alle se et færdigt produkt og beslutte sig om, at lave en levering eller fortsætte med at implementere de næste prioriteter i det nye sprint. SCRUM projekter vokser i en serie af sprints svarende til iterationer i XP. Produktet bliver designet, programmeret og testet i et sprint. SCRUM definerer 3 roller (Product Owner, Scrum Master, Team), fire møder (Sprint planning, Sprint review, Sprint retrospective, Daily scrum meeting) og 3 artefakter (Product backlog, Sprint backlog, Burndown chart). SCRUM kan blive brugt til alle arter af projekter, men passer generelt bedst, hvis det er et nyt og kompleks projekt med kort tidsrum til at udvikle det. Afhængig af kompleksiteten og størrelsen af projektet kan man så benytte UP eller XP som udviklingsmetode. Figur 7 Overblik SCRUM 15

16 Konklusion/ulemper/positive sider SCRUM er et agilt kompromis mellem ingen og for meget proces. SCRUM arbejder med kort fokus i form af sprint logs, hvori projektets fremgang evalueres hver 2-4 uge. SCRUM behøver ikke nær så meget dokumentation da selve koden af projektet er dokumentation. I SCRUM lægges der mere vægt på holdet frem for processen. SCRUM er en projektmanagement model og kan både benytte sig af traditionelle og agile udviklingsmetoder. Valg af systemudviklingsproces Boehm har udviklet et kort for at hjælpe med at finde den rigtige project management model. Han definerer 5 kritiske punkter. Hvis man ender i midten af kredsen, vælger man en agil model, ellers skal man bruge en traditionel model. Ender man med en blandet profil har man eventuelt mulighed for at tilpasse sin profil. Det gør man i Personnel, Size eller Culture. Figur 8 Projektkort Efter at man har besluttet sig for en model, skal man vælge en metode. Når dette projekt bliver lavet i boehms diagram bliver projektet meget tæt på midte, dette sker blandt andet fordi størrelsen på personalet er en enkelt person, og det kritiske ved dette projekt er kun mangel af komfort, samtidig har projektet også en stor del dynamisk udvikling hvor der godt kan ske en del ændringer i løbet af projektet, dog er disse ikke alt for store, men den ligger ved de ca. 10% change. Culture ligger omkring de 70% hvilket betyder at diagrammet ligger meget mod midten af diagrammet, på grund af dette burde der ifølge dette diagram vælges en agil udviklingsmetode. 16

17 Der er to udviklingsmetoder der kan bruges hvis man skal gå efter hvad beohms diagram siger, og det er scrum og extreme programming, dog på grund af at der kun er en enkelt person i dette projekt mister scrum meget af sin funktionalitet da det handler meget om kommunikation mellem de uddelte roller, og hvis der kun er en person kan der ikke uddeles roller. På grund af dette er der blevet valgt at bruge extreme programming, selv om der er nogle af de metoder som bliver brugt af extreme programming som ikke giver mening at lave da der kun er en person i dette projekt, dette betyder at der blandt andet mangler pair programming, og på grund af mangler som det, mangler der quality assurance, på grund af dette er der blevet valgt at der skal være mere fokus på at få testet de forskellige features ordentligt. User stories der er blevet skrevet nogle user stories, som i følger den agile fremgangs måde at forberede på. I dette tilfælde hvor brugeren også er udvikleren, er disse user stories meget simplificeret for at udtrykke de krav der er til produktet, samtidig udtrykker de features som brugeren gerne vil have i meget specifikke krav. 1. som en bruger vil jeg kunne afspille sange 2. som en bruger vil jeg kunne oprette en liste af sange 3. som en bruger vil jeg kunne skifte sang 4. som en bruger vil jeg kunne afspille en youtube video 5. som en bruger vil jeg kunne tilføje youtube videoer på afspilningslisten 6. som en bruger vil jeg kunne sortere afspilningslisten 7. som en bruger vil jeg kunne bruge min mobil til at tilføje et youtube link til afspilningslisten 8. som en bruger vil jeg kunne høre en bestemt sang som den næste og vil gøre det fra mobilen. 9. som en bruger vil jeg kunne skrue ned for lyden 10. som en bruger vil jeg kunne pause en sang Risk management Til at snakke om risk management bliver der brugt nogle risk reducing/eleminerigns metder som er kort skrevet herunder, disse fire metoder er 4 forskellige måder at håndtere risks på. Avoidance (eliminate, withdraw from or not become involved) Reduction (optimize mitigate) Sharing (transfer outsource or insure) Retention (accept and budget) ingen forbindelse hvis der ikke er forbindelse så kan der ikke afspilles youtube links, da det kræver internet, og der kan samtidig ikke laves noget kommunikation med telefon appen. på grund af dette skal det være muligt for computer appen stadig at fungere som en musikafspiller skulle internettet fejlen. 17

18 Denne fejl kan ikke undgås, da der ikke altid vil være mulighed for at få en forbindelse, og der skal derfor reduceres i stedet for, denne fejl kan reduceres ved at sørge for at programmet beholder så mange funktion som muligt når der ikke er forbindelse, og springer de funktioner over, eller gør dem utilgængelige når der ikke er forbindelse. dårlig forbindelse hvis forbindelsen er dårlig, så vil det få youtube videoer til ikke at load hurtigt nok, og på grund af dette vil det skabe problemer. Dette vil sørge for at youtube videoer ikke kan afspilles ordentligt, dog ville det stadig være muligt at modtage beskeder fra mobil applikationen, dog vil det tage længere tid alt efter forbindelse. Dette problem kan ikke løses da der ikke altid kan skabes en god forbindelse, og på grund af dette så kan der kun reduceres de problemer som en dårlig forbindelse skaber. for at reducere denne risk skal der være mulighed for at springe youtube videoer over hvis de ikke loader hurtigt nok. produktet var for stort for at sørge for at produktet ikke er for stort, så skal der laves en realistisk estimering af hvor meget der kan laves, dog kan der godt estimeres forkert, og på grund af dette kan produktet godt være for stort. For at reducere dette skal der prioriteres, for at finde ud af hvilke features der er vigtigst, og hvilke features der nemmest kan undværes, dette vil fjerne problemet i de fleste tilfælde, dog hvis projektet er meget for stort, og der derfor skal skæres nogle vigtige features væk, så vil problemet kunne blive reduceret i stedet for at blive undgået helt hvis produktet er for stort til at det kan laves i den aftalte mængde af tid, så bliver der nødt til at blive skåret features. helbredsmæssige problemer helbredsmæssige problemer kan ikke undgås helt, dog er det muligt at reducere. For at reducere de helbredsmæssige problemer kan der først og fremmest undgå ting der går arbejdere syge, dog hvis der stadig sker helbredsmæssige problemer kan skal der enten fjernes features fra listen over features da der bliver mistet noget arbejdstid. En anden måde at reducere den tidsmangel der sker ved en helbredsmæssig situation ville være at sætte mere tid af til at arbejde på projektet, dog vil dette ikke altid være muligt. projektet er mere komplex end forventet. I tilfælde af at projektet har nogle features der er mere komplex end forventet skal der gøres en af følgende ting. Den første mulighed er at finde en mindre kompleks løsning til div. komplekse løsninger, dog er dette ikke altid en god løsning, og det er ikke altid muligt. 18

19 Den anden løsning ville være at tilføje mere arbejdstid, eller skære features væk for at danne mere tid til de komplekse dele af projektet. computerfejl. hvis der går noget galt med computeren, enten på hardware eller på software, så skal det rettes op på hurtigst muligt, disse fejl vil altid koste tid, og måske data. for at undgå at miste data skal der laves version control og programmet skal være gemt på internettet for at sikre at programmet altid kan hentes af andre computere. dette vil sørge for at hvis der sker en stor software eller hardware fejl, så kan programmet stadig hentes på en anden computer og arbejdes videre med der. hvis der sker hardware fejl skal hardwaren blive repareret hurtigst muligt, og hvis dette tager for lang tid skal der anskaffes en anden computer til at tage over mens den gamle computer er til reparation. Hvis der sker en stor softwarefejl, skal den repareres hurtigst muligt, om det så er at formatere computeren, eller bare at gendanne til at tidligere punkt. Valg af lydfiler I dette projekt skal der vælges hvilke lydfiler der skal være mulige at afspille i musik afspilleren, dette er nødvendigt at tage stilling til på grund af flere årsager. Den første årsag er at når der skal normaliseres så skal filerne åbnes og ændres, da hver eneste filtype er opbygget forskelligt så skal alle filer arbejdes med på forskellige måder, så for at få en realistisk mængde af lydfiltyper, skal der tages stilling til hvor mange forskellige lydfiler programmet skal kunne understøtte til at starte med, for at vælge imellem de mange forskellige audio filtyper. For at finde ud af hvilke audio filtyper der skulle bruges blev der stillet spørgsmålet, hvilke audio filtyper er de mest normale for musik, til dette er svaret oftest mp3 filtypen, dette er typisk det filformat der bliver brugt til det meste musik som man får fra cd er og fra internettet. På grund af dette bliver mp3 formatet valgt som en af de audio filformater der skal være understøttet af dette produkt. Dog for at lave normalisering som er et krav for dette produkt, vil der komme spørgsmålet om hvordan det skal gøres imellem flere forskellige audio filtyper, for at besvare dette spørgsmål vil der blive valgt mindst en anden filtype som skal understøttes så der skal normaliseres imellem forskellige filtyper. for at vælge den anden filtype er der blevet kigget på hvilke filtyper der er almene. For at finde ud af hvilke filtyper der er almene er der blevet søgt efter det, og ifølge dette link: så er nogle af de mest normalle filtyper følgende: Mp3, Wma, Wav, Real audio, MIDI og Ogg, ifølge beskrivelsen som også findes på hjemmesiden, så er MIDI et format der er brugt meget af instrumenter såsom synthesizers eller lydkort. WMA er microsofts filformater til at encode digital audio, dette audio format minder meget om mp3 formatet. 19

20 WAV formatet et simpelt filformat som kan afspilles af næste alle windows applikationer. Real audio er et audio format der er meget brugt af realplayer, og det er brugt til at stream lyd så det kan afspilles i realtid. ogg formatet er et audio format som oftest bliver brugt til at afspille og gemme digital music, forskellen på dette er at det er gratis og det er ikke patented. Til dette produkt er der blevet valgt WAV formatet. Dette format er blevet valgt af flere årsager, Den første årsag er at det er et simpelt format, og det vil derfor være nemmere at arbejde med end mange af de andre formater der er komprimeret på forskellige måder. En anden årsag er at det er et meget normalt format som mange forskellige programmer kan afspille. En tredje årsag er at der er meget dokumentation der er nemt tilgængelig til wav filer, og på grund af dette vil det blive nemmere at arbejde med wav formatet i stedet for andre formater. Da dette er et projekt der skal indeholde ny viden som ikke er blevet undervist i på skolen, vil der blive lavet normalisering på de udvalgte filtyper, og der vil derfor blive valgt wav formatet da det lægger et godt grundlag for lydfiler, da der ikke er komprimering af nogen art på dem. Så i sidste ende vil der blive valgt wav og mp3 fil formatern Feature list I denne del af rapporten vil der blive beskrevet de forskellige features der var planlagt, dette inkludere hvad de skal gøre, og hvorfor de skal implementeres, der vil samtidig blive givet en prioritering og en beskrivelse til hvorfor der bliver givet den udvalgte prioritet. prioriteten er et tal mellem 1 og 10 hvor 10 er de vigtigste, og 1 er de ikke vigtige features. Et skema blev lavet over feature listen samt prioritet hvor der også blev estimeret de forskellige features, dette skema kan findes i bilag 1. lydkontrol i programmet skal der være mulighed for at ændre på lydniveauet på programmet, dette er en god feature at have for at kunne finjustere lydniveauet på musikken, så den hverken er for høj eller for lav, dette kan også gøres i windows egen lydkontrol, dog vil dette skabe en let og brugervenlig tilgang til at ændre på lydniveauet. Samtidig er dette også noget som brugere forventer af alle musikafspillere, og dette gør det til en forventet features som ville være meget skuffende hvis den manglede. Denne feature har fået en prioritet på 9, da det er en meget vigtig feature, dog er der andre features som denne feature er afhængig af, så som muligheden af at kunne afspille lydfiler. 20

21 afspille lydfiler for at dette program kan blive til en musikafspiller der kan afspille både audio filer, og youtube links bliver den nødt til at have nogle af de mest basiske funktioner for at virke. Denne funktion er den grundlæggende funktion i programmet, uden denne funktion ville programmet miste en af sine mest basiske funktioner og dette må ikke ske. Denne feature vil sørge for at der kan afspilles lyd fra lydfiler. Denne feature har fået en prioritet på 10. Den har fået en prioritet på 10 da dette er en af de mest basiske og samtidig vigtigste funktioner i en musikafspiller, og uden denne feature ville programmet miste stort set alt hvad programmet skal. Samtidig er denne feature også vigtig i det at den skal bruges til at få mange andre features til at give mening. afspille youtube links en af ideerne bag ved dette program var at lave en musikafspiller der også kunne afspille youtube links, på grund af dette er denne feature meget vigtig. Planen med denne feature var at det skulle være muligt at indsætte et youtube link, hvorefter dette program så ville kunne afspille den hvis et gyldigt link blev givet, Denne funktion skulle også have mulighed for at blive integreret i andre funktioner, såsom at kunne ændre på lydniveauet og blive sat ind i en afspilningsliste. Denne feature har fået en prioritet på 9, selvom denne feature er meget vigtig for selve programmet har den ikke fået en prioritet på 10, da der er andre basiske funktioner der er vigtige at få på plads før denne funktion bliver implementeret. Dog er denne funktion stadig meget vital for programmet, da denne funktion var en af de grundlæggende ideer bag produktet, og den har derfor fået en prioritet på 9. spole i sang(seek bar) En feature som blev planlagt til dette produkt var at lave en seek bar, denne feature er en normal feature som kan ses i mange forskellige musikafspillere, og det er derfor en feature der er forventet af en musik afspiller. En seek bar sørger for at man kan spole i en sang, så hvis der er en intro man gerne vil springe over kan man springe et stykke tid ind i sange. Seek baren skal implementeres på en måde så den virker med både de normale lydfiler, men også på youtube videoer hvis det er en youtube video der bliver afspillet mens seek baren bliver ændret på. seek baren har fået en prioritet på 5, selvom en seek bar er noget man typisk finder i en musikafspiller, så er det en feature der godt kan undværes hvis det er absolut nødvendigt. Samtidig i dette projekt er der mange ting som er blevet vurderet til at være vigtigere, enten på den ene eller den anden måde, og på grund af dette har seek baren fået en prioritet på 5. 21

22 afspilningsliste En feature som ofte ses i mange musikafspillere er en afspilningsliste, en afspilningsliste indeholder alle de sange som musikafspilleren skal afspille, uden en afspilningsliste ville man skulle åbne en ny lydfil imellem hver sang, for at undgå dette vil der blive implementeret en afspilningsliste for at sørge for at brugeren kan lave afspilningslister. En afspilningsliste gør det også nemt for brugeren at skifte sang ved at udnytte afspilningslisten, og samtidig vil brugeren kunne se hvilken sang der bliver afspillet som den næste. Afspilningslisten skal i dette projekt kunne indeholde både audio filer og youtube links. Den skal have mulighed for dette på grund af den grundlæggende ide bag dette projekt. afspilningslisten har fået en prioritet på 9. Den har fået denne prioritering da denne feature er meget vigtig at have i en musikafspiller, og samtidig dækker denne feature det krav som er blevet sat op, med at der skal kunne laves en afspilningsliste af både musik filer og youtube links. Dog har denne feature ikke fået en prioritet på 10 fordi der er andre funktioner som denne feature kræver er færdige før den kan blive implementeret, der er derfor blevet valgt at denne feature har en prioritet på 9 i dette projekt. åbne lokale lydfiler (browser) En feature som er meget nødvendigt er evnen til at åbne lokale lydfiler, dette er et krav for mange andre funktioner, da det ikke er muligt at lave mange af de funktioner der er i dette produkt uden at kunne åbne en lydfil. Denne feature skal sørge for at brugeren kan åbne en browser hvorefter at brugeren skal kunne finde sine lydfiler og åbne dem, så de enten kan blive afspillet, eller blive tilføjet til afspilningslisten når den er implementeret. Denne feature har fået en prioritet på 10, da denne feature er meget vigtig for mange af de andre features i dette produkt var den nødt til at blive prioriteret højt. Uden denne funktion ville programmet miste evnen til at kunne lave en brugerdefineret afspilningsliste, eller bare evnen til at kunne afspille lokale lydfiler, og på grund af dette har den fået den høje prioritet på 10. drag'n drop filer Denne filer skulle gøre det muligt at tilføje filer på afspilningslisten ved at markere dem i den mappe de ligger i, og trække dem ind på afspilningslisten, denne feature er ikke vigtig og er mest af alt planlagt af ren luksus. Denne feature har fået en prioritet på 4, den har fået denne prioritet da denne feature ikke er særlig vigtig, og at den mest af alt er der for at give brugeren en feature som han gerne vil have, dog er denne feature ikke vital på nogen måde, på grund af dette har den fået en lav prioritet. 22

23 skifte sang En feature som er meget vigtig er muligheden for at skifte sang i afspilningslisten, dette skal kunne gøres ved at klikke på en sang i afspilningslisten. Denne feature er en basisk feature som findes i musikafspillere som benytter afspilningslister. Denne feature har fået en prioritet på 9, den har fået denne prioritet da det er en meget basisk funktion i en musikafspiller, og det er noget brugeren altid forventer der findes i afspilleren. Fordi denne funktion er så vigtig for brugeren, og samtidig en basisk feature fra musikafspillere, har den fået en prioritet på 9. pause/play knap Produktet skal også have en feature der gør det muligt at pause sange, og hvis de allerede er pauset så skal der være mulighed for at fortsætte sangene, dette er en funktion som ses i alle musikafspillere, og den er vigtig at have, så brugeren ikke skal lukke programmet ned for at få musikken til at stoppe i et øjeblik. Denne funktion skal også virke med youtube videoer, da det også skal være muligt at pause dem og få dem til at fortsætte ved at klikke på den samme knap som de normale lydfiler. Denne feature har fået en prioritet på 9, den har fået denne prioritet da denne feature er meget vigtig for programmet, da der skal være mulighed for at pause sange, dog har denne feature ikke fået en 10 i prioritet da der skal være mulighed for at afspille en sang før den kan blive paused, på grund af dette har den fået prioriteten 9 og ikke 10. næste/forrige knap produktet skal have mulighed for at gå videre til den næste sang, eller gå tilbage til den forrige sang, dette er endnu en feature som findes i alle musikafspillere, og det er en feature som brugere vil forvente at der er i produktet. Denne feature skal også integrere youtube videoer, da det skal være muligt at gå videre til den næste sang, selv hvis den nuværende eller næste sang er en youtube video. Denne feature har fået en prioritering på 9, den har fået denne prioritet da denne feature er meget vigtig, og er noget der findes i samtlige musikafspillere, på grund af dette vil brugeren altid forvente at denne feature findes i programmet, samtidig er det også vigtigt at kunne skifte til den næste og forrige sang. random afspilning. produktet skal have mulighed for at skifte imellem tilfældig afspilning og normal afspilning, dette skal enten gøres ved at blande afspilningslisten hvis brugeren vil have tilfældig afspilning eller også skal den afspille tilfældige sange fra listen, uanset hvilken metode der bliver valgt er konceptet det samme, at de næste sange bliver blandet. Denne feature har fået en prioritet på 3, da denne feature ikke på nogen måde er vital for produktet, denne feature er bare en luksus feature som brugeren gerne vil have, men som er langt fra nødvendig. 23

24 repeat Programmet skal have en feature der gør at brugeren kan vælge om afspilningslisten skal gentages, eller om den kun skal afspille en gang, denne feature skal tage stilling til tilfældig afspilning hvis der bliver valgt at den ikke skal blande afspilningslisten, men bare afspille tilfældige sange. Denne feature har fået en prioritet på 3, da denne feature ikke på nogen måde er vital for produktet, denne feature er bare en luksus feature som brugeren gerne vil have, men som er langt fra nødvendig. reklame skip for youtube videoer Programmet skal have implementeret en løsning for de store reklamer på youtube, da nogle reklamer starter før videoen, afspiller lyd, og kan tage flere minutter skal der findes en løsning på at få disse reklamer skilt af vejen, da disse reklamer ville være træls for brugeren, da det ville skabe en unødvendig pause i afspilningen. Denne feature har fået en prioritet på 6, den har fået denne prioritet da denne feature ville være rar at have, og den ville gøre at brugeren ikke ville blive tvunget til at sidde ved computeren og konstant holde øje med om reklamen kan skippes, eller det ville skabe en stor pause hvor der er reklame i stedet for musik. på grund af dette har den fået en relativ høj prioritet, dog er der på grund af krav fra opgavens side er der blevet sat nogle andre features end højere end denne, og derfor har denne feature kun fået en prioritet på 6. Normalisering Denne feature er er et krav til dette produkt, denne er inddraget i dette produkt for at få en ny viden, og bruge det i et produkt, normaliseringen skal gøre at de forskellige lydfiler i en afspilningsliste ikke har forskellige volume. Normaliseringen vil ændre på filerne for at få dem til at altid have den samme volumen højde. Denne feature har fået en prioritet på 8, den har fået denne prioritet på grund af et krav fra opgavens side, da denne feature ikke i sig selv er den vigtigste feature. Hvis denne feature ikke var et krav ville den have en prioritering på 6 eller under, dog på grund af krav fra opgavens side har den fået en prioritet på 8. sort playlist Programmet skal have en feature der gør det muligt at sortere afspilningslisten efter nogle bestemte krav, såsom alfabetisk eller efter længden af lydfilerne. Denne feature har fået en prioritet på 3, den har fået denne prioritet da denne feature ikke er særlig vigtig for produktets ydeevne. Denne feature er en feature der er rar at have for brugeren, dog langt fra nødvendig, denne feature har derfor fået sin prioritet på 3. 24

25 rearrange playlist Programmet skal have mulighed for at re arrangere de forskellige sange i afspilningslisten, så de kan blive sorteret efter brugerens behov, dette skal tillade at brugeren selv kan flytte rundt på diverse elementer i afspilningslisten. Denne feature har fået en prioritet på 4, da denne feature mest af alt kun er en luksus feature der er rar at have for brugeren, og ikke en nødvendig feature. På grund af dette har denne feature ikke fået en høj prioritet. asynkron design. Programmet skal have asynkrone funktioner da programmet skal have nogle features som skal gøres samtidig med at musik bliver afspillet, på grund af dette skal visse features af programmet laves på en asynkron måde, dette design skal tages stilling til, og der skal samtidig tages stilling til visse metoder der kræver den asynkrone fremgangsmåde, denne feature er lavet på grund af messaging systemet, så der ikke kommer forstyrrelser når der skal modtages en besked. Denne feature har fået en prioritet på 7, da denne metode er påkrævet af visse metoder for ikke at få pauser i musikken når programmet skal lave nogle andre funktioner. send message/message system Programmerne skal have en måde at kommunikere mellem hinanden, dette skal gøres via et messaging system. Denne feature er påkrævet af nogle af de andre features. Denne feature har fået en prioritet på 7, den har fået denne prioritet fordi den er påkrævet af nogle af de andre features, og har derfor fået en højere prioritet end de features som skal kræver denne feature. input link Mobil applikationen skal have mulighed for at sende et youtube link til computer programmet, hvorefter den youtube video skal tilføjes til afspilningslisten på computeren, dette ville sørge for at der kan tilføjes youtube videoer til afspilningslisten uden at det er nødvendigt at sidde ved computeren. Denne feature har fået en prioritet på 6. Denne feature kræver at musikafspilleren allerede kan fungere som musikafspiller for at denne feature kan virke, samtidig er der også andre features som er påkrævet for at få denne feature til at virke som den skal uden at skabe et problem for det flow der er i en musikafspilning, på grund af dette har den fået en prioritet på 6, der var overvejelser om denne feature skulle have en prioritet på 7 da den dækker nogle af de fag som der er blevet undervist i under uddannelsen, dog kræver denne feature en del forarbejde, og der er derfor blevet valgt at forarbejdet skal ligge på en prioritet på 7, hvor denne feature så får en på 6. 25

26 input song name Programmet skal have mulighed for at kunne modtage en besked fra mobil applikationen, hvori der bliver sendt et navn på en sang, denne sang skal så sættes i kø som den næste sang på afspilningslisten. Dette ville give brugere mulighed for at vælge den næste sang selv når de ikke sidder ved computeren. Denne feature har fået en prioritet på 6. Denne feature kræver at musikafspilleren allerede kan fungere som musikafspiller for at denne feature kan virke, samtidig er der også andre features som er påkrævet for at få denne feature til at virke som den skal uden at skabe et problem for det flow der er i en musikafspilning, på grund af dette har den fået en prioritet på 6, der var overvejelser om denne feature skulle have en prioritet på 7 da den dækker nogle af de fag som der er blevet undervist i under uddannelsen, dog kræver denne features en del forarbejde, og der er derfor blevet valgt at forarbejdet skal ligge på en prioritet på 7, hvor denne feature så får en på 6. send sound file Programmet skal have mulighed for at kunne modtage lydfiler fra den app der er planlagt i sammenhæng med dette projekt, Samtidig skal appen også kunne sende lydfiler til musikafspilleren på computere. Denne feature skal gøre det muligt for brugere at tilføje deres egne sange fra mobilen selv hvis de ikke ligger på computeren. Denne feature har fået en prioritet på 2, da denne feature ikke er vigtig, og der er mange features der er meget vigtigere end denne har denne feature ikke kunne få en høj priorit Arkitektur af programmet SOA I dette projekt er der planlagt at bruge SOA til at lave kommunikationen mellem mobil applikationen og computer applikationen. SOA konceptet skal blive brugt til at lave en event baseret kommunikation mellem de to applikationer, dette skal sørge for at computer applikationen ikke fejler ved at der mangler en mobil applikation at kommunikere med, på grund af dette kan de to applikationer fungere seperat fra hinanden på grund af den lave afhængighed af hinanden, dog ville mobil applikationen ikke have meget funktionalitet tilbage når den ikke kan kommunikere. SOA er samtidig et værktøj som der er blevet undervist i under uddannelse, i faget messaging systems. I dette tilfælde skulle det bruges til at sørge for at messaging systemet i mobil app'en fulgte denne event baseret fremgangsmåde, dog kom dette ikke til at ske da denne applikation ikke blev lavet på grund af mangel af tid. Strukturen i projektet I dette projekt er der en struktur af hele projektet som en helhed, til dette er der 26

27 blevet lavet et lille diagram for at vise denne struktur. Denne struktur viser at en mobilapplikation der har en streg til både en computer applikation, og internet, internettet skal bruges til at finde youtube videoer, den skal bruge kommunikationen til computeren til at sende beskeder til den. Computeren har kommunikation til både mobil applikationen i tilfælde af at der skal sendes noget tilbage, og den har samtidig forbindelse til internettet, den skal bruge internettet til at afspille youtube videoer. Communication between app and computer app For at finde ud af hvilken type channel der skal bruges til dette projekt, er der i dette afsnit blevet skrevet nogle forskellige type af message channels som måske kunne bruges til at lave det messaging system som programmet skal bruge. Der vil samtidig blive beskrevet hvorfor hvilke typer channels passer bedre end andre, og der vil blive taget stilling til hvilken form for message system der skal bruges. point-to-point hvis Point-to-Point skal virke så skal der være en ny channel for hver bruger, denne skal kunne oprettes, dette vil skabe en større mængde channels som der skal holdes øje med af musikafspilleren, dog vil alle android applikationerne kun skulle bruge en channel hver, da de hver især får tildelt deres egen channel til at sende information til musikafspilleren. publish-subscribe channel Dette er det modsatte af hvad dette program skal bruge. Et publish-subscribe pattern er at der kan være flere modtagere for hver publisher, dog i dette tilfælde skal der bruges flere publishers for hver modtager. Så i dette projekt skal der ikke bruges et publish-subscribe pattern. datatype channel En Datatype channel består i at sende flere forskellige datatyper på en gang, og i tilfældet af dette projekt ville det være en mulighed hvis der skal være mulighed for at kunne sende musik, eller bare links via en channel til musikafspilleren, dette system ville kunne løse det problem, dog er der stadig det samme problem som der blev skabt i Point-to-Point ved at der skal oprette channels for hvert ekstra device der skal tilsuttes til dette program guaranteed delivery Guaranteed delivery pattern sørger for at beskeden bliver leveret før den bliver slettet, dette kan i sidste ende skabe problemer hvis der er problemer med forbindelsen og der derfor ikke bliver forbundet til den valgte channel, dette vil tage plads på mobilenheden, dette vil ikke skabe bruge plads på mobilenheden som har begrænset mængde af plads. Samtidig er der ingen kritisk data der bliver sendt i dette program så der er intet grundlag for at bruge dette pattern for at sikre at beskederne kommer igennem. 27

28 Dette Projekt I dette projekt vil Point-to-Point blive brugt til at skabe channels til de forskellige devices som der skal kommunikere med musikafspilleren, dette vil blive sørge for at mobilenheden kan kommunikere med musikafspilleren, dette vil dog kræve at der kan tilføjes forskellige channels til hver enhed, på grund af dette skal musikafspilleren kunne indtage en dynamisk mængde af channels til at kommunikere med. I dette diagram kan man se et eksempel på et Message pattern som går fra et android device til et vilkårligt styresystem, i dette projekts tilfælde C#, dette gør den ved at bruge channels til at sende en besked til en message translator som kan oversætte det den får fra android programmet til noget der kan læses af C# programmet, hvorefter at denne message translator vil sende den nu oversatte besked videre til C# programmet, hvorefter den vil blive bearbejdet af C# for at give det ønsket resultat. Tidsplan I dette projekt blev der også lavet en tidsplan for at få en nogenlunde ide om hvornår de forskellige features skulle være færdigt, der har været mange ændringer i tidsplanen, hver uge blev der taget stilling til om der var nogle features der tog længere tid end planlagt, og der blev så taget stilling til om hvad der skulle gøres i tidsplanen for at gøre plads til de vigtigste features. På grund af dette ændrede tidsplanen sig meget under forløbet, og i tidsperioden hvor der skulle laves normalisering blev der brugt mere tid end planlagt, på grund af dette blev tidsplanen flyttet meget rundt på. Denne tidsplan er ikke lavet for at være helt præcis, den viser kun de generelle ting der skal laves i diverse periode, et eksempel på dette ville være at når der står i tidsplanen at der skal arbejdes på rapporten, så er der ikke skrevet ned hvad i rapporten der skal skrives, og der er heller ikke skrevet ned hvor meget i rapporten der skal laves, der er blevet lavet denne løse tidsplan for nemmere at kunne lave et dynamisk udviklingsforløb, hvor når en ting er færdig kan der sættes i gang med den næste ting uden at ændre på tidsplanen. Nogle features som var vigtige for dette forløb fik dog et sted i tidsplanen, eftersom den akademiske artikel og normaliseringen var et krav for dette produkt, var det vigtigt at få skrevet den artikel, og få programmeret den feature, og derfor blev der planlagt en periode før dette hvor der står i tidsplanen at applikationen skulle være klar til at implementere denne normaliserings løsning. Dette gav en tidsbegrænsning til all features der var påkrævet af normaliserings løsningen. Derefter var der også lavet plads i tidsplanen specifikt til at skrive denne normaliserings løsning, denne periode startede med at være meget kortere, det endte dog med at den periode måtte udvides en stor del, da der kom problemer da løsningen skulle implementeres. På tidsplanen i hver uge er der også en opgave der hedder ret tidsplan, dette er for at tage stilling til om alt som skulle laves i sidste uge var blevet nået, og om der skulle flyttes rundt på nogle ting, det blev samtidig også brugt til at finde ud af hvad der var blevet lavet, og hvad der skulle laves derefter. 28

29 Tidsplanen kan ses på bilag 2 Hvorfor v2 af youtube api i stedet for v3 I dette projekt skal der bruges youtube for at kunne hente youtube links og afspille dem, for at gøre dette skal der bruges en youtube API, i dette projekt er der blevet kigget på både v2 og v3 af youtube api en[1]. Til dette projekt er der blevet valgt at bruge v2 af api en, dette skyldes at dokumentationen omkring v3 ikke er god, og det er svært at finde hjælp til denne version af api en, da dette er den første gang programmøren skal arbejde med denne api er der værdi i at bruge den version der har den bedre dokumentation, og den bedre hjælp, i dette tilfælde er det v2 af youtube api en. Dette kan dog skabe problemer i fremtiden hvis google vælger at opdatere youtube til et punkt hvor v2 af denne api ikke længere er understøttet, dette kan også gøre at der måske mangler nogle funktioner som der er blevet implementeret i v3. Det virker dog til at v2 af api en udfylder alle de krav som dette projekt har til den, og der vil derfor bliver valgt at bruge v2, da der er mere dokumentation, og den kan udfylde de forskellige krav som produktet stiller. Normalisering I dette program skal der være mulighed for at normalisere sange, for at gøre dette skal der tages en beslutning om hvordan det skal gøres, der er nogle forskellige valgmuligheder som alle har nogle fordele og ulemper. I det følgende afsnit vil der blive snakket om de forskellige muligheder for normalisering, samt hvilke valgmuligheder der er blevet valgt til dette projekt. Metoder for normalisering Den første valgmulighed ville være at normalisere hele afspilningslisten ud efter en udvalgt sang. Dette vil dog skabe nogle problemer. Det første problem ville være at dette ville tage meget plads på computeren, dog er der i dag ikke store problemer med pladsmangel på computere, men dette ville hurtigt kunne bruge flere gigabit, da det er relativt simpelt at have en musiksamling på flere gigabytes, og hvis der skulle normaliseres en afspilningsliste der indeholdt en hel musik indsamling så ville dette fylde lige så meget som musiksamlingen. Hvis der samtidig bliver konverteret til wav filer for at normaliseres, så vil de lokale musikfiler måske fylde mere end den originale musiksamling, da wav filer ikke er komprimeret som mp3 filer er. Dog er dette kun relevant hvis der Det næste problem ville være at der ville være en lang liste af sange der skal normaliseres før de kan afspilles fra den lokale, normaliseret kopi, på grund af dette skal der holdes styr på hvilke sange der er normaliseret, og hvilke sange der ikke er normaliseret endnu, så hvis brugeren skifter sang, så skal der være mulighed for at afspille den sang før den er blevet normaliseret. Den anden valgmulighed er at ændre brugerens egen lydfiler, dette skaber dog et dilemma hvor brugerens egne lydfiler bliver ændret, dog ville dette skabe utryghed hos brugeren da der når filerne er blevet ændret kan de ikke bare ændres tilbage. 29

30 Denne metode vil stadig have problemet med at det vil tage tid at normalisere en hel afspilningsliste, og på grund af dette så vil der være mulighed for at en sang ikke er normaliseret når der bliver skiftet til dem. Dog ville dette kun kunne ske hvis normaliseringen køre simultant med musikken, hvis ikke, så ville denne metode dog bruge en del tid der er baseret på hvor mange sange der skal normaliseres, så hvis afspilningslisten er langs, så vil det noget tid at normalisere hele afspilningslisten, og det er derfor en bedre løsning at få den til at normalisere samtidig med at den afspiller musik, hvor der dog skal være noget check på at der ikke kan normaliseres den sang der bliver afspillet, da dette vil skabe fejl ved at prøve at ændre en fil mens den bliver brugt af en anden metode. Den tredje valgmulighed er at have en tre lokale filer, en til den forrige sang, en til den næste sang, og en til den nuværende sang. Denne metode vil bruge parallelprogrammering til altid at normalisere den næste sang, hvor den vil bruge den forrige sang som den sang den skal normalisere efter, på denne måde vil den næste sang være klar når musikafspilleren skifter sang, og hvis brugeren gerne vil høre den forrige sang, så vil den også være gemt. Dette gør at to af de almene sangskift metoder bliver dækket ind, altså forrige og næste sang. På denne måde skal der bruges mere ydeevne generelt da der konstant skal normaliseres, dog vil den næste sang være klar til at blive afspillet når den skal afspilles, denne løsning har den fordel at når der skal normaliseres så kan de lokale filer gemmes i wav formatet, der behøver derfor ikke at laves noget encoding af mp3 filer efter normaliseringen har taget sted. Denne metode kommer dog ikke fejlfri. En ulempe ved denne metode er at den på ingen måde understøtter at skifte til en sang som ikke er den næste eller forrige da den kun har gemt en lokal kopi af en normaliseret udgave af den nuværende, den næste og den forrige sang. Konklusion i dette projekt er der blevet valgt at bruge løsning 3 hvor det kun er den næste og forrige sang der skal normaliseres på, dette er blevet valgt for at undgå at tage for meget plads på brugerens computer, og samtidig sørge for at de originale filer stadig forbliver de samme. Hvordan skal det gøres? Da der skulle programmeres en metode til at lave normalisering efter at begge filer blev konverteret til pcm værdier skulle der stadig tages stilling til hvilken metode der ville bruges til at normalisere data værdierne, til at gøre dette kunne der bruges følgende løsninger: Der kunne søges efter den største værdi i hvert datasæt, derefter ville man kunne regne den procentmæssige forskel på disse to værdier ud. Når man kender den procentmæssige forskel mellem de to højeste punkter ville det derefter være muligt at reducere den højeste sangs dataset med den procent værdi, den procent værdig skal dog bruges på hele datasættet, da hvis den kun bliver brugt på den værdier der er højere end den højeste værdi i den første sang vil man skabe problemer med at sange vil kunne komme til at lyde betydeligt dårligere det er derfor vigtigt at hele datasættet bliver påvirket. hvis man bruger denne metode til at lave normaliseringen med vil alle sange blive skruet op, dette har nogle fordele og ulemper, dog er nogle af disse fordele og ulemper kun i ekstreme situationer og vil derfor oftest ikke betyde noget. 30

31 ulempen ved at forøge sang volumen er at hvis en bliver forøget for meget vil den blive forvrænget, dog er dette kun hvis der sker en stor forøgelse i sang niveauet, da den procent som datasættet skal forøges med for at skabe sådan et problem vil være så stort, så ville dette problem oftest ikke ske. den næste mulighed ville være at gå efter den laveste værdi i datasættet, dette ville skabe stort set samme normaliseringsprocess bare at i stedet for at gå efter de højeste værdier og normalisere ud fra dem, så skal der tages de laveste værdier og normaliseres ud fra dem. ulempen ved dette er at hvis en sang har en outro eller en intro der starter meget lavt, så vil dette skaber problemer overfor sange der ikke har en intro eller en outro der starter lavt, da de sange som har en intro eller en outro ofte vil have meget lave værdier i starten og i slutninge, så ville det ofte være disse værdier der ville blive sammenlignet efter, og det ville gøre sange uden intro eller outro meget lave, selv i forhold til andre sange, dette er et problem som godt ville kunne opstå i afspilningslister, og ville derfor være et reelt problem. den næste mulighed ville være at gå efter et gennemsnitligt tal, hvor man ville tage alle værdier i datasættet og regne gennemsnittet ud, hvorefter der vil blive sammenlignet med en anden lydfils datasæts gennemsnit, dette ville kunne sørge for at alle sange har det samme gennemsnit, dog har dette ligesom de andre metoder at gøre dette på, også en negativ side. Ulempen ved dette ville være at hvis en sang har en lang intro og outro som begge er lave, vil dette få sangens gennemsnit til at være meget lavt, selv hvis sangen ellers er middelmådig i lydstyrke, dette vil betyde at sange der bliver sammenlignet med denne sang vil blive reduceret meget i styrke, eller den sang som har et meget lavt gennemsnit vil blive forøget meget i styrke, dette ville kunne forårsage forringelse i sangens lydkvalitet da den procent den skal forøges med ville kunne være overraskende høj, samtidig hvis sange blev reduceret til denne sangs niveau, så ville alle sange blive utroligt lave i forhold til denne sang, da den eneste grund til at denne sang har et lavt gennemsnit er på grund af en outro og intro, som begge kunne være meget lave, og lange. Der ville samtidig også være en ulempe hvis nogle sange har nogle høje lyde i perioder i sangen, så ville dette øge gennemsnittet på denne sang, og det ville forårsage at selve sangen ville lyde lav i forhold til andre sange, ud over på selve de høje lyde. Konklusion på grundlag af disse forskellige løsninger og de overvejelser der er blevet lavet omkring dem, så er der blevet valgt at lave en normalisering der bygges på den højeste lyd i sangen, selvom dette har problemer hvis sange har høje øjeblikke i sangen, der er blevet valgt denne løsning da mange sange har outro og intro, og derfor vil det problem opstå meget oftere end hvis der bliver normaliseret efter den højeste værdi. Denne løsning er også blevet valgt for at skabe et maksimalt lydniveau på sange da dette vil blive skabt naturligt ved at normalisere efter den højeste lyd i en sang, dette vil sørge for at selv hvis en sang har et øjeblik hvor den har meget høje lyde i en forholdsvis lav sang, så vil dette stadig ikke skabe problemer, da sangen er normaliseret efter den høje lyd, og ikke resten af den forholdsvise lave sang. 31

32 Asynkron design Når normaliseringen skal programmeres så skal der tages stilling til om der skal laves parallelprogrammering over normaliseringen, hvis der ikke bliver lavet parallelprogrammering på dette så vil der være en pause mellem hver sang i noget tid for at normalisere sange. Dog ville dette give en nemmere implementering, og derfor kortere udviklingstid. Hvis der bliver lavet parallelprogrammering vil der være en længere udviklingsperiode, dog vil dette reducere den tid brugeren skal vente på normaliseringen eftersom det eneste brugeren skal vente på i dette tilfælde er at en ny tråd bliver startet hvorefter at tråden vil fortsætte mens den næste sang køre, dette vil sørge for at brugeren får en bedre oplevelse med programmet. På grund af kravene til projektet og rapporten fra skolens side skal der udnyttes så meget fra de fag der er blevet undervist i som muligt, og i faget Development of large scale systems var der undervisning i asynchronous design i lektion 11. Dette er konceptet bag parallelprogrammering. I development of large scale systems bliver asynkront design brugt til at lave store systemer, det kan dog også bruges i små systemer til at reducere eller fjerne ventetid på visse funktioner. På grundlag af dette er der blevet valgt at lave parallelprogrammering på denne funktion, og det vil derfor udvide udviklings tiden lidt, dog vil brugeroplevelsen bliver bedre. Selvom kravene til dette projekt sørger for at dette altid ville blive valgt, så ville dette produkt stadig have valgt at lave asynkront design. Dette ville blive valgt da dette produkt er lavet til at afspille musik, og hvis et musikprogram skal holde pause for at så ville en musikafspiller miste meget kvalitet da musikafspilning er hovedfunktionen i programmet, og hvis den funktion ikke virker som ønsket så vil programmet ikke gøre sin basiske funktion. AKADEMISK ARTIKEL I sammenhæng med denne rapport er der også blevet skrevet en akademisk artikel, denne artikel vil beskrive hvordan der bliver lavet normalisering I dette project, den vil samtidig beskrive teoretisk hvordan en normalisering mellem wav filer og mp3 filer teoretisk kan laves. da denne akademiske artikel er blevet skrevet I sammenhæng med dette project vil den akademiske artikel blive presenteret i dette afsnit. 32

33 Normalization in wav and mp3 Michael Frøstrup Andersen Business bachelor in software development UCN Aalborg, Denmark Abstract with all the different volumes of sound files how can they all be normalized to create a more uniform experience, and how is it possible to normalize between different file types? The solution is to work with the data of a file type until a point is reached where the different files can be compared, and then it can be normalized. the header contain important information, and these values are the audio format, bits per sample and the sample rate. The audio format shows if the data has been compressed in any way, if the value is 1, then it is a linear quantization, if it is any other value, then it is compressed in some way, and in that Introduction When working with music files there is often a difference in volume in each sound file, because of that there is often going to be either a change in volume between each sound, or some sounds are going to be harder to hear than others. To battle this, normalization can be made on the sound files, this can be done at a low level, by changing the file itself instead of changing the output, this will cause the sound files to have the same volume on all the different sound systems, instead of just one. This article will describe some of the needed fields in the different files that need to be considered before changing the volume on either file type. The article will also talk about what needs to be done before it is possible to change volume. In the end, this article will also explain what the project, which was written in conjunction with this report, will do to normalize songs within the program. Wav file format The wav file format is one of the simpler file formats that is commonly used for windows computers[1], and the wav file type also has a dataset of pcm values, which is the values that are used when normalizing different audio files, other files will have to be converted to pcm values, and then converted back into their original state, but this is something the wav file does not have to do because it uses pcm values in the dataset, which is why this article will include it. The wav file format consists of a header and a data section, for this article there is an interest in only the necessary values to change the volume of the file. An example of the structure of a wav file type can be seen on figure 1, because all wav files always have these values in the header, and they are always the same size which can also be seen in figure 1, this will add up to a total of 44 bytes in before the data will start. But to change the volume not only is the data needed, some values in Figure 1 [2] case the data needs to be decompressed first. The audio format value is there to show how many hertz the data is used with, because this can be different from file to file. This means that some sound files can play at a higher hertz level than other, and when comparing different sound files it is important to have the same audio format, if not then the data will not be comparable. In the case there needs to be a normalization on 33

34 files with different audio formats, they have to be converted to match. The last one is bits per sample which shows if it was an 8bit recording or a 16bit recording, this is important because when comparing different sound files this is used to generate a comparable pcm value. These 3 values are the important values in the header, because all the values in the header all have a predefined size all of the data is easily accessible, the precise byte to find the data is 44 bytes into the file, as can be seen on figure 1. To further increase compression, the 15 tables are paired with another parameter for a total of 29 different ways each of the three regions can be compressed. The side information contains MP3 file format The mp3 file format is one of the most used sound formats today[1], it is used to store most songs, because the format is used in many song, and is a very common sound file it is a great feature to normalize the sound files between each other, but to be able to do this, some understanding of mp3 files is needed to normalize them. The mp3 format is more complex than the wav format, the mp3 format consists of a header, side information, data and finally ancillary data, for each frame in the mp3 file, the header takes 4 bytes of data, the side information takes 17 bytes if it describes a single channel bit stream, if it does not describe a single channel bit stream it will be 32 bytes of side information and the data is variable. To get the audio data needed to change the audio volume on the sound file on the mp3 format a few more variables compared to the wav format is needed. One of the reasons that the mp3 format needs additional information compared to the wav format is because the mp3 is compressed using Huffman coding[3], because of this the data must be decoded before it is changed. Before trying to decode an mp3 file there needs to be an understanding what is being decoded, each frame in a mp3 file consists of up to four chunks, two for each channel, each of these chunks contain up to 576 frequency samples. When working with a hertz audio signal, the first frequency sample represents frequencies at around 0 hertz, while the last sample represents hertz around Each of these samples is made of five different regions that have variable length. The regions are best described as the following quote: These samples are divided into five different regions of variable length. The first three regions are known as the big values regions, the fourth region is known as the count1 region (or quad region), and the fifth is known as the zero region. The samples in the zero region are all zero, so these are not actually Huffman coded. If the big values regions and the quad region decode to 400 samples, the remaining 176 are simply padded with 0. [5], these big value regions are the important lower frequencies in the audio, and when it is done decoding it will contain a value between and These 3 values are coded with three different Huffman tables[3], which are defined in the MP3 standard[6] The tables are designed to compress the typical content of the frequency regions as much as possible. Figur 2 [7] 34

35 information which of the 29 possibilities to use. Somewhat confusingly, the standard calls these possibilities tables. We will call them table pairs instead. [5]. While this is the basic structure of the mp3 file, which can also be seen in figure, an mp3 file can also contain an ID3 tag, and ID3 tag is a 128 byte tag that is at the end of the file, this is used to store text information. This text information consists of TAG which symbolizes if the ID3 tag is there or not, then title, artist, album, year, comment, track and genre. Re-quantization Quantization is simply the approximation of a large range of values with a smaller set of values i.e. using fewer bits. For example if you take an analog audio signal and sample it at discrete intervals of time you get a discrete signal a list of samples. As the analog signal is continuous, these samples will be real values. If we quantize the samples, say approximate each real valued sample with an integer between and , we end up with a digital signal discrete in both dimensions. Quantization can be used as a form of lossy compression. For 16 bit PCM each sample in the signal can take on one of 2 16 values. If we instead approximate each sample in the range to , we lose information but save 1 bit per sample. The difference between the original value and the quantized value is known as the quantization error, and this results in noise. The difference between a real valued sample and a 16-bit sample is so small it s inaudible for most purposes, but if we remove too much information from the sample, the difference between the original will soon be audible. [1] I. Re-quantization in MP3 When the mp3 file has been decoded by the Huffman[3] and the file is ready to being worked with, there has to be made some re-quantization to make comparable values to the data in the wav file format. The MP3 encoder uses a non-linear quantizer, meaning the difference between consecutive requantized values is not constant. This is because low amplitude signals are more sensitive to noise, and thus require more bits than stronger signals [5] the first thing that has to be done is raise all samples by ¾, the purpose of this is to make the signal-to-noise ratio more consistent after that all the 576 samples are then scaled by a quantity found in the, some frequency regions however are partitioned into several scale factor bands which is further scaled individually, this is what the scale factor value in the MP3 file is for. Each chunk in the MP3 file can be scaled in three different ways, the first one is called a long, in which case the 576 frequencies will have to be scaled by the global gain and the 21 scale factors. Another type of chunk is the short chunk where the 576 frequencies are really three interleaved sets of 192 frequency samples. In this case instead of being scaled by the 21 scale factors, it is instead scaled with a set of three numbers from the subblock_gain value[5] The third type of chunk is a mix of the two other chunk types. When each of these samples have been multiplied with the corresponding scaling factors the number that is left is a value between -1 and 1. I. Normalizing MP3 and Wav After the MP3 have been re-quantized to that degree, it can almost be compared to the data taken from a wav file, the only difference is if the wav file is an 8 bit recording the samples from the wav file needs to be scaled a quantity of 255 or if it is a 16 bit recording the scaled quantity of 32767, this make the wav data have a value between -1 and 1 which is comparable to the mp3 file, at this point all that needs to be done is to make sure that the highest and lowest values lies as close to each other as desired, which is up to the normalization. When the normalization is done, both the wav file and the mp3 file s data sections has to be turned into a normal data section for each separate file, to do this for wav files all that needs to be done is to reverse the scaling done just before comparing it to the mp3 file, after that is done, the wav file just needs the correct header, and then it can be saved. The mp3 on the other hand needs quite a lot more work, since all of the mp3 first needs to be quantitated again, after the data have been quantitated again, it still needs to be encoded with one of the 23 Huffman tables that can be found in the specification[6]. When the data has been encoded again the side information needs to be updated to match the new data since it now may need a new Huffman table to decode it. I. How it can be done So far the theory about decoding and encoding an mp3 file has been explained, there is also the question in how did the author do it, in the case of the project that was writing in conjunction with this academic article a solution was made. This solution was not simply doing what has been explained in the theory above, instead the project converts the mp3 files into wav files and then compares the raw data files of the wav files together to normalize them, this is done due to the fact that to gain access to the different Huffman tables used to encode and decode the mp3 files, the user needs to be able to access the standard[6]. The standard[6] is not easily accessible, and because of this, while writing the project that was made in conjunction with this article, access to the standard[6] was not there. To avoid this problem a different measurement was taken, since there has been made many different programs that can play and even convert mp3 files, very few of them can give the output of data that is needed to do the normalization as described earlier in this article. Many of these programs have 35

36 the possibility of turning mp3 files into wav files, and this is what the project used to normalize with. The project simply converts mp3 files into wav files, when this is done the program will have access to the wav file that was just converted. This wav file contains a data set of pcm values, these values are the values that decide how loud the music is, so to increase or decrease the volume, these values has to be either decreased or increased, to do this the program loads two wav files and finds their highest pcm values. When these values are found, the difference between them is calculated in percentage. When the percentage is found all the pcm values in the wav file that needs to be changed will be either increased, if it was louder than the none changing wav file, or decreased, if it was more quiet than the none changing wav file, by the percentage that was calculated earlier, after this is done, the files are saved with the correct headers and then both wav files have the same maximum value in the data set. Because of the way this is made, there is no encoding of mp3 files, as all the program does is decode the mp3 with the help of other programs to get the raw data, and then that data is saved in a wav file. Even though this is the way it has been chosen to be done, this method still has some cons and pros. One of the cons of doing it this way is the fact that the files are saved as wav files, which takes up more space than the mp3 files due to the compression of the mp3 files. This method will have the pro that when coding the solution, doing a one way conversion is faster to make, and easier to handle. References [1] januar 2015 [2] mat/ December 2014 [3] januar 2015 [4] januar 2015 [5] januar 2015 [6] ISO/IEC Coding of moving pictures and associated audio for digital storage media at up to about 1,5 Mbit/s Part 3 [7] tech.org/programmer/docs/mp3_theory.pdf januar 2015 januar 2015 [8] b97/$file/Thesis%20report- %20MP3%20Decoder.pdf januar 2015 II. Conclusion While it is possible to change both wav files and mp3 files, when trying to normalize them with each other, a lot of work has to be done. The mp3 files have to be decoded, and a calculation is needed to get the pcm values that are required to compare for the normalization, which can be done by using the theory in this article. If comparing files of the same type it is an easier task to normalize them since there needs to be less calculation, by taking either only wav files or mp3 files, the normalization can be made instead of the re-quantization for the mp3 files, and for the wav files the normalization can be made from the data directly extracted from the wav files data section. Because the mp3 standard[6] is not easily accessible another solution is integrating other programs in the decoder to decode the mp3 files, while these programs do exists, most of them are made to play music files, so while they can play them they are not made to be used for normalization, so in that case the program needs to be reverse engineered to find the solution that is needed to compare the sound files. While these programs might not be able to easily give the data values in a comparable form, some of the programs do have methods that can convert from mp3 to wav, in which case the normalization process is easy, as explained earlier in this article under the how it can be done section. 36

37 Test: Introduktion For at holde styr på hvilke tests der bliver lavet, og for at sikre sig at der bliver lavet tests på programmet blev der under forløbet arbejdet på en testplan der ville beskrive de tests der skulle laves til de features der blev sat i gang. Dette skabte denne testplan som indeholder en kort beskrivelse af de forskellige tests der er og bliver lavet under forløbet. Resourcer De forskellige tests i dette projekt har nogle forskellige resourcer som der skal bruges når der skal testes. For at teste mulighederne omkring youtube videoer skal der være en forbindelse til internettet.. Til alle testene skal der være adgang til en comuter med programmet på for at kunne teste det. For at testeplay/pause i usertests skal der Hvad skal testes? De følgende funktioner bliver testet via unit tests: ChangeVolume, denne metode skal testes for at være sikker på at det er muligt at skifte lydnivaeu på programmet, dette skal testes med boundry tests og en normal test for at teste om funktionen virker normalt. Getduration, der skal testes muligheden for at få længden af en sang, både som en string, og som en double. Removesong, denne metode skal testes for at sikre sig at det er muligt at fjerne sange fra afspilningslisten. Dette skal testes med en valid test, og en test hvor der ikke er nogen sang valgt. Getyoutubevideo, denne metode skal testes for at være sikker på at det er muligt at hente youtube videoer og tilføje dem til afspilningslisten. Dette skal testes med både valide og invalide links. Addsong, det skal være muligt at tilføje sange til afspilningslisten, og der skal testes hvis sangen ikke er en ordentlig sang. Dette skal testes ved både at teste youtube link, med et validt link, men også med et validt filtype og en ikke valid filtype. Normaliseringen, for at teste normaliseringen skal der testes om det er muligt at skrue op og ned for en sang, der skal samtidig testes hvis filen ikke findes. Dette skal testes ved at teste når der bliver skruet op for lyden, ned for lyden, og når der er en invalid filsti. De følgende features skal testes manuelt da der problemer med at skabe denne unittest på grund af shockwaveflash elementet. På grund af dette er der blevet valgt at de skal testes ved ad hoc tests: 37

38 Play/pause, denne metode skal testes for at være sikker på at programmet kan pauses, og kan startes igen, selv når det er youtube videoer, eller normale sange. Next/prev song, denne metode skal testes for at sikre at det er muligt at skifte sang på alle tidspunkter, både når den næste sang er en youtube sang eller en audio fil. Changsong, denne metode skal testes for at sikre sig at det er muligt at skifte sang Hvad bliver ikke testet? Change mp3 to wav bliver ikke testet, denne metode bliver brugt i de andre tests når der bliver brugt mp3 filer, men der bliver også gået ud fra at de metoder er testet fra Naudios side. Risks Hvis en test fejler skal der findes en løsning for at få den til at være rigtig, dette vil koste projektet tid på grund af fejlfinding. Schedule Tidsplanen for testing følger testing for hele forløbet, hvor ingen feature er færdig før den er blevet testet, og på grund af dette vil der ikke blive skrevet en tidsplan til testplanen, dog skulle der i slutningen af projektet blive planlagt acceptance tests for at teste om programmet nåede de krav der var stillet op, dog nåede projektet ikke langt nok til at opstille en acceptance test. Udgivelses kriterier For at programmet kan blive udgivet skal alle test kunne blive udført med det korrekte resultat. Der skal samtidig gennemføres acceptance test på programmet inden sidste udgivelse 38

39 Hvorfor nåede projektet ikke det der var forventet? projektet havde mange planer, dog dette projekt ikke alle disse planer. Der var problemer da der skulle laves normalisering, da dette var ny viden, var det svært for programmøren at estimere, på grund af dette blev der sat for lidt tid af til den feature. Det tog meget længere tid end forventet af flere årsager, for det første var det svære at få forståelse inden for emnet da mp3 filer var meget svære at forstå i forhold til hvad der var forventet. Et andet problem der opstod var da der skulle laves huffman coding på mp3 filer for at afkode mp3 filer så skulle der bruges nogle bestemte huffman tables, og disse tables var ikke frit tilgængelige, dette blev der søgt efter i længere tid end forventet, da de fleste dokumenter der snakker om mp3 filer referere til standarden, og for at få adgang til den standard skulle der betales flere penge end der til dette produkt var til rådighed, så for at prøve at undgå standarden, så blev der udforsket nogle gratis programmer som kunne konvertere mp3 filer til wav filer, så der blev brugt meget tid på at prøve at se hvordan de programmer virker, da nogle af disse programmer kom med source code, dog gav dette ikke nogle resultater der kunne bruges til at afkode de mp3 filer til et punkt hvor der var mulighed for at normalisere dem. Dog under dette blev der fundet et program der hedder Naudio[2], som kunne konvertere mp3 filer til wav filer, men der blev ikke fundet en måde på at udnytte disse metoder til at convertere mp3 filer til pcm værdier, og derefter encode dem til mp3 filer igen,. Da tiden var løbet ud og der skulle laves resultater hurtigst muligt blev der lavet en anden løsning på normaliserings problemet, dette forløb kostede dog meget mere tid end forventet, og der blev derfor ikke nået alle de features som der var ønsket. De forskellige features der blev skåret væk fra produktet i denne release var blandt andet app funktionen hvor det skulle være muligt at sende en sang til afspilleren fra en mobil enhed og få programmet til at sætte den i kø, denne funktion blev skåret væk på grund af tidsmangel. Dette var den største feature der blev skåret væk på grund af denne tidsbegrænsning og de problemer der blev forårsaget af normaliseringen og de problemer der var omkring det. Der blev også skåret nogle af de små features som ikke var nær så vigtige, men som dog stadig ville være rare at have for brugeren, disse features includere følgende: Selve programmet: 1. seek bar, at kunne spole i sangen. 2. flytte elementer i afspilningslisten, så brugeren selv kan lave en orden som sangende skal afspilles i. 3. mulighed for at drag n drop filer fra computeren ind i programmet 4. en mulighed for at lave tilfældig afspilningsliste. 5. en mulighed for at slå gentagne afspilningsliste fra/til 6. mulighed for at sortere afspilningslister efter div. krav, såsom alfabetisk Appen: til appen mangler selve appen, men selve appen havde nogle mindre funktioner som også er blevet skåret væk på grund af tidsmangel. 1. mulighed for at sende et sangnavn til programmet på computeren for at sætte den i kø 2. mulighed for at sende et youtube link til programmet for at sætte den i kø 3. mulighed for at sende lydfiler fra mobil til computer og sætte dem i kø 39

40 Hvad var planen med det der ikke blev nået planen med mobil applikationen var at det skulle være muligt at sætte sange i kø med en mobil, på denne måde skulle man ikke op til computeren for at sætte en sang i kø. Planen med dette var lavet til fest brug hvor flere personer gerne ville sætte sange i kø, men det vil normalt skabe en gruppe folk som står ved computeren for at skifte sang når den nuværende sang slutter, da der normalt ikke er en mulighed for at sætte en sang i kø, på denne måde vil der altid kun være en person der kan sætte en sang i kø af gangen. Det appen skulle gøre ville være at det var muligt for personer at sætte sange i kø, uden at skulle gå hen til computeren, planen var at computer applikationen skulle kunne sætte flere sange i kø efter hinanden, på den måde ville den ende med at skabe en række sange som folk har bedt om at få i kø. Planen med denne app var at den skulle bruge faget messaging systems som der blev undervist i under undervisningsforløbet, for at gøre det som denne app skulle ville den bruge et messaging system til at kommunikere imellem en app og en computer app, da messaging systems kunne bruges imellem forskellige programmer var det meningen at mobil applikationen skulle være kodet i java, dette var blevet valgt for at sørge for at der ville blive brugt mere fra faget messaging systems, i dette tilfælde ville der blive brugt lektionerne 6 til 12, hvori der bliver beskrevet om messaging systemer, og der bliver samtidig beskrevet hvordan nogle programmer kan snakke imellem hinanden ved hjælp af messaging systems. Planen var også at der skulle bruges SOA til dette, da SOA er lavet til at være et event drevet system ville det passe godt til den måde som disse to programmer skulle virker på. Ved at udnytte SOA ville ingen af programmerne være afhængige af hinanden, og der ville i stedet for kun ske kommunikation mellem de to programmer når det var nødvendigt. Dette ville skabe et design hvor hver del af programmet skulle være uafhængige af hinanden, dog ville mobil appen ikke have en ordentlig funktion der ville være brugbar. Dette kan også ses i program strukturen i rapporten da der var blevet taget stilling til hvordan denne del af produktet skulle virke. Dette var planen med mobil applikationen, selv om den var langt den største feature som blev skåret væk, så var der stadig planer med de mindre funktioner, der var især lagt tanker bag de funktioner og features som ville kunne påvirke youtube videoer, da youtube api en er meget begrænset i hvad der er muligt med den eller ej, så skulle der laves nogle overvejelser om hvordan disse funktioner skulle laves og hvordan de teoretisk kunne laves i programmet hvor det både ville virke på de normale lydfiler og samtidig youtube videoen. Den første lille funktion var seek bar, denne funktion var virkede relativt nemt at implementere på de normale lydfiler, dog for at få den til at virke på youtube links skulle der laves noget lidt mere specielt. For at gøre dette ved en youtube video skal der regnes ud hvor mange % ind i sangen der skal spoles, eftersom man kender længden på sangen ville dette være meget muligt, dog er det ikke muligt at skifte tidspunkt i en youtube video mens den er loaded, og på grund af dette kan der ikke laves en seek bar på en nem måde i stedet for skal youtube videon loades igen men den skal denne gang starte på det tidspunkt som er blevet bestemt af seek baren, dette kræver lidt loading tid, og der skal derfor tages stilling til dette på grund af den måde som playlisten er blevet lavet på i dette program fordi den skal lave en afspilningsliste af både youtube videoer og normale musikfiler skal der ændres på hvor lang tid der er tilbage. Konceptet bag dette bliver også brugt i den metode der pauser youtube videoer. 40

41 Den feature der skulle tillade brugeren at flytte rundt på elementer i afspilningslisten blev også skåret væk, planen med denne feature var at tillade brugeren selv at opsætte en bestemt rækkefølge og ændre i den imens afspilningslisten bliver brugt. Denne feature virker nem at programmere, det eneste problem ved denne metode bliver skabt på grund af normalisering, dette problem bliver skabt fordi under normaliseringen er der blevet valgt kun at normalisere den forrige, den næste og den nuværende sang, og hvis der bliver flyttet rundt på sange, så skal der tages stilling til dette i denne metode. En måde at få dette til at virke ville være at hver gang en sang bliver flyttet rundt på skal der laves et check for at se om det er den næste, nuværende eller forrige sang til den der bliver afspillet, og hvis det er en af dem, så skal der laves noget nyt normalisering. Dog ville der opstå et problem hvis disse sange blev flyttet på i sidste øjeblik og der ikke var nok tid til at normalisere, hvis dette skete skulle programmet selv kunne finde ud af bare at afspille den næste sang uden at normalisere den. Hvis det bliver gjort på denne måde vil der ikke være en pause mellem sange, og for brugeren vil der være en flydende afspilning af sangene. den næste feature der blev fjernet på grund af mangel af tid var muligheden for at lave tilfældig afspilning, planen med dette var at lave at afspilningslisten ikke bare gik fra toppen og ned, men i stedet for skiftede til en tilfældig sang når en sang sluttede, denne feature blev planlagt da der er mange musikafspillere der har denne feature, og det virker til at være en god og solid feature at have i en musik afspiller, for at få denne funktion til at virke ville der skulle ændres lidt på programmet på grund af den måde normaliseringen virker på. Da normaliseringen kun normalisere nogle begrænset sange baseret på hvilken sang der bliver afspillet vil dette skabe lidt problemer med tilfældig afspilning, dette kunne løses på to forskellige måder, som der dog ikke er blevet taget stilling til endnu, den ene metode ville være at shuffle afspilningslisten så når musikafspilleren spiller sangene igennem så vil de komme i en tilfældig rækkefølge på grund af at de er blevet shuffled. Den anden metode ville være at ændre lidt i programmet, så når der bliver afspillet en sang, så finder den ud af med det samme hvilken sang der skal være den næste, og sender den information videre til normaliseringsprocessen. Den næst feature var at det skulle være muligt at slå gentagne afspilningsliste fra eller til, programmet blev lavet til at afspille afspilningslisten igen hvis den nåede slutningen, dog er dette ikke altid ønsket og det ville derfor være godt hvis denne feature blev implementeret, dog er det ikke en stor eller vigtig feature. Dette skulle gøres ved at når slutningen af afspilningslisten bliver nået skulle der laves et check for at se om afspilningslisten skulle gentages eller ej, hvis ja, så skal den bare starte forfra, hvis nej, så skulle den bare stoppe med at afspille der. Det eneste tidspunkt dette ville skabe problemer på ville være hvis man implementerede den tilfældige afspilning af afspilningslisten, uden at ændre på selve listen, da dette ville forårsage at der skal holdes styr på visse numre der er blevet afspillet og hvilke numre der ikke er, og til dette ville der skulle laves en løsning. Den sidste feature der blev fjernet på grund af mangel af tid var muligheden for at vælge nogle sorterings metoder til afspilningslisten, om det så skulle være alfabetisk eller om det skulle være baseret på længde. Disse to sorteringskriterier er bare eksempler og der kunne godt laves andre, end dem. Det eneste dette ville kræve var at programmet skulle have lavet disse metoder til at ændre på selve afspilningslisten, dog skal dette kunne gøres imens at sangen bliver afspillet i listen, og på grund af dette vil der måske godt kunne ske lidt uforudsete ting hvis der skal skiftes sang mens listen bliver sorteret, dog er dette bare noget der skulle laves tests for at sikre sig at der ikke gik noget galt, og at alt virker flydende for brugeren. 41

42 Samtidig vil dette også kunne lave nogle problemer med normalisering, på grund af den måde normaliseringen bliver lavet på vil den skabe problemer hvis afspilningslisten bliver ændret som bliver beskrevet tidligere i dette afsnit. 42

43 Konclusion I dette projekt blev der sat nogle mål op, desværre under dette forløb blev disse mål ikke nået, der blev lavet en applikation som kunne afspille både musik filer og youtube videoer, der blev lavet en form for lydbegrænsning som i dette projekt blev lavet i form af normalisering af mp3 og wav filer, og der blev samtidig udnyttet viden som er blevet undervist i under forløbet på uddannelsen. Dog blev der ikke lavet en mobilapplikation som beskrevet i problemformuleringen, der er dog blevet taget nogle overvejelser til denne funktion og den er blevet udformet en meget simpel plan til hvordan denne feature skulle laves. Denne feature blev ikke lavet hovedsageligt på grund af mangel på viden omkring hvordan normaliseringen kunne laves, dette tog længere tid end forventet, og der blev derfor mangel på tid, og denne feature blev skåret væk. Der er blevet brugt materiale fra forskellige fag, dette inkludere system of large scale development, messaging systems og test til at lave dette produkt, dog blev faget messaging systems kun brugt teoretisk, da dette fag skulle bruges til mobil applikationen. Under dette projektforløb er der blevet lært nogle forskellige ting, der er blevet lært hvordan det er muligt at normalisere og ændre på mp3 og wav filer, og der er blevet lært omkring googles youtube api. Der kunne godt laves mere på dette projekt da der er klare mangler ifølge problemformuleringen, og dette er noget der kunne arbejdes videre på, der ville samtidig være mulighed for at tilføje flere audioformater til listen over audioformater som er understøttet af dette program. 43

44 References [1] [2] Bilag Bilag 1 (feature list, prioritering og estimering.) Bilag 2 (tidsplan) 27/10-2/11 fix problemformulering overvej arkitektur og rapport skrivning om emnet overvej arkitektur omkring messaging og rapport skrivning om emnet/overvejelser overvej tests/testplan og rapport skrivning om emnet/overvejelser risk management tidsplan (skal kikkes på hver mandag) feature list prioriteringsliste 3/11-9/11 44

45 tidsplan (ret til) overvejelser over filformat og rapport skrivning om emnet/overvejelser user stories sanity check på priotets liste skrives rapport omkring arbejds metode(agile/traditionel) programmer og test features fra feature/prioriterings listen 10/11-16/11 tidsplan (ret til) programmer og test features fra feature/prioriterings listen rapport skrivning opdater priotets liste. Ret user stories Valg af youtube api 17/11-23/11 tidsplan (ret til) programmer og test features fra feature/prioriterings listen programmet skal være klar til at implementere en lyd begrænsings løsning efter denne uge. Ret user stories! Opdater trello 24/11-30/11 tidsplan (ret til) Lær hvordan man manipulere lydfiler. Programmer lydbegrænsings løsning 45

46 Skriv på akademisk artikel 1/12-7/12 tidsplan (ret til) Programmer lydbegrænsings løsning Skriv på akademisk artikel rapport skrivning 8/12-14/12 tidsplan (ret til) Programmer lydbegrænsings løsning programmer og test features fra feature/prioriterings listen rapport skrivning 15/12-21/12 tidsplan (ret til) lav rettelser på den akademiske artikel rapport skrivning 22/12-28/12 tidsplan (ret til) jul, her bliver der ikke lavet meget programmer og test features fra feature/prioriterings listen rapport skrivning 46

47 29/1-4/1 tidsplan (ret til) raportskrivning programmer de sidste funktioner der kommer med i programmet. 5/1-11/1 færdiggør rapport ret academisk artikel fix den sidste test ret rapport 12/1-12/1 aflevering af produkt aflevering af rapport 47