Research and Development 1/^Archief/2009-2010/01/Pilot

Uit Werkplaats
Ga naar: navigatie, zoeken
Bagjoke.jpg

Research and Development 1

Patrick van Bommel
Sjaak Smetsers


 © comments



  • Property "Auteur1" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/01Gebruiker:Aaron van Geffen" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
  • Property "Auteur2" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/01Gebruiker:Raoul Estourgie" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
  • Property "Auteur3" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/01Gebruiker:Erik Boss" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.
  • Property "Auteur4" (as page type) with input value "  Research and Development 1/^Archief/2009-2010/01" contains invalid characters or is incomplete and therefore can cause unexpected results during a query or annotation process.

Initieel onderzoek

Live opnemen en streamen?

Ondanks de snelheden van de internetverbindingen van tegenwoordig, kost het nog aardig wat tijd om data te versturen: er moeten aardig wat nodes bezocht worden om van bron naar doel te komen. Dat gaat al vrij snel gepaard met enkele honderden milliseconden, wat funest is als er muziek gemaakt wordt. Tegelijkertijd inspelen is daarom meteen uitgesloten, omdat de latency die optreedt bij het afgaan van de nodes vaak zodanig hoog is, dat de streams van de andere bandleden zodanig laat binnenkomen, dat het geheel asynchroon zou gaan klinken ("buiten de maat").

Om deze redenen is het voor ons beter om alleen reeds opgeslagen muziek streambaar te maken, en niet alles on-the-fly af te spelen.

Opnamen maken in de browser, hoe?

Om ons project succesvol en gebruiksvriendelijk te maken, is het belangrijk om te kunnen interfacen met de microfoon van een computer. Vanuit veiligheidsoverwegingen is het echter niet zonder meer mogelijk vanuit een browser een hardwarecomponent aan te spreken. Er zijn drie technieken om dit alsnog voor elkaar te krijgen: ActiveX, Java en Flash.

ActiveX

ActiveX is een techniek van Microsoft en wordt alleen ondersteund door Internet Explorer. Het toevoegen van nieuwe ActiveX-componenten is tegenwoordig vrij omslachtig vanwege misbruik door malwarefabrikanten in het verleden. Per saldo is dit dus niet zo'n gebruiksvriendelijke oplossing.

Java

Hoewel Java cross-platform is, is het implementeren van zogenaamde applets in browsers erg traag. Bovendien zijn de Java Runtimes op lang niet alle computers geïnstalleerd, wat zou betekenen dat gebruikers voor onze site deze zouden moeten installeren. In de praktijk gebeurt dat niet.

Silverlight

Silverlight is een relatief nieuwe technologie van Microsoft die erg bedoeld is voor het streamen van beeld en geluid over Internet. Hoewel de technologie goed werkt onder Windows en MacOS X, laat de ondersteuning voor Linux te wensen over. Twee van de drie groepsleden werken echter fulltime met Linux, dus Silverlight is niet zo'n handige keuze in dat opzicht.

Flash

Flash wordt onder elk gangbaar platform ondersteund en is ook op vrijwel alle computers aanwezig. Het ligt dus voor de hand om hiervoor te kiezen.

Conclusie

Een Flash-implementatie is voor ons project het beste, daar het een groot draagvlak onder gebruikers heeft.

In welk geluidsformaat opslaan?

Voor ons project is het essentieel om muziekstreams op te slaan en ze later weer af laten spelen. Omdat we hopen dat de site druk bezocht gaat worden, moeten we dus rekening houden met de grootte van de muziekbestanden. Als ze niet gecomprimeerd worden, zal het laden van de muziek erg langzaam verlopen en de server het sneller druk krijgen met het verwerken van het verkeer. We willen echter ook niet dat de kwaliteit van het product al te erg achteruit gaat, dus hierin moet een afweging gemaakt worden.

FLAC

FLAC staat voor Free Lossless Audio Codec. Lossless betekent dat er geen data verloren gaat bij het comprimeren. Dit zorgt ervoor dat de muziekkwaliteit exact hetzelfde blijft ten opzichte van ongecomprimeerde muziek, terwijl de bestandsgrootte wel aanzienlijk afneemt.

Voordelen:

  • Open source (we hoeven geen licentie kosten te betalen);
  • Lossless compressie (geen kwaliteitsverlies);
  • Een stuk kleiner dan WAV;

Nadelen:

  • FLAC bestanden kunnen nog steeds erg groot zijn;
  • Bevat ook onhoorbare tonen;

MP3

Het MP3-codec is ontwikkeld door de Duitser Karlheinz Brandenburg en nog steeds een van de meest populaire audiocompressieformaten. Het maakt gebruik van de gehoorbeperking van de mens. Als een bepaalde toon bijvoorbeeld luid is, zal een toon die er vlak naast ligt en minder luid is niet hoorbaar zijn. Deze tonen worden daarom gefilterd. Ook als er een geluid zowel links als rechts wordt afgespeeld, zal deze maar één keer worden opgeslagen. Dit wordt ook wel joint stereo genoemd. MP3 is een lossy compressie, omdat er gegevens verloren gaan tijdens de compressie. Als een MP3-bestand echter verkocht wordt, zal daar patentgelden voor afgedragen moeten worden.

Voordelen:

  • Kleine bestanden
  • Wordt door vrijwel iedere mediaspeler ondersteund

Nadelen:

  • Lossy, dus verminderde kwaliteit;
  • Afdracht van patentgelden bij verkoop;
  • Ondersteunt maar twee kanalen;

Ogg Vorbis

OGG Vorbis is een open source lossy audio compressor. De kwaliteit van ogg vorbis is echter veel beter dan die van mp3[1].

Voordelen:

  • Open source, dus geen patentgelden;
  • Kleine bestanden;
  • Bijna geen hoorbaar verschil tussen origineel en gecomprimeerde versie;
  • Ondersteunt tot 255 kanalen en daarmee goed voor alle verschillende instrumenten;

Nadelen:

  • Lossy, dus daarom nog steeds kwaliteitsvermindering, zij het marginaal;

Conclusie

Aangezien audiokwaliteit voor ons project belangrijk is, maar de bestanden tevens niet te groot mogen worden in verband met live streaming, is OGG Vorbis duidelijk de beste keuze voor ons project. Dit willen we daarom ook gaan implementeren in onze website.

Interface van software

De UI die we gaan ontwerpen voor StreamComposer moet mijns inziens een aantal eigenschappen hebben:

  1. De interface moet er aantrekkelijk uitzien: Ofwel, we willen met onze tijd mee gaan en geen web 1.0 taferelen te zien krijgen. Dit wil je bereiken door onder andere een consistent kleurenpallet te gebruiken en de interface minimalistisch te ontwerpen.
  2. Consistentie: Als een user op een knop drukt, en daarna op een andere gelijksoortige knop drukt, hoort dit ook op een gelijksoortige manier afgehandeld te worden. Play en Pause knoppen doen wel iets anders, maar wat ze doen wordt op een gelijksoortige manier afgehandeld (in ieder geval voor de user).
  3. Bereikbaarheid: Alle veelgebruikte settings en functies moet vrijwel binnen handbereik liggen. Een bepaalde optie mag in principe nooit in meer dan 3 klikken te bereiken zijn. En in principe probeer je dit in één of twee klikken beschikbaar te maken.
  4. Mr. Stupid approves: De interface moet toegankelijk en intuitief te gebruiken zijn voor alle soorten users.
  5. Keyboard-cat approves: Ook als Mr. Stupid hierboven een fout maakt, moet dit opgevangen kunnen worden. Natuurlijk is het onmogelijk je te verweren tegen de grote legioenen der Mr. Stupids (If you make something idiotproof, the world will just create a better idiot) maar je moet in ieder geval alle normale fouten kunnen opvangen. Vele dingen zijn op te vangen door Y/N schermpjes tevoorschijn te toveren bij ingrijpende dingen, of gewoon een "Undo" functie.

- Ruimte voor meer -

Deze eisen zijn niet zozeer specifiek voor ons Project, ze kunnen gelden voor bijna elk soort van UI voor bijna elk soort programma. Als je de bovenstaande eisen leest en je kijkt naar enigzins vergelijkbaar opgebouwde sites zoals een Youtube/Vimeo of zelfs een wikipedia dan zie je dat ze dit soort eisen in gedachten houden bij het ontwerpen van zo'n interface.

- Eerste "schets" van interface komt op deze locatie.

Aanpak serverside

Voor dit project is een serverside applicatie essentieel. Qua operating system zijn er in feite twee keuzes: Windows en Linux. Windows is commercieel, dus om kosten te besparen is het beter voor Linux te kiezen. Linux heeft dankzij haar open source karakter nog vele andere voordelen, zoals een wijd scala aan applicaties en libraries die aangesproken kunnen worden, waaronder audio-/streamlibraries. Windows heeft ongetwijfeld ook een API voor haar gesloten libraries, maar juist door het gesloten karakter daarvan is de werking ervan zonder licentie moeilijker te achterhalen.

Om tijd én kosten te besparen is het dus voordelig om hier voor Linux te kiezen. Ook vanuit een ideologisch oogpunt is het gebruik van Linux voor ons een redelijke keuze. De filosofie achter Linux is een filosofie die wij willen ondersteunen als dit niet ten koste gaat van de kwaliteit. Gezien het feit dat het eerder de kwaliteit ten goede komt is er dus geen reden om niet te kiezen voor Linux.

Afsluiting initieel onderzoek

Antwoord op de vraag: gaat ons dit lukken? Met andere woorden, is het plan reëel?