projektarbete : programmering i c++ · web viewmen i praktiken är nästan alla filer i ett...

Digitalt ljud och programmering i Java

Christoffer WeidmarLäsåret 02/03

Handledare Martin Sandgren

Versionshistoria..........................................................................................................................3Inledning.....................................................................................................................................4

Syfte........................................................................................................................................4Omfattning..............................................................................................................................4Metodik och handledning.......................................................................................................5Rapporten................................................................................................................................6

Bakgrundsfakta...........................................................................................................................7Kraven på programmet...........................................................................................................7Hjälpmedel..............................................................................................................................7Programspråket Java...............................................................................................................8

Historik...............................................................................................................................8Strukturen i Java.................................................................................................................8Objektorientering................................................................................................................9Objektorienterade metoder................................................................................................10Filhantering.......................................................................................................................11Det binära systemet...........................................................................................................11Det hexadecimala systemet...............................................................................................11Filer och filformat.............................................................................................................12Digitalt ljud.......................................................................................................................14Ljudvågor..........................................................................................................................14Analogt ljud.......................................................................................................................14Digitala format..................................................................................................................14Sampling och DA omvandling..........................................................................................15DA omvandlare.................................................................................................................17Olika filformat..................................................................................................................17Mp3 formatet....................................................................................................................18Mp3 kodning.....................................................................................................................18

Program för hantering av Mp3 filer......................................................................................19Problemformulering..........................................................................................................19Delproblem (a), beskriv mp3 filer och deras uppbyggnad...............................................20Delproblem (b), sök efter liknande program.....................................................................21Delproblem (c), gör ett huvudprogram.............................................................................21Delproblem (d), gör testfiler.............................................................................................22Delproblem (e), öppna och kontrollera en fil....................................................................22Delproblem (f), läs ut ID3 v1 information........................................................................23Delproblem (g), läs ut ID3 v2 information.......................................................................25Delproblem (h), läs ut mp3 Header information...............................................................35Lösning (h5), testprogram för mp3 header.......................................................................41Delproblem (i), Användargränssnitt.................................................................................41Delproblem (j), felhantering.............................................................................................45Framtida förbättringar.......................................................................................................46

Slutkommentar......................................................................................................................47Referenser.............................................................................................................................49

Internet..............................................................................................................................49Böcker...............................................................................................................................49Programvara......................................................................................................................49

Exempel på användargränssnitt................................................................................................50

Digitalt ljud och programmering i Java - Christoffer Weidmar - sida 2 av 54

Versionshistoria

Version Datum Kommentar

1 januari 2003 Första version. Mest programkod.

2 februari 2003-04-26 Mellanversion efter kommentarer från handledaren. Mera allmänna beskrivningar.

3 10 mars 2003 Programkoden mera komplett. Utförligare beskrivningar om filhantering och digitalt ljud.En del kommentarer om programkoden.

4 22 maj 2003 Lagt till ett enkelt användargränssnitt. Rättat en delfel i koden. Kompletterat rapporten med mycket mer detaljerade beskrivningar om problem/lösning, programmets struktur och programkoden.


InledningSyfte

Mitt syfte med projektet var från början främst att bygga ett program som jag själv har nytta av, och samtidigt lära mig mera om programmering eftersom det är ett område jag kanske kan tänka mig att arbeta med i framtiden. Före projektet hade jag endast ”lekt” litet med Visual Basic och spelmotorer så projektet kändes som ett bra tillfälle att komma igång mera på allvar.

Efter en del funderande bestämde jag mig för att ta fram ett enkelt och lättöverskådligt sorteringsprogram för musikfiler i mp3 format. Svårigheten verkade rimlig och programmet var något jag själv kunde ha nytta av. Det programspråk som jag valde blev Java eftersom det är ganska nytt och är ”trendigt” inom programmeringsvärlden. Java är också vanligt i ”open source” kretsar (d v s där människor utvecklar program och låter andra använda koden gratis), och därför finns det en hel del kod åtkomlig via nätet som man kan lära sig mycket av och i vissa fall också använda som ”halvfabrikat”.

Jag hade också planer på att publicera mitt program på en egen webbsida där det ska vara lätt att ladda ner det körbara programmet och där jag även tänker lägga den färdiga koden som bidrag till ”open source”. Därför skriver jag också de flesta kommentarerna på engelska.

Det operativsystem jag valde var Windows XP. Anledningen var helt enkelt att jag hade det på min hemdator redan. Det hade varit intressant att lära sig även Linux, men det kändes som ett för stort steg att ta i detta projekt.

OmfattningDet visade sig att arbetet var mycket mera krävande än jag trott från början. Det var svårt att lära sig programmera på egen hand. Det tog många timmar bara att få ihop en fungerande utvecklingsmiljö. Och dessutom krävdes det väldigt mycket arbete för att ta reda på och förstå hur de musikfiler programmet använder egentligen är uppbyggda. Det finns en hel del information på nätet men mycket är ofullständigt och i en del fall stämde inte informationen alls med hur filerna ser ut i verkligheten. För att förstå hur filerna är uppbyggda blev det också nödvändigt att förstå litet mera om vad digitalt ljud egentligen är.

Eftersom den teoretiska delen och de praktiska problemen med att avkoda filerna var större än jag väntat mig fick mina planer för programmet justeras. Från början hade jag tänkt mig ett program som skulle vara komplett och nästintill professionellt, men jag fick nöja mig med ett program där ”kärnan”,


d v s logiken för att läsa och avkoda informationen fungerar men användargränssnittet inte är komplett. Att bygga ett helt komplett fönsterbaserat användargränssnitt skulle troligen ta lika mycket som hela det övriga arbetet. Jag planerar att fortsätta arbeta på det på lediga stunder under sommaren.

Metodik och handledning

Som jag nämnde tidigare var arbetet svårare, eller framför allt mera omfattande än jag trott från början. Jag tvingades även byta handledare mitt i arbetet vilket gjorde att jag kanske gjorde litet för mycket arbete på egen hand i början och även kanske tog mig ”vatten över huvudet”. I programmeringsavsnitten har jag fått en del hjälp av min pappa som har en del erfarenhet av C++ och andra programspråk. Jag fick hjälp framför allt med de avsnitt som hanterar beräkningar och bithantering. Vi har också samarbetat med användar-gränssnittet. När man arbetar med ”objektorienterad” teknik bygger man inte alltid allting helt själv, utan många funktioner finns i klassbibliotek. I Java-biblioteket ”Swing” från Sun Microsystems finns t ex massor av funktioner för att bygga fönster, menyer och andra användbara funktioner för användargränssnitt. Eftersom Java är vanlig inom ”open source” rörelsen finns det normalt en hel del programkod på nätet som man kan ha nytta av. Oftast går programmeringen ut på att använda komponenter där man kan, förändra dem där de inte passar och skriva egen kod för de delar som är speciella för programmet.

När jag letade på nätet efter liknande program hittade jag inga som fungerade precis så som jag ville ha det. Jag hittade heller inga färdiga komponenter. Däremot hittade jag så småningom en del program som på olika sätt hanterade ID3 taggar. De flesta var dock inriktade på de enklare, s k ID3 version 1. I en del fall kunde kod jag hittade på nätet hjälpa mig att bättre förstå hur taggarna är uppbyggda i verkligheten men det var väldigt litet jag kunde använda mig ”rakt av”. Koden hängde i många fall samman med annan programkod som både var svår att förstå och ofta saknades. Däremot kunde jag lära mig mycket om programmering genom att läsa andras programkod. I några fall har jag gjort på samma sätt som i befintliga program, men även i dessa fall har jag skrivit in och testat koden för att förstå hur den fungerar.

För användargränssnittet har jag använt mig av halvfärdig kod. Jag har dels använt en del från Sun Microsystems som har flera användbara ”tutorials” på nätet, dels har jag tagit programkod från en bok i Java Swing (se referenserna). Detta gäller framför allt menyer och fönster.


Rapporten

Förutom inledningen redovisas projektarbetet i denna rapport i tre delar. Den första ger en teoretisk bakgrund till arbetet. Jag ger bakgrundsfakta om digitalt ljud, viktiga filformat och hur mp3-filer är uppbyggda. Syftet med det är att det skall vara lättare att förstå hur programmet fungerar eftersom vissa ljudtekniska begrepp som t ex samplingsfrekvens används i programmet.

I den andra delen förklarar jag programmets krav, vilka tekniska problem som har lösts och hur de har lösts. Jag försöker förklara hur programmet fungerar i stort, och jag beskriver dessutom de viktigare programavsnitten med bland annat exempel på programkod. De delar som inte beskrivs i detalj i detta avsnitt bör man kunna förstå genom att titta i programmets kommentarer. Sist i detta avsnitt finns också en sammanfattning där jag berättar om mina intryck från arbetet och vad jag tycker att jag har lärt mig.

Den tredje och sista delen är själva programkoden och dokumentationen av denna. Programdokumentationen består av programlistor med kommentarer plus klass/objektdiagram och andra dokument som skapats med hjälp av utvecklingsmiljön. Där finns också ett par bilder som visar hur användargränssnittet ser ut.


Bakgrundsfakta

Kraven på programmet

Det är naturligtvis viktigt att tänka igenom vad programmet skall göra. I det här fallet var det inte så svårt eftersom det var ett program jag själv ville använda. Det svåra var att begränsa omfattningen. Jag ville från början ha med en hel mängd funktioner, men efter att ha insett hur lång tid det skulle kräva bestämde jag mig för att ”skala ner” min kravlista till några basfunktioner. När dessa fungerar kan jag sedan bygga ut programmet med nya funktioner. Listan var:

1. Programmet skall fungera för Windows XP.2. Det skall ha ett enkelt grafiskt gränssnitt som kan byggas ut. Till att böra

med skall programmet styras med ett menysystem och mus.3. När menyerna fungerar skulle det vara bra även med kortkommandon för

vanliga funktioner. 4. Programmet skall ha ett fönster där det ska vara möjligt att utforska filer i

datorn.5. Datorn ska ha en sorteringsfunktion som skall fungera för mp3 filer. De

skall alltså kunna skiljas ut från andra filer. 6. Mp3 filerna skall visas i ett separat fönster.7. Programmet skall kunna sortera ut intressant information ur mp3 filerna

som t ex titlar, artister och annan intressant information som genre, ljudkvalitet och låtarnas längd.

8. Informationen skall kunna sorteras, helst på flera olika sätt. Sorteringsfunktionen skall också stödja sortering efter ”Beats per minute” (BPM), d v s takten/ hastigheten i låten. Detta är ett stöd när man skall välja musik för att mixa.

I den nuvarande versionen finns de flesta funktioner med förutom sortering, men det grafiska gränssnittet är inte komplett.

HjälpmedelJag hade ju inga pengar att köpa program för så jag letade efter gratis utvecklingsverktyg på nätet. Bl a har Sun gratis ”SDK” (Software Development Kit”) som innehåller kompilator, länkare och en del hjälpmedel för felsökning. Men det kändes krångligt att arbeta med bara redigeringsprogram och kompilator. Jag hittade inga bra gratisprogram för Java men jag fick tips om verktyget ”Together Controlcenter” från Togethersoft (numera Borland). Detta är en mycket trevlig utvecklingsmiljö som innehåller ”allt” och efter att ha förklarat min situation fick jag låna en utbildningslicens av Togethersoft.


Programspråket Java

Historik

Java började utvecklas under början av 90-talet av Sun Microsystems. Grundtanken var att konstruera ett universellt och portabelt språk. Den som utvecklar program skall inte behöva tänka på vilken sorts maskin programmet skall köras på eller vilket operativsystem som används. Koden skall i stort sett vara densamma om det så skrivs för en kaffekokare eller en superdator, och oavsett om operativsystemet är Linux, Windows, Mac-OS eller något helt annat.

Sun kom med den första prototypen 1995. Det var många som höjde på ögonbrynen och tyckte att det verkade onödigt med ett språk till. Just då hade språket ’C’ blivit det som gällde bland ”riktiga programmerare” och även det hade tagits fram med målsättningen att ge mycket flyttbar kod. De tidiga versionerna av Java fick mycket kritik för att vara långsamma.Men sedan dess har det hänt mycket och de senaste två åren har många börjat använda Java för både inbäddade system (t ex telefoner) och för stora affärssystem. Mycket av Javas växande popularitet beror också på att det på ett lätt och framför allt säkert sätt tidigt integrerades med Internet för skapandet av både webbsidor och serverlösningar för webbaserade system.

Strukturen i Java

Java kan lite förenklat sägas vara en vidareutveckling av språket C, men där man har försökt ta bort de största nackdelarna. Programmerare gillar ’C’ därför att det inte har några begränsningar. Den som utvecklar kan komma åt allting i datorn på maskinnivå vilket kan ge snabba program. Men man offrar en del säkerhet och det finns möjlighet att göra fel som är svåra att hitta. I ’C’ kan man t ex arbeta med något som kallas ”pekare”, vilket betyder att man kan arbeta direkt mot vissa minnesadresser. Det gör att man kan kringgå kompilatorns typkontroll och t ex försöka använda en textsträng som heltal. Javakompilatorn har många fler typkontroller och tillåter inte direkt pekarhantering. Men den största och viktigaste skillnaden är att Java är helt objektorienterat till skillnad från C++ som kan sägas vara ’C’ med påbyggnad för objektorientering.

Javas flyttbarhet uppnås genom att programmeraren aldrig arbetar direkt mot operativsystemet utan använder sig av något som kallas ”virtuell maskin” (JVM). Denna innehåller allt det som krävs för att ett program skall kunna köra i en viss maskin. Eftersom samma stöd finns överallt behöver programmeraren inte bry sig om i vilken miljö programmet skall användas.


Förutsättningen för att det skall fungera är givetvis att någon dessförinnan byggt en virtuell maskin för den hårdvara och det operativsystem som man vill använda. Sun har tagit fram en del stöd och många företag har tagit fram virtuella maskiner för sina produkter och därför finns det idag Java-stöd för stordatorer, Mac, de flesta PC och även handdatorer och vissa mobiltelefoner. Det finns också Javabibliotek för vissa processorer för de som utvecklar sin egen hårdvara, men för att det skall fungera krävs mycket arbete.

Den främsta nackdelen med Java är prestanda och minnesbehov. Det ”indirekta” sättet att arbeta mot en virtuell maskin istället för direkt mot operativsystemet ger en del tidsförluster. Speciellt lång tid tar det vid uppstart av programmen och det märks tydligt i det utvecklingsverktyg jag använde som i sig är byggt i Java. Kritikerna menar också att Java är minneskrävande. Detta har jag dock inte märkt något av eftersom mitt program är ganska litet.

Objektorientering

Tidigare programmeringsspråk som t ex ’C’ hade ofta formen av långa textdokument med snårigt sammanlänkad kod där också mycket små ändringar i en del kunde få katastrofala konsekvenser för andra delar av programmet. Java är ett helt objektorienterat språk. Det innebär att man bygger programmet som ett antal objekt som samverkar och tillsammans utgör ett program. Objekten innehåller både de data som logiskt tillhör objektet och de funktioner som kan utföras med objektets datamängd. Objektets data är normalt ”gömda” så att det bara är objektets egna funktioner som kan komma åt dem. Detta kallas ”inkapsling” och har flera fördelar:

- De som använder funktionerna blir inte beroende av hur data är definierade och behöver därför inte påverkas bara för att data ändras lite.

- Risken för fel blir mindre eftersom man har ett funktionellt gränssnitt som är enkelt att förstå för den som skall använda funktionen.

Ett Javaprogram består av ett antal ”klasser”. Dessa innehåller funktioner och data som kan kallas instansvariabler. En klass kan ses som en ”mall”, d v s en definition av vad objekt av en viss typ skall innehålla. När programmet sedan körs skapas verkliga objekt (instanser) som programmet kan använda. Utifrån klassens definitioner skapas instansvariablerna genom att minnesutrymme skapas och de tilldelas startvärden mm.

När man strukturerar sitt program väljer man att definiera sina klasser på ett sådant sätt att det blir ”naturligt”. Om man t ex skall bygga ett program som registrerar försäkringar blir kanske ”Person”, ”Bil” eller ”Försäkring” naturliga klasser. Programmet blir då lättare att förstå, och ändringar och tillägg kan sedan göras utan att hela systemet påverkas.


Mitt program handlar om filhantering och några exempel på klasser jag använder är ”mp3header” och ”mp3file”.

Java har också ett bra standardbibliotek med klasser som är färdiga att använda. Ofta använder man sig av något som kallas för ”arv”. Det betyder att man skapar nya klasser som dels ”ärver” alla funktioner och instansvariabler från föräldraklassen, dels får de tillägg i form av ytterligare variabler och/eller funktioner som man själv vill lägga till. Eftersom biblioteken i Java är så omfattande blir de litet svåröverskådliga för den som är ovan. Man ser också spåren av tidigare Java-versioner och det är ibland förvirrande när samma sak kan göras på litet olika sätt beroende på om man använder gamla eller nya klasser. Speciellt gäller detta användargränssnitten där man tidigare använde biblioteket Awt men nu rekommenderas att använda det nyare Swing biblioteket.

Java räknas nu som ett framtidens programmeringsspråk med regelbundna uppdateringar och en ny inriktning på databaser och stora system med många transaktioner. Java är numera vanligt i bankvärlden. Nackdelen är användar-gränssnitten där Microsoft fortfarande verkar bättre.

Objektorienterade metoder

När man utvecklar mindre program är det vanligt att man börjar skriva kod direkt. Den som programmerar kan oftast hålla det mesta i huvudet eftersom det är man själv som hittat på allt. Men om man arbetar i större system där det finns flera personer involverade behövs det ett sätt för att kunna får en översikt över systemet, förstå vad andra gör och hur det man själv utvecklar skall passa ihop med övriga delar. Det kan då vara bra att rita en modell över systemet, ungefär som man använder ritningar när man bygger hus. När man utvecklar större system börjar man därför ofta med att göra en eller flera ritningar. I större projektgrupper finns ibland personer som är specialister på att strukturera systemen och de kallas ibland arkitekter precis som vid husbyggnad. Modellerna är ofta bra som hjälpmedel för det egna tänkandet eftersom man lättare ser hur saker kan hänga samman när man tittar på modellen, och det kan vara ett stöd för minnet om man senare behöver ändra i programmet.

När man arbetar objektorienterat i industrin verkar det vara UML (Universal Modeling Language) som är mest använt. Det är en standard som utvecklats av ett antal kända metodexperter och som innehåller en mängd olika modeller för att beskriva olika aspekter av ett system. I mitt projekt har jag använt mig litet av klassdiagram och det är enkelt att rita med Together Controlcenter (TC). När man ritar en klass skapar programmet automatiskt ett ”skal” för motsvarande klass i Javakod och när man sedan lägger till kod i klassen uppdateras


klassdiagrammet automatiskt. När man sedan är klar med programmet har man samtidigt en komplett ritning som garanterat stämmer med det som finns i koden. Ett problem med att göra ritningar är att man medan man arbetar upptäcker nya problem som gör att de tidigare lösningarna inte är så lyckade. Det gäller t ex var man placerar olika datastrukturer och i vilken klass man lägger en viss funktion. Det blir besvärligt att ändra ritningen efterhand som man gör förändringar men TC hanterar mycket av detta automatiskt.

Filhantering

Det binära systemetAllting i en dator är ju i grunden uppbyggt av ”ettor och nollor”. Men vad menas egentligen med det? För att kunna förstå måste man förstå det binära talsystemet. En ”bit”, eller Binary Digit, är den talenhet en dator hanterar på den lägsta nivån. En bit kan ha två värden; ett eller noll, ungefär som en strömbrytare som kan vara av eller på. Om man utökar antalet ”strömbrytare” till två får man dubbelt så många kombinationsmöjligheter. De två bitarna kan ha värdena 00, 01, 10 och 11. För varje tillkommande bit dubblar man antalet kombinationsmöjligheter och de olika bitarnas positioner representerar talet 2n-1 där n är antalet bitar. Om man har åtta bitar får man 256 möjligheter och kan då representera talen 0-255. Man brukar kalla detta en byte. En kilobyte är 1024 byte och större enheter är gigabyte och terabyte.

Det hexadecimala systemetEftersom datorns minne arbetar med binära värden skriver man ibland talen i binär form i programmen. Detta gäller speciellt när man vill hantera enskilda bitar eftersom logiken blir tydligare. T ex kan man i Java skriva ett 8-bitars värde som: 1010 0110 som i det här fallet alltså betyder 166. Detta sätt att skriva tal blir dock opraktiskt när man hanterar större siffror och därför arbetar man ofta med det hexadecimala systemet som är ännu mera kompakt än det decimala. I det hexadecimala systemet skrivs siffrorna som i basen 16, d v s 160, 161 o s v, och för att kunna representera tal upp till 15 används bokstäverna A-F där A representerar 10 och F representerar 15. Varje 8-bitars tal kan då skrivas som två hexadecimala siffror, och talet 166 ovan blir då i hexadecimal representation: A6. Det är speciellt vanligt att man använder hexadecimal representation för stora tal som t ex minnesadresser.


Filer och filformat

Datorns processor är gjord för att mycket snabbt kunna hantera binär information. De instruktioner som processorn utför ”längst ner”, i maskinkod, är egentligen enkla instruktioner som att t ex addera två tal, skriva ett tal i ett register och liknande. När man skriver ett program med språk som Java är instruktionerna mera avancerade men dessa instruktioner översätts till enkla för en snabb hantering av processorn. Ett datorprogram i sig består av binär information, och när ett program kör finns en del av programmet i det dynamiska minnet (RAM). Samtidigt finns i minnet även den information som programmet arbetar med för tillfället som t ex variabler eller text.

Datorns hårddisk fungerar på motsvarande sätt som datorns RAM, d v s binär information lagras, fast permanent på ett magnetiskt eller optiskt media. Förutom hårddiskar används CD-skivor, DVD eller magnetband som ofta används för säkerhetskopiering. Medan innehållet i RAM är temporärt och varierar efter hand som olika program körs, är hårddiskens innehåll organiserat i och finns kvar även när datorns stängts av. En fil är en mängd information som hänger samman, och som datorn hanterar som en enhet. Filerna är i grunden uppbyggda av ettor och nollor men har olika betydelse och kodning beroende på hur operativsystem och tillämpningsprogram använder informationen.

Datorns operativsystem, som Linux eller Windows, innehåller ett antal standardfunktioner för att hantera filer. Dessa funktioner finns i den del av datorns operativsystem som kallas filsystem. De flesta av funktionerna använder man när man arbetar med Windows ”filsökare” och t ex raderar eller flyttar filer. Funktionerna finns även i standardbibliotek som man kan komma åt när man skriver sina program. I Java finns de flesta sådana funktioner i ett bibliotek som kallas för java.io (där ’io’ står för in/ut, d v s inmatning och utmatning).

Det finns oändligt många sätt att organisera data i filer. I princip kan var och en som skriver program hitta på vad som helst. Huvudsaken är att den som gör program som använder informationen förstår hur filerna är uppbyggda och kan anpassa sig till det. Därför finns det en stor mängd filtyper. Men eftersom det skulle vara svårt och opraktiskt att utbyta information om alla program skulle ha sina egna unika filformat så har det efter hand bildats standarder. Eftersom musik är intressant för så många så finns det många program som stödjer t ex mp3-filer. Detta är ingen officiell standard och det finns små variationer men i stort kan de flesta program hantera alla mp3-filer.

Oftast används de sista tre tecknen i filnamnet för att markera vilken typ av fil det är. Word-filer slutar exempelvis på ’.doc’, enkla textfiler kallas ’.txt’ och de


filer som är intressanta för mitt program heter ’.mp3’. Filerna organiseras av operativsystemet i olika mappar och undermappar som bildar en trädstruktur. Det finns en del funktioner i biblioteket java.io för att navigera i filträden.

För användaren, och de program som arbetar med filerna, ser det ut som om informationen ligger samlat i en enda följd. Men så är egentligen inte fallet, utan för att kunna utnyttja hårddisken bättre är informationen lagrad i olika avsnitt (sektorer) som länkas samman av operativsystemet. Det betyder att en fil rent fysiskt kan vara utspridd över en större del av hårddiskens yta.

Som tidigare nämnts så är all information binär. På ett sätt kan man därför säga att alla filer egentligen är binära. Men eftersom så mycket av datoranvändningen går ut på att hantera text pratar man ofta om två grundtyper av filer, dels ”textfiler”, dels ”binärfiler”. En textfil kan man skapa genom att t ex använda tillbehörsprogrammet ”Anteckningar” i Windows. Om man på detta sätt skapar en fil och skriver texten ”Java” kommer det att lagras i filen på det standardsätt för att lagra text som kallas ASCII. Det betyder att varje tecken är kodat som ett 8-bitars värde. Om man öppnar filen med ett redigeringsprogram som kan hantera binära värden så kan man se att texten ”Java” representeras som fyra sådana värden som i hexadecimal form blir: 4a 61 76 61

Eftersom alla textfiler i Windows lagras på precis samma sätt kan alla program som hanterar text förstå ASCII formatet. Med ”binärfiler” menas då alla filer som inte är rena textfiler. Exempel på filer som är nästan helt binära är musikfiler och bilder. Men i praktiken är nästan alla filer i ett blandat format. Det gäller även Word och andra textbaserade filer. För att hantera formatering i Word (t ex fetstil) finns binär information insprängd i filerna. Det kan man se om man skapar en Word-fil och skriver texten ”Java” även i denna. Filen blir då 24 kbyte stor och först från position 2560 (hexadecimalt) hittar man själva texten i ASCII-kod. De filer mitt program arbetar med är i högsta grad ”blandade” vilket ställer krav på programmet som beskrivs senare i rapporten.

Mitt program går till stora delar ut på att arbeta med filsystemet och att avkoda olika typer av beskrivande information som finns på olika ställen i filerna. Detta har varit en av de stora utmaningarna för mig. Som en introduktion går jag i följande avsnitt kortfattat igenom vad digitalt ljud är och hur det representeras i datorn. Man behöver inte förstå digitalt ljud i detalj för att kunna använda mitt program och förstå programkoden. Men eftersom begrepp som t ex ”samplingsfrekvens”, ”lager” och ”bithastighet” används i programmet för beräkningar och avkodning anser jag att det är viktigt med en beskrivning av vad detta egentligen betyder.


Digitalt ljud

LjudvågorLjudvågor är vågformade rörelser i ett medium. Precis som vattenvågor sprider sig över en vattenyta sprider sig ljudvågorna i t ex luften genom att sätta luftmolekylerna i rörelse. När ljudvågorna når våra öron sätts trumhinnan i rörelse så att den svänger i samma takt som luften och rör sig proportionellt mot energin i vågen. Örats olika delar översätter detta till nervimpulser (elektriska signaler) som hjärnan kan tolka som ljud. Ljud kan beskrivas av två viktiga storheter:

- Frekvens: Hur snabba svängningarna är (vilka toner).- Amplitud: Hur starka svängningarna är (vilken styrka).

Kombinationen av frekvens och amplitud ger ljud som vi kan uppfatta som t ex tal, buller eller musik. Ljud, precis som andra vågrörelser i naturen, är kontinuerliga, d v s variationer i nivå och styrka kan vara oändligt små eller stora. Sådana förlopp kallas också analoga. Det finns alltså inga speciella ”steg” mellan olika nivåer och frekvenser utan dessa varierar kontinuerligt. De flesta ljud i naturen som t ex fågelkvitter, tal, skratt och vindens sus i träden innehåller ett stort antal frekvenser och nivåer. Ett ljud som endast består av en enda frekvens uppfattas ofta som störande och ”disharmoniska”.

Analogt ljudFör inte speciellt länge sedan var den utrustning som användes för att spela in och spela upp ljud analog. Vanliga bandspelare representerade ljudet i form av variationer i magnetbandet, och i vinylskivor graverade man in analoga spår som fick skivspelarens pickupnål att vibrera med en frekvens och amplitud som motsvarade ljudet. Teoretiskt sett borde detta vara pefekt men tekniska svårigheter gjorde att ljudkvaliteten ändå inte var perfekt och man fick störningar som knaster och brus. Begränsningarna gjorde att man började forska efter andra sätt och eftersom digitaltekniken började bli avancerad tack vare datorernas utveckling var det naturligt att söka efter digitala lösningar.

Digitala formatFör många kanske digitalt ljud fortfarande verkar främmande och nytt men i praktiken använder de flesta av oss digitalt ljud dagligen. Varje gång vi lyssnar på radio eller sätter på en CD lyssnar vi på ett digitalt ljud, d v s där informationen lagrats på ett medium som ettor och nollor som kan avkodas av den utrustning som spelar upp ljudet för oss.

Vid inspelning måste det någonstans i kedjan ske en översättning från det analoga formatet till ett digitalt format. Detta kallas AD omvandling. När man


sedan spelar upp ljudet igen måste det någonstans ske en översättning åt andra hållet eftersom ljud per definition är analogt. För några år sedan var det vanligt att inspelning och mixning av musik fortfarande skedde på vanliga bandspelare och det var inte förrän man skulle pressa CD skivorna som ljudet digitaliserades. Därefter kom de digitala bandspelarna (DAT) där man redan vid inspelningen skapade digital information. Numera är det vanligt att man spelar in direkt på hårddisk.

Vid avspelning från t ex en CD spelare finns en DA omvandlare som utifrån den digitala informationen på en CD skiva genererar analoga signaler som skickas till förstärkaren vilken i sin tur genererar analoga spänningsvariationer för att styra högtalarna. Resultatet blir analogt ljud som når våra öron.

Eftersom analogt ljud är oändligt variationsrikt i både frekvensinnehåll och ljudstyrka skulle det i teorin krävas ett oändligt antal bitar och en oändligt snabb utrustning för att helt utan fel representera ljudinnehållet i en viss inspelning. Uppgiften är egentligen omöjlig, för eftersom det digitala systemet representeras av tal med fasta steg mellan kan man aldrig uppnå den fullständigt kontinuerliga signal som finns i det naturliga ljudet. Så snart man ersätter de kontinuerliga variationerna med fasta (s k diskreta) steg förlorar man information. Ett digitalt ljud blir därför alltid en förenkling av det analoga.

Lyckligtvis kan människan inte uppfatta hur fina nyanser som helst, och med modern teknik kan inspelning och avspelning av digitalt ljud göras med så hög kvalitet att det börjar bli svårt att skilja mellan verkligt och inspelat ljud. I varje fall är moderna digitala inspelningar helt överlägsna de gamla analoga. Många hävdar att det nya ljudet är ”kallare” än det analoga, men vid blindtester går det inte att se några klara skillnader utan upplevelsen beror på vilken teknik (t ex filter och effekter) som används vid inspelning och avspelning.

Sampling och DA omvandlingDen krets som omvandlar det analoga ljudet till digitalt ljud fungerar på följande sätt: I skissen nedan visas en enkel sinusformad ljudsignal. För att digitalisera denna tar kretsen prov på (d v s samplar, låneord från engelskans sample) ljudnivån (amplituden) vid ett antal jämna och väldigt små tidsintervall. Varje nivå representeras sedan som ett siffervärde som lagras i digital form. Översättning av amplituden till ett digitalt värde kallas kvantisering. Noggrannheten i värdena, d v s hur många olika nivåer som kan lagras, avgörs givetvis av antalet bitar. I modern utrustning som DAT-bandspelare används typiskt 16 bitar vilket gör att amplituden för varje mätvärde (sampel) kan översättas till ett värde som varierar mellan 0 och 65535. Detta gör det möjligt att återge amplitudvariationer mellan lägsta och högsta värde på 96 dB. En


förutsättning för hög kvalitet är givetvis att mätutrustningen (AD omvandlaren) har mycket hög noggrannhet.

Fig: Sampling av en sinusvåg

Förutom antalet bitar är den sk samplingsfrekvensen avgörande för kvaliteten. Samplingsfrekvensen beskriver det tidsintervall mellan vilka AD omvandlaren samplar ljudnivån. En frekvens på 10 Hz (intervaller per sekund) betyder att det är 1/10 sekund mellan varje sampel. Det är naturligtvis alldeles för långa intervall för att kunna återge musik. Den frekvens som ofta används är 44100 Hz. Denna frekvens är naturligtvis inte vald av en slump. Enligt forskaren Harry Nyquist är den högsta frekvens som ett digitalt system kan återge halva samplingsfrekvensen. Detta kallas Nyquistteoremet. Med en samplingsfrekvens på 44100 Hz kan man alltså återge frekvenser på drygt 22000 Hz vilket är lämpligt eftersom det mänskliga örat kan uppfatta frekvenser mellan 20 och 20000 Hz. Med ännu högre samplingsfrekvenser uppnås ännu högre kvalitet och många moderna utrustningar för hårddiskinspelning arbetar med 96 kHz (96000 Hz) samplingsfrekvens. Detta borde egentligen inte ge några hörbara skillnader, men kvaliteten upplevs ändå högre eftersom vissa ljud är oerhört komplexa och upplevelsen ges av samverkan mellan olika övertoner. Övertonerna är inte hörbara men bidrar ändå till ”klangfärgen”. Det kan vara detta som gör att de tidiga digitala systemen upplevdes som ”kalla” av ljudentusiasterna.


DA omvandlareSom nämndes ovan så tar AD omvandlaren bara prov på ljudstyrkan (amplituden). Ljudfrekvenserna återskapas genom att DA omvandlaren spelar upp ljudinformationen genom att omvandla amplitudvärdena till spänningar och skicka detta till ljudkretsarna i intervaller motsvarande samplingsfrekvensen. På så sätt återskapas både frekvens och ljud med en noggrannhet som motsvarar inspelningsförhållandena.

Fig: DA omvandlaren

Olika filformatDet finns en stor mängd format för att lagra digitalt ljud på hårddisk. Mängden information kan vara väldigt stor. Med 44.1 kHz sampling och 16 bitar krävs ca 10 Mbyte för att lagra en minuts musik. Ett exempel på filformat som i stort sett lagrar den digitala informationen oförändrad är Wave. Microsoft ligger bakom denna standard och de flesta ljudprogram för in- och avspelning kan hantera detta format. Informationen i en Wave-fil består nästan enbart av ”råa” 16-bitars samplingsvärden i binär form. Om det är två kanaler (d v s stereo) ligger ljudet oftast med vartannat amplitudvärde för höger och vartannat för vänster kanal.

Utrymmeskrävande format som Wave fungerar bra men man fyller snabbt hårddisken och i bärbara spelare skulle det inte få plats speciellt mycket musik. En annan nackdel är den distribution av musik via nätet som blivit så populär. Även med ADSL blir överföringstiden så lång att Wave-filer blir opraktiska. Därför har ett antal komprimerade format tagits fram.

Komprimeringen av ljudfilerna bygger på algoritmer (betyder metoder/ strategier) som går ut på att man utnyttjar kännedomen om hur de mänskliga sinnena uppfattar ljud. Genom att utnyttja denna kunskap kan man reducera informationsmängden kraftigt utan att ljudkvaliteten försämras lika mycket. Populära komprimerade ljudformat är t ex mp3 och Aiff.


Mp3 formatetEn mp3-fil, eller MPEG-3 (Moving Pictures Experts Group) fil som förkortningen egentligen står för är en ytterst komprimerad musikfil. Det blev så småningom något av en revolution när musikfiler med denna metodik kunde komprimeras ner till en tiondel av storleken med en mycket liten förlust i ljudkvalitet. Patentet för mp3 formatet togs av en professor vid Frauenhofer institutet i Tyskland redan 1989, men det var först år 1998 då ”Winamp”, en musikspelare som stödde formatet mp3, kom som formatet började komma till allmän användning.

Rättigheterna till mp3 och WinAmp släpptes fria av Frauenhofer institutet vilket givetvis har en stor del i varför det blev en nästintill lavinartad effekt med spridande av musikfiler över nätet. Problemet med piratkopiering var fött och sedan dess har det pågått en ständig kamp mellan skivbolag och artister och förespråkare av de fria ljudformaten. Flera alternativa format har släppts men eftersom licensrättigheterna har varit kontrollerade av utvecklare eller på annat sätt innehållit begränsade licenser har de inte blivit lika populära. Numera finns stöd för mp3 avspelning i t ex bärbara spelare, stationära CD-spelare, i handdatorer och telefoner.

Mp3 kodningAnledningen till att MP3 formatet kan krympa filstorleken till cirka en tiondel utan att förlora särskilt mycket i kvalitet är en snillrik kodning som bygger på små förenklingar i ljudinformationen som knappast är hörbara:

Basljud har låg frekvens och sång har vanligen högre frekvens. Med hjälp av Frauenhofer-kodningen sorteras de frekvens som hörs minst konsekvent bort. En vanlig lyssnare hör inte dessa förändringar eftersom de till stora delar sker i ”periferin”. Denna form av att sortera bort vissa frekvenser kallas för ” Minimal audition threshold”.

De frekvenser som är mera hörbara framhävs mer istället för de frekvenser som är borttagna. Detta kallas för ”Masking effect”

Vidare används ”Joint Stereo”, d v s en metodik som gör att höger och vänster ljudkanal smälts ihop. Redan med denna manöver nästan halveras filstorleken. MP3 är alltså till stora del ett mono-format, men vid avspelning upplever lyssnaren ändå en stereoeffekt.

Vidare används s k Huffman kodning, vilket är en avancerad matematisk algoritm som sorterar bort vissa frekvenser som förekommer mera sällan än andra. Detta kan ses som en vidareutveckling av Frauenhofer formatet.


Program för hantering av Mp3 filer

ProblemformuleringSyftet och de övergripande kraven på programmet beskrivs i den första delen av rapporten. Efter hand delade jag in uppgiften i några olika delar. Detta var egentligen inte så metodiskt som det kan verka eftersom jag fick hoppa en hel del mellan olika uppgifter men i stort sett var arbetet indelat i några huvuddelar:

a. Ta reda på hur mp3 filer är uppbyggda och hur man kan filtrera ut den intressanta informationen.

b. Sök efter liknande program på nätet och se om några komponenter kan vara användbara.

c. Gör ett huvudprogram för att prova att utvecklingsmiljön fungerar och att allting är rätt installerat. Detta program kan sedan användas för att driva olika tester.

d. Lägg upp några lämpliga musikfiler för test. e. Börja själva projektet med att göra ett program som kan öppna en fil och

se om det är en mp3-fil. f. Lägg till funktioner som kan hantera ID3 v1 taggar och läsa all

information som kan finnas i en sådan. Gör även testprogram för detta.g. Lägg till funktioner som kan hantera ID3 v2 taggar och läsa all

information som kan finnas i en sådan. Gör även testprogram för detta.h. Lägg till funktioner som kan läsa den information som finns i själva mp3

filen (den s k ”headern”). Gör även testprogram för detta.i. Gör ett enkelt menysystem och bygg ut användargränssnittet med

funktioner för att visa informationen och presentera i både filer och fönster i menysystemet.

j. Gör funktioner för felhantering.

Mitt program innehåller det mesta förutom att användargränssnittet inte är komplett. Det som tagit absolut längst tid är (g) och (h). Det tog tid att förstå hur filerna är uppbyggda och det vart svårt rent programtekniskt.

I följande avsnitt beskriver jag kortfattat de olika momenten (a) – (j) och vilka problem jag stötte på. De mest besvärliga avsnitten beskriver jag mera ingående och jag tar också med några exempel på programkod.


Delproblem (a), beskriv mp3 filer och deras uppbyggnadLösning: Eftersom programmet går ut på att hantera mp3 filer är det naturligtvis viktigt att förstå exakt hur en mp3 fil är uppbyggd. Informationen i en sådan fil är ”blandad”, d v s det finns dels ren textinformation, dels binär information av flera olika typer. Den binära informationen är ganska komplicerad. Viss information ligger väldigt tätpackad i delar av byte och detta gör att programmet i flera fall måste arbeta med enskilda bitar. Även sifferinformation som t ex uppgifter om olika längder ligger lagrad på ett sätt som gör att det inte ”bara” är att läsa den, vilket beskrivs längre fram i detta avsnitt. I stort kan mp3 filerna sägas bestå av följande tre huvuddelar:

1. mp3 header: Binär information. I denna del finns en del data som främst används av mp3-spelarna. Informationen talar om t ex vilken typ av kodning som används (det finns ett antal olika). Mitt program använder ett par parametrar, bl a för att räkna ut hur långt musikstycket är.

2. mp3-kodad ljudinformation: Binär information som innehåller själva ljudinformationen på det format som beskrevs ovan. Mitt program läser inte detta för närvarande.

3. mp3 textinfo: Större delen av den information mitt program använder finns i s k ”taggar”, d v s speciella avsnitt med beskrivande information som kan ligga både före och efter ljudinformationen i filen.

Själva ljudinformationen är naturligtvis det viktigaste för de program som spelar in och spelar av musiken. Men för mitt ändamål är den andra informationen viktigast eftersom det är i dessa delar den information jag är intresserad av finns.

Det har för ”taggarna” uppstått en informell standard som heter ”ID3” och de flesta håller sig till detta format även om det finns olika variationer. Det finns i grunden två olika typer av ”taggar”. Den enklaste, och som kom först, är helt textbaserad och har en fast storlek. Denna kallas ofta ”ID3 v1”. Ett nyare format kallas ”ID3 v2” och är betydligt mera komplicerat eftersom informationen varierar i både storlek och innehåll och innehåller blandad binär och textbaserad information. En annan svårighet är att det finns olika nyare versioner som t ex ”ID3 v2.2” o s v, men de förändringar som görs numera är mest inriktade på att t ex lägga in bildinformation, länkar till webbadresser och olika typer av certifikat för att hantera licensrättigheter. Detaljerna för de olika delarna beskrivs närmare i de avsnitt som beskriver respektive programavsnitt.


Delproblem (b), sök efter liknande programLösning: Jag hittade inga komponenter som jag kunde använda direkt. Men jag hittade en del ”open source” kod som jag kunde lära mig av. Detta hjälpte mig att förstå hur filerna var uppbyggda. Jag lärde mig också mera om Java-program och hur man praktiskt läser information från filer. Speciellt lärde jag mig om hur man hanterar ”exceptions” (kan på svenska kallas ”undantag”), d v s feltillstånd i programmen. När man t ex läser filer och gör beräkningar är det mycket som kan gå fel och för att programmet inte bara skall krascha eller hänga sig kan man använda undantagshanteringen för att ta hand om felet så att programmet kan fortsätta fungera ändå.

Delproblem (c), gör ett huvudprogramLösning: I Java skapar man ett huvudprogram genom att skriva en funktion som döps till main och som ser ut på ett speciellt sätt. När programmet startas i Javamiljön kommer koden för main att vara det som körs igång allra först. I mitt program finns klassen Driver som innehåller main som alltså är huvudprogrammet. I main finns den kod som behövs för att starta programmet och skapa de klasser som behövs för att köra igång allting. Det ser ut så här: public class Driver { public static void main(String[] argv) {

... GuiDriver myGuiDriver = new GuiDriver(); myGuiDriver.kickIt(); } }

I funktionen main används argv för att man skall kunna skicka olika typer av information till programmet vid uppstart. För närvarande använder jag inte denna funktion i mitt program. I mitt program gör main egentligen inte så mycket. Först startas användargränssnittet genom att skapa en instans av klassen GuiDriver. Sedan anropas funktionen kickIt() i denna klass och den blir sedan huvudprogrammet. Det är praktiskt eftersom mycket kommer att handla om att arbeta med användargränssnittet och starta olika delprogram.

Kommentar: Det är inte alltid lätt att avgöra var funktioner och data skall ligga. Man märker efter hand att man behöver komma åt information som finns på andra ställen och det verkar inte finnas några egentliga regler för var man lägger olika saker. Det verkar som om man får gå på känsla och erfarenhet. Det är svårt när man är nybörjare.


Delproblem (d), gör testfiler

Lösning: Jag hämtade hem några program från nätet av typ ”tag editors”, d v s program för att läsa och skriva in information i mp3 filer. De visade sig fungera ganska dåligt. Några kraschade, andra verkade inte visa rätt information. Det program som verkade bäst var Winamp, som innehåller funktioner för att läsa och skriva information i den fil som spelas för tillfället. Jag tog några filer och skrev in information i taggarna som jag sedan kunde använda för test.

Delproblem (e), öppna och kontrollera en fil

Lösning: Jag definierade klassen mp3file som innehåller allmän information om en mp3-fil. Denna får ”ärva” från biblioteksklassen File som finns i java.io. Genom detta kan jag efter hand lägga till en del funktioner som är speciella för min filhantering, och samtidigt kan jag använda de funktioner och datastrukturer som redan finns för att arbeta med filer. Deklarationen blir: Import java.io.File; public class mp3file extends java.io.File { private final String MP3_EXTENSION = "mp3"; .. public mp3file(String dir, String filename) { super(dir, filename); } }

Funktionen som har samma namn som klassen, d v s mp3file, är en s k ”konstruktor”. Det är en funktion som anropas när man skapar ett objekt av denna klass, d v s när man t ex skriver xx = new mp3file(..). Denna funktion gör för tillfället endast ett anrop till sin ”förälders” konstruktor för att knyta filens namn och katalog till objektet. För att prova att det fungerar att skapa ett objekt finns följande kod i Driver.main():

String dir = "C:\\Users\\Gemensamma downloads\\Java\\JAVA projekt\\testfiler";

String testFilename = "test.mp3"; testfile = new mp3file(dir, testFilename);

I Driver.main() anropas sedan en annan funktion i mp3file för att kontrollera om det är en mp3 fil: if (testfile.isMp3File()) { ... // Ok i så fall }


Koden för detta i mp3file är enkel: public boolean isMp3File() { return ((this.getName()).toLowerCase().

endsWith(MP3_EXTENSION)); }

Funktionen getName() finns i java.io.File och den returnerar en textsträng som här sedan omvandlas till små bokstäver genom toLowerCase() som är en standardfunktion i Java-bibliotekets String klass. Genom funktionen endsWith()jämförs de sista tecknen i filnamnet med texten ”mp3”. Om de sista tecknen stämmer returneras ”true”, annars ”false”.

Kommentar:Syftet med denna funktion är bara att snabbt filtrera bort alla filer som inte kan vara mp3-filer. För att avgöra om filen verkligen är av rätt format behövs andra kontroller. Men jag väntar med det eftersom jag får göra andra kontroller sedan när jag letar efter information.

Delproblem (f), läs ut ID3 v1 information

Lösning: Vissa filer har inga taggar alls, vissa har en tagg av ena sorten (v1 eller v2) och vissa har båda typerna. Den äldre varianten v1 är alltid 128 byte stor1. Om den finns så ligger den alltid sist i filen. Alla version 1 taggar börjar med bokstäverna TAG. Sedan följer, alltid i samma ordning, följande information:

De första fem fälten är alltid ren textinformation men ofta lämnas vissa fält tomma. Fältet för spårnummer är numeriskt och det är även fältet för genre. Det är kodat enligt en princip som de flesta följer. Det är dock ingen riktig standard.Så här kan en ID3v1 tag se ut om man tittar på den i ett redigeringsprogram: TAGSetting sun Chemical Brothers Surrender 1999CoOol

De sista två tecknen är binära. Med WinVi kan man se att spåret är 6 och genren 19, d v s Techno. Men titeln är fel – den borde egentligen vara ”The sunshine underground” och det visar att man inte alltid kan lita på informationen.1 En byte = ett tecken


Sångtitel 30 Tecken

Artist 30 Tecken

Album 30 Tecken

År 4 Tecken

Kommentar 28 Tecken

Spår 1 Byte

Genre 1 Byte

Programlogiken blir ganska enkel även om det tog tid att få det att fungera. Först definierar jag en klass som döps till id3v1. Den innehåller bl a en funktion kallad hasTag() som undersöker om det finns en tagg av v1 typ. Den tittar dels på filens längd, som naturligtvis måste vara större än 128 tecken (TAG_LEN nedan), dels kontrollerar den om de första tre tecknen är lika med textsträngen ”TAG” (finns i konstanten TAG_START): public boolean hasTag() throws IOException { RandomAccessFile inputFile = null; inputFile = new RandomAccessFile(mp3_file, "r"); if (inputFile.length() <= TAG_LEN) { return false; } long filePos = inputFile.length() - TAG_LEN; inputFile.seek(filePos); byte buffer[] = new byte[3]; if (inputFile.read(buffer, 0, 3) != 3) { throw new IOException("Could not read TAG"); } inputFile.close(); String testTag = new String(buffer, 0, 3, UNICODE); if (!testTag.equals(TAG_START)) { return false; } return true; }

I klassen finns även datastrukturer för att spara undan den information som hittas i taggen. De fylls på med funktionen readTag(). Först läser denna funktion hela v1 taggen, och sedan fyller den på datastrukturerna genom att läsa tecknen från de fasta positionerna på följande sätt: inputFile = new RandomAccessFile(mp3_file, "r"); inputFile.seek(inputFile.length() - TAG_LEN +

TAG_START.length()); byte[] buffer = new byte[TAG_LEN - TAG_START.length()]; if (inputFile.read(buffer, 0, TAG_LEN –

TAG_START.length()) != TAG_LEN - TAG_START.length()) { throw new IOException("Could not read tag"); } String tag = new String(buffer, 0, TAG_LEN –

TAG_START.length(),UNICODE); title = tag.substring(0, 30).trim(); artist = tag.substring(30, 60).trim(); ... // Resten av informationen

För att testa funktionerna finns i Driver.main() anrop av readTag() för testfiler och resultatet kontrolleras genom att innehållet i datastrukturerna skrivs ut.


När man läser filer använder man s k ”strömmar”. Ett objekt av typen java.io.File beskriver bara sökvägen till filen. Sedan måste man koppla den till en ström som man kan se som en ”rörledning” där data kan skickas till och från en hårddisk eller t ex en port. Det finns två sätt att göra det på. Det ena sättet är en Input/OutputStream och det andra är RandomAccessFile. Man kan egentligen använda vilket som helst i de flesta fall men enligt läroböckerna verkar det som om t ex OutputStream är tänkt att använda när man matar ut en mängd data i en följd till en fil. RandomAccessFile verkar användas när man skall ”hoppa” till olika bestämda ställen i en fil och läsa små datamängder åt gången. Från början använde jag InputStream men övergick till RandomAccess eftersom det verkade bättre för v2 taggarna.

Kommentarer: När man använder klassen Input/OutputStream kan man läsa och skriva data till filer på två sätt, antingen binärt eller som text. Om man använder binärt format skriver och läser man informationen som den är, d v s utan omvandlingar. Men om man läser eller skriver textsträngar omvandlas de mellan det format som gäller för operativsystemet (som kan vara olika) och den representation som gäller för strängarna i minnet. I Java använder man alltid en kodning som heter ”unicode” som är en 16-bitars standard. ASCII är ju bara på 8 bitar och kan därför inte klara t ex japanska vilket unicode kan.

När man använder RandomAccessFile är det alltid binär läsning så i exemplet ovan omvandlar jag bufferten till olika textsträngar. Jag hittade ett exempel på nätet hur det går till men fick problem i början. Anledningen var att när man skapar en textsträng från en mängd byte genom tag = new String(buffer, ..) måste man också ange att unicode skall användas för att konverteringen skall fungera. Detta hittade jag till slut i en tutorial på nätet.

Delproblem (g), läs ut ID3 v2 information

Lösning: Från början verkade problemet vara likadant som för v1 taggarna. Men det visade sig vara mycket mera komplicerat. Det tog tid att hitta information om formaten, och det blev också mycket svårare eftersom olika saker verkar gäller för olika versioner av ID3V2 standarden, och felen i vissa filer gjorde inte saken lättare. Efter hand som jag förstod hur komplicerat detta skulle bli fick jag dela in problemet i olika delar.


Allt detta gjorde jag inte i en följd utan jag fick hoppa mellan olika delproblem efter hand som jag lärde mig mera om hur det fungerade:

g1 : Ta reda på hur v2 taggarna är uppbyggda. g2 : Skapa klasser där informationen kan lagras. g3 : Skriv en funktion som kontrollerar om det finns en v2 tagg i en mp3

fil. g4 : Skriv funktioner för att läsa ut och beräkna storleksinformation och

positioner i filerna för olika typer av information. g5 : Skriv en funktion som kontrollerar om det finns en s k ”extended

header” och justera positionerna för det. g6 : Skriv funktioner för att läsa in, kontrollera och lagra de olika typerna

av information. g7 : Skriv testprogram för att kontrollera inläsningen.

Lösning (g1):Den första svårigheten med V2 taggar är att informationen kan ha en obegränsad storlek till skillnad från den fixa storleken för V1 taggen. Detta beror på att ID3 version 2 togs fram för att man skulle kunna lagra mera information. Den kan därför innehålla många fler detaljer om låtar. Men den största skillnaden är att V2 taggen dessutom kan innehålla i princip vilken binär eller textinformation som helst. Exempel är bilder på artister, länkar till olika webbplatser och HTML filer. Så här ser strukturen för V2 taggen ut i stort:

Header 10 byte

Förlängd header Obegränsad storlek

Informationsblock (frames) Obegränsade i storlek

Utfyllnad (extra info) Obegränsad i storlek

Avslutning 10 byte

Header:

Den första ”Headern” (överskriften) innehåller följande information: identifierare: 4 byte (text) versionsnummer 2 byte (binärt) flaggor 1 byte (binärt) storlek 4 byte (binärt)

Som framgår i beskrivningen av V1 taggen så är den konstant i storlek och informationen är relativt enkel att avkoda. Men det enda som man från början kan vara säker på för en V2 tagg är:

- Om den finns, så ligger den alltid allra först i filen- Den börjar med de tre ASCII-tecknen ”ID3”


Version: Det som framför allt skiljer mellan olika versioner är att högre versionsnummer har stöd för mera information. För varje högre versionssiffra (1, 2, 3 o s v) har olika typer av ”ramar” (frames) tillkommit, Mellanversioner, som t ex 3.1, 4.2 o s v innehåller oftast mindre justeringar.

Tyvärr verkar ID3 inte vara någon riktig officiell standard, d v s det finns ingen stor organisation eller en massa företag som utvecklar den. Tidigare fanns en förening (www.id3.org) som verkade ta mest men webbplatsen fungerar sällan och frågan är vad som egentligen kommer att hända framöver. Eftersom ”mp3-världen” mera fungerar som en löst sammansatt ”community” är det si och så med hur olika personer följer standarden och det ger praktiska svårigheter. Naturligtvis är det speciellt svårt när man som nybörjare börjar titta på innehållet i filerna och det inte stämmer med beskrivningarna.

Flaggor: De finns i en byte där värdet för varje enskild bit har en viss betydelse. För närvarande verkar det vanligaste vara att de fyra högsta bitarna i flagg-byten %abcdxxxx har följande betydelse:a: anger om ”unsynchronising” används för hantering av fel i filenb: anger om det finns en förlängd header eller ejc: anger om det är en taggversion under utveckling (d v s opålitlig)d: anger om det finns en avslutning (de 10 tecknen enligt ovan)

I mitt program är jag mest intresserad av den bit som anger om det finns en förlängd header eftersom programmet måste hoppa över den om den finns.

Storlek: Storleken på hela taggen anges alltså av fyra byte som man måste tolka olika beroende på om det finns en förlängd header eller ej. Om den finns så ingår den i den totala storleken. I denna storlek ingår även avslutningen på 10 byte (om den finns). Storleksinformationen ligger med den högsta (mest signifikanta) byten först.

Just storleksinformationen var mycket förvirrande i början. Förutom att storleken betyder olika beroende på hur flaggorna är satta så verkade siffrorna över huvud taget inte stämma. När man tittade på testfilerna med ett redigeringsprogram så verkade ibland storleken på headern vara större än hela filen. Efter en hel del letande på nätet hittade jag en beskrivning som förklarade detta. Tydligen är det så att olika versioner av MPEG-standarden innehåller olika typer av synkroniseringsinformation, d v s som talar om för mp3-spelaren när ljudinformationen och olika ljudblock börjar. I en del äldre varianter av MPEG användes den högsta biten för ett antal byte i början av ett ljudblock för sådan synkronisering. Detta verkar ha ändrats i nya varianter, men eftersom vissa äldre mp3 spelare letar efter sådan information kan det hända att de ”spårar


http://www.id3.org/

ur” om de hittar information där den högsta biten är ett-ställd. Ett sätt att undvika det är att informationen görs ”synch-safe”. Det betyder att man inte använder den högsta biten utan siffrorna förskjuts ett steg per byte, med början i den minst signifikanta byten. Ett exempel:

Bit nr: 7654 3210Byte 1: 0000 0001Byte 2: 0110 1101Byte 3: 1001 0010Byte 4: 1100 0111

Detta skulle kunna representera storleksinformationen för en väldigt stor ID3 v2 header, t ex med bildinformation. Här är alltså den högsta biten ett-ställd för både byte 3 och 4. För att undvika detta gör man om värdet till ”synch-safe integer” med följande algoritm:

- läs Byte 4 (minst signifikanta)- spara värdet för den högsta biten i denna byte, B4.7- nollställ B4.7- läs B3, spara de två högsta bitarna B3.7 och B3.6- skifta in den sparade B4.7 från höger i B3- nollställ B3.7- etc.

På detta sätt kommer det binära värdet att förändras till:Bit nr: 7654 3210Byte 1: 0000 1011Byte 2: 0011 0110Byte 3: 0010 0101Byte 4: 0100 0111

I mitt program blir algoritmen den omvända, d v s siffrorna måste byggas upp genom att börja med den mest signifikanta byten och skifta in rätt antal bitar successivt från vänster och på det sättet bygga upp ett normalt heltal som anger headerns storlek (se även avsnitt g4). Det var ganska svårt att inse hur detta hängde ihop och eftersom några av testfilerna var felaktiga var det ännu svårare.

Informationsblock (frames): Den för mitt program intressanta informationen finns i de frames, eller informationsblock, som ligger efter den inledande informationen. Varje Frame har sin egen header som ser ut på följande sätt: Frame ID: 4 tecken (text) Storlek : 4 byte (binärt) Flaggor : 2 byte (binärt)


Storleksinformationen på 4 byte är även i detta fallet ”synchsafe”. Storleken inkluderar inte Frame-headern om 10 byte. Flaggorna kan innehålla information som anger t ex komprimeringar och olika typer av kryptering. Mitt program använder inte denna information utan hoppar över flaggorna.

Efter flaggorna följer sedan själva informationen, som kan vara i både text och binärt format. Jag är i mitt program bara intresserad av textinformation. Jag började med en typ av information och byggde efter hand ut med flera typer. En svårighet är att informationen inte kommer i en viss ordning utan ibland kommer låttiteln först, ibland sist etc. Man får därför leta efter de olika ID som används som rubrik. Det finns ett ganska stort antal olika Frames. Några av de jag är intresserad av att läsa är: ID BetydelseTIT1: Grov kategorisering som t ex “klassiskt”. TIT2: Sångtitel. TALB: Namnet på album som innehåller sångenTOAL: Indikerar originalinspelning, t ex om sången är en nyinspelning eller cover.TRCK: Spårets nummer, om låten är från ett album.

De fyra inledande tecknen är alltså de nyckelord mitt program söker efter för att avgöra om det är information jag är intresserad av (se avsnitt g6).

Lösning (g2):Det verkade logiskt att ha en klass för de viktigaste begreppen. Som beskrivs ovan hade jag tidigare definierat klassen id3v1 för att ta hand om data och funktioner för den första typen och nu tillkom id3v2 för v2 taggen. På samma sätt som för v1 taggen definieras funktionen hasTag() och även funktionen readTag(). I klassen id3v2 definieras även en del konstanter för olika positioner i filen. Från början hade jag i id3v2 även en del datastrukturer för att spara undan den inlästa informationen.

Det verkade naturligt att skilja mellan den övergripande informationen i taggen (storlekar, flaggor mm) och själva informationsinnehållet i de olika blocken. Anledningen var att både själva klassen i sig och readTag() växte och blev allt mer omfattande eftersom hanteringen av taggen blev ganska komplicerad. I läroböcker och tutorials står att om man har bara några få klasser med nästan alla funktioner och all data i så är det ett tecken på att programmet inte är så ”objektorienterat” gjort och därför kan vara svårt att vidareutveckla. Då bör man t ex dela upp klassen i två eller t o m fler delar.

I det här fallet är ju hanteringen av hela taggen, beräkning av storlek och sökandet efter ramar ganska skilt från tagginnehållet så därför är det vettigt att skapa en ny klass för själva informationen. Denna kallas v2Frames och ansvarar


för att läsa in informationsinnehållet. Efter ytterligare arbete kändes det ändå naturligt att skapa ännu en klass med ansvar för att lagra och hantera ett enstaka datablock. Denna döptes till v2Frame. På så sätt kommer v2Frames att vara knuten till ett antal objekt (instanser) av klassen v2Frame.

Lösning g3, kontroll av headerDenna lösning gjordes på ungefär samma sätt som för v1 taggarna, d v s en funktion hasTag() kontrollerar om det finns en tag. Skillnaden är främst att funktionen letar allra först i filen och att den söker efter andra tecken.

Lösning g4, kontroll av storlekar etcAnsvaret för att läsa storleksinformation, flaggor och annan allmän information finns i id3v2.readTag(). Logiken ser ut på följande sätt:

- Kontrollera om det finns en v2 tagg genom att anropa hasTag()- Skapa en buffert och läs in de fyra byte som innehåller totallängden- Konvertera dessa fyra byte till heltalet tagLength. - Läs den byte som innehåller flaggorna och kontrollera den bit som

markerar om det finns en ”extended header”- Om det finns en sådan, läs in storleksinformationen för denna och

konvertera till heltalet extHeaderOffset- Räkna ut på vilken position i filen som datablocken börjar genom

beräkningen: sizeOfTag = 10 + extHeaderOffset + tagLength

För att kontrollera flaggbitarna och för att räkna ut storleksinformationen användes ett par funktioner som placerades i en speciell klass för ”diverse-funktioner”. Den enklare av dessa ser ut på ungefär följande sätt:

public boolean bitIsSet(byte b, int pos) { boolean isSet = false; if ((pos >= 0) && (pos < 8)) { isSet = ((b & (byte)(1 << pos)) != 0); } return isSet;}

Här används de två binära operatorerna ’<<’ och ’&’. Operationen ’A & B’ kombinerar två binära tal bitvis. Om bitarna i en viss position är ettställda för både A och B så blir även samma bit i resultatet ettställd. Om däremot denna bit är nollställd för antingen A, B eller båda så blir denna bit noll i resultatet. Detta kan man använda för att kontrollera om en viss bit är ettställd. Om t ex värdet för A är 8, d v s den fjärde biten från ”höger” är ettställd så blir resultatet av ’A & B’ bara skilt från noll om den fjärde biten är ettställd även i B.


Skiftoperationen << flyttar här alla bitarna ett steg till vänster i en byte, så efter operationen (1<<pos) får man ett tal där biten på plats ’pos’ är ettställd medan alla andra bitar är nollställd. Denna kombineras sedan med ’b’ för att kontrollera om resultatet blir skilt från noll.

Den andra viktiga funktionen som används här heter utils.charsToSynchSafeLong() och den fungerar som den algoritm för att skapa synchsafe heltal som beskrevs tidigare i dokumentet, fast tvärtom. Algoritmen utgår från den mest signifikanta byten (den första) och gör följande:

- Beräkna hur många positioner, räknat i antal byte, som denna byte skall skiftas (om det är den första byten av 4 skall den skiftas 3 byte åt vänster).

- Beräkna hur många bitar som egentligen tillhör nästa byte. Dessa bitar finns längst till höger. Samtidigt vet man då hur många bitar som tillhör denna byte, d v s resten.

- Använd operatorn ’&’ för att skaffa två tal genom att ”maska”, det ena genom att maska med de bitar som tillhör denna byte, den andra med de bitar som tillhör nästa byte.

- Skifta talen så många positioner till vänster som krävs för att bitarna skall hamna på rätt ställe med hänsyn till både vilken byte det är och hur många bitar som finns på ”fel” ställe i just denna byte. För detta används operationen ’<<’

- Addera resultaten till en delsumma. - Fortsätt på samma sätt med samtliga byte När alla byte hanterats

innehåller summan det konverterade heltalet.

Koden blir ungefär:public static long charsToSynchSafeLong(byte[] in, int firstPos, int noOfChars) { for (int i=firstPos; i < (firstPos+noOfChars); i++) { // Create a mask for bits belonging to the next byte. bytesToShift = noOfChars - 1 - (i - firstPos); synchMaskBits = 8 - bytesToShift; maskByte = 0xff >>> synchMaskBits; nextByte = in[i] & maskByte; // Remaining bits belong to this byte thisByte = (in[i] & (0xff - maskByte)); // Now add the values. This is shifted by // bytesToShift positions, adjusted for the // synchSafe bits belonging to the next byte. bitsToShift = (bytesToShift * 8) - bytesToShift; returnValue += (long)(thisByte) << bitsToShift; // Remaining part belongs to left bits of next byte returnValue += (long)(nextByte) << bitsToShift; } return returnValue;}


Lösning g5, kontroll av extended headerNär funktionen för att kontrollera en viss bit fungerade var det relativt enkelt att kontrollera om filen har en extended header eftersom detta (se ovan) anges av en viss bit i den byte som innehåller flaggorna: hasExtendedHeader = numeric.bitIsSet(buffer[0], EXT_HEADER_BIT);

Om biten var ettställd betyder det att man måste läsa in storleksinformationen, d v s de fyra byte som kommer omedelbart efter. Även de måste konverteras med funktionen utils.charsToSynchSafeLong().

Lösning g6, inläsning av informationenSvårigheten var att bestämma hur klasserna skulle definieras och var olika delar av inläsningen skulle ligga. Det finns säkert många olika sätt att göra det på.Så här arbetar programmet i stort:

- id3v2.readTag() anropas av ett program. Dessförinnan har en mp3 fil knutits till objektet genom konstruktorn som anropades när man skapade id3v2 objektet.

- Först beräknar readTag() positionen där informationen börjar på det sätt som beskrivs ovan.

- Därefter skapas ett v2Frames objekt: theFrames = new v2Frames();Konstruktorn v2Frames() förbereder inläsningen genom att skapa en vektor, allFrames, där den inlästa informationen skall lagras efter hand.

- Sedan tar det nya objektet över ansvaret för inläsningen med anropet: theFrames.readFrames(inputFile, HEADER_LEN + extHeaderOffset, tagLength);

- En ytterligare klass, v2Frame, bröts ut. Denna är till för att lagra innehållet i ett enda block. Den har en funktion för att läsa in sig själv, kallad readFrame().

Funktionen readFrames() blev ganska omfattande och delades upp i några delar.


Så här ser koden ut:while (!endOfFile && fileOffset < tagLength) { v2Frame theFrame = new v2Frame(); bytesRead = 0; if ((bytesRead = theFrame.readFrame(theOpenFile, filePos + fileOffset)) != 0) { if (keepFrame(theFrame)) { if (!storeFrame(theFrame)) { endOfFile = true; } } fileOffset += bytesRead; noOfFramesRead++; } else { endOfFile = true; }}

Funktionen arbetar alltså i en slinga tills den antingen läst hela taggen eller tills något oväntat inträffar. I klassen v2Frames (där alltså de inlästa v2Frame objekten lagras i en vektor) finns två viktiga hjälpfunktioner. Funktionen keepFrame() kontrollerar om det inlästa blocket är ett av dem jag vill behålla. I strängvektorn frameTypes finns de första tecknen för de typer jag är intresserad av (se ovan) och koden för att kontrollera blir:public boolean keepFrame(v2Frame theFrame) { for (int i = 1; i < frameTypes.length; i++) { if (frameTypes[i].equals(theFrame.getFrameType())) { theFrame.setFrameId(i); return true; } } return false;}

Hjälpfunktionen v2Frame.getFrameType() är en enkel hjälpfunktion som returnerar den tidigare inlästa typen för detta block.

Som framgår ovan anropar readFrames() funktionen v2Frames.storeFrame() när den genom anropet till keepFrame() kommit fram till att informationen skall sparas. Uppgiften för storeFrame() är att kopiera blockets information till de datastrukturer som sedan skall användas av användargränssnittet för att visa på skärmen eller skriva ut informationen i en lista. Anledningen till att jag gör en speciell funktion för detta är mest att det verkar vara en praktisk uppdelning. I början var jag inte säker på hur användargränssnittet skulle se ut och det verkade vettigt att lägga kopplingen till användargränssnittet på ett speciellt ställe.


Kommentar: Koden för denna del av programmet är kanske inte så svår. Rent tekniskt är den enklare än funktionerna för att omvandla byte till ”synchsafe” heltal. Men det var svårt att hitta en riktigt bra struktur för var informationen skulle lagras, var olika funktioner skulle placeras och vilken funktion som skulle ansvara för vad. Jag gjorde flera ändringar och fortfarande har jag känslan av att man skulle kunna göra helt annorlunda. Jag tror att det tar krävs mycket vana för att få en riktigt bra design.

Lösning g7, testprogramFör att testa funktionerna för v1 och v2 taggar lade jag upp ett antal testfiler. Vissa hade information i sig från början och en del fick jag komplettera genom att mata in uppgifter genom Winamp.

Därefter lade jag direkt i Driver.main() upp anrop till readTag() etc och för att kunna följa upp resultaten lade jag in många anrop där jag skrev ut olika data. I de fall där jag fick oväntade resultat lade jag in några extra utskrifter för försöka hitta var det gick snett. Exempel på ”debugutskrifter”:I Driver.main(): System.out.println("Hej, detta är det nya projektet, innan jag öppnar: " + dir + "\\" + testFilename);

I id3v2.readFrame() finns t ex: System.out.println("Börjar med att anropa hasTag"); if (!hasTag()) { System.out.println("Filen hade ingen läsbar Tag"); throw new IOException("Could not read tag"); }

Ett alternativ hade varit att använda sig av de testverktyg (s k ”debugger”) som finns i utvecklingsmiljön. Men det tar ganska mycket tid att ställa allting i ordning och det tar också längre tid att stega igenom programmet än det tar att göra utskrifter. Om det är ett komplicerat program eller om man inte kan skriva ut (t ex om det är ett system utan skärm eller felet är i själva utskriften) kan det säkert vara bra att använda debuggern.


Delproblem (h), läs ut mp3 Header information

Lösning: Det kan finnas en hel del information i ID3 v1 och v2 taggarna. Men jag hittade inte ett par som jag tyckte självklara data, som t ex låtens spellängd och samplingsfrekvens. Efter att ha läst en del dokument om mp3 standarden förstod jag att denna information inte finns i taggarna därför att den redan ligger i själva mp3 filen, i ett antal informationsblock före själva ljudinformationen. Jag delade in arbetet på ungefär samma sätt som för ID3v2, d v s:

h1 : Ta reda på hur mp3 informationen ser ut. h2 : Skapa klasser där informationen kan lagras. h3 : Skriv funktioner för att läsa ut informationen. h4: Skriv en funktion för att beräkna filens spellängd. h5 : Skriv testprogram för att kontrollera inläsningen.

Vissa av de steg som behövdes för v2 taggarna behövdes inte här.

Lösning (h1), mp3 informationenDen information som jag är intresserad av finns i den s k mp3 headern. Precis som med ID3 v2 taggen så tog det tid att klara ut hur denna är konstruerad. Svårigheten är inte som i ID3 v2 att det finns många versioner av standarden, för det verkar som om de flesta följer ungefär samma mönster. Men informationen är väldigt kompakt och kodad på ett ganska komplicerat sätt. Det går inte att bara läsa ett fält och översätta det till ett värde utan man måste avkoda bitfält och dessutom kombinera olika värden med tabeller för olika kodningsversioner. Mp3 headern består endast av 4 byte, där man bara använder sig av 2 ½ byte för att lagra allmän information. Om man tittar med WinVi på de första fyra byten i en musikfil kan det i binär (hexadecimal) form se ut på följande sätt:ff fb 90 44

Översatt till binära siffror blir det alltså:1111 1111 1111 1011 1001 0000 0100 0100

Efter att som vanligt letat bland mp3 och open-source sajterna på nätet hittade jag information om vad detta betyder. Jag beskriver här detta steg för steg:


Mp3 headern kommer direkt efter v2 taggen (om en sådan finns) och innehållet är enligt följande:

Sync:De första tolv bitarna är alltså synkroniseringsinformation, d v s en följd av ettställda bitar för att mp3 spelarna skall hitta rätt.

ID:Därefter kommer en ID-bit som indikerar vilken av de två övergripande ljukodningar som filen är gjord för: ID=0 betyder MPEG-2, medan ID=1 betyder MPEG-1. Den första versionen av MPEG-1 standarden kom redan 1992. Sedan dess har det utvecklats flera olika beräkningsscheman kallade Layer-1, Layer-2 och Layer-3. Det vanligaste för dagens musikfiler är Layer-3, och MP3 var från början en förkortning för ”MPEG-1 Layer 3”.I exemplet ovan är ID-biten ettställd vilket alltså betyder MPEG-1. Detta var förväntat eftersom MPEG-2 mest används för digital video.


Layer:För att spela upp musik i en dator är en variant lämplig, medan ett ännu mera kompakt format kan vara lämplig för ”strömmande media”, d v s musik som spelas upp direkt via nätet. Därför finns ett antal olika lager (”layer”) format definierade. De två bitarna anger vilket av de tre Layer1-3 som använts. För att avkoda detta krävs en tabell:

Bitvärden Betydelse0 0 Odefinierat0 1 Layer III1 0 Layer II1 1 Layer I

Om man tittar på innehållet i exemplet ser man att bitvärdena är 0 1 vilket betyder Layer III. Detta är också väntat och är egentligen ointressant för mitt program. Men informationen är nödvändig för att man skall kunna avkoda samplingsfrekvens och bithastighet.

Prot.Bit:Används inte här.

Bitrate:Bitrate, eller bithastigheten, anger vilken läshastighet som krävs för att spela upp informationen utan störningar. Bithastigheten är ett kvalitetsmått, d v s hög hastighet betyder vanligen högre kvalitet och den hänger samman med samplingsfrekvensen. Högre frekvens vid samplingen gör att fler mätvärden produceras som måste tas om hand av spelaren. En hög bithastighet ställer vid spelning över en Internetförbindelse också höga krav på överföringen och därför måste man ofta använda lägre hastigheter i ”strömmande media”.Den vanligaste kvaliteten ligger runt 128 bitar i en mp3 fil avsedd för lokal uppspelning.


De fyra bitar som anger bitrate i kbit/sekund kräver en speciell tabell för att kunna avkodas, där bitfält och kombinationen av kodning och lager används för att hitta rätt värde. Så här ser den ut:

Bitratevalue

MPEG-1,layer I

MPEG-1,layer II

MPEG-1,layer III

MPEG-2,layer I

MPEG-2,layer II

MPEG-2,layer III

0 0 0 0

0 0 0 1 32 32 32 32 32 8

0 0 1 0 64 48 40 64 48 16

0 0 1 1 96 56 48 96 56 24

0 1 0 0 128 64 56 128 64 32

0 1 0 1 160 80 64 160 80 64

0 1 1 0 192 96 80 192 96 80

0 1 1 1 224 112 96 224 112 56

1 0 0 0 256 128 112 256 128 64

1 0 0 1 288 160 128 288 160 128

1 0 1 0 320 192 160 320 192 160

1 0 1 1 352 224 192 352 224 112

1 1 0 0 384 256 224 384 256 128

1 1 0 1 416 320 256 416 320 256

1 1 1 0 448 384 320 448 384 320

1 1 1 1

Fig: Olika lager och bithastigheter

I exemplet ovan var de fyra bitarna som indikerade bithastigheten: 1 0 0 1 och eftersom filen är kodad i MPEG1 layer III kan man ur tabellen utläsa att bithastigheten är 128 bps.


Frequency:De två bitar som anger samplingsfrekvensen kräver också en tabell för att kunna avkodas. Den ser ut så här:

Värde MPEG-1 MPEG-2

0 0 44100 Hz 22050 Hz

0 1 48000 Hz 24000 Hz

1 0 32000 Hz 16000 Hz

1 1

I exemplet var bitarnas värde: 0 0Eftersom kodningen är MPEG-1 betyder det alltså att samplingsfrekvensen är 44.1 kHz, vilket är den vanligaste frekvensen för de låtar man brukar kunna ladda ner från nätet. För professionella tillämpningar räcker detta inte och de flesta ljudkort och musikprogram avsett för studios klarar 96 kHz eller t o m högre frekvenser.

Mode:Dessa bitar talar om ifall det är mono eller stereo. Som vanligt krävs en tabell:

Värde Mode

0 0 Stereo

0 1 Joint stereo

1 0 Dual channel

1 1 Mono

I exemplet är värdet: 0 1 och det betyder alltså ”joint stereo”. Jag är i mitt program just nu inte intresserad av denna information men det kan vara intressant vid mixning och det är möjligt att jag tar med det i en senare version.

Lösning (h2), klasser för att hantera mp3 headerJag bedömde inte att det skulle behövas speciellt många funktioner eftersom bithantering och sådant redan var gjort för ID3 v2. Jag definierade därför endast en klass, mp3header, med ansvar för att läsa in informationen, omvandla till användbara värden och lagra dessa. Jag insåg att det skulle behövas en del hjälpfunktioner och datastrukturer för t ex de olika omvandlingstabellerna, men jag kunde på det här stadiet inte riktigt förutse hur de skulle se ut.


Lösning (h3), funktioner för att hantera inläsningen av headernDet behövdes en funktion, readHeader(), med ansvar för att läsa de olika bitfälten, omvandla dessa till användbara värden med hjälp av tabellerna ovan och sedan lagra värdena. Programsekvensen är enkel:

- läs in hela headern på en gång i en byte vektor- läs in bitfälten- omvandla till de värden vi är intresserade av- lagra värdena i objektet

Utmaningen är att hitta ett bra sätt att översätta bitarna till motsvarande värden. Eftersom tabeller används i standarden kan det vara lämpligt att använda tabeller även i programmet. Detta kan bli en bra lösning eftersom de flesta bitfälten binärt bildar värdena 0, 1, 2 o s v och därför kan användas som index i t ex vektorer. Det finns säkert många sätt att lösa detta men i readHeader() är det gjort på följande sätt för alla värdena:

- maska bort alla ointressanta bitar- skifta de bitar som finns kvar längst till höger - använd det tal som blir resultatet som index i en vektor som innehåller det

värde vi letar efter.

För alla typer av data jag söker efter finns en vektor motsvarande beskrivningen ovan. Som exempel kan man ta bithastigheten. Som visas ovan finns bithastigheten i bit 3 och 4 av den tredje byten i mp3 headern. Den del av readHeader() som filtrerar ut denna ser ut på följande sätt, där headerBuffer[2] alltså är den tredje byten räknat från index 0:…private final int[] SampleRates ={44100, 48000, 32000, 44100};…bitMask = 0x0c; // 0000 1100int sampleRateIndex = (bitMask & headerBuffer[2]) >>> 2;sampleRate = SampleRates[sampleRateIndex];

Först maskas alltså alla bitar utom de två bort med operatorn ’&’, sedan skiftas bitarna två positioner så att de hamnar längst till höger. På så sätt får man ett tal mellan 0 och 3. Denna används sedan för att hitta rätt värde i den fördefinierade (d v s konstanta) vektorn SampleRates.

Lösning (h4), beräkning av spellängdFrån början när jag bara kände till de två typerna av ID3 header tyckte jag att det var underligt att det inte fanns något fält för låtarnas spellängd. I alla mp3 spelare visas spellängden så det var uppenbart att det fanns ett sätt att ta reda på det. När jag sedan upptäckte mp3 headern trodde jag att det var där man skulle kunna hitta spellängden men de beskrivningar jag hittat (se ovan) nämner inget stöd för det, och jag har heller inte hittat något program på nätet.


Det enda jag kunde komma på var att mp3 spelarna måste räkna ut spellängden på något sätt, och om man tittar närmare på mp3 headern kan man faktiskt göra en ungefärlig beräkning med den information som finns där. Algoritmen finns i den interna funktionen mp3header.setPlayLength() och fungerar som:

Om s = filens storlek i kbit, och v = bithastigheten (bitrate) i kbit/s, så blir den ungefärliga spellängden i sekunder: l = s/v. Före divisionen omvandlas filens storlek från byte till kbit genom att dividera med (1024*8), eftersom det går 1024 byte på en kbyte och 8 bitar på en byte.

Tester visar att resultatet stämmer ganska bra med det som visas i mp3 spelarna. Det slog från början ett antal sekunder (min beräkning visade ibland någon sekunder längre speltid). Men när jag i en senare version justerade filstorleken genom att dra ifrån storleken för ID3 v1 och v2 header stämde det bättre. Det är v2 headern som har betydelse eftersom den kan vara ganska stor i vissa fall.

Lösning (h5), testprogram för mp3 headerDessa tester gjordes på samma sätt, d v s med testfiler och utskrifter inifrån Driver() och readHeader().

Delproblem (i), AnvändargränssnittLösning: Detta problem kan göras hur stort som helst. Från början hade jag tänkte göra ett avancerat användargränssnitt men det hade krävt för mycket tid. Jag insåg tidigt att jag skulle få begränsa mig till något som var relativt enkelt.Problemet kan delas upp i följande delar:

1. Bestäm hur man skall arbeta med systemet.2. Bygg menyer, knappar och annat som behövs för att det skall fungera som

det är tänkt.3. Testa att allt fungerar.

Lösning (i1), arbetssättAnvändaren skall kunna göra följande i den första versionen:

- Välja vilken hårddisk programmet skall arbeta med. Helst skall man kunna välja flera.

- Starta sökningar som letar upp alla mp3 filer på den eller de hårddiskar som valts.

- Läsa taggar och mp3 header från de mp3 filer som hittats.- Visa informationen i ett fönster på skärmen- Skriva informationen till en textfil

I en kommande version bör man även kunna göra en HTML fil.


Lösning (i2), Menyer och knapparJag använde Javas Swing bibliotek för att göra följande, där den mesta koden finns i klassen GUIDriver:

HuvudmenyAnvändaren skall ha ett huvudfönster med en vanlig meny. Den skall se ut som det brukar i Windows, d v s med ”File” och ”Edit”.

Denna funktion byggdes med bland annat komponenterna JFrame (ett huvudfönster) och en JMenuBar som är menyobjekt som kopplas till en JFrame. Varje funktion som skall kunna väljas har en motsvarande JMenu. Koden ser ut på följande sätt: frame = new JFrame("MP3 File properties"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); // Create a menu bar JMenuBar menuBar = new JMenuBar(); // File Menu, F JMenu fileMenu = new JMenu(FILE_ACTION); fileMenu.setMnemonic(KeyEvent.VK_F); menuBar.add(fileMenu);

För att man skall kunna veta vilka val användaren gör måste man bygga funktioner som kan hantera händelser. Varje gränssnittsobjekt kan ha ett antal hanterare av olika slag. Man kopplar hanterarna till knappar, menyer eller annat objekt. Exempel på en sådan hanteringsfunktion: static class MenuActionListener implements ActionListener { public void actionPerformed(ActionEvent actionEvent) { if(SCAN_ACTION.equals(actionEvent.getActionCommand())) { scanDrives(); } if (..) { ... }

Menyn File ScanNär användaren väljer denna funktion skall programmet läsa in vilka mp3 filer som finns på den eller de hårddiskar som valts. Funktionen anropar ScanDrives som kontrollerar vilka hårddiskar som är valda och sedan anropar hjälpfunktionen theManager.getFileList() i tur och ordning för de valda diskarna. Funktionen läser in hela filträdet och lagrar alla filer den hittar i en vektor (datatypen Vector) som sedan kan användas av de andra funktionerna. Fördelen med att använda en vektor är att storleken kan växa efter hand.


Menyn File OutputMed denna funktion kan användaren välja placering och namn på den fil som programmet skapar. Funktionen använder sig av Javabibliotekets JFileChooser som är i stort sett färdig att användas.

Menyn File SaveFunktionen går igenom listan på alla filer som tidigare lästs in med Scan funktionen och anropar för varje fil funktionen doOneFile() som läser in v1 tagg, v2 tagg och mp3 header för varje fil och skapar ett mp3file objekt för varje. Dessa skrivs sedan till disk genom att funktionen anropar mp3file. streamToFile(). Den fil som används är den som användaren valt. Om ingen valts används en standardfil C:\tmp\mp3collection.txt.Funktionen streamToFile() formatterar inte informationen utan skriver rad för rad med en rubrik före varje datatyp.

Menyn File DisplayFunktionen gör motsvarande som Save, fast informationen visas på bildskärmen.För detta används en tabell av typen JTable som sedan kopplas till ett fönster. För att man skall kunna bläddra om tabellen blir större än fönstret krävs ett fönsterobjekt av typen JScrollPane. Funktionen löper igenom alla tidigare inlästa filnamn, anropar doOneFile() precis som vid skrivning till disk. Därefter kopieras informationen till tabellen som sedan knyts till fönstret enligt:

while (..) { source = (File)fileIterator.next(); file = new mp3file(source.getPath()); doOneFile(file); rowData[no] [0] = file.getName(); rowData[no] [1] = file.getArtist(); … } JTable fileTable = new JTable(rowData, columnNames); fileTable.setAlignmentY(JTable.CENTER_ALIGNMENT); JScrollPane tableScrollPane = new JScrollPane(fileTable); contentPane.add(tableScrollPane, BorderLayout.CENTER);

Menyn Save ExitMan kan lämna programmet på två sätt, antingen genom att välja Exit i menyn eller genom att stänga fönstret med den vanliga kryss-knappen. Från menyn lämnar man programmet med systemanropet exit(). Motsvarande görs automatiskt av fönsterhanteraren om fönstret skapats med valet EXIT_ON_CLOSE.


Menyn Edit DrivesDenna meny används för att användaren skall kunna välja vilken eller vilka hårddiskar som skall sökas igenom. Vid uppstarten av menysystemet anropas GUIDriver.InitFileSearch(). Denna förbereder genom att kontrollera vilka hårddiskar som finns installerade. För detta används systemfunktionen getRoots().

För att kunna välja hårddiskar används kryssrutor, vilket i Java heter JCheckbox. För att kunna använda dem måste de knytas till ett fönster, i detta fall av ”pop-up” typ som sedan kan stängas. JDialog är den vanligaste typen av sådant fönster. Så här ser koden ut för att skapa dialogen där det finns lika många kryssrutor som diskar (även disketter och CD fungerar): JDialog itemDialog = new JDialog(frame, "Choose Drives"); itemDialog.setBounds(100, 200, 200, 200); ActionListener DriveBoxListener = new DriveBoxActionListener(); contentPane.setLayout(new GridLayout(0, 1)); for (int i = 0; i < drives.length; i++) { driveBoxes[i] = new JCheckBox("Drive " + drives[i], includeDrives[i]); contentPane.add(driveBoxes[i]); driveBoxes[i].addActionListener(DriveBoxListener); }

Precis som för menyer så krävs något som tar hand om de händelser som kan uppstå. I detta fallet är det att användaren väljer eller väljer bort en disk. Hanteringsfunktionen här heter DriveBoxListener och den ändrar status från ”true” till ”false” eller tvärtom för den hårddisk som är kopplad till rutan.

Menyn Edit ItemsDenna funktion är inte aktiv ännu men tanken är att användaren skall kunna välja vilka datafält som skall vara med på listor och bildskärm. Detta kommer att hanteras med kryssrutor precis som vid val av hårddiskar.

Kommentar:Det kan se enkelt ut att göra användargränssnitt eftersom så mycket verkar färdigt. Men det är i praktiken svårare än att göra kod för t ex bithantering. När man jobbar med egen kod eller kortare program som bara använder sig av ”primitiva” funktioner är det lätt att göra fel men också ganska lätt att testa. När man jobbar med användargränssnitt har man ingen kontroll utan måste lita på att biblioteksfunktionerna fungerar som det är tänkt. När de då inte gör det (det händer nästan alltid) finns det egentligen inget bra sätt att testa, utan man får experimentera för att försöka hitta en lösning där man kan gå runt problemet. Det kan vara otroligt tidskrävande.


Jag upptäckte att de beskrivningar av gränssnittsobjekten som finns på nätet inte alltid stämmer eftersom det finns ett antal versioner av Java. Därför stämmer det inte heller med läroböckerna och detta kan ta mycket tid att reda ut. Och ibland går det helt enkelt inte att få saker att fungera. Vissa problem kan ta en kväll eller mer.

En annan svårighet är att de olika klasserna hänger ihop på ett ibland mycket komplicerat sätt. Man måste skapa objekten i en viss ordning, knyta dem till varandra i en viss ordning etc, som man måste experimentera fram.

Exempel på hur användargränssnittet ser ut finns i bilaga 1 sist i rapporten.

Delproblem (j), felhanteringMånga programmerare citerar ”Murphys lag” som säger ”allt som kan gå fel kommer att gå fel”. Även om man försöker testa allt kommer det förmodligen att finnas fel kvar. Några saker är viktiga för att programmet skall vara stabilt:

- Undantagshantering- Egna kontroller- Tester

Java verkar ha en bra felhantering. När saker går snett är det sällan som datorn hänger sig. Istället får man oftast en s k ”Exception”. På svenska brukar det kallas undantag. När programmet hoppar ur med en exception får man för det mesta en utskrift som talar om var felet uppstod.

När man använder sig av systemanrop, t ex i Java.System eller Java.File, så kan de ”kasta” undantag av olika slag för att signalera att det gick fel. Kompilatorn kräver att man antingen tar hand om de felen eller talar om att man inte tar hand om det. Om man vill kunna fånga felet måste man bygga in koden i ett ”fångstnät” som ser ut enligt: try {

// Kod som kan ge fel } catch (Exception ETT_UNDANTAG) { // Kod som hanterar felet }Om felet uppstår hoppar programmet ur den del som finns inom de första parentesen och kör den kod som finns i ”catch” delen. Om man inte vill bygga en felhantering måste man i klassens deklaration skriva ”throws ..” för att markera att klassen kan generera sådana fel.

Man kan definiera egna undantag också men det har jag inte gett mig in på i detta projekt.


Jag har lärt mig att man i princip inte kan testa för mycket. Men den viktigaste lärdomen är nog att man skall arbeta i små steg med tester mellan. Om man gör en massa ny kod innan man testar och det blir underliga fel så kan de vara svåra att hitta. Men om man testar oftare när man gjort mindre tillägg så vet man ju precis var felet måste vara. De svårare fel som uppstod i programmet var att vissa filer var helt felaktiga och därför gav helt tokiga uppgifter om storlekar på header o s v. Jag hade heller inte känt till att det i min dator fanns massor av mycket små mp3-filer som används som ljudeffekter av olika program, och för dessa verkar inget stämma i ens den mp3 headern som skall vara standard.

Framtida förbättringar

Förutom en del funktioner som t ex sortering så skulle det vara en klar förbättring att använda flera ”trådar”. I Java fungerar trådar som en delprocess som kan köra självständigt medan datorn utför andra uppgifter. I det nuvarande programmet är allting en enda process och det är inte alltid så lyckat. Om hårddisken är stor med många filer tar kommandot ”Scan” en del tid. Under den tiden ”fryser” datorn menyn så att man inte kommer in förrän kommandot är klart. Det vore också trevligt med något slags status som visar att datorn jobbar. I Javabiblioteket finns en ”progress indicator” som verkar smidig men det kräver att man kör flera parallella trådar.


Slutkommentar

När man tittar tillbaka på arbetet känns det som att jag egentligen gjort flera arbeten på en gång:

1. Rapport om digitalt ljud och filformat för digital musik2. Programmeringsprojekt3. Rapport med kommentarer om programmeringsprojektet, metodik mm.

Lärdomar: Det är svårt att bedöma hur lång tid saker tar. Det verkar som om allt tar

minst dubbelt så lång tid som man trodde från början, speciellt om det är första gången man arbetar med något. Jag borde ha haft en mindre ambitionsnivå från början men det var inte lätt att inse det eftersom jag inte hade någon erfarenhet. Jag hade heller inga synpunkter från någon handledare att utgå från eftersom jag inte hade någon handledning under den första halvan av arbetet.

Det är svårt att sätta gränser för omfattningen. Efter hand som tiden går är det lätt att arbetet sväller ut. Om jag skulle göra något liknande igen skulle jag försöka göra något ”minimalistiskt” från början och hellre utvidga arbetet efter hand om det finns tid.

P g a missförstånd lade jag ner för mycket tid på beskrivande text om digitalt ljud. Jag ville göra handledaren nöjd och tyckte själv att det var intressant. Men handledaren tyckte inte att det var så viktigt för arbetet. Resultatet blev att jag fick problem på slutet eftersom min handledare bad mig att komplettera med beskrivningar av själva programmet. Jag hade tänkt göra detta men kanske inte så omfattande som handledaren förväntade sig. Jag fick därför ägna en hel del fritid under min utlandspraktik med att göra kompletterande beskrivningar. Det man kan lära sig av detta är att det hade varit bättre att träffa handledaren mycket oftare. Och det hade antagligen varit bra att skicka exempel på olika delar i rapporten mycket tidigare för att få ”feedback”.

Jag upptäckt också att det är mycket svårare än jag trodde att programmera. Eller rättare sagt, det är svårare att programmera ”på riktigt”. Om jag inte hade fått en del hjälp därhemma när jag körde fast, och om jag inte hade kunnat hitta en del exempel på nätet att utgå från och lära mig av hade jag aldrig hunnit få fram något körbart under projektet.


Detta var mitt första riktiga program och det tagit väldigt mycket tid. Jag har uppskattningsvis lagt ner minst 200-250 timmar hittills. Mer än halva tiden har gått åt till att leta efter information och experimentera med olika filformat. Det tog också tid att få ihop en utvecklingsmiljö och lära sig hur den fungerade.

Jag har lärt mig väldigt mycket om både ljud, datorer och programmering. Jag tycker att Java fungerar mycket bra och vill gärna försöka lära mig mer. Jag har också fått mer respekt för svårigheterna med programmering. Det krävs både uthållighet, noggrannhet och logiskt tänkande.


Referenser

Internethttp://www.ueberdosis.de/java/id3.htmlhttp://wmcfproductions.com/mp3s.htmhttp://www.flashguru.co.uk/000100.phphttp://sourceforge.net/projects/jd3lib/ http://www.javazoom.net/javalayer/javalayer.htmlhttp://www.javazoom.net/javalayer/javalayerme.htmlhttp://www.programmersheaven.com/articles/userarticles/mark/tut3/tut3_1.htmhttp://www.programmersheaven.com/zone29/cat1044/index.htmhttp://www.programmersheaven.com/c/MsgBoard/wwwboard.asp?Board=7&src=28&Setting=http://media.uis.edu/classes/com541f01/leepper/research2/mpeg.pdfhttp://www.mpeg.org/MPEG/index.htmlhttp://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol3/sab/test.htmlhttp://www.sp303.com/mp3.htmhttp://www.diee.unica.it/pv2000/proceedings/papers/1.pdfhttp://media.uis.edu/classes/com541f01/leepper/research2/mpeg.pdfhttp://java.sun.com/docs/books/tutorial/uiswing/mini/index.htmlhttp://developer.java.sun.com/developer/onlineTraining/Programming/BasicJava1/front.html#swing

Böcker

- Börja med Java 2, Ivor Horton, Pagina Förlags AB 2001- Definitive Guide to Swing for Java 2, John Zukowski, APress 2002

Programvara Together Controlcenter v 6.0 från Togethersoft (sedan januari 2003 ägt av Borland Inc.)


http://developer.java.sun.com/developer/onlineTraining/Programming/BasicJava1/front.html#swing

http://developer.java.sun.com/developer/onlineTraining/Programming/BasicJava1/front.html#swing

http://java.sun.com/docs/books/tutorial/uiswing/mini/index.html

http://media.uis.edu/classes/com541f01/leepper/research2/mpeg.pdf

http://www.diee.unica.it/pv2000/proceedings/papers/1.pdf

http://www.sp303.com/mp3.htm

http://www.doc.ic.ac.uk/~nd/surprise_96/journal/vol3/sab/test.html

http://www.mpeg.org/MPEG/index.html

http://media.uis.edu/classes/com541f01/leepper/research2/mpeg.pdf

http://www.programmersheaven.com/c/MsgBoard/wwwboard.asp?Board=7&src=28&Setting

http://www.programmersheaven.com/c/MsgBoard/wwwboard.asp?Board=7&src=28&Setting

http://www.programmersheaven.com/zone29/cat1044/index.htm

http://www.programmersheaven.com/articles/userarticles/mark/tut3/tut3_1.htm

http://www.programmersheaven.com/articles/userarticles/mark/tut3/tut3_1.htm

http://www.javazoom.net/javalayer/javalayerme.html

http://www.javazoom.net/javalayer/javalayer.html

http://sourceforge.net/projects/jd3lib/

http://www.flashguru.co.uk/000100.php

http://wmcfproductions.com/mp3s.htm

http://www.ueberdosis.de/java/id3.html

Exempel på användargränssnitt

Grundfönster med huvudmeny

Här syns valmöjligheterna i menyn File.

Fönster för att välja hårddisk


Fönster för att välja fil för utdata

Fönster för att visa utdata i tabell

Här visas fönstret komprimerat. Det kan expanderas. Man ser att viss information saknas ibland. Ljudeffekten ”Heartbeats” saknar det mesta.


Exempel på utskrift till fil

När användaren väljer att skriva information till fil skrivs just nu all information. I en kommande version kanske man bör kunna välja vad som skall ”dumpas”, och det gäller speciellt om man gör en HTML fil för att visa på skärm. Just nu ser det ut t ex så här:

FileName: Linkin Park - Lying From You.mp3Song Title: Lying From YouArtist: Linkin ParkAlbum: MeteoraYear:2003 Comment: track: 1Genre: Not setBPM: Content: Composer: Length(s): 170Sample rate: 44100BitRate: 192

FileName: Summertime & Surinder Shinda.mp3Song Title: raat da na bole (summertime reArtist: Panjabi MC \raat da na boleAlbum: GrassrootsYear: 1996Comment: track: 3Genre: JungleBPM: Content: Composer: Length(s): 303Sample rate: 44100BitRate: 128


projektarbete : programmering i c++ · web viewmen i praktiken är nästan alla filer i ett...

Documents