Audioformaatit

versio 2.0

Jan-Markus Holm

Ohjelmistotekniikan seminaari

Tietotekniikan Cum Laude-harjoitustyö

22.4.1998

Jyväskylän yliopisto

Matematiikan laitos

Tiivistelmä

Seminaariesitelmä sisältää katsauksen audioformaatteihin. Tarkoituksena on aikaansaada mahdollisimman hyvä kuva siitä, millaisia lähinnä tietokoneaudioformaatteja on olemassa, sekä tutustua niiden rakenteeseen. Kirjoitelmaan on lisätty 22.4.1998 luvut, jotka käsittelevät audioformaatteja ohjelmointinäkökulmasta.

Sisällysluettelo

1. Johdanto
2. Ääni tietokoneessa
2.1. Digitaalinen audio
2.2. A/D- ja D/A -muunnokset
2.2.1.Digitaalisen suotimen käsite
2.2.2. Näytteistys- ja pidätyspiiri
2.2.3. A/D-muunnos
2.2.4. D/A-muunnos
2.3. Analogisen äänen käsittely
3. Aaltomuotoisen äänen perustekijät
3.1. Näytteistystaajuus
3.2. Näytekoko
3.3. Äänen tiedostokoko
4. Digitaalisen audion ja koodauksen perusteita
4.1. Tavallinen audiodigitointi
4.2. Kovalevyäänitys
5. Digitaalisen äänen koodaus
5.1. Audiosignaalin koodaus
5.1.1. Taajuuspainotettu koodaus (Frequency domain coders)
5.1.2. Alikaistakoodaus (Subband coding)
5.1.3. Muunnoskoodaus (Transform coding)
5.1.4. Hybridikoodaus (Subband/Transform)
5.1.5. Useampikanavaisten audiosignaalien koodaus
5.1.6. Olemassaolevien koodausalgoritmien tuolla puolen
5.2. Audion pakkausmenetelmiä
6. Audion koodaus- ja tallennusmuodot, eli tallennusstandardit ja audioformaatit
6.1. MPEG
6.1.1. MPEG-1 ja -2 sekä niiden rakenne
6.1.2. MPEG-koodaus
6.1.3. MPEG-audiokerrokset (layers)
6.1.4. MPEG-Layer 3
6.1.5. MPEG-4
6.2. RealAudio-formaatti
6.3. Audio IFF, AIFF, AIFC
6.4. NeXTin ja Sunin UNIX-formaatit .au ja .snd
6.4.1. SNDSoundStruct: Kuinka NeXT-järjestelmä esittää ääntä
6.4.2. SNDSoundStructin kentät.
6.4.3. Formaattikoodit
6.4.4. Pilkkoutunut äänidata
6.4.5. NeXT sndfile header -formaatti
6.5. IFF/8SVX-äänitiedosto
6.6. ADPCM
6.7. ACE/MACE
6.8. Microsoftin ADPCM (.wav ja .pcm)
6.9. IMA/DVA ADPCM (.wav ja .pcm)
6.10. CELP
6.11. GSM
6.12. LD-CELP
6.13. LPC-10E
6.14. ODA ACA
6.15. PCM
6.16. SB-ADPCM
6.17. SMDL
6.18. US Federal Standard 1016
6.19. Macintosh SND
6.20. MIME
6.21. Creative Voice (VOC)
6.22. Raw PCM
6.23. RIFF WAVE (.wav)
6.24. CCITT u-Law ja A-Law
6.25. AVR
6.26. Amiga MOD (.mod ja .nst)
6.27. Sample Vision (.smp)
6.28. Tandy Deskmate (.snd, .sng)
6.29. Sound Designer(II)/Audio Media
6.30. AVI
6.31. Dialogic ADPCM
6.32. Muita formaatteja
6.33. Sovellusohjelmista
7. Digitaaliaudioprotokollat
8. Audioformaatit ohjelmoinnissa
8.1 Windowsin äänenkäsittelyn pääfunktioluokista
8.1.1 MessageBeep
8.1.2 sndPlaySound
8.1.3 MCI-kutsut
8.1.4 WaveOut-kutsut
8.1.5 Äänilaitteiden tiedot
8.1.6 MIDI ohjelmoinnissa
8.1.7 Visual Basic
8.1.8 Muuta informaatiota
8.2 WWW-sovellukset
8.2.1 MIDI-tiedostot
8.2.2 WAV-, AU- JA AIFF -tyyppiset audiotiedostot
9. Yhteenveto
10. Lähteet ja lisämateriaalia

1. Johdanto

Seminaariesitelmäni pyrkii esittelemään mahdollisimman laajasti audioformaatteja ja -käsittelytapoja. Tieto on koostettu useista eri tietolähteistä. Aiheesta ei ole juurikaan löydettävissä erillistä kirjallisuutta, vaan aihepiiriä koskevaa tietoa on sisällytettynä muihin yhteyksiin. Näistä olennaisimpia audioformaatteja koskevia asioita on koottu tähän kirjoitelmaan.

Motivaationa kirjoitelmalleni on ollut oma kiinnostukseni aiheeseen. Lisäksi olen halunnut koota yhteen mahdollisimman paljon muutoin niin hajanaisen aiheryhmän tietoa. Seminaarikirjoitelmaksi tämä saattoi hieman venyä. Ajattelisin kuitenkin tämän olevan hyvänä pohjana 'peruskäsikirjaksi' itselleni, jota on mahdollista tarpeen vaatiessa aikojen saatossa täydentää. Erääksi valitettavaksi seikaksi muodostui myös ajan loppuminen, joten myöhemmin esille tulleita mahdollisia varteenotettavia tietolähteitä jäi tutkimatta.

Kirjoitelmassa esiintyy paljon tekijöitä, jotka voidaan ajatella soveltuvan useampaankin asiayhteyteen. Viittausten määrä olisi kasvanut niin suureksi, etten tämän vuoksi ole niitä käyttänyt, vaan lukijalla on mahdollisuus itse ottaa asiasta selvää kulloinkin kyseessä olevan asiasanan yhteydestä. Lisäksi liitteet sisältävät lisäinformaatiota useisiin kohtiin (mainittu erikseen ao. kohdassa).

MIDIä (Musical Instrument Digital Interface) sivutaan muutamien formaattien yhteydessä, sekä äänen ohjelmointia käsittelevässä luvussa. MIDI-ääni on viestejä esimerkiksi sähköisten soittimien (syntetisaattorit) ja tietokoneiden välillä. Se siis sisältää vain tietoa siitä, miten toiminta suoritetaan, eikä lainkaan yksittäistä signaalitietoa. MIDI on kuitenkin massiivinen järjestelmä, josta on saatavilla paljon tietoa niin kirjallisuudessa kuin tietoverkossakin. Lisätietolähteenä voin mainita esimerkiksi Musiikki internetissä -kirjoitelmani (Jan-Markus Holm, http://www.jyu.fi/~hojakr/Intermus.html, kevät 1997), jossa käsitellään mm. MIDIn yleisiä piirteitä.

Kirjoitelman aluksi käydään läpi ääneen liittyviä yleisiä seikkoja ja sen elektroniseen käsittelyyn liittyviä perusperiaatteita, sekä signaalinkulkua ja -käsittelyä. Luvussa 3 tarkastellaan äänen digitaaliseen muokkaukseen sisältyviä perustapahtumia ja yleisesti tietokoneella tapahtuvassa äänenkäsittelyssä huomioonotettavia tekijöitä. Tämän jälkeen siirrytään digitaalisen äänen ja koodauksen perusteisiin, josta päästään sujuvasti äänen koodauksen ja kompressointimenetelmien tarkastelemiseen.

Luvussa 6 tullaan kirjoitelman varsinaiseen pääteemaan, eli audion koodaus- ja tallennusmuotoihin, joita voidaan kutsua myös tallennusstandardeiksi tai audioformaateiksi. Sokeriksi pohjalle olen ottanut luvussa 7 esille tapauksia reaaliaikaisen tiedonsiirron digitaaliaudioprotokollista.

Omana erillisenä merkittävänä osionaan on luku 8, jossa käsitellään äänitiedostojen ohjelmallista käsittelyä ohjelmointiympäristöissä, kuten esimerkiksi C-kielessä. Tämä luku pitää sisällään niin ohjelmaesimerkkejä kuin sanallista selitystä ääniformaattien ohjelmoinnista.

2. Ääni tietokoneessa

Ääniaaltoja on mahdollista muokata ja käsitellä. Luonnollisessa ympäristössä ihminen voi työntää pumpulitupot korviinsa ja näin vaimentaa tulevia ääniaaltoja. Megafonilla ääntä voidaan vahvistaa ja eri instrumenteilla saatu ääni on suora tulos fysikaalisista ilmiöistä, kuten kielen tai ilmapatsaan värähtely. Koska ääni on oikeastaan ilmanpaineen vaihtelua ilmassa, voidaan se muuttaa esimerkiksi jännitevaihteluiksi. Tämä luku perustuu lähteisiin [El 94], [Ba 85], [Bu 93], [Fda 97] ja [Ko 93].

Elektroninen media tarjoaa mitä suurimpia mahdollisuuksia äänen muokkaamiseen. Elektronisessa muodossa ääntä voidaan mm. suodattaa, muuttaa sen aika-arvoja, kääntää takaperin, vertailla toiseen informaatioon, lajitella, kasvattaa tai pienentää intensiteettiä ja säröttää. Digitaalista informaatiota voidaan prosessoida eri prosessointilaitteilla, kuten esimerkiksi sekvenssereillä (engl. music sequencers) ja kovalevyäänittimillä (engl. direct-to-disk audio recorders).

Eräs elektronisen signaalin muokkaamisen perusparametreista on amplitudin (äänenvoimakkuus) muokkaaminen. Tämä tapahtuu linjavahvistimien avulla. Lisäksi ohjelmasignaalia on mahdollista muokata lukemattomilla muilla tavoilla. Tätä varten on suotimia (engl. filters), jotka toimivat eri medioita yhdistävinä prosessoreina. Nämä siis nimensäkin mukaisesti valikoivat tarvittavan informaation, äänen tapauksessa halutut taajuudet. Suotimia ovat muun muassa sulkusuotimet (engl. cut-off filters), yli- ja alipäästösuotimet (engl. high- and low-pass filters), sekä kaistansuotimet (engl. band-pass filters).

Signaalia voidaan myös tuottaa ja syntetisoida elektronisesti. Tästä voi olla joskus hyötyäkin. Esimerkiksi edullinenkin systeemi voi tuottaa laaja-alaisemman äänen kuin yksikään mekaaninen instrumentti tai luonnollinen äänilähde. Elektronisia signaaleja tuottava komponentti on nimeltään oskillaattori (engl. oscillator), joka on nimetty muodostamiensa oskilloivien aaltojen mukaan. Monimuotoisemmat signaalit muodostetaan modulaatiotekniikalla. Siinä signaaliin vaikutetaan toisen aallon tiedossa olevilla parametreillä (taajuus, amplitudi, pulssinleveys). Syntetisaattoripiirien äänenprosessointi perustuu pitkälti juuri tähän.

2.1. Digitaalinen audio

Äänenkäsittely tietokoneessa on aina digitaalista. Ääni voi olla peräisin useasta eri äänilähteestä, jotka voidaan yhdistää tietokoneessa. Mikrofonin tai muun äänilähteen välityksellä saadun analogisen audiosignaalin sisäänlukemiseksi tarvitaan esimerkiksi äänikortti. Digitaalisessa aaltomuodossa tallennetun äänen voidaan ajatella olevan kuin äänilähteestä tulevien ääniaaltojen kuvan. Tallennus ja toisto tapahtuvat tietokoneen äänijärjestelmän toimiessa digitaalisen ääninauhurin tapaan. Ääniaallot, puhe, musiikki tai hälyäänet, muuttuvat mikrofonissa sähköiseksi, analogiseksi värähtelyksi, joka johdetaan tietokoneen äänijärjestelmän analogia/digitaalimuuntimeen. Malli signaalin kulusta on esitetty kuvassa 1.

Ääni digitoidaan tietokoneeseen liitetyllä A/D-muuntimella (engl. Analog/Digital Converter). Tämä on mikropiiri, jolla värähtelystä (aalloista) otetaan näytteitä tasavälein (ts. aalto 'katkaistaan') ja otetaan siitä 'poikkileikkaus', joka kertoo aallon korkeuden (amplitudin) katkaisuhetkellä. Tämä tieto tallennetaan numeerisessa muodossa. Äänen digitoinnissa vallitsevat yleiset digitoinnin pelisäännöt. Tämän mukaan näytteenottotaajuus vaikuttaa äänen taajuuskaistaan eli äänen kirkkauteen. A/D-muunnoksen tasojen määrä (kvantisointi) määrää digitoidun äänen dynamiikan eli hiljaisten ja voimakkaiden äänien suhteen. Molemmat vaikuttavat digitoidun äänen sisältämään tiedon määrään ja siten myös näin saatavan tiedoston kokoon. Kun näytteitä otetaan riittävän tiheästi, esimerkiksi 22000 kertaa sekunnissa, niistä muodostuu varsin hyvä kuva alkuperäisestä ääniaallosta.

Seuraavassa pieni katsaus digitaalisen audion kehityshistoriaan:

• 1857 Leon Scott demonstroi fonoautografin (puhekoneen).
• 1937 Binäärikoodaus (PCM) keksittiin A.H. Reevesin toimesta.
• 1961 Digitaalinen kaiutus simuloitiin tietokoneisiin.
• 1967 NHK (Japan) demonstroi digitaalisen audionauhurin.
• 1971 Digitaalinen viivesysteemi esiteltiin.
• 1971 BBC demonstroi digitaalisen stereoaudionauhurin.
• 1972 Digitaalisesti masteroitu levy Nippon Columbialta, Japanista.
• 1972 PCM käytössä korkeatasoisissa äänilähetyksissä radiossa ja TV:ssä Isossa-Britaniassa.
• 1975 Tosiaikainen digitaalinen kaiutussysteemi käyttöön.
• 1976 Digitaalisesti tallennettu Caruso-äänilevy ilmestyi.
• 1976 BBC demonstroi 10-kanavaisen digitaalinauhurin.
• 1977 Useita ammattimaisia digitaaliaudioäänitteitä julkaistiin.
• 1979 Ensimmäinen signaaliprosessori julkistettiin (Intel 2920).
• 1980 Ajatus Compact Disc -systeemistä julkistettiin.
• 1982 CD-soittimet tulivat.
• 1982 THX-äänijärjestelmä (elokuva)teatteriin (Return of the Jedi).
• 1984 Ensimmäinen ammattimainen digitaalisen audion miksauskonsoli.
• 1985 AES/EBU digitaalisen audion liitäntä.
• 1986 Digitaaliset radiolähetykset (Digital Audio Broadcasting, DAB) alkoivat.
• 1986 R-DAT -standardi. Työ aloitettiin vuonna 1981.
• 1987 LaserDisc (laserlevy) CD-tasoisella digitaaliäänellä.
• 1989 Digital Satellite Radio (DSR).
• 1989 Nicam 728.
• 1990 Koti-THX.
• 1990 SCMS-turvajärjestelmä DATiin suojaamaan laitonta kopiointia.
• 1991 Digital Audio S-VHS.
• 1991 Dicital Compact Cassette (DCC) Philipsiltä.
• 1991 MiniDisc (MD) Sonyltä.
• 1992 DAB, 2. vaihe.
• 1992 Dolby Stereo Digital (SRD) (elokuva)teattereihin (Batman Returns).
• 1992 Parannuksia CD-äänen laatuun. Super Bit Mapping.
• 1993 ISO/MPEG-standardointi, vaihe 2; monikanavainen ja monikielinen audio.
• 1993 Digital Theatre System (DTS) (Jurassic Park).
• 1993 Video-CD. Full motion video CD-I:n kanssa. Digitaalinen video ja audio. VHS-tasoinen kuva.
• 1993 Digitaaliset näytteistystaajuusmuuntimet (Digital sampling rate converters).
• 1994 DAB-koelähetykset Suomessa.
• 1994 ISO/MPEG, vaihe 4.
• 1994 Dolby Surround Digital kotikäyttöön.
• 1997 DAB käyttöön suomessa.

2.2. A/D- ja D/A -muunnokset

A/D- ja D/A -muuntimet (engl. Analog-To-Digital and Digital-To-Analog Converter, ADC and DAC) ovat laitteita, jotka saattavat audiosignaalin tietokoneella käsiteltävään muotoon ja siitä takaisin. Nämä ovat siis erillisiä muunninpiirejä, jotka voivat sijaita esimerkiksi tietokoneeseen liitettävässä äänikortissa. Luku perustuu lähteeseen [Ba 85].

A/D-muunnin vastaanottaa analogisen jännitepulssin ja muuntaa sen diskreettien lukujen sarjoiksi prosessissa, jota voidaan kutsua digitoinniksi (engl. digitizing) tai näytteistykseksi (sämpläykseksi, engl. sampling). D/A-muunnin taas kääntää diskreetin sarjan jatkuvaksi analogiseksi jännitteeksi. Näitä piirejä käytetään joko erikseen tai yhdessä useissa eri digitaalisen median laitteissa.

A/D-muuntimen ulostulosignaali on nykyisin usein 8- tai 16-bittinen digitaalinen 'sana', joka sisältää analogisen jännitesignaalinäytteen amplitudin.

2.2.1.Digitaalisen suotimen käsite

Digitaaliset suotimet voidaan jaotella kahteen pääluokkaan: äärelliseen impulssivasteeseen (engl. Finite Impulse Response, FIR) ja äärettömään impulssivasteeseen (engl. Infinite Impulse Response, IIR) perustuviin. IIR-suodin on samanlainen analogisen kanssa siinä, että impulssi vaimenee eksponentiaalisesti ajan suhteen katoamatta koskaan kuitenkaan täysin. Yleisen digitaalisen suotimen lohkokaavio on esitetty kuvassa 2.

Analoginen signaali muunnetaan näytteistetyksi dataksi digitaalista suodatusta varten. Yleinen Nyquistin teoria näytteistyksestä kertoo sen, että näytetaajuuden tulee olla ainakin kaksinkertainen korkeimpaan sisääntulosignaalin perustaajuuskaistaan verrattuna prosessoituakseen virheettömästi. Tavallisesti käytetään analogista alipäästösuodinta (engl. Low-pass filter) signaalin esiprosessoimiseksi niin, ettei A/D-muuntimelle pääse kuin suuruudeltaan korkeintaan puolet näytteistystaajuudesta olevia signaaleja.

Näytteistys- ja pidätyspiirin (engl. Sample-and-hold circuit) tarkoituksena on varmistaa, ettei A/D-muuntimelle tulevan signaalin jännite muutu aikana, jonka analogisesta digitaaliseksi tapahtuvan muunnos vaatii.

Jokaisen näytteistysvaiheen lopuksi digitaalisuodin tuottaa 8- tai 16-bittisen 'sanan' D/A-muuntimelle, joka muodostaa analogisen amplituditiedon digitaalisesta merkistöstä riippuen. Joskus voidaan käyttää alipäästösuodinta signaalia pehmentävänä jälkiprosessointisuotimena eliminoimaan signaalissa mahdollisesti tapahtuneita virheitä.

2.2.2. Näytteistys- ja pidätyspiiri

Analoginen signaali näytteistetään ja pidätetään (pidätyspiiri) useasti analogisesta digitaaliseksi tapahtuvan muunnoksen aikana. Sisääntuleva analoginen signaali näytteistetään muunnoskierroksessa ensimmäisenä. Näytteistysvaiheen lopussa kapasitori (kuva 3) puretaan valmistauduttaessa vastaanottamaan uusi sisääntuleva näyte.

2.2.3. A/D-muunnos

Kuva 4 esittää 8-bittisen riittävän approksimaation A/D-muuntimelle (ADC). Tämän tyyppinen konvertteri vaatii kahdeksan kellobittiä muunnoksen suorittamiseksi sisääntulosignaalista huolimatta. Pääsääntöisesti tällaisella muuntimella on tarpeeksi suuri konversionopeus. Muunnos alkaa aloituspulssilla ja päättyy kahdeksan kellokierrosta myöhemmin. Sisääntulosignaali pysyy vakiona koko muunnosprosessin ajan, kunnes se kulkee näytteistys- ja pidätyspiirin kautta.

A/D-muunnin löytää sisääntulevalle jännitesignaalille V(in) 'digitaalisten sanojen' maksimin, joka tämän perusteella asettaa vertaimen (engl. comparator) ulostulojännitteen V(c) nollaksi. N-bittiselle konvertterille tämän voi suorittaa N:nä askeleena. Aluksi kaikki kahdeksan bittiä on asetettu nollaksi. Ensimmäisen askeleen aikana 'kaikkein tärkein bitti' MSB (Most Significant Bit) nostetaan jännitteeseen (+5V). Jos V(c) on silti nolla, on ensimmäinen askel suoritettu ja kuudes bitti nostetaan toisen kierroksen alussa. Jos V(c) on ollut nostettuna ensimmäisellä askeleella, on MSB laskettu takaisin alas nollaksi ja kuudes bitti nostettu toisen kierroksen alussa. Prosessia jatketaan niin kauan, että kaikki kahdeksan bittiä on asetettu.

Kuvan 4 jännitteen V- vertaimen negatiivinen sisääntulo voidaan ajatella kahdeksan binaarisen jännitteen lineaarisena summana kaavan

mukaisesti, jossa V(7) on MSB ja V(0) LSB (Least Significant Bit). Porrasmainen vastusverkosto on oikeastaan D/A-muunnin, joka uusii analogisen jännitteen lähimpänä oikeaa olevan bittijärjestyksen tarkistamiseksi sisääntulojännitteen ja uusitun jännitteen välillä. Maksimaalinen muunnosnopeus riippuu vertaimen tarvitsemasta ajasta ja vaihtomuutosten asettumisen vaatimasta ajasta. Jännitteen ja virran vastineet vertaimessa vaikuttavat vertauspisteeseen ja näin ollen koko A/D-muuntimen tarkkuuteen. Muunnoksen tapahduttua on digitaalisen ulostulon tarkkuus ±½ LSB.

2.2.4. D/A-muunnos

D/A-muunnos on kuvailtu jo aikaisemmin A/D-muunninapproksimaation esittelyn yhteydessä luvussa 2.2.3. Kuva 5 osoittaa D/A-muuntimen (DAC) perustuvan vastusportaistoon. Muunnosprosessi on hyvin nopea, sillä se riippuu ensisijaisesti yksinkertaisen operaatiovahvistimen asettumisajasta. Binäärijännite D/A-sisääntulossa täytyy olla tarkkaan verrattu tietyille korkeille ja matalille tasoille täsmällisen analogisen signaalin uudelleenmuodostumiseksi.

2.3. Analogisen äänen käsittely

Ääntä voidaan tietokoneessa käyttää tietyssä määrin myös analogisessa muodossa. Se käsittää äänen, joka tulee ulkoisesta lähteestä, eikä sitä ole tallennettu tietokoneeseen digitaalisessa muodossa käsiteltäväksi. Ulkoisesta lähteestä tulevaa ääntä voi kuitenkin ohjata tietokoneen avulla. Tärkein ulkoinen äänilähde on usein kuitenkin CD-asemassa oleva CD-äänilevy. Ulkoisena äänilähteenä voi olla myös puhelin, jolloin multimediatekniikka mahdollistaa tietokoneen käytön esimerkiksi puhelinvastaajana, tai erilaiset puhelinpalvelinsovellukset. Lisäksi on mahdollista liittää tietokoneeseen radio- tai televisioviritinkortti ja saada lähetyksistä tuleva ääni tietokoneen käytettäväksi.

3. Aaltomuotoisen äänen perustekijät

Seuraavassa perehdytään äänen laatuun vaikuttaviin tekijöihin. Se, miten hyvin tallennettu (ylipäätään tietokoneella prosessoitu) ääni toistettaessa vastaa alkuperäistä, riippuu siitä, miten tarkka kuva siitä on tallennettu. Tähän vaikuttaa ennen kaikkea kaksi tekijää: näytteistystiheys ja näytekoko. Kuvassa 6 on esitetty Windows-sovelluksella muokattu ääninäyte. Luku perustuu lähteisiin [Ko 93], [Bu 93] ja [AFF1 95].

3.1. Näytteistystaajuus

Näytteistystaajuus (engl. sampling rate) tarkoittaa sitä, kuinka tiheästi näytteitä on otettu. Näytteistystaajuus ilmoitetaan taajuutena, kiloherzeinä (tai herzeinä eli n kertaa sekunnissa), joka tarkoittaa näytteiden määrää sekunnissa (samples/s). Mitä tiheämmin näytteitä otetaan, sitä suurempi kiloherziluku ilmoittaa näytteistystiheyden ja sitä parempi on saadun äänen laatu. Koska näytteitä otetaan ajan mukaan etenevistä aalloista, näytteistystiheys määrää, miten korkeat äänet tallentuvat ja toistuvat. ADC ottaa tilannekuvan eli näytteen (engl. sample) analogisen signaalin tasosta tietyllä ajanhetkellä. Näytteistystaajuus ilmoittaa, kuinka usein analoginen signaali digitoidaan.

Äänen korkeus riippuu sen värähtelytaajuudesta. Jos näytteitä otetaan esimerkiksi 11 000 kertaa sekunnissa eli näytteistystiheys on 11 kHz, mutta äänen taajuus on vaikka 15 kHz eli 15 000 värähdystä sekunnissa, ei kaikista värähdyksistä saada lainkaan näytettä. Jos äänen taajuus on 11 kHz, saadaan kustakin ääniaallosta vain yksi näyte, joka ei riitä. Vasta kun kustakin aallosta saadaan kaksi näytettä (suurin piirtein pohjalta ja huipulta, positiivinen ja negatiivinen amplitudin taso), muodostuu niistä suurin piirtein oikea kuva. Siksi 11 kHz:n näytteistystaajuudella toistuvat hyvin vain 5,5 kHz:ä matalammat äänet. Hyvään toistoon vaaditaan kuitenkin useampia näytteitä kustakin aallosta. Nyquistin teoreeman mukaan tietyntaajuisen äänen toistumiseen vaaditaan siksi vähintään kaksinkertainen, ja korkealaatuiseen nelinkertainen näytteistystaajuus. Näytteistystaajuudet esitetään aina kanavakohtaisesti laskettuina, joten esimerkiksi äänitettäessä stereodataa 8000 näytettä sekunnissa, on näytteitä oikeastaan 16000 sekuntia kohden.

Tietyt näytteistystaajuudet ovat monestakin syystä suositumpia kuin toiset. Toiset tallennuslaitteet ovat rajattuja tietylle alueelle ja taas tietyt toistolaitteet tukevat suoraan niitä. Tavallisimpien taajuuksien suosio voidaan selittää yksinkertaisemmin myös kellotaajuutta jakavilla piireillä.

3.2. Näytekoko

Äänen laatuun vaikuttaa systeemin erottelukyky (engl. resolution). Mitä suurempi määrä signaalin tasoa kuvaavaa dataa on, sitä hienompi on kuvattavan signaalin tarkkuus. Signaalin resoluutiolla eli erottelukyvyllä tarkoitetaan siis sitä, millainen määrä bittejä on varattu kuvaamaan signaalin kunkin pisteen amplitudia. Mitä suurempi bittiresoluutio on, sitä suurempi määrä diskreettejä amplitudiarvoja voidaan esittää. Esimerkiksi normaalille audio-CD:lle on standardoitu 16 bitin resoluutio, jolloin jokaisen audiosignaalin pisteen amplitudiarvo voidaan esittää 65536 eri arvolla. Vastaavasti 8-bittisessä audiossa on vain 256 eri amplituditasoa.

Erottelukyvyn bittien lukumäärä määrää myös signaalin dynamiikan, jolloin jokainen bitti vastaa 6 dB. Täten 8-bittinen audio antaa 48 dB:n dynamiikan (kasettidekki), 12-bittinen 72 dB:n (avokelanauhuri), ja 16-bittinen 96 dB:n dynamiikan (lähellä ihmiskorvan dynamiikkaa).

Kvantisointia (engl. quantization) esiintyy silloin, kun lähdesignaalin arvot sijoittuvat erottelukyvyn mahdollistavien arvojen väliin. ADCn tapauksessa analoginen arvo pyöristetään eli kvantisoidaan lähimpään tarjolla olevaan digitaaliarvoon. Kvantisointi siis tuottaa eräänlaisen porrasefektin, joka voidaan havaita pienenä luonnottomuutena DACsta ulostulevassa signaalissa. Audion tapauksessa tämä voidaan havaita hieman rakeisena tai suhisevana äänenä. Kvantisoinnista aiheutuvat haittavaikutukset siis pienenevät resoluution kasvaessa.

Kvantisoinnissa täytyy aina ottaa huomioon virheiden mahdollisuus, joskin ne ovat hyvin pieniä. Suuriamplitudisella signaalilla on hyvin pieni korrelaatio signaalin ja virheen välillä. Virhe on siis erittäin satunnaista ja ilmenee analogisen valkoisen kohinan tapaan. Matalatasoisilla signaaleilla virheiden muoto signaalin suhteen muuttuu ja se ilmenee signaalissa säröytymisenä (engl. distortion). Korrelointia voidaan poistaa lisäämällä analogista signaalia, värinää (engl. dither), ensisijaisesti lineaariseen A/D-muuntimeen. Tästä hyödytään siinä, että kvantisoinnin virheet satunnaistuvat. Tällöin värinä ei peitä häiriöitä, vaan poistaa ne.

Värinäsignaalin lisäys siis minimoi säröytymisen. Se tarjoaa myös mahdollisuuden koodata amplitudeja pienemmiksi kuin 'vähäpätöisimmän bitin tekniikassa' (esim. LSB, luku 2.2.3.). Tällaisia tekniikoita ovat mm. pulssinleveysmodulaatio (engl. pulse width modulation) ja keskiarvoistus (engl. averaging). Värinä vaikuttaa ääneen digitointisysteemissä nostamalla äänentasoa hieman.

Äänentason vuodot yli normaalitasosta ilmenevät suhisevina ääninä. Tätä kutsutaan äänen rakeutumiseksi (engl. granulation noise).

3.3. Äänen tiedostokoko

Aaltomuotoisena tallennetun äänen vaatima tila T (tavuina) voidaan laskea kaavalla

jossa

• K on kanavien lukumäärä (mono=1, stereo=2),
• F on näytteenottotaajuus herzeissä,
• B on näytekoko (8 tai 16 bittiä) ja
• t on äänijakson kesto sekunneissa.

Kaavasta voidaan nähdä tiedostokoon nopea kasvu pyrittäessä korkealaatuiseen ääneen. Esimerkiksi 10 sekunnin CD-tasoinen stereoääni vaatii 1.7 Mt tallennustilaa, mutta 8-bittinen, 11 kHz:n monoääni vain 110 kt.

Tallentamisen ja toistamisen tarkkuus riippuu käytettävän tietokoneen äänijärjestelmän ominaisuuksista. Äänikortteja (A/D- ja D/A-muuntimia) on sekä 8- että 16-bittisinä. 8-bittinen äänikortti käsittelee vain 8-bittistä ääntä, mutta 16-bittisellä on mahdollista sekä 8- että 16-bittinen käsittely. Äänen lopullinen laatu riippuu luonnollisesti tallennustason lisäksi monista eri tekijöistä, kuten alkuperäisen äänen tasosta, tietokoneen äänijärjestelmän ominaisuuksista (kohinasuhde, häiriöttömyys) ja toistolaitteistosta (vahvistin, kaiutin, kuulokkeet) sekä kuunteluympäristöstä (melu). Äänen tallennustasoa määriteltäessä on siksi otettava huomioon äänijärjestelmän kokonaisuus ja arvioitava, millaisessa tilanteessa ja millaisin välinein ääntä tullaan tarvitsemaan.

4. Digitaalisen audion ja koodauksen perusteita

Tietokonepohjaiset digitaaliaudiotuotteet käyttävät hyväkseen muunnintekniikkaa, jossa ADC digitoi audion ja DAC muuntaa numeerisen informaation takaisin analogiseen muotoon. Laitteistovaatimuksissa ja digitaalisen esityksen muodoissa on eroja yksinkertaisten audiodigitoijien (engl. audio digitizers) ja kovalevyäänityssysteemien (engl. hard disk recording systems) välillä. Tämä luku perustuu lähteisiin [Bu 93] ja [Ida 96].

Digitaalitekniikalla pystytään koodaamaan lähes virheettömästi koko äänikaista, mutta sen laadukas toteuttaminen vaatii suuren bittinopeuden. Studiokäytössä yleisessä DAT-järjestelmässä (Digital Audio Tape) käytetään 48 kHz:n näytteenottotaajuutta sekä lineaarisesti 16 bitillä kvantisoitua PCM-signaalia (Pulse Code Modulation). Perinteisillä koodausmetodeilla päästään noin puoleen tämän vaatimasta tilasta, jolloin saavutettu hyöty on vasta liian pieni.

Seuraavassa muutamia esimerkkejä myös muista digitaalisista äänilähteistä. CD (Compact Disk) sisältää 16-bittistä, PCM-moduloitua, 44.1 kHz:stä signaalia. DCC (Digital Compact Cassette) on 16-18-bittistä, kompressoitua (PASC) signaalia. MD (MiniDisc) myös 16-bittistä kompressoitua ATRAC-signaalia. DSR (Digital Satellite Radio) on 16:sta 14:ään bittiin kompanderoitua (companding, kompressori-ekspanderi) signaalia.

Ominaisuuksina digitaalisella audiosignaalilla edellisiin on 32, 44.1 ja 48 kHz:n näytteistystaajuudet ja vähintään 16-bittinen pituus, sekä dynamiikka-alue, joka on laajempi kuin 96 dB. Vaatimuksina lähinnä ovat 18-bittinen A/D-muunnin ja vähintään 16-bittinen signaaliprosessori.

Koodausmenetelmiä käsitellään enemmän luvussa 5 ja koodausstandardeja luvussa 6.

4.1. Tavallinen audiodigitointi

Audiodigitoijassa on yleensä suhteellisen halpa ADC-systeemi muuntamassa balansoimattomasta sisääntulolinjasta audioaalloista saatavaa signaalia näytteistettyyn muotoon. Laatu on usein 8-bittistä näytteistystaajuuksilla 22 kHz:stä alaspäin aina 11 kHz:iin (jopa alemmas). DAC on samaa tasoa.

Laitteistoissa voi olla usein sisäänrakennettuja ominaisuuksia (kaiuttimia, (puhe)mikrofoneja). Esimerkiksi Macintoshin sisäänrakennettu audiojärjestelmä on 8-bittinen 22 kHz:n taajuudella. Tuotteet, kuten MacRecorder ja sisäänrakennettu mikrofoni ovat hyvä esimerkki edullisesta systeemistä.

Audion digitoinnin piirissä on suurena taipumuksena standardoida pääasiassa vain muutama näytteistystaajuus, tiedostoformaattien eroista huolimatta. Näitä ovat 8000 Hz:n 8-bittinen u-law mono, 22050 Hz:n 8-bittinen merkitsemätön mono ja stereo, sekä 44100 Hz:n, 16-bittinen merkitty mono ja stereo.

Laitteistojen kehitys menee eteenpäin huimaa vauhtia ja aina tehokkaampia laitteistoja ja lisäosia (äänikortit ym.) tulee markkinoille. Taulukossa 3 on kuitenkin listattuna suuntaa-antavaa laitteistotietoa äänenkäsittelyn näkökulmasta. On otettava huomioon se, että taulukkoon on merkitty laitetiedot ilman erillisosia. Laitteille on olemassa suuri määrä erillistä 'hardwarea' mm. äänityksiin ja digitointiin. Laitteet tarvitsevat luonnollisestikin erilliset ohjelmistot. Luku perustuu lähteeseen [AFF1 95].

4.2. Kovalevyäänitys

PC-tietokoneiden uusin aluevaltaus musiikkistudioissa ovat kovalevyäänittimet (engl. Hard Disk Recorder). Järjestelmä korvaa perinteisen analogisen moniraitanauhurin digitaalisella systeemillä. Kovalevyäänityksessä analoginen tulosignaali muunnetaan digitaaliseksi AD-muuntimella ja tallennetaan (yleensä SCSI-liitäntäiselle) kovalevylle. Toistossa tiedosto luetaan levyltä ja muunnetaan jälleen analogiseksi.

Äänen laatu on samaa tasoa kuin CD:ssä tai DATissa ja editointimahdollisuudet ovat suuret. Ääntä pääsee käsittelemään jopa tuhannesosasekunnin tarkkuudella.

Kovalevyäänittimiä on pääasiallisesti kahta tyyppiä: tietokoneen sisälle asennettavalla lisäkortilla toimivat ja ulkoiset, tietokoneesta riippumattomat, järjestelmät. Tässä esitelmässä keskitytään ainoastaan tietokoneeseen asennettaviin systeemeihin.

Sisäiset järjestelmät (esim. DigiDesign Session 8) käyttävät PC:n sisälle asennettavaa lisäkorttia, joka sisältää järjestelmän tarvitsemat AD-muuntimet ja ohjauselektroniikan. Tietokoneeseen asennettava ohjelmisto ohjaa kortin toimintaa. Etuna perinteiseen analoginauhuriin ja ulkopuoliseen digitaaliäänittimeen tarjoaa sisäinen kovalevyäänitin tutun käyttöliittymän ja toiminnan integroitumisen yhdelle koneelle.

Useimmat kovalevyäänittimet ovat 8-raitaisia. Kotikäyttöön on myös neliraitaversioita, esim. Turtle Beachilta. Turtle käyttää äänen tallennukseen ja toistoon tietokoneen omia kovalevyjä (myös AT/IDE-liitäntäisiä). Kovalevyäänitysten laitteistojen tekniikka edistyy huimaa vauhtia.

Ilmoitettu raitamäärä kovalevyäänittimissä ei kuitenkaan kerro koko totuutta. Useimmissa laitteissa hyödynnetään ns. non-destruktiivista editointia. Tämä tarkoittaa sitä, että jokainen yksittäinen äänitys joka laitteella tehdään, varaa levyltä oman tilansa. Vaikka sama kohta kappaleesta äänitetään samalle raidalle uudestaan, ei edellinen otto tuhoudu, vaan se on tarpeen vaatiessa palautettavissa. Näin käyttäjä voi tallettaa käytettävissä olevasta levytilasta riippuen suuren määrän 'virtuaaliraitoja', joista voidaan valita ne, joita lopulta käytetään.

Toinen raitamäärään vaikuttava seikka on tehdä ns. downmix. Downmixissä useampi raita yhdistetään miksaamalla yhdeksi ja tallennetaan tulos uudelle raidalle. Näin nämä kaksi ensimmäistä raitaa vapautuvat uudelleen käytettäviksi. Sama onnistuu tietenkin myös analogilaitteissa, mutta digitaaliäänityksessä ei kohina lisäänny raitojen yhdistämisestä, joten summaamista voidaan tehdä huomattavasti laajemmassa mittakaavassa kuin analoginauhureissa.

5. Digitaalisen äänen koodaus

Tavanomaisen audiosignaalin talteenotto ja säilytys sellaisenaan vaatii resursseja. Niinpä on tehty kokeiluja muistitilan pienentämiseksi. On esimerkiksi kokeiltu jättää hiljaisia tai muita ihmisen kuulemattomia hetkiä tallentamatta, poistaa usein toistuvia komponentteja tai muuttaa koodausta. Voidaan esimerkiksi tallentaa kahden näytteistetyn arvon erotus varsinaisten arvojen sijaan. Tämä vie vähemmän tilaa, sillä aalto ei juurikaan muutu näytteiden välillä. Edellä mainitut toimenpiteet perustuvat ns. säästö- eli reduktiokoodaukseen. Luku perustuu lähteisiin [Coas 96] ja [Wab 97].

Lisäksi hyödynnetään kuulokynnystä, joka on äänentaso, jolla ihminen pystyy kuulemaan tietyntaajuisen äänen. Ihmisen kuulokynnys on parhaimmillaan 4kHz:n taajuudella. Se on erittäin alhainen (~0 dB) 1-5 kHz:n taajuusalueella, jolla alueella kuulokynnyksestä ei ole hyötyä äänenkoodauksessa. Mutta koska korkeammilla äänillä (>16kHz) kuulokynnys nousee jyrkästi, käytetään koodausta näille alueille.

Edellisten lisäksi voidaan vielä mainita kriittinen kaista. Ihmiskorva analysoi kuulemaansa ääntä siten, että tietyn kriittisen kaistan sisälle osuvat taajuudet analysoidaan yhtenä kokonaisuutena. Tämä johtuu pelkästään ihmiskorvan fyysisistä ominaisuuksista. Esimerkiksi MPEG-koodauksessa signaali jaetaan lineaarisesti taajuuskaistoihin. Tällöin saadaan tilanne, jossa yksittäisen kaistan leveys saadaan pidettyä ihmiskorvan kriittisen kaistan edellyttämissä rajoissa.

Koodausta ja kompressointia käsitellään huomattavasti enemmän luvussa 6 audioformaattien yhteydessä.

5.1. Audiosignaalin koodaus

Hyvää, ellei erinomaista, audiokoodausta saadaan erilaisilla taajuuspainoitetuilla koodereilla (engl. frequency domain coders). Tällaisia ovat mm. alikaistakoodaus (engl. subband coding, SBC) ja mukautuva muunnoskoodaus (engl. adaptive transform coding, ATC). Kooderien erot riippuvat lähinnä äänen spektrikomponenttien määrästä, kvantisointistrategioista ja tapahtuvien koodausvirheiden peittämisestä. Tämä luku perustuu pääasiassa lähteeseen [Coas 96].

5.1.1. Taajuuspainotettu koodaus (Frequency domain coders)

Taajuuspainotetussa koodauksessa lähetettävän tiedon määrää vähennetään muokkaamalla alkuperäisestä signaalista lyhyempimuotoista äänispektritietoa. Lisäksi käytetään hyväksi korvan peitto-ominaisuuksia. Taajuuspainotetut kooderit tarjoavat suoran menetelmän taajuuskomponenttien häiriöiden muotoilemiseksi ja vaimentamiseksi niin, ettei niitä tarvitse lähettää.

Alkuperäisen signaalin spektri on jaettu taajuuskaistoihin. Jokainen taajuuskomponentti on kvantisoitu erikseen. Kutakin taajuuskomponenttia kohti käytettyjen bittien määrä vaihtelee. Mitä olennaisempi ja tärkeämpi komponentti on kyseessä, sitä hienommin se kvantisoidaan, ts. käytetään enemmän bittejä. Lähdesignaalin dynaamisen bittien sijoittelun kontrollointia varten tarvitaan eräänlainen spektrivaippa. Tämä tarkoittaa siis sitä, että bittien sijoitteluinformaatiota tulee lähettää jatkuvasti dekoodaajalle rinnakkaisinformaationa toiminnan tehokkuuden vuoksi.

Ratkaiseva merkitys taajuuspohjaisessa audiosignaalin koodauksessa on esikaikujen (engl. pre-echoes) esiintymisellä. Esimerkiksi, kun hiljaista kohtaa seuraa jokin perkussioääni samassa koodausalueessa (engl. coding block), on mahdollisuutena verrattaen suuri hetkellinen kvantisointivirhe. Esikaiuista voi tulla hyvin selvästi kuuluvia, varsinkin virheherkillä alhaisilla bittimäärillä.

Esikaiut voidaan peittää aikapohjaisella esipeitto-efektillä (engl. pre-masking). Ne voidaan välttää käyttämällä lyhyempiä koodausalueita. Kuitenkin rinnakkaisinformaation siirtoon tarvitaan suurempi bittimäärä, jos alueet ovat liian lyhyitä.

5.1.2. Alikaistakoodaus (Subband coding)

Lähdesignaali syötetään analysoivaan suodinsarjaan (engl. analysis filter bank). Se sisältää M-kappaletta kaistansuotimia taajuudellisesti rinnakkain niin, että sarja alikaistasignaaleja voidaan lisätä yhdistellen niitä halutulla tavalla ja näin tuottaa alkuperäinen signaali tai sitä lähellä oleva.

Jokaisen suotimen ulostuloa on häivytetty määrällä M, joka on siis summa alkuperäiseen signaaliin verrattavista alikaistasignaaleista. Jokaisen suotimen signaali on kvantisoitu erikseen.

Vastaanottopuolella jokaisen alikaistan näytteistystaajuutta lisätään vastaamaan alkuperäistä signaalia. Tämä toteutetaan lisäämällä signaaliin tarpeellinen määrä nollanäytteitä. Synteesisuodinsarjan (engl. synthesis filter bank) kaistaulostuloissa voi ilmetä laajentunutta, interpoloitunutta alikaistasignaalia. Jos systeemissä on 'täydelliset' jälleenmuokkaussuotimet, on summasignaali vastaava kuin kvantisoimaton lähdesignaali.

Esimerkkejä alikaistakoodauksesta ovat ISO/MPEG-audiokoodauksen tasot I ja II sekä Presicion Adaptive Subband Coding (PASC), jota käytetään DCC:ssä.

5.1.3. Muunnoskoodaus (Transform coding)

Sarja sisääntulevia näytteitä muutetaan lineaarisesti erikseen sarjaksi muunnoskertoimia. Tämän jälkeen nämä kertoimet kvantisoidaan ja lähetetään digitaalisessa muodossa dekoodaajalle. Siellä käänteiset muuntimet kartoittavat signaalin takaisin aikapohjaiseksi.

Tyypillisimpiä muunnoksia ovat diskreetti Fourier -muunnos (DFT) tai diskreetti kosinimuunnos (DCT) laskettuina FFT:n (Fast Fourier Transform) periaatteella. Diskreetit muunnokset voidaan esittää suodinsarjoina. Kaistojen impulssivasteiden lopullisia pituuksia voidaan kutsua lohkojen rajaefektiksi (engl. block boundary effect). ATC-kooderit käyttävät modifoitua DCT:tä (MDCT). Siinä käytetään päällekkäisiä analyysilohkoja, jotka voivat olennaisesti muuttaa näitä efektejä.

Nämä muunnokset täyttävät tehokkaasti heikosti näytteistetyn muunnosperäisen suodinsarjan. Niissä ei ilmene lohkojen rajaefektejä ja niillä on korkeampi muuntokoodaushyöty kuin DCT:llä. Lisäksi niiden perusfunktioilla on paremmat taajuusvasteet.

Esimerkkejä muunnoskoodauksesta ovat mm. Dolby AC-2 -koodaus ja AT&T:n Perceptual Audio Coder (PAC).

5.1.4. Hybridikoodaus (Subband/Transform)

Hybridikoodaus on yhdistelmä diskreetistä muunnoksesta ja suodinpankkien käytöstä. Erilaisia taajuusresoluutioita voidaan järjestää eri taajuuksille joustavasti käyttämällä suodinpankkien 'rypästä' ja lineaarista MDCT-muunnosta (engl. hybrid filterbank). MDCT-muunnos jakaa jokaisen alikaistasekvenssin myöhemmin taajuussisältöiseksi saavuttaakseen korkeataajuisen resoluution. Tästä esimerkkinä on mm. Sonyn Adaptive Transform Acoustic Coding (ATRAC), joka on käytössä MiniDiscissä ja MPEG-1:n layer III:ssa.

5.1.5. Useampikanavaisten audiosignaalien koodaus

Epämääräisyydet ja asiaankuulumattomuudet voidaan poistaa useilla tavoilla saaden näin kokonaisbittimäärää pienemmäksi. Näitä ovat kanavienvälinen riippuvuus ja kanavienvälinen peittoefekti. Lisäksi stereo-kuulumattomat komponentit monikanavasignaalissa, jotka eivät edesauta äänilähteiden paikantamisessa, saattavat tulla tunnistetuiksi ja uudelleenmuokatuiksi monofonisessa muodossa. Esimerkkeinä tästä mm. MPEG-2:n monikanavakoodaus ja Dolby AC-3 -koodaus.

5.1.6. Olemassaolevien koodausalgoritmien tuolla puolen

Parempi stereoesityksen binauraalisen (molemmin korvin kuultavan) kuvan aistimuksen ymmärtäminen johtaa uusiin koodausratkaisuihin. Useita hankkeita on jo valmisteilla korkeatasoisen koodauksen suorittamiseksi alhaisilla bittitasoilla (MPEG-2 ja MPEG-4). Myös digitaalisen surround-järjestelmän alueella on odotettavissa lisätoimia. Matkapuhelinverkoissa koodereiden ei tule toimia vain alhaisilla bittitasoilla, vaan myös pysyä vakaana purskevirheiden ja pakettihäviöiden alueilla. Tätä varten kehitellään virheidenpiilotustekniikoita.

5.2. Audion pakkausmenetelmiä

Signaalin koodausta jokaista arvoa tallentamatta kutsutaan kompressoinniksi (engl. compression, pakkaus). Kompressoinnista on eri valmistajien ja kehittelyryhmien omia malleja ja ne ovat vahvasti kehitystyön alla jatkuvasti. Tämä luku perustuu lähteisiin [Af 97], [Coas 96] ja [Bu 93].

Aluksi bittimäärän pienentäminen oli vaatimatonta. Ensiaskelia kompressoinnin maailmaan tarjoilivat muun muassa seuraavat tekniikat. Hetkellinen yhdistely (engl. instantaneous companding) muuntaa tasaisen 11-bittisen PCM:n epäsäännölliseksi PCM-esitykseksi (u-law, a-law). Eri muotoja lohkoyhdistelystä (engl. block companding) ovat järjestelmät kuten DSR ja NICAM. Mukautuvaa differentiaalista PCM:ää (ADPCM) käytetään mm. CD-I -järjestelmissä.

Audiodata on yllättävän hankalaa pakattavaksi tehokkaasti. 8-bittiselle datalle oli suhteellisen onnistunut Huffmanin koodausmalli, joka perustuu hyvien näytteiden välisiin 'deltoihin' eli erotuksiin. 16-bittisen datan pakkausmenetelmien kehittämiseen ovat yhtiöt, kuten Sony ja Philips, käyttäneet miljoonia dollareita. Philipsin luonnos aiheesta on PASC.

Audiodatan kompressointitapoja on useita, ja on syytä ottaa huomioon jokaisen hyvät ja huonot puolet. On otettava huomioon myös se, että jokainen äänitiedosto (eri formaateissa) voidaan koodata usealla eri tavalla. Esimerkiksi AIFF-tiedostot voidaan purkaa (engl. uncompress) ja pakata MACElla tai kompressoida vaikka ADPCM/IMAlla.

Kuvataan seuraavaksi hieman yleisimpiä kompressointimenetelmiä, sekä niiden vahvuuksia ja heikkouksia. On huomioitavaa, että kaikki menetelmät ovat todellisuudessa häviöllisiä eli ne kompressoivat näytteistyksen laadun kustannuksella.

Julkiset äänenpakkausstandardit saavat yhä suurempaa suosiota. Näitä ovat mm. CCITT G.721 (32 kbit/s ADPCM (Adaptive Delta Pulse Code Modulation)) ja G.723 (24 ja 40 kbit/s ADPCM). Esimerkiksi Sun Microsystems on asettanut lähdekoodinsa liitteenä näihin algoritmeihin (kuten G.711, joka määrittelee u-lawin ja a-lawin).

MACEn pakkaus ja purku ovat äärimmäisen nopeita, mutta näytteistyksen laatu heikkenee aika paljon. MACEn nopeudesta on osoituksena mm. se, ettei esimerkiksi QuickTime-elokuvan ääniraidan (MACE-kompressoitu) dekoodaaminen tietokoneella lisää merkittävästi tietokoneen kuormaa. MACE-koodaus kuuluu pääsääntöisesti Macintosh-maailmaan, sillä muut järjestelmät eivät käsittele MACEa helposti. MACE tukee vain 8-bittistä äänidataa. Kompressiosuhteet ovat 3:1 ja 6:1. Huonosta yhteensopivuudesta ja alhaisesta näytteistyksestä johtuen en pitäisi MACEa kovin varteenotettavana vaihtoehtona.

IMA/ADPCM -systeemi on hyvä vaihtoehto MACEn ja MPEGin välissä. IMA tarjoaa varteenotettavan nopean koodauksen ja purun sekä laskee näytteen tasoa vain hieman. IMA-standardin pakkaussuhde 16-bittiselle äänelle on 4:1 (8-bittistä ei tueta).

MPEG (Motion Picture Experts Group) on kehittänyt standardeja käsittämään yhdistettyä audio-visuaalista tiedonsiirtoa. Standardi tunnetaan lyhenteellä MPEG. Audiossa MPEG noudattaa psykoakustiikan perusperiaatteita, eli ottaa huomioon sen, kuinka aivot tulkitsevat äänen laadullisia seikkoja ja mitä taajuusalueita korva aistii herkimmin. MPEG-standardi vaatii myös suorituskykyä laitteistolta. MPEGistä kerrotaan lisää luvussa 6.

U-Law on nopea 2:1 -pakkausmenetelmä 16-bittiselle Sun Microsystemsin käyttämälle audiolle. Tällä kompressointimenetelmällä on kenties suurin yhteensopivuustuki audiokompressointimenetelmien kentässä. Koodausstandardeja esitellään tarkemmin luvussa 6.

6. Audion koodaus- ja tallennusmuodot, eli tallennusstandardit ja audioformaatit

Kautta historian lähestulkoon joka laitteistolla on ollut oma tiedostotyyppinsä audiodataa varten. Toiset niistä ovat enemmän tai vähemmän yhteensopivia, mutta yleensä kaikki tiedostoformaatit ovat muunnettavissa toiseksi, tosin joskus informaatiota hukkaavasti. Tämä luku perustuu lähteisiin [Af 97], [Ko 93], [AFF1 95], [AFF2 95], [Ja 97], [Pa 96], [Fr 97] ja [Da 95].

Digitaalisen audion tallennusstandardeja käsittelevät sekä yksityiset että julkiset organisaatiot. Aktiivisesti tällä alueella toimivia organisaatioita ovat mm.

• ISO/IEC JTC1/SC18: JTC1 on ensimmäinen ja ainoa ISOn ja IEC:n 'Joint Technical Committee' toimien informaatioteknologian alueella. JTC1:n alakomitea SC18 toimii mm. dokumentoinnin parissa.
• ISO/IEC JTC1/SC29 on JTC1:n alakomitea, jonka vastuualueina on koodiesitykset audiolle, kuvalle, multimedialle sekä hypermedialle.
• European Telecommunications Standards Institute (ETSI).
• International Telecommunication Union (ITU) (aikaisemmin CCITT: Comité Consultatif Internationale de Téléphones et Télégraphes).
• Digital Audiovisual Council (DAVIC).

Äänen tiedostoformaatit ovat laitteen muihin piirteisiin verrattuna oma, erillinen osa-alueensa. Tiedostotyypit voidaan jakaa kahteen eri kategoriaan. Itsekuvailevissa (engl. self-describing) tiedostotyypeissä laiteparametrit ja koodaus ovat määriteltyinä jonkinlaisena erillisenä otsakkeena, 'headerina'. 'Raa'oissa' (engl. raw) formaateissa laiteparametrit ja koodaus ovat yhdistettyinä. Itsemäärittelevät formaatit muodostavat oman 'koodausperheensä', jossa otsakekentät ilmaisevat tapauskohtaisen käyttötarkoituksen, toisin kuin otsakkeettomat formaatit, jotka eivät salli parametrivariaatioita.

Otsakekentät sisältävät näytteistys(laite)parametrejä ja muuta informaatiota (kuten äänen kuvaus- ja tekijänoikeustietoa). Useimmat headerit alkavat nk. maagisella luvulla (engl. magic number) (kts. luku 6.4.2.), joka on jokaiselle formaatille ominainen luku. Jotkut formaatit eivät välttämättä määrittele mitään otsakekentässä, vaan ne muodostuvat osioista, joissa itsessään on sisällä osiot koodausinformaatiosta. Datan koodaus määrää sen, millä tavoin näytteet tallennetaan (esim. ovatko ne merkittyjä, merkitsemättömiä, tavuina vai lyhyinä kokonaislukuina). Myös kanavien lomittaminen on tietynlaista koodausta.

Tässä luvussa perehdytään varsinaisesti audioformaatteihin. Standardit ja formaatit on käsitelty tyyppikohtaisesti. Jokaisen kohdalle on kerätty niihin liittyvää olennaista, ja ylipäätään saatavilla olevaa, tietoa. Luvussa sijaitsevat sulassa sovussa nekin formaatit, jotka voitaisiin yleisesti ryhmitellä vaikka koodaukseksi, kompressoinniksi tai normaaleiksi tiedostoiksi. Kuitenkin useista niistä löytyy yhtymäkohtia toisiinsa.

Joidenkin formaattien kohdalla on esitelty myös koodausmetodeita ja (tieto)rakenteita. Karkeana yleistyksenä voitaisiin sanoa niiden olevan samankaltaisia useiden muidenkin formaattien kohdalla, joten kirjoitettuja pätkiä kannattaa ajatella tukirunkoina myös muille tapauksille.

6.1. MPEG

MPEG (Moving Pictures Experts Group) (tiedostotarkentimina mm. MPG:t .mp2 ja .mp3) on ISOn (International Standard Organization), eli kansainvälisen standardoimisliiton komitea, joka kehittää liikkuvan kuvan ja audion pakkaamisen standardeja. Tämä alati laajeneva komitea on perustettu vuonna 1988 ja edustajia on 20 maasta.

MPEG/audio on geneerinen äänen kompressiostandardi. Useista vokaalimalleihin perustuvista puheelle optimoiduista koodausmenetelmistä poiketen se kompressoi signaalia olettamatta mitään itse lähteen luonteesta. MPEG/audio koodaa kaiken, minkä ihmiskorva voi kuulla. Standardissa on useita kompressiomoodeja. MPEG/audion bittijonoon voidaan lisäksi kohdistaa satunnaishakuja ja suorittaa nopeutettua kelausta.

MPEG-komitea, kuten muutkin standardoimiskomiteat, luo standardeja versioittain. Tämän vuoksi myös MPEG on nimennyt standardinsa numeroimalla ne taulukon 4 osoittamalla tavalla.

MPEG-1 ja -2 ovat täysin valmiita standardeja, joita useimmat äänen ja/tai kuvan pakkausta tarvitsevat sovellukset käyttävät. Molemmat standardit koostuvat taulukossa 5 esitellystä neljästä pääosasta.

6.1.1. MPEG-1 ja -2 sekä niiden rakenne

MPEG-1 ISO/IEC JTC1/SC29 WG11 (tunnetaan myös nimellä Moving Pictures Expert Group) on ensimmäinen, muttei suinkaan vähäpätöisin standardi. Se sai kansainvälisen standardin aseman lokakuussa 1992. Siinä on viisi osaa, joista neljä on MPEG-1:lle ja MPEG-2:lle yhteisiä. Viides osa on ohjelmistosimulaatio, joka on raportti kolmen ensimmäisen osan teknisestä ohjelmistorakenteesta. Näytteenottotaajuudet MPEG-1:ssä ovat 32, 44.1 ja 48 kHz.

Kompressoitu bittijono voi tukea yhtä tai kahta äänikanavaa jollakin neljästä vaihtoehdosta:

• yhden kanavan monomoodi,
• kahden riippumattoman äänikanavan monomoodi,
• stereokanaville stereomoodi, jotka jakavat keskenään bitit, mutta eivät käytä yhdistettyä stereokoodausta,
• yhdistetty stereomoodi, joka hyödyntää joko stereokanavien välistä korrelaatiota tai kanavien välistä vaihe-eroa, tai molempia.

MPEG-1:llä on ennalta määrätyt bittinopeudet. Kompressoidulla bittijonolla voi olla useita ennalta määrättyjä kiinteitä nopeuksia välillä 32...224 kbit/s kanavaa kohti. Kompressiotasoja MPEG-1:llä on kolme erilaista.

Lisää standardin yksityiskohdista löytyy julkaisusta [ISO/IEC 11172-3:1993 Information technology -- Coding of moving pictures and associated audio for digital storage media up to about 1,5 Mbit/s -- Part 3: Audio].

MPEG-2 ITU ja ISO/IEC JTC1/SC29 WG11 on MPEG-1:n seuraaja ja valmistui marraskuussa 1994. Tämän standardin tarkoitus ei siis ole korvata MPEG-1:stä, vaan täydentää sitä. Tästä syystä MPEG-2:n yhdeksästä osasta viisi ensimmäistä ovat lähes samoja kuin MPEG-1:ssä.

MPEG-2:ssa on monikanavaäänituki. Se tukee viittä hifiaudiokanavaa. Nämä ovat pääkanavat (vasen & oikea etu), keskikanava, sekä takakanavat (niinsanotut surround-kanavat). Lisäksi on optionaalinen pienitaajuuksinen lisäkanava, joka on tarkoitettu subwoofer-informaatiolle eli alhaisimmille taajuuksille. Tämä kanava on nimetty LFE:ksi (engl. Low Frequency Enhancement).

Standardissa on myös lisäys seitsemän itsenäisen kanavan järjestelmälle, jolloin saadaan lisää sovelluksia standardin piiriin. Tämän lisäyksen pääkäyttökohteena on kuitenkin monikieliaudiodatan tallennus.

MPEG-2 ja MPEG-1 on toteutettu keskenään yhteensopiviksi. Eteenpäin yhteensopivuuden mukaisesti MPEG-2:n pitää hyväksyä kaikki MPEG-1:n näytteenottotaajuudet ja bittinopeudet. Taaksepäin yhteensopivana MPEG-1:n koodekki osaa avata MPEG-2:lla tehdyn koodauksen. Matrixing-laskentametodilla surround-informaatio lasketaan mukaan downmix-koodauksessa, jossa MPEG-1:n dekooderilla koodataan auki MPEG-2:sen monikanavaista informaatiota. MPEG-2:ssa on myös pienempiä näytteenottonopeuksia.

Standardi sisältää 32, 22.1 ja 48 kHz näytteenottonopeuksien lisäksi näiden puolinopeudet (16, 22.05 ja 24 kHz).

Bittijonot ovat alhaisemmin kompressoituja. Standardi sisältää lisäksi matalia nopeuksiin 8 kbit/s saakka kompressoituja bittinopeuksia.

Lisäinformaatiota on saatavissa lähteestä [ISO/IEC DIS 13818-3/ITU H.222 Information technology -- Coding of moving pictures and associated audio information -- Part 3: Audio].

MPEG-1 ja MPEG-2 -standardien audio-osa (numero 3) määrittelee MPEG-audiokoodauksen perusrakenteen, joka koostuu kolmesta kerroksesta (engl. layer). Näitä kutsutaan myös kolmeksi algoritmiksi. Layer on terminä yleisesti käytössä monissa kielissä, ja on näin joissakin yhteyksissä käytetympi nimitys kuin kerros. Layerit ovat tehokkuusjärjestyksessä Layer 3:n ollessa tehokkain ja Layer 1:n taasen yksinkertaisin.

6.1.2. MPEG-koodaus

MPEG-koodauksen perustana on MUSICAM-koodaus. Tämä on algoritmi, joka kehitettiin ennen MPEG-standardeja. Algoritmi oli siinä määrin hyvin tehty, että se otettiin käyttöön MPEGissä. MUSICAMista tehtiin yksinkertaistettu versio, joka lanseerattiin käyttöön Layer 1:ssä. Huonona puolena MPEG-1:ssä on se, että se tarvitsee varsin suuren bittinopeuden, eikä siis pakkaa audiodataa tehokkaasti.

MPEG-koodauksen perusrakenteen ensimmäisessä vaiheessa PCM-audiosignaali jaetaan alikaistoihin, kunhan se ensin muutetaan taajuusjakoiseksi käyttämällä suodinpankkia. Seuraavassa vaiheessa muodostetaan psykoakustinen malli, jossa käytetään apuna nopeaa Fourier-muunnosta (FFT, Fast Fourier Transform). Psykoakustinen malli laskee tehotasot ja määrittelee näitten avulla peittoäänten tehon.

MPEG-purkaja on huomattavasti yksinkertaisempi kuin kooderi, sillä sen ei tarvitse muodostaa mitään malleja, eikä suorittaa ylimääräisiä laskutoimituksia. Dekooderi ainoastaan purkaa paketit, rakentaa kvantisoidun spektrin ja muuntaa taajuusjakoisen koodin aikatasoon.

6.1.3. MPEG-audiokerrokset (layers)

MPEG-audiokoodaus on jaoteltu jo aiemmin mainittuihin kolmeen kerrokseen. Kooderin rakenne monimutkaistuu huomattavasti siirryttäessä Layer 2:sta kolmanteen. Tämä on suora seuraus siitä, että pakkauskertoimet suurenevat huomattavasti juuri tällä askeleella. Kaikilla kerroksilla on samat perustoiminnot, joissa kooderi analysoi datan, muodostaa mallin ja koodaa datan.

Koodauksessa syntyy paketteja, jotka sisältävät eri määrän audiosignaalin näytteitä kerroksesta riippuen. Ensimmäisen kerroksen paketissa on 384 näytettä, sekä 2. ja 3. kerroksilla on 1152 näytettä yhdessä paketissa. Tässä on siis huomattava ero. Jokaisen paketin alussa on 32 bittinen otsikko- eli header-kenttä. Otsikkokenttä pitää huolta synkronoinnista ja sekä kuljettaa koodausparametrit.

Layer-1:stä käytetään pääasiassa DCC-kaseteissa (Digital Compact Cassette). Järjestelmässä käytetään maksimibittitasoa, eli 192 kbit/s/kanava.

Layer-2 on eräänlainen kompromissimalli. Se sijoittuu kahden enemmän käytetyn layerin väliin, eikä sille tehtyjä sovelluksia ole paljoa.

6.1.4. MPEG-Layer 3

MPEGin layer 3 on ehdotonta eliittiä audiokoodausmaailmassa tällä hetkellä. Sen perusominaisuuksiin kuuluu laadukas äänenlaatu tiiviistä pakkauksesta huolimatta. Pakkaussuhde on 1/12 alkuperäisestä, jolloin saadaan CD-tasoista ääntä ilman havaittavaa äänenlaadun heikkenemistä. Tästä voidaan laskea, kuinka mainio tilankäyttö systeemillä on. Layer 3 on määritelty sekä MPEG-1:ssä että MPEG-2:ssa.

Layer 3 soveltuu korkean äänenlaatunsa puolesta kaikenlaiseen musiikin tallennukseen ja kohtalaisen alhaisten bittinopeuksiensa vuoksi myös audiodatan siirtoon. Esimerkkeinä voitaneen mainita korkealaatuinen stereoääni ISDN-linjan läpi. Tällä on useita käyttötarkoituksia, kuten äänen radiotyylinen lähettäminen alhaisen bittinopeuden omaavien satelliittikanavien kautta, äänen siirto tietokoneverkoissa (kuten Internetissä), lähinnä musiikin tallennus huomattavan pieneen tilaan, korkealaatuisen puheen siirto (käyttöä esimerkiksi uutisraportoinnissa) ja DVD-levy.

PC-koneisiin on suunniteltu ohjelmistoja, joilla voidaan koodata ja purkaa Layer 3 -dataa, sekä soittaa mp3-musiikkia (Layer 3 –musiikin maailmanlaajuinen nimitys) reaaliajassa. Real Time Player eli reaaliaikainen toistosovellus on ollut vaikea kehittää, mutta innostus mp3:a kohtaan on suurta ja markkinoille tulee jatkuvasti uusia sovelluksia käyttöön. Näitä ovat mm. Audioactive, Winplay ja MuseArc sekä Xing-Technologyn StreamWorks, joka on eräs nykysovelluksia ajatellen kenties varteenotettavin.

6.1.5. MPEG-4

MPEG-4 on uusin stardointivaiheessa oleva komitean projekti, joka on tarkoitettu erittäin matalia bittitaajuuksia tarvitseville järjestelmille. Suurin muutos on interaktiivisuus. Vastaanottaja voi kesken tiedonsiirron esimerkiksi muokata bittinopeutta ja/tai muuttaa stereo-signaali mono-signaaliksi, jolloin bittinopeus kasvaa.

Audio-osan perustavoitteena on multimedia-sovellukset, kuten video/internet-puhelimet. MPEG-4 -audiokoodaus jaetaan synteettiseen ja luonnolliseen koodaukseen. Standardi tukee erilaisia audioformaatteja, kuten näytteenottotaajuutta, amplitudiresoluutiota, kvantisoinnin luonnetta sekä kanavien lukumäärää. Synteettinen audio on tulevaisuuden alaa ja MPEG-4:ssä on määriteltynä mm. synteettinen puhedata ja 3D-kuuleminen.

6.2. RealAudio-formaatti

Progressive Networkin RealAudio (tiedostotarkennin .ra) -teknologia mahdollistaa RealAudion player- ja server-ohjelmien välisen interaktiivisen linkityksen, jonka avulla voidaan toteuttaa äänilähetyksiä koko Internet-verkkoon.

Lähetyspäässä tarvitaan palvelinohjelmisto, joka soveltuu laajamittaiseen verkossa tapahtuvaan lähetystoimintaan. Lähetystoimintaan tarvitaan oma kotisivu ja kiinteä liittymä Internet-verkkoon. RealAudio Server -ohjelmisto on yhteensopiva minkä tahansa MIME-koodia tukevan palvelinohjelman kanssa, joita ovat esimerkiksi Netscapen Netsite ja Macin HTTPD.

Riippuen äänen pakkaustiheydestä yksittäisen kanavan kaistanleveyden pitää olla 10 - 22 kb sekunnissa. RealAudio-ohjelmisto vaatii keskimäärin 2MB kiintolevytilaa. Riippuen pakkaustiheydestä RealAudio-formaatissa olevat tiedostot vaativat keskimäärin 1.1-2.4kb jokaista äänisekuntia kohden. Näin ollen esimerkiksi yhden tunnin pituinen lähetys vaatii levytilaa 3.6MB:stä 8 MB:aan.

RealAudio encoder on ohjelma, jolla voidaan muuntaa eri ääniformaatissa olevia tiedostoja (esim. wav, au, pcm jne.) RealAudio-formaattiin. Koodattu RealAudio-materiaali voidaan soittaa Internetissä reaaliaikaisesti, käyttämällä asianmukaisia ohjelmia (player ja server). Koodaus voidaan suorittaa kahden vaihtoehtoisen algoritmin mukaisesti. RealAudio 14.4 -algoritmi mahdollistaa monofonisen AM-tasoisen äänen, joka vaatii vähintään 14.4Kbps modeemiyhteyden Internetiin. 28.8 -algoritmi mahdollistaa lähes FM-tasoisen äänen ja vaatii vähintään kaksi kertaa nopeamman yhteyden. RealAudio-kooderi on suunniteltu toimimaan Windows 95 ja Windows NT -ympäristöissä sekä Macintoshissa.

14.4-algoritmissa tarvitaan vapaata levytilaa 1K jokaista koodattavaa sekuntia kohti. 28.8 -algoritmi vaatii vastaavasti 1.8K vapaata levytilaa sekuntia kohti. "LIVE" -koodaus edellyttää vähintään Pentium-tasoisen suorittimen ja enemmän keskusmuistia.

6.3. Audio IFF, AIFF, AIFC

AIFF (Audio Interchange File Format) (tiedostotarkentimet .aif, .iff ja .aff) on Apple Computer Inc.:n kehittämä standardi. Se on kehitetty audioinformaation siirron yhteensovittamiseksi eri tietokonejärjestelmien välillä, tallentamaan mahdollisimman hyvälaatuista ääntä (digitaalisia audionäytteitä) ja instrumentti-informaatiota. Tämän laajennus AIFC tai AIFF-C tukee kompressointia. Molemmat formaatit ovat vahvasti myös SGI:n (Silicon Graphics) suosiossa.

Standardi on yhdenmukaistettu Electronic Artsin kehittämän standardin EA-IFF-85 Standard for Interchange Format Files kanssa. Tämä rakentuu palasista seuraavalla tavalla. Yleinen osa (engl. Common Chunk) pitää sisällään määritteet kanavien määrästä, näytteiden määrästä, näytekoon ja näytteistystaajuuden (näytteiden määrä sekunnissa). Äänidataosa (engl. Sound Data Chunk) taas määrää näytteen kehykset. Jokainen kehys sisältää 1-6 kanavaa. Mono- ja stereoääni, sekä kolmi-, neli-, viisi- ja kuusikanavainen surround-ääni ovat tuotettavissa. Varioitu näytekoko (1 ja 32 bitin välillä) on paketoitu erikokoisina 8-bittisinä tavuina. Merkkiosaa (engl. Marker Chunk) voidaan käyttää identifioimaan äänitieto-osien synkronointipisteet. MIDI- ja instrumenttiosa voidaan luokitella osaksi yleistä informaatiota. Sovellusosa (engl. Application Specific Chunk) mahdollistaa tiettyä sovellusyhteensopivuutta koskevan perustiedon lisäämisen. EA-IFF-85:n tekstiosa (engl. Text Chunk) mahdollistaa kommentoinnin. Siihen voidaan sisällyttää mm. nimi, tekijä ja tekijänoikeustiedot ja äänitystiedot.

AIFF on kenties paras audioformaattivaihtoehto sovellusyhteensopivuutta ajatellen. Se tukee 16-bittistä, 44 kHz:n stereoääntä, mutta tämä ei koske välttämättä kaikkia AIFF:ää tukevia sovelluksia. Kuten aiemmin todettiin, AIFF tukee myös polyfonista ääntä, eli ääntä useammalla kuin kahdella kanavalla.

AIFF-C tai AIFC on pakattua AIFF-tietoa. Kompressointivaihtoehdoista AIFF-tiedostomuodon kanssa voi käyttää MACEa ja ADPCM/IMAa.

MACE-pakatut tiedostot ovat harvinaisia. Koodaus ja purku ovat nopeita, mutta laatu on huono verrattuna ADPCM/IMA- tai MPEG-pakkaukseen. MacIntoshin Sound manager hallitsee MACE-purkamisen automaattisesti. Todennäköisesti myös erillisiä MACE-työkaluja on olemassa, mutta esimerkiksi AIFC-MACE -soittimia ei ole tiedossa.

Useat nykyiset ohjelmat tukevat ADPCM/IMA-pakattuja AIFF-tiedostoja. Windowsille tällaisia sovellusohjelmia on esimerkiksi Goldwave. MacIntoshille riittää mikä tahansa normaali AIFF-soitinsovellus (esim. SoundApp tai SoundManager) mahdollisine 'työkalulaatikkoon' (toolbox) lisättävine ADPCM/IMA-tukineen.

AIFF-ohjelmia ovat mm. seuraavat:

• Amigan Play16
• Apple IIGS:n AudioZap,
• Macintoshin
• SoundApp (soittaa ja muuntaa useiden formaattien välillä: Mac (sisältää IMA 4:1-, MACE- ja uLaw-pakkaukset), AIFF (sisältää IMA 4:1-, MACE- ja uLaw-pakkaukset), WAVE (sisältää IMA- ja ADPCM-pakkauksen), uLaw/Sun Audio, QuickTime movie audio track, MPEG tasot I/II, ja soittaa lisäksi MODeja, S3Miä ja MIDIä),
• Sound Effects,
• SoundHack,
• SoundExtractor,
• Sample Editor,
• UUTool,
• BST,
• M5Mac,
• OS/2 - Five to Five (AU/AIFF/WAV/...) ja
• Windows - Goldwave.

Ammattimaisia sovelluksia ovat mm. Passport Designin Alchemy ja Digidesignin Sound Designer, sekä äänen editointiohjelmista mm. SoundEdit 16 ja OSC:n Deck II.

Lisätietoa standardista on dokumentoituna lähteessä [Apple Computer Inc, Audio Interchange File Format (AIFF): A Standard for Samples Sound Files, Version 1.2.]. Lisäksi AIFF-C spesifikaatio on saatavilla FTP:llä osoitteesta ftp://ftp.sgi.com/sgi/aiff-c.9.26.91.ps.Z.

Liitteessä 1 on lista ja kuvaukset AIFC:n määrittelemistä funktioista.

6.4. NeXTin ja Sunin UNIX-formaatit .au ja .snd

Unix/NeXT audio -muotoa (tiedostotarkennin .au tai .snd) olevissa tiedostoissa voidaan käyttää u-Law-, A-Law- tai lineaarista PCM-tallennusta. Tätä tiedostoformaattia käsitteleviä apuohjelmia on Windowsille ja DOSille. Tiedostomuotoa voidaan joissakin tapauksissa lukea myös raakamuodossa. Normaali tilanne on juuri itsekuvaileva (header) formaatti, jota tässä luvussa tullaan käsittelemään. Lisäksi snd-tiedostoja on myös Mac/PC-formaateissa otsakekentittöminä (headerless), joten sekoittamisen mahdollisuus on olemassa (SOX-tyyppi on NxTS).

6.4.1. SNDSoundStruct: Kuinka NeXT-järjestelmä esittää ääntä

NeXT-ääniohjelmisto määrittelee SNDSoundStruct -tallennusrakenteen äänen esittämiseksi. Tallennusrakenne kertoo äänitiedoston, Mach-O -äänisegmenttiformaatit ja äänen tyyppitiedot. Sitä käytetään myös kuvailemaan ääntä 'Interface Builderille'. Tavallisimmat äänenmuokkausoperaatiot, kuten toisto, äänitys ja leikkaa-liimaa -operaatiot, on esitetty helpoiten ääniobjektissa. Useissa tapauksissa äänen muokkaussovellus tarvitsee tietoa SNDSoundStruct -arkkitehtuurista. Jos äänidataa halutaan tarkastella tai muokata tarkemmin, täytyy tietorakenteesta olla perillä.

SNDSoundStruct sisältää otsikkotiedon (header), äänen attribuutteja kuvailevaa informaatiota ja ääntä vastaavan datan. Määrittelyn rakenne näyttää seuraavalta

int magic;            /* magic number SND_MAGIC */
int dataLocation;     /* offset or pointer to the data */
int dataSize;         /* number of bytes of data */
int dataFormat;       /* the data format code */
int samplingRate;     /* the sampling rate */
int channelCount;     /* the number of channels */
char info[4];         /* optional text information */
} SNDSoundStruct;

6.4.2. SNDSoundStructin kentät.

Magic on maaginen luku, joka identifioi struktuurin SNDSoundStructiksi. Se sisältää myös muun tietyksi äänidataksi tekevän identifiointitiedon.

Aikaisemmin mainittiin SNDSoundStructin sisältävän otsakekentän, jota seuraa äänidata. Todellisuudessa tallennusrakenne sisältää vain otsakekentän, kun data on kokonaan erillinen osa, kuitenkin jatkuen heti tallennusrakenteen jälkeen. dataLocationia käytetään osoittamaan data. Yleensä luku on tavutieto tallennusrakenteen alusta äänidatan ensimmäiseen tavuun. Tässä tapauksessa data tulee välittömästi tallennusrakenteen jälkeen, joten dataLocation voidaan ajatella myös otsakekentän kokona. Toinen dataLocationin käyttötapa on määrittää osoite paikantamaan data, jos se ei seuraa välittömästi tallennusrakennetta. Tätä kuvaillaan luvussa 6.4.3.

Kentät dataSize, dataFormat, samplingRate ja channelCount kuvailevat äänitiedon. dataSize on koko tavuina (ei sisällä SNDSoundStructia). dataFormat on koodi, joka identifioi äänen tyypin. Näytteistetyille äänille tämä on kvantisointitieto. Tieto voi olla myös ohjeet DSP:lle äänen syntetisoimiseksi. samplingRate kertoo näytteistystaajuuden (näytteistetty äänidata). Laitteisto tukee kolmea taulukossa 7 esitettyä näytteistystaajuutta (ilmoitettu kokonaislukuina).

channelCount kertoo näytteistetyn äänen kanavien lukumäärän.

info on NULL-loppuinen merkkijono, johon voi sisällyttää äänen kuvauksen tekstimuodossa. Infon koko asetetaan talletusrakenteen luonnissa, eikä sitä voi sen jälkeen muuttaa. Tämän tulee olla vähintään neljän tavun mittainen (jos käytössä).

6.4.3. Formaattikoodit

Äänen formaatti esitetään positiivisina 32-bittisinä kokonaislukuina (integer). NeXT varaa luvut väliltä 0-255. Oman formaatinkin voi määritellä luvuilla, jotka ovat suurempia kuin 255. Suurin osa NeXTin määrittelemistä formaateista kuvaa näytteistetyn äänen amplitudikvantisointia, kuten taulukosta 8 on havaittavissa. Formaattikooditaulukko on lähteen alkuperäisessä asussa. Muutamia puutteita koodien selityksissä on havaittavissa.

SND_FORMAT_UNSPECIFIED

SND_FORMAT_MULAW_8

SND_FORMAT_LINEAR_8

SND_FORMAT_LINEAR_16

SND_FORMAT_LINEAR_24

SND_FORMAT_LINEAR_32

SND_FORMAT_FLOAT

SND_FORMAT_DOUBLE

SND_FORMAT_INDIRECT

SND_FORMAT_NESTED

SND_FORMAT_DSP_CORE

SND_FORMAT_DSP_DATA_8

SND_FORMAT_DSP_DATA_16

SND_FORMAT_DSP_DATA_24

SND_FORMAT_DSP_DATA_32

SND_FORMAT_DISPLAY

SND_FORMAT_MULAW_SQUELCH

SND_FORMAT_EMPHASIZED

SND_FORMAT_COMPRESSED

SND_FORMAT_COMPRESSED_EMPHASIZED

SND_FORMAT_DSP_COMMANDS

SND_FORMAT_DSP_COMMANDS_SAMPLES

SND_FORMAT_ADPCM_G721

SND_FORMAT_ADPCM_G722

SND_FORMAT_ADPCM_G723_3

SND_FORMAT_ADPCM_G723_5

SND_FORMAT_ALAW_8

Useimmat em. formaateista määrittelevät erikokoista ja -tyyppistä näytteistettyä tietoa. Seuraavassa joistakin tarkempia tietoja:

• SND_FORMAT_DSP_CORE -formaatti sisältää ladattavan DSP-ydinohjelman.
• Funktiot SNDBootDSP() ja SNDRunDSP() vaativat äänet tässä muodossa.
• SND_FORMAT_DSP_CORE -ääni muovataan lukemalla DSP-lataustiedosto (".lod") SNDReadDSPfile()-funktion kanssa.
• SND_FORMAT_DSP_COMMANDS -formaattia käytetään erottamaan ääniohjelmistolla (Music Kit) tehtyjä DSP-komentoja sisältäviä ääniä. Tätä formaattia olevia soundeja on mahdollista luoda vain Music Kitin orkestraatioluokan kautta, mutta ne ovat toistettavissa SNDStartPlaying() -funktiolla.
• SND_FORMAT_DISPLAY -formaattia käytetään Sound Kitin SoundView-luokassa. Tällaisia soundeja ei voi soittaa.
• SND_FORMAT_INDIRECT havaitsee hajonnaisesti (eri osissa) tulleen datan.
• SND_FORMAT_UNSPECIFIED -formaattia käytetään tunnistamattomille formaateille.

6.4.4. Pilkkoutunut äänidata

Äänitieto tallennetaan yleensä peräkkäisiin muistilohkoihin. Kuitenkin editoitaessa näytteistettyä äänidataa (leikkaus, liittäminen), data saattaa tulla epäjatkuvaksi tai paloitelluksi. Jokaiselle dataosalle on annettu oma SNDSoundStruct -otsakekenttä, jolloin jokaisesta osasesta tulee näin erillinen SNDSoundStruct -rakenne. Näiden uusien rakenteiden osoitteet on koottu jatkuvaksi, NULL-päätteiseksi lohkoksi. Alkuperäisen SNDSoundStructin dataLocation-kenttä on asetettu uuden lohkon osoitteeksi samalla, kun alkuperäinen formaatti, näytteistystaajuus ja kanavien lukumäärä on kopioitu uusiin SNDSoundStructeihin.

Pilkkoutuminen sallii suuren määrän liikkuvaa dataa sillä aikaa, kun ääntä editoidaan. Pilkkoutuneen äänen toisto on suoraa, sillä koskaan ei tarvitse tietää, onko ääni paloiteltuna vai ei. Kuitenkin todella vahvasti pilkkoutuneen äänen toisto on aavistuksen heikompaa kuin jatkuvan. C-funktiota SNDCompactSamples() voidaan käyttää liittämään pilkkoutunut äänidata.

Näytteistetty äänidata on luonnollisesti pilkkoutumatonta. Juuri äänitetty, äänitiedostosta saatu ääni tai 'Mach-O'-segmentti eivät ole pilkkoutunutta. Ainoastaan näytteistysdatasta voi tulla pilkkoutunutta.

6.4.5. NeXT sndfile header -formaatti

Taulukossa 9 on esitettynä NeXT sndfilen otsakekentän osat.

NeXTin yleisimmät kombinaatiot on esitetty taulukossa 10.

6.5. IFF/8SVX-äänitiedosto

IFF/8SVX:llä tarkoitetaan Amigan äänitiedostoa (tiedostotarkennin .iff). IFF-tiedoston ensimmäiset 12 tavua on käytetty erottamaan Amigan kuva (FORM-ILBM), Amigan ääninäyte (FORM-8SVX), tai jokin muu yhdenmukainen IFF-spesifikaatioinen tiedosto.

IFF FORM -ääninäytemuodot löytyvät myös EA-IFF-85 -dokumentaatiosta, jossa ovat eriteltyinä spesifikaatiot mm. grafiikalle, äänelle ja muokatulle tekstille. IFF/8SVX mahdollistaa amplitudin korkeuskäyrien hahmottamisen (iskun, vaimenemisen, jne.). Kompressio on valinnainen.

Huomionarvoinen seikka on CD-I -järjestelmän käyttämä standardiformaatti, joka on myös IFF-formaatti, mutta tosin ainoastaan reaaliaikamuodossa.

Seuraavassa tiedosto-otteessa on esimerkkinä FutureSound-audiotiedosto, jossa on 15000 näytettä 10000 kHz:n taajuudella. Tiedosto on 15048 tavun mittainen. Määrittelystä löytyy tietoa taajuudesta, kanavista sekä instrumenttitietoa.

0000: 464F524D 00003AC0 38535658 56484452 FORM..:.8SVXVHDR F O R M 15040 8 S V X V H D R 

0010: 00000014 00003A98 00000000 00000000 ......:......... 20 15000 0 0 

0020: 27100100 00010000 424F4459 00003A98 '.......BODY..:. 10000 1 0 1.0 B O D Y 15000 

0000000..03 = "FORM", identifies this as an IFF format file. 

FORM+00..03 (ULONG) = number of bytes that follow. (Unsigned long int.) 

FORM+03..07 = "8SVX", identifies this as an 8-bit sampled voice. 

????+00..03 = "VHDR", Voice8Header, describes the parameters for the BODY. 

VHDR+00..03 (ULONG) = number of bytes to follow. 

VHDR+04..07 (ULONG) = samples in the high octave 1-shot part. 

VHDR+08..0B (ULONG) = samples in the high octave repeat part. 

VHDR+0C..0F (ULONG) = samples per cycle in high octave (if repeating), else 0. 

VHDR+10..11 (UWORD) = samples per second. (Unsigned 16-bit quantity.) 

VHDR+12 (UBYTE) = number of octaves of waveforms in sample. 

VHDR+13 (UBYTE) = data compression (0=none, 1=Fibonacci-delta encoding). 

VHDR+14..17 (FIXED) = volume. (The number 65536 means 1.0 or full volume.) 

????+00..03 = "BODY", identifies the start of the audio data. 

BODY+00..03 (ULONG) = number of bytes to follow. 

BODY+04..NNNNN = Data, signed bytes, from -128 to +127. 

0030: 04030201 02030303 04050605 05060605 

0040: 06080806 07060505 04020202 01FF0000 

0050: 00000000 FF00FFFF FFFEFDFD FDFEFFFF

0060: FDFDFF00 00FFFFFF 00000000 00FFFF00 

0070: 00000000 00FF0000 00FFFEFF 00000000 

0080: 00010000 000101FF FF0000FE FEFFFFFE 

0090: FDFDFEFD FDFFFFFC FDFEFDFD FEFFFEFE 

00A0: FFFEFEFE FEFEFEFF FFFFFEFF 00FFFF01 

BODYsta ei voida tehdä oletusta sen alkavan 48 tavun jälkeen. Kuten VHDR, palaset nimeltä NAME, AUTH, ANNO tai (c) voivat kuulua mukaan ja ne voivat esiintyä missä järjestyksessä tahansa.

6.6. ADPCM

ADPCM (Adaptive Differential Pulse Code Modulation) käsittää audiosignaalin digitointia alueilla 16, 24, 32 ja 40 kbit/s.

ITUn suositus G.726 sisältää pääpiirteet 64 kbit/s a-law ja u-law PCM-kanavamuunnokselle alueilla 40, 32, 24 tai 16 kbit/s. Muunnos on lisätty PCM-bittivirtaan käyttäen ADPCM-muunnoskoodausta. Pääsovellus kanaville 24 ja 16 kbit/s on kanavien kantoääni (engl. carrying voice) DCME:ssä (Digital Circuit Multiplication Equipment). Ensisijainen sovellus kanavalle 40 kbit/s on kantaa modeemisignaalia DCME:ssä, varsinkin modeemeille yli 4800 kbit/s.

Standardin peruskäyttökohteet ovat korkeiden nopeuksien digitaalisissa telekommunikaatiosysteemeissä.

Lisätietoa standardin yksityiskohdista on saatavilla osoitteesta International Telecommunications Union (ITU), Place des Nations, CH-1211 Geneva 20, Switzerland.

Standardin yksityiskohtia löytyy myös julkaisuista [G.726a 91], [G.726A 95], [G.726III/G.727II 95], [G.727a 91] ja [G.727A 95].

6.7. ACE/MACE

Applen audion kompressointi- ja ekspandiontijärjestelmä. Päästandardi on ACE, joka Macintosheille tunnetaan kirjainyhdistelmällä MACE. Tämä häviöllinen systeemi pyrkii ennustamaan aallon kulkua seuraavaan näytteeseen.

6.8. Microsoftin ADPCM (.wav ja .pcm)

Microsoftin ADPCM (Adaptive Delta Pulse Code Modulation) (tiedostotarkentimet .wav, .pcm) on tiivistysmuoto, jota käytetään mm. CD-I -järjestelmässä videoäänenä. Tiivistyssuhde on noin 1:2-1:8, mutta tiivistys ei ole hävikitön. 16-bittinen ääni tallentuu tässä 4-bittiseksi. Äänikortit, joissa on digitaalinen signaaliprosessori (DSP), voivat tiivistää äänen samalla hetkellä.

6.9. IMA/DVA ADPCM (.wav ja .pcm)

IMA/DVA ADPCM (tiedostotarkentimet .wav, .pcm) tiivistää äänen eri algoritmiä käyttäen kuin Microsoftin ADPCM perusmenetelmän ollessa sama. Tämä menetelmä mahdollistaa myös 16-bittisen äänen tiivistyksen 3-bittiseksi, mutta sen toistamiseen kykenevät vain harvat ääniohjaimet. Menetelmä on alunperin kehitetty videotallennukseen.

6.10. CELP

CELP (Code Excited Linear Prediction) on digitaalisten lähetysten puheenkoodaussysteemi. Se toimii samanlaisella mallinnuksella kuin LPC (luku 6.13.). Systeemi laskee alkuperäisen puheen ja synteettisen mallin välillä tapahtuneet virheet ja lähettää sekä malliparametrit että hyvin tiivistetyn esityksen virhetiedoista. Pakattu esitys on kooderien ja purkajien käytössä olevan 'koodikirjan' 'sisällysluettelo', josta nimitys 'Code Excited'. CELP-kooderi tekee LPC:hen verrattuna enemmän työtä, mutta myös tulos on laadukkaampi. Esimerkiksi FIPS-1016 CELP on laadultaan samaa tasoa kuin 32 kbit/s ADPCM, mutta käyttää vain 4.8 kb/s (samoin LPC).

CELPin takana on US Department of Commerce ja standardin yksityiskohtia löytyy lähteestä [Fs1].

Lisätietoa on saatavissa osoitteesta US National Technical Information Service (NTIS), U.S. Department of Commerce, 5285 Port Royal Road, Springfield, VA 22161, U.S.A. (Phone: +1 703 487 4650).

6.11. GSM

GSM (Global System for Mobile Communication) on puheen digitaalinen koodaussysteemi matkapuhelinten satelliittivälityksessä. Organisaatio järjestelmän takana on ETSI ja tietoa standardista löytyy lähteestä [IE].

GSM on euroopassa ja nykyisin monin paikoin muuallakin käytössä oleva puheen koodausjärjestelmä. GSM06-10 kompressoi 160 13-bittistä näytettä 260 bittiin (33 tavuun), 1650 tavua/s (8000 näytettä/s).

Lisätietoa systeemistä saa osoitteesta ETSI, F-06921 Sophia Antipolis Cedex, France (+33 92 94 42 57).

6.12. LD-CELP

LD-CELP (Low Delay Code Excited Linear Prediction) on avoimien järjestelmien digitaalisten lähetysten puheenkoodaussysteemi. Järjestelmän takana oleva organisaatio on ITU ja standardin yksityiskohtaista tietoa löytyy lähteestä [G.728a 92].

Järjestelmä on ITUn standardi käytettäväksi matalaviiveisenä versiona CELPistä. Se digitoi 4kHz:n puhetta nopeudella 16 kb/s.

Lisätietoa standardista saa osoitteesta International Telecommunications Union (ITU), Place des Nations, CH-1211 Geneva 20, Switzerland.

6.13. LPC-10E

LPC-kooderi (Linear Prediction Coder (Enhanced)) on puheen digitoinnin analyyttinen malli. Se sovittaa puheen yksinkertaiseen, analyyttiseen muotoon (traktaatti). Tämän jälkeen se erottaa puheen kokonaan pois ja toimittaa parametrit parhaiten sopivassa muodossa. LPC-purkaja käyttää näitä parametreja muodostamaan synteettistä puhetta. Puhe on ymmärrettävää, mutta kuulostaa konemaiselta.

Systeemin takana ovat yhteistyössä US DoD ja NATO. Tietoja standardista löytyy lähteestä [FIPS], sekä standardointitiedoista US DoD Federal Standard 1015.

Lisätietoa standardista saa osoitteesta GSA Federal Supply Service Bureau, Specification Section, Suite 8100, 470 E. L'Enfant Place S.W., Washington, DC 20407, U.S.A. (Phone +1 202 755 0325).

6.14. ODA ACA

ODA ACA (Open Document Architecture Audio Content Architecture) sallii audioinformaation sisällyttämisen ODAlla koodattuihin dokumentteihin. Standardi on määritelty standardissa ISO/IEC JTC1/SC18 WG3 ja yksityiskohdat standardista löytyvät lähteestä [T.419 95].

ODA-standardin osa 9 sallii ääniviestien tai muun audiosisällön liittämisen ODA-dokumentteihin. Äänitiedostot voidaan koodata käyttämällä ITU-standardeja G.711 (A-law & U-law PCM), G.722 (SB-ADPCM), G.726/7 (ADPCM) ja J41/2 (käytetään korkealaatuiselle 384kb/s signaaleille), sekä standardeja ISO MPEG-1 ja MPEG-2, standardeja GSM 06-10, ANSI S4 ja AES3.

ODA-audiotiedostot on aina vaihdettavissa toisiksi prosessoitaviksi formaateiksi. Monikanava-audiodataa voidaan toimittaa lisättynä loogisilla attribuuteilla, kuten kontrollin rajauksella ja tarkoituksenmukaisilla kestoilla, sekä ulkoisilla attribuuteilla, kuten kontrolloinnin supistamisella ja taajuusvaippakäyrillä (engl. frequency envelope). Taajuusvaippakäyrä käyttää 33 ISO 266:1975:ssa määriteltyä näytteistystaajuutta kontrolloidakseen kaventamistasoa kaikkien äänien sovittamiseksi.

Käyttö on rajoitettu. Lisätietoa on saatavilla ITUsta, ISOsta tai kansallisesta standardointiorganisaatiosta.

6.15. PCM

PCM (Pulse Code Modulation) on analogisen äänen muunnosstandardi esimerkiksi digitaalista puhelinliikennettä varten. Taustaorganisaatio on ITU ja standardin yksityiskohdat löytyvät lähteestä [G.711 90].

PCM:ää käytetään analogisten signaalien, kuten puheen ja musiikin, digitoinnissa. Sitä on käytetty alunperin pääasiassa digitaalisten verkkojen lähetyksissä. ITUn suositus G.711 sisältää kansainvälisesti hyväksytyn metodin PCM:n käyttämiseksi äänisignaalien digitoimiseen 64kb/s-tasoiselle (4kHz) audiosignaalille.

PCM:ää on kahta formaattia: A-law (Eurooppa) ja u-law (USA). Bittien lukumäärän spesifiointi u-lawille on jokseenkin hankalaa näytteiden ollessa logaritmisesti koodattuja 8 bittiin, mutta niiden dynaaminen säde kuitenkin on lineaarista 12-bittistä dataa.

Kuten kaikessa digitaaliaudiossa, ADC:t, DAC:t, bittiresoluutio ja näytteistystaajuudet, kaikki seikat esiintyvät myös digitaaliäänittimissä. Tähän liittyen kiinnostaa myös se, kuinka audio itse asiassa sijoittuu 'digitaalinauhalle'. Yleisin koodaustekniikka on PCM. Se konvertoi bittivirran ketjuksi kapeita suorakulmaisia pulssiaaltoja, jotka edustavat bittiarvoja. Tämä virta pulsseja kirjoitetaan kohteeseen. Toistettaessa prosessi on käänteinen ja pulssit konvertoidaan takaisin bittiarvoiksi.

Digitaalinen informaatio kirjoitetaan yleensä kohteeseen 'ylikorostetusti' niin, että informaatiosta on aina olemassa 'varmuuskopio' virheiden varalle. Tämän prosessin varustamiseksi data on usein limitetty nauhalle samankaltaisella pyörivän kuvapään tekniikalla kuin videonauhureissa. Tämä limitysprosessi poistaa mahdollisuuden käsineditointiin.

Lisätietoa standardista on saatavilla osoitteesta International Telecommunications Union (ITU), Place des Nations, CH-1211 Geneva 20, Switzerland.

6.16. SB-ADPCM

SB-ADPCM (Sub-Band Adaptive Differential Pulse Code Modulation) kattaa puheen koodauksen ISDN-linjoilla yli 64kb/s toimituksissa. Taustaorganisaationa on ITU ja standardin yksityiskohdat löytyvät lähteestä [G.722 90].

SB-ADPCM kuvailee, kuinka laadultaan keskinkertaisen audiosignaalin tulisi olla koodattu käyttämällä varianttia ADPCM:ää yli 64kb/s:n lähetyksissä Integrated Service Digital Network (ISDN) -linjoilla. Standardia käytetään signaaleille taajuuksilla 7kHz:iin saakka.

ISDN:n esiintyminen on vielä vähäistä, mutta siellä missä ISDN on käytössä, on SB-ADPCM standardimetodi puheen digitoinnissa.

Lisätietoa standardista on saatavilla osoitteesta International Telecommunications Union (ITU), Place des Nations, CH-1211 Geneva 20, Switzerland.

6.17. SMDL

SMDL (Standard Music Description Language) on eräänlainen yleisyhteys musiikin, merkintäjärjestelmien (scores) ja kriittisen musiikkianalyysin välillä. Taustalla on standardi ISO/IEC JTC1/SC18 WG8 ja standardin yksityiskohdat on esitetty lähteessä [ISO10743].

Standardi käytää Hypermedia/Time-based Structuring Language (HyTime) -formaattia yhdistämään musiikin, merkintäjärjestelmät ja musiikin selitykset. Yksittäisten komponenttien (esim. synkronointiyksityiskohdat, esitysmetodit) suhteet tallennetaan käyttämällä Standard Generalized Markup Languagea (SGML).

SMDL perustuu neljään alueeseen (engl. domain): loogiseen- , ele/liike-, visuaaliseen- ja analyyttiseen alueeseen. Musiikin työ (musical work) rakentuu tietystä määrästä musiikkisegmenttejä. Jokaisen työn voi liittää johonkin työluokkaan ja siihen voi sisältyä informaatiota asianomaisesta ja tallennuslähteestä.

Loogisen alueen työ esitetään yksittäisinä ns. 'cantus-komponentteina', joista jokainen on oman aikajanansa kanssa virtuaalisessa ajassa ilmaistuna. Cantuksella voi olla useita säikeitä, sanoituksia, tai 'tahtipuikkoja' ajan kontrolloimiseksi ja 'tahtipuikkoja' (sound modification statements) toimimaan yhteistyössä sen kanssa. Kuormitus ja korkeustaso on kontrolloitavissa ja synkronoitavissa.

Loogisessa alueessa määritelty musiikki voidaan linkittää HyTime-standardilinkityksellä merkintätavaksi visuaaliseen alueeseen, esitystavan kontrollin spesifikointiin elealueeseen, ja yksittäisiksi analysoitaviksi komponenteiksi analyyttiseen alueeseen. Eri cantusten linkittämiseksi voidaan käyttää 'teemoja'.

Standardin lisätietoja on saatavilla ISOsta tai kansallisista standardointiorganisaatioista.

6.18. US Federal Standard 1016

Tämä äänikoodausstandardi perustuu 4800 bps kiihdytettyyn lineaariseen äänikooderiin (CELP 3.2). Julkaisuja aiheesta ovat mm. "Details to Assist in Implementation of Federal Standard 1016 CELP", sekä virallinen "Federal Standard 1016, Telecommunications: Analog to Digital Conversion of Radio Voice by 4,800 bit/second Code Excited Linear Prediction (CELP)".

Toinen rinnasteinen systeemi saman otsikon alle on US DoD's Federal Standard 1015/ NATO STANAG 4198. Se perustuu 2400 bps lineaariseen ennustuskoodaukseen (LPC-10) ja se uudelleenjulkaistiin standardina Federal Information Processing Standards Publication 137 (FIPS Pub 137).

6.19. Macintosh SND

Macintoshin äänitiedostot ovat SND-tiedostoja (.snd). Resurssina se on samantyyppinen kuin esimerkiksi Microsoft Windowsin WAV-formaatti. Macintoshin snd-tiedostolla on alussaan alkutiedot (header) kuten AIFF:ssä ja WAVissa, mutta ne ovat muutoin samantyyppistä äänitietoa. Tiedostot ovat merkitsemätöntä tyyppiä (unsigned).

6.20. MIME

MIME on lähinnä sähköistä postiliikennettä koskeva Internet-standardi, jossa on määritelty audiodatan siirtämistä koskevaa koodaustietoa, sekä laite- ja ohjelmatietoa. Tämä on laajoja mittasuhteita saava formaatti, ja määrittelee oikeastaan eräänlaisen jälkiäänitetyn perusaudion, 8-bittisen u-lawin näytteistettynä 8000 näytettä/sekunnissa.

6.21. Creative Voice (VOC)

Creative Labsin SoundBlaster VOC (tiedostotarkennin .voc) on DOS-ympäristössä (esim. peleissä) yleisin aaltomuotoisen äänen formaatti. Se on aina 8-bittinen ja tiedoston pituus on rajoitettu (16 minuuttia). Useat muutkin äänikortit Sound Blasterin lisäksi tukevat sitä ja se voidaan tarvittaessa muuntaa WAV-muotoon.

Seuraavassa esitetään esimerkki VOC-tiedostoformaatista (tavut heksamuodossa). Se sisältää otsakekenttäosan (tavut 00-19) ja sarjoja datalohkoista (tavut 1A+).

HEADER:

======= 

byte # Description 

------ ------------------------------------------ 

00-12 "Creative Voice File" 

13 1A (eof to abort printing of file) 

14-15 Offset of first datablock in .voc file (std 1A 00 in Intel Notation) 

16-17 Version number (minor,major) (VOC-HDR puts 0A 01) 

18-19 2's Comp of Ver. # + 1234h (VOC-HDR puts 29 11)

- --------------------------------------------------------------- 

DATA BLOCK: =========== 

Data Block: TYPE(1-byte), SIZE(3-bytes), INFO(0+ bytes) 

NOTE: Terminator Block is an exception -- it has only the 

TYPE byte. TYPE Description Size (3-byte int) Info 

---- ----------- ----------------- ----------------------- 

00 Terminator (NONE) (NONE) 

01 Sound data 2+length of data * 

02 Sound continue length of data Voice Data 

03 Silence 3 ** 

04 Marker 2 Marker# (2 bytes) 

05 ASCII length of string null terminated string 

06 Repeat 2 Count# (2 bytes) 

07 End repeat 0 (NONE) 

08 Extended 4 *** 

*Sound Info Format: **Silence Info Format: 

--------------------- ---------------------------- 

00 Sample Rate 00-01 Length of silence - 1 

01 Compression Type 02 Sample Rate 

02+ Voice Data 

***Extended Info Format: 

--------------------- 

00-01 Time Constant: Mono: 65536 - (256000000/sample_rate) 

Stereo: 65536 - (25600000/(2*sample_rate)) 

02 Pack 

03 Mode: 0 = mono 

1 = stereo 

Marker# -- Driver keeps the most recent marker in a status byte 

Count# -- Number of repetitions + 1 

Count# may be 1 to FFFE for 0 - FFFD repetitions 

or FFFF for endless repetitions 

Sample Rate -- SR byte = 256-(1000000/sample_rate) 

Length of silence -- in units of sampling cycle 

Compression Type -- of voice data 

8-bits = 0 

4-bits = 1 

2.6-bits = 2 

2-bits = 3 

Multi DAC = 3+(# of channels) 

6.22. Raw PCM

Raaka PCM (SAM, Signed Raw Format, tiedostotarkennin .sam) sisältää pelkän äänitiedon ilman lisätietoja tai tiivistystä. Näytteet on tallennettu etumerkillisinä (signed) 7-bittisinä.

Muutamia vanhoja header-esimerkkejä on esitetty liitteessä 4.

6.23. RIFF WAVE (.wav)

Microsoftin Waveform, WAV (tiedostotarkennin .wav) on Windowsin aaltomuotoisen äänen perusformaatti ja tässä ympäristössä yleisimmin käytetty. Se tukee kaikkia näytteistystaajuuksia, 8- ja 16-bittistä näytekokoa sekä mono- ja stereokanavia. WAV-tiedostot ovat RIFF (Resource Interchange File Format) -tyyppisiä, vapaasti suomennettuna resurssien keskinäisen vaihdon tiedostomuotoja. Nämä määritykset tallentuvat osaksi tiedostoja niin, että ääniajuri osaa toistaa ne oikeassa muodossa. RIFF-muodossa tiedostoihin voidaan tallentaa myös paljon muuta tietoa, mm. kappaleen nimi ja esittäjä. Käytetty tallennustekniikka on Microsoft PCM.

RIFF-tiedosto muodostuu yhdestä tai useammasta lohkosta jokaisen osoittaessa seuraajaansa. Jokaisella lohkolla on tyyppi, jonka jälkeen seuraa joukko tietoja. Näistä sovellus voi valita ne tiedot, joista se on kiinnostunut. Tiedoston lohkoa edeltää aina seuraavantyyppinen otsikko (engl. header)

typedef struct {
FOURCC ckID;
DWORD ckSize;
} CK;

FOURCC-objekti on neljän tavun levyinen kenttä, joka määrittää lohkon tyypin. Tässä tapauksessa kentän arvona on WAVE. ckSize määrittää ko. dataosion koon tavuina. Lohkot voivat sisältää alalohkoja. Perusäänitiedoston todellinen rakenne on WAVE-lohko, joka sisältää fmt-lohkon ja data-lohkon.

RIFF-tiedostoihin on sovelluksen mahdollista lisätä vain omaa käyttöään varten tarkoitettua tietoa. Tätä varten on olemassa oma lohkotyyppinsä ZSTR (zero-terminated string). Tämä tulee WAVEn alalohkojen jälkeen.

RIFF-tiedostoja on olemassa myös hieman erilainen RIFX-tiedostotyyppi, jossa objektit ovat hieman eri järjestyksessä. Tässä fmt-lohko on monimutkaisempi ja on varsinaisesti WAVEFORMAT-objekti, jonka loppuun on liitetty lisätietoja. WAVEFORMAT on seuraavanlainen

typedef struct waveformat_tag {
WORD wFormatTag;
WORD nChannels;
DWORD nSamplesPerSec;
DWORD nAvgBytesPerSec;
WORD nBlockAlign;
} WAVEFORMAT;

Kenttä wFormatTag sisältää vakion WAVE_FORMAT_PCM, joka on yleensä määritelty (#define) ykköseksi. Tämä kertoo siis ohjelmalle, miten ääni on koodattu. nChannels-kentän arvo monoäänelle on 1 ja stereolle 2. nSamplesPerSec ilmoittaa alkuperäisen äänen näytteistysnopeuden. nAvgBytesPerSec äänitiedon tarvittavien tavujen keskimääräisen määrän sekuntia kohti. Kentän nBlockAlign arvo määrittää yhteen näytteeseen tarvittavien tavujen määrän. Näin esim. 8-bittinen näyte mahtuu yhteen tavuun ja 9-16-bittinen tarvitsee kaksi tavua.

Äänitiedosto määrittää näytteen bittien tarkan määrän WORD-objektina, joka on liitetty WAVEFORMAT-objektin perään. C-kielen merkinnöin rakenne on määritelty seuraavasti:

typedef struct pcmwaveformat_tag {
WAVEFORMAT wf;
WORD wBitsPerSample;
} PCMWAVEFORMAT;

Käsiteltäessä WAVE-lohkon fmt-alalohkoa, käytetään todellisuudessa paremminkin PCMWAVEFORMAT- kuin WAVEFORMAT-objektia. Tämän kenttä wBitsPerSample määrittää näytteen bittien todellisen määrän.

Kaikilla RIFF-tiedostojen funktioilla on etuliite mmio ja niitä käytetään HMMIO-tyypin kahvojen (engl. handle) avulla. Seuraavassa RIFF-tiedoston avaaminen lukemista varten

HMMIO h;
if((h=mmioOpen(path, NULL, MMIO_READ)) == NULL {
/* virheilmoitus */
return(0)
}

MMIO_READ ilmoittaa funktiolle mmioOpen tiedoston avaamisen lukemista varten. Muita lippuja ovat mm.

• MMIO_WRITE: avataan tiedosto kirjoittamista varten,
• MMIO_READWRITE: avataan tiedosto sekä lukemista että kirjoittamista varten, ja
• MMIO_CREATE: luodaan uusi RIFF-tiedosto.

Tiedoston avauksen onnistuttua mmioOpen palauttaa HMMIO-tyypin kahvan. Jos avaus epäonnistuu, palauttaa se arvon NULL. Äänitiedoston avauduttua haetaan sen WAVE-lohko seuraavasti:

MMCKINFO mmParent;
mmParent.fccType=mmioFOURCC('W','A','V','E');
if(mmioDescend(h,(LPMMCKINFO)&mmParent,NULL;MMIO_FINDRIFF)) {
mmioClose(h,0);
/* virheilmoitus */
return (0);
}

MMSYSTEM.H-tiedostossa määritelty MMCKINFO-rakenne sisältää seuraavan informaation:

typedef struct {
FOURCC ckid;
DWORD cksize;
FOURCC fccType;
DWORD dwDataOffset;
DWORD dwFlags;
} MMCKINFO;

Lohkoon siirtymiseksi on asetettava MMCKINFOn ckid-kentän arvoksi paikallistettavan lohkon tyyppi. Tätä varten on olemassa makro mmioFOURCC. Tämän jälkeen kutsutaan funktiota mmioDescend, joka palauttaa nollan, jos lohko on paikallistettu. Tällöin mmioDescend-funktiolle välitettyyn MMCKINFO-objektiin on sijoitettu ko. tiedot. cksize-kenttä määrittää lohkon koon tavuina. Tätä arvoa on syytä käyttää aina tarkkaa määritystä varten. MMIO_FINDRIFF ohjaa mmioDescendiä hakemaan lohkoa, jonka tunnuksena on ID RIFF ja tyyppinä sille välitetyn MMCKINFOn ckid-kentän määrittämä tyyppi. Toinen vastaavanlainen objekti on MMIO_FINDCHUNK, joka hakee jotain määrättyä viipaletta. mmioClose-funktion kutsu on tärkeää, kun ollaan valmiita RIFF-tiedoston kahvan kanssa. Tämä vapauttaa HMMIO-objektiin liittyvät puskurit ja muut muistiobjektit (vrt. fclose).

Seuraavassa koodiesimerkkipätkässä siirtyminen WAVE-lohkon fmt-alalohkoon:

MMCKINFO mmSub;
mmSub.ckid=mmioFOURCC('f','m','t',' ');
if(mmioDescend(h,(LPMMCKINFO)&mmSub,
(LPMMCKINFO)&mmParent, MMIO_FINDCHUNK)) {
mmioClose(h,0);
/* virheilmoitus */
return (0);
}

Tämän jälkeen PCMWAVEFORMAT-objekti luetaan fmt-lohkosta seuraavasti:

PCMWAVEFORMAT waveformat;
int n;
n=min((unsigned int)mmSub.cksize.sizeof(PCMWAVEFORMAT));
if(mmioRead(h,(LPSTR)&waveformat,(long)n) != (long)n) {
mmioClose(h,0);
/* virheilmoitus */
return(OL);
}
if(waveformat.wf.wFormatTag != WAVE_FORMAT_PCM) {
mmioClose(h,0);
/* virheilmoitus */
return(OL);
}

Luettavaan tiedostoon viitataan käyttämällä HMMIO-kahvaa ensimmäisenä parametrina mmioReadia kutsuttaessa. Toinen parametri on far- tai huge-osoitin oletettuun tietopuskuriin. Kolmas on luettavien tavujen määrää ilmoittava suuri kokonaisluku. Tämän tarkistaa mmioRead, joka palauttaa arvonaan lukemiensa tavujen todellisen määrän. Tämän jälkeen siirrytään ulos lohkosta ja valmistaudutaan lukemaan seuraava funktio.

mmioAscend(h,(LPMMCKINFO)&mmSub,0);

Ensimmäinen mmioAscendin parametri on HMMIO-kahva, jota käytetään viitattaessa luettavaan tiedostoon, toinen on osoitin poistumista vastaavaan lohkoon ja kolmas ns. 'valeparametri'.

Seuraavassa jatkoa koodiin, jota tarvitaan äänitiedoston muistiinlukemisessa:

GLOBALHANDLE wavehandle;
HPSTR wavepointer;
mmSub.ckid=mmioFOURCC('d','a','t','a',);
if(mmioDescend(h,(LPMMCKINFO)&mmSub,
(LPMMCKINFO)&mmParent, MMIO_FINDCHUNK)) {
mmioClose(h,0);
/* virheilmoitus */
return (0);
}
if((wavehandle=GlobalAlloc(GMEM_MOVEABLE | GMEM_SHARE,
mmSub.cksize)) == NULL {
mmioClose(h,0);
/* virheilmoitus */
return (0);
}
if((wavepointer=(HPSTR)GlobalLock(wavehandle)) == NULL) {
GlobalFree(wavehandle);
mmioClose(h,0);
/* virheilmoitus */
return (0);
}
if(mmioRead(h,wavepointer,mmSub.cksize) != mmSub.cksize) {
GlobalUnlock(wavehandle);
GlobalFree(wavehandle);
mmioClose(h,0);
/* virheilmoitus */
return (0);
}
GlobalUnlock(wavehandle);

Tämän jälkeen luettu RIFF-tiedosto voidaan sulkea funktiolla

mmioClose(h,0);

Tässä esiteltyjen lisäksi erilaisia mmio-kutsuja on olemassa huomattavasti enemmän.

6.24. CCITT u-Law ja A-Law

CCITT u-Law (myy-) ja A-Law tiivistysmuodot tiivistävät 16-bittisen äänen 8-bittiseksi. Tulos vastaa laadultaan suunnilleen 12-bittistä ja on parempi kuin ADPCM. Tiivistys tapahtuu muuttamalla lineaariset numeroarvot logaritmisiksi. Muunnoksen lähdekoodi u-Law -muunnoksissa toimitetaan osina nk. SOX-paketteja, jotka ovat helposti otettavissa erilleen muiden sovellusten käyttöön. Virallinen määrittely on CCITT-standardi G.711.

Samankaltainen u-Lawin kanssa on toinen enkoodausmenetelmä, A-Law. Tämä on käytössä eurooppalaisena puhelinstandardina. UNIX-työasemille tuki on heikompi.

u-Law on muotoa

y={[sgn(m)/ln(1+u)]*ln(1+(u|m/mp|))}  , kun |m/mp| <= 1.

A-Law on muotoa

y={[A/(1+lnA)][m/mp]}                 , kun |m/mp| <= 1/A

tai

y={sgn(m)/(1+lnA)*[1+lnA*|m/mp|]}     , kun 1/A <= |m/mp| <= 1

u:lle käytetään arvoja 100 ja 255, A:lle 87.6, mp on piikkitiedon arvo (engl. Peak message) ja m on kvantisointiarvo. Kaavat yksinkertaistuvat, jos asetetaan x=m/mp ja sgn(x)=sgn(m), jolloin -1<=x<=1. Muunnos u-Lawista A-Lawiin on järjetöntä, jos muunnoksessa esiintyy kvantisointivirheitä.

8-bittisen u-Lawin resoluutio (erottelukyky) on samaa suuruusluokkaa kuin 12-bittisellä lineaarisella ja vastaavasti 12-bittisellä u-Lawilla sama kuin 16-bittisellä lineaarisella koodauksella. Vertailua on tarkasteltu taulukossa 11.

Lisätietoa on saatavissa lähteistä [La] ja [TSC].

6.25. AVR

AVR (Audio Visual Research) on Macintosh-ympäristössä käytössä oleva, usein kaupalliseen toimintaan liittyvä tiedostoformaatti. Tällä formaatilla on 128 tavun mittainen otsakekenttä, josta esimerkki seuraavassa:

char magic[4]="2BIT"; 

char name[8]; /* null-padded sample name */ 

short mono; /* 0 = mono, 0xffff = stereo */ 

short rez; /* 8 = 8 bit, 16 = 16 bit */ 

short sign; /* 0 = unsigned, 0xffff = signed */ 

short loop; /* 0 = no loop, 0xffff = looping sample */ 

short midi; /* 0xffff = no MIDI note assigned, 0xffXX = single key note assignment, 0xLLHH = key split, low/hi note */ 

long rate; /* sample frequency in hertz */ 

long size; /* sample length in bytes or words (see rez) */ 

long lbeg; /* offset to start of loop in bytes or words. set to zero if unused. */ 

long lend; /* offset to end of loop in bytes or words. set to sample length if unused. */ 

short res1; /* Reserved, MIDI keyboard split */ 

short res2; /* Reserved, sample compression */ 

short res3; /* Reserved */ 

char ext[20]; /* Additional filename space, used if (name[7] != 0) */ 

char user[64]; /* User defined. Typically ASCII message. */

6.26. Amiga MOD (.mod ja .nst)

MOD-tiedostot (tiedostotarkenteet .mod ja .nst) tulivat kuuluisiksi Amigan äänitiedostoina ja siirtyivät sieltä muihinkin järjestelmiin. MIDI-tiedostojen lailla MODit (ja johdannaiset, kuten S3M, 669 ja MADx) varastoivat musiikkitietoa. Toisin kuin MIDI, MODit ja niiden sukulaiset eivät varastoi ainoastaan nuottitietoa, vaan myös digitoidut näytteet instrumenteista. Toisin kuin kunnollinen MIDI-toisto tarvitsee wavetable-äänikortin PC:ssä tai QuickTimen Macintoshissa, jokainen kone saa aikaan hyvätasoista MOD-musiikkia kohtalaisella 8-bittisellä äänikortilla. Kuitenkin MODien sisältäessä myös digitoituja näytteitä, on ne huomattavasti tiedostokooltaan MIDI-tiedostoja suurempia.

MOD-tiedostot ovat musiikkitiedostoja, jotka sisältävät kaksi osaa: digitoitujen näytteiden pankin ja kuvailevaa sekvenssointitietoa siitä, milloin ja miten soittaa näytteitä. Joustavan systeeminsä ja tarjolla olevien MOD-tiedostojen määrän, sekä täten suunnattoman suuren suosionsa, ansiosta MOD-player -sovelluksia on tarjolla useimmille laitesysteemeille.

MOD-tiedostojen näytteet ovat 'raakoja', 8-bittisiä, merkittyjä ja otsakekentättömiä, lineaarista digitaalista dataa. Siinä voi olla jopa 31 erilaista näytettä, joista jokainen voi olla pituudeltaan jopa 128K (yleensä pienempiä, luokkaa 10K-60K). Vanhempi MOD-formaatti salli vain 15 näytettä, mutta näitä ei ole enää juurikaan liikkeellä. MOD-sämpleille ei ole varsinaista standardinäytteistystaajuutta.

MOD-tiedostojen informaatio alkaa neljällä raidalla informaatiota siitä, mitkä, milloin, kuinka pitkään ja millä taajuudella näytteet tulee esittää. Tämä tarkoittaa sitä, että tiedostossa voi olla 31:n eri digitoidun instrumentin soundit. Näistä neljän äänen yhdenaikainen toistaminen on mahdollista. Tämä mahdollistaa laajan skaalan orkestraatiomahdollisuuksia aina puhe-, laulu- ja omien instrumenttien näytteitä myöten, toki laitteistosta ja ohjelmistosta riippuen. Omien näytteiden käyttömahdollisuus instrumenttina onkin omalta osaltaan syynä MODien suosioon.

Edellämainittu 15 instrumentin MOD on muutoin samanlainen kuin 31 instrumentin, mutta muutama eroavaisuus formaateista löytyy:

• Kun näytteitä on vain 15, alkaa viimeinen sämple tavusta 440 ja kulkee tavuun 469.
• Kappaleen pituus on tavussa 470 (rinnasteisena tavulle 950 31-instrumenttisessa MODissa).
• Yleisesti havaittuna tavu 471 vaikuttaisi olevan ohitettu.
• Tavu 472 aloittaa tiedoston järjestelmäkartan (sequence table) (tavu 952 31 MODissa).
• Varsinainen järjestelmä (pattern) alkaa tavusta 600 (tavu 1084 31 MOD).

MOD-ohjelmistoja on saatavissa ainakin seuraavasti:

• Amigalle ProTracker ja DeliTracker,
• Macintoshille PlayerPro (tukee S3M-, MOD-, MADx-, XM-tiedostotyyppejä ja muitakin), MacMod Pro ja SoundApp,
• MS-DOSille DMP,
• OS/2:lle DMP,
• Unixille MOD ja Tracker, sekä
• Windowsille MOD4Win, WinMod ja WinMod Pro.

ProTracker-formaattiesimerkki on nähtävissä liitteessä 3.

6.27. Sample Vision (.smp)

Sample Vision on laitekohtainen äänimuoto (tiedostotarkennin .smp). Se on yleensä ammattimuusikoiden käyttämä ohjelma näytteiden lähettämiseen ja vastaanottamiseen PC-koneeseen MIDI-liitännän kautta. Järjestelmässä on mahdollista muokata useita parametreja (kuten luuppikohtia, korkeutta, aikakompressiota ja näytetaajuutta). Järjestelmän tukena ovat 'sämplerit' (erillisiä soitinmoduleja), joita ovat mm. AKAI (S700, X700, S900, S950, S612, S1000/ 1100), Casio (FZ1, FZ10M, FZ20M), Ensoniq (EPS, EPS16, ASR10, Mirage), Emu (Emax, EmaxII), Korg (DSS1, DSM1, T workstation), Oberheim DPX-1, Peavey DPM-3, Roland (S10, MKS100, S220, S50, S330, S550), Sequential Circuits Prophet 2000/2002, Sample Dump Standard devices ja Yamaha TX16W.

smp-formaatti eriteltynä näyttää seuraavalta:

Offset Size Description 

000 18 'SOUND SAMPLE DATA ' ASCII FILE ID 

0018 04 '2.1 ' ASCII FILE VERSION 

0022 60 USER COMMENTS 60 ASCII CHARACTERS 

0082 30 SAMPLE NAME LEFT JUSTIFIED 30 ASCII CHARACTERS 

0112 04 SAMPLE SIZE SAMPLE DATA COUNT IN WORDS 

0116 ?? SAMPLE DATA 1 WORD PER SAMPLE, LEAST SIGNIFICANT BYTE FIRST, LSW FIRST; SIGNED 16 BIT INTEGERS 

?? 02(DW) RESERVED 

?? 04(DD) LOOP 1 START USE SAMPLE COUNT NOT BYTE COUNT 

?? 04(DD) LOOP 1 END 

?? 01(DB) LOOP 1 TYPE 0=LOOP OFF,1=FORWARD,2=FORWARD/BACKWARD 

?? 02(DW) LOOP 1 COUNT TIMES TO EXECUTE LOOP BEFORE NEXT LOOP 

THERE ARE SEVEN MORE IDENTICAL LOOP STRUCTURES FOR A TOTAL OF 8 

?? 10 MARKER 1 NAME ASCII MARKER NAME 

?? 04(DD) MARKER 1 POSITION FFFF MEANS UNUSED 

THER ARE SEVEN MORE IDENTICAL MARKER STRUCTURES FOR A TOTAL OF 8 

?? 01(DB) MIDI UNITY PLAYBACK NOTE MIDI NOTE TO PLAY THE SAMPLE AT ITS ORIGINAL PITCH 

?? 04(DD) SAMPLE RATE IN HERTZ 

?? 04(DD) SMPTE OFFSET IN SUBFRAMES 

?? 04(DD) CYCLE SIZE SAMPLE COUNT IN ONE CYCLE OF THE SAMPLED SOUND. -1 IF UNKNOWN 

(DD) 4 BYTES, LS BYTE FIRST, LS WORD FIRST 

(DW) 2 BYTES, LS BYTE FIRST 

(DB) 1 BYTE 

Käytännön kokeet ovat havainnollistaneet, että Sample Vision kirjoittaa tiedostoon vain seitsemän 'luuppistruktuuria' (silmukkarakennetta) kahdeksan väitetyn sijaan.

6.28. Tandy Deskmate (.snd, .sng)

Tandyn .snd-tiedostot tulevat Sound.pdm:ltä, joka on ohjelma DeskMate-ympäristön yksityisessä hallinnassa. Ne ovat käytettävissä Music.pdm:ssä, joka kehittää musiikkimoduleita (.sng-tiedosto). DeskMate-ääni ja -musiikki vaativat Tandyn äänipiirin. Ohjelmistoihin, jotka kääntävät RIFF WAVEn tai muun 8-bittisen PCM-formaatin .snd-muotoon, kuuluu mm. Conv2snd-niminen ohjelma (Kenneth Udut). Uudemmat ohjelman versiot tulevat Snd2wav:n kera, joka muuttaa snd:n RIFF WAVEksi. On syytä huomioida, että myös NeXTillä ja Mac/PC:llä on omat snd-formaattinsa.

DeskMaten snd-tiedostoja on kahden tyyppisiä: äänitiedostoja ja instrumenttitiedostoja. Molemmat sisältävät 8-bittisiä merkitsemättömiä PCM-näytteitä.

Äänitiedostot ovat yksinkertaisempia. Ne ovat sekalainen valikoima näytetiedostoja, joissa on kiinteänmittainen otsakekenttä sisältäen äänen nimen, äänitystaajuuden ja äänen pituuden. Äänet voivat olla äänitettyjä 5500 Hz:n, 11kHz:n tai 22kHz:n taajuudella.

Instrumenttitiedostot sisältävät Music.pdm:n käyttämiä näytteitä sekä taajuus- ja 'luuppitietoa' edustamassa instrumenttia. Instrumenttitiedostoissa on valmistauduttu iskuihin (engl. attack), vaimennuksiin (engl. sustain) ja 'häivennyksiin' (engl. decay) useammilla näytteillä, jotka sisältävät eri liitetaajuuksia ollakseen Music.pdm:n käytössä mallintamaan soittimia eri taajuuksilla. Yhteen instrumenttitiedostoon voidaan sisällyttää 16 eri nuottia (16:lla eri näytteellä). Tiedostot on aina tallennettu 11kHz:llä. Sekä ääni- että instrumenttitiedostoja on myös mahdollista kompressoida.

DeskMaten snd-tiedoston otsikkokenttä muodostuu 16 tavusta aiemmin mainittua informaatiota, jonka jälkeen tulee yksi tai useampia 28 tavun nuottitallenteita. Näyteinformaatio, joka voi olla kompressoitua, seuraa otsakekenttää. Tiedosto-ote Deskmaten snd-tiedostosta on nähtävissä liitteessä 6.

6.29. Sound Designer(II)/Audio Media

Tämän formaatin SOX (Sound Exchange) -tyyppi on Sd2f. Se on muokattavissa mm. SoundHack -ohjelmalla. Sovellusohjelmia tietokonejärjestelmille on saatavissa mm. Macintoshille SoundHack.

6.30. AVI

AVI-äänimuoto (tiedostotarkennin .avi) on videoiden ääniraita, joka voidaan erottaa erikseen muokattavaksi ja tallennettavaksi.

6.31. Dialogic ADPCM

Dialogic ADPCM on laitekohtainen äänimuoto (tiedostotarkennin .vox). Sovellusohjelmia on olemassa.

6.32. Muita formaatteja

Edellä on mainittu tärkeimmät ja pitkäikäisimmät äänen tiedostoformaatit ja koodausjärjestelmät. Näiden lisäksi on olemassa suuri joukko muita, harvinaisempia tai erikoisempia laite- tai sovelluskohtaisia, audioformaatteja. Näitä on listattuna seuraavassa.

• DVI-audioformaatti Inteliltä. Se on ADPCM-yhteensopiva.
• HCOM-formaatti (tiedostotarkennin .hcom) Macintosheille, 8 bittiä/kanava, käyttää Huffman-kompressiota. SOX:n (Sound Exchange) tunnistamana sisältää MacBinary-otsikkokentän ja tiedostotyyppi kenttänä FSSD.
• IFF/SMUS Amigalle, jota mm. digitoijat ja musiikkiohjelmat käyttävät.
• DEC system on varioitu NeXT-formaatti. Se käyttää ns. 'little-endian' -koodausta ja eri maagista lukua.
• NIST SPHERE on yleinen DARPA-puhejärjestelmässä. Sen otsikkokenttä on oliopohjainen, 1024 tavun lohko ja ASCII-rakenne liitettynä aaltomuotoiseen dataan. Otsikkokenttä on yhdistelmä määrätystä formaatista (alkuosa) ja olio-osasta (seuraaja).
• FSSD (tiedostotarkennin .fssd) Mac/PC:lle, kts. HCOM. Vaihtuva näytteistystaajuus, 8-bittinen ja 1-kanavainen.
• UL (tiedostotarkennin .ul) on US telephonyn 8k, 1-kanavainen, 8-bittinen u-law -koodaus.
• IRCAMin SOX-tyyppi on IRCM, (tiedostotarkennin .sf).
• MacMix on SOX-tyypiltään MSND.
• DSP Designerin SOX-tyyppi on DSPs.
• DEC CRL Audio File tukee Digital RISC -järjestelmiä, kuten Ultrix, Digital Alpha AXP (OSF/1), Sun Sparc ja SGI AL (Indigo, Indy).
• NCD NetAudio tukee X-terminaalien NCD MCX -linjoja, kuten Sparc (SunOS 4.1.3 tai Solaris 2.2), SGI ja ehkä myös LINUX.
• Covox V8 (tiedostotarkennin .v8).
• Gravis Patch (tiedostotarkennin .pat).
• InterVoice (tiedostotarkennin .ive).
• Audio Visual Research file format (tiedostotarkennin .avr).
• MADx kts. Amiga MOD.
• S3M kts. Amiga MOD.
• 669 kts. Amiga MOD.

Näiden lisäksi on suuri määrä eri ohjelmavalmistajien sovellusten määräämiä projektiformaatteja sovellusohjelmilta, kuten mm. Cakewalk ja Sound Forge (tiedostotarkentimina mm. .wrk, .mff, .rmi, .bun, .sds, .sfr, .dig ja .sd). Nämä sisältävät sovelluksen omaa tietoa. Näitä formaatteja ei tarkastella lähemmin tässä esitelmässä.

6.33. Sovellusohjelmista

Audiotyöskentelyn sovellusohjelmia on olemassa tänä päivänä paljon. Osa on 'vanhoja hyviä' ja osa uudempia, moninaisemmilla 'lisäherkuilla' varustettuja. Sovellusohjelmia on esiteltyinä erikseen joidenkin audioformaattien kohdalla luvussa 6. Useat sovellukset ovat hyvin laaja-alaisia, ts. pystyvät käsittelemään useamman eri valmistajan formaatteja.

Liitteessä 2 on esimerkkinä informaatiota Antexin sovelluksesta NuWave Digital Audio Editor for Compressed Files.

7. Digitaaliaudioprotokollat

Toisinaan digitaalinen audioinformaatio tulee siirtää laitteiden välillä reaaliajassa. Yleisimmin vastaantulevat tiedonsiirtoprotokollat (esim. multimediatuotteet) ovat AES/EBU, SDIF-2 ja S/PDIF.

AES/EBU on Audio Engineering Societyn ja European Broadcast Unionin kehittämä. Se on yleisin käytössä oleva järjestelmä ammattimaisissa digitaaliaudiosysteemeissä. Se on 2-kanavainen RS-422 liittymä käyttäen balansoituja linjoja ja joko XLR- tai D-sub -liittimiä.

SDIF-2 (Sony Digital Interface Format) on kehitetty videonauhapohjaisiin PCM-äänityslaitteisiin. Systeemi käyttää 75-ohmisia balansoituja linjoja BNC-liittimillä.

S/PDIF (Sony/Philips Digital Interface Format) kehitettiin yhteistyössä Sonyn ja Philipsin kesken. Keskeisintä on, että se on balansoimaton versio AES/EBU -protokollasta käyttäen joko RCA- tai kuituoptisia liitäntöjä. S/PDIFia käytetään mm. DAT-nauhureissa, CD-soittimissa ja F1-koodaajissa (DATin edeltäjä, videostandardin tyyppinen järjestelmä) digitaalisin liitännöin.

8. Audioformaatit ohjelmoinnissa

Tässä luvussa tarkastellaan hieman äänitiedostojen sisältöä ohjelmoijan kannalta. Multimediaohjelmointia on mahdollista toteuttaa useilla eri ohjelmistoilla, mutta tässä kirjoitelmassa tullaan keskittymään lähinnä Windows-pohjaiseen, C- ja Visual Basic -ohjelmointiin. Luku perustuu pääasiassa lähteisiin [Mi 91], [Gu 94] ja [Ri 94].

8.1 Windowsin äänenkäsittelyn pääfunktioluokista

Luvussa tarkastellaan Windows-ympäristössä käsiteltävään ääneen, sekä äänen ohjelmointiin liittyviä tekijöitä. Tämä luku perustuu pitkälti Steve Rimmerin kirjoittamaan kirjaan Windows-multimediaohjelmointi [Ri 94], sekä Microsoftin kirjaan Multimedia Programmer's Reference [Mi 91]. Tähän lukuun olennaisesti, esimerkiksi Windowsin WAVE-ohjelmointiin liittyviä asioita käsitellään myös RIFF WAVEn yhteydessä luvussa 6.23.

Windowsissa on neljä äänitiedostojen käsittelyn pääfunktioluokkaa. Ne ovat vaativuusjärjestyksessä

• MessageBeep,
• sndPlaySound,
• MCI-kutsut, ja
• waveOut-kutsut

Tästä voidaan huomata Windowsin luonne tarjota useita vaihtoehtoja saman tuloksen saavuttamiseksi.

8.1.1 MessageBeep

MessageBeep-funktio ja sen parametrit ovat tarpeellisten laajennusten kanssa (äänikortti ja Windows-ajurit) käytettävissä. Parametrit on määritetty vakioina, kuten MB_OK ja MB_ICONASTERISK. Varsinaiset näillä parametreilla soitettavat äänet on määritelty WIN.INI -tiedoston [sounds]-osassa wav-tiedostotarkenteisina. Näin määritelty äänitiedosto voidaan soittaa esim. komennolla

MessageBeep(MB_ICONASTERISK);

Huomioitavaa on järjestelmän rajallisuus. Jos esimerkiksi määrittelyissä tai laitteistossa on puutteita, on tuloksena pelkkä 'piip'-signaali.

8.1.2 sndPlaySound

sndPlaySound on alkeellisin funktio ohjelman alaisuudessa soitettavia äänitiedostoja varten. Määrittelyinä sille riittää äänitiedoston nimi polkuineen tai osoitin muistissa olevaan äänitiedostoon. Funktiolla on kaksi parametria: osoitin ja joukko lippuja. Tästä esimerkkinä seuraava funktio, joka soittaa tiedoston Hello.wav:

sndPlaySound((LPSTR)"Hello.wav".SND_ASYNC);

Jos tiedostoa Hello.wav ei löydy, soittaa funktio WIN.INIssä määritellyn SystemDefault -äänen. sndPlaySound-funktio palauttaa arvon True, jos se onnistuu soittamaan jotain. Muuten funktio palauttaa arvon False.

Toinen sndPlaySound-funktion parametri antaa useita ohjausmahdollisuuksia. Tämä voidaan muodostaa useiden lippujen välisillä OR-operaatioilla. Yleisin näistä on edellisessä funktioesimerkissä esitetty SND_ASYNC, jonka vaikutuksesta sndPlaySound-funktio palauttaa ohjauksen sitä kutsuneelle ohjelmalle heti soiton alustamisen jälkeen. Näin ääni voi soida taustalla sovelluksen ryhtyessä muihin tehtäviin. Jos halutaan suorittaa soitto loppuun ennen vuoron siirtämistä, suoritetaan se lipulla SND_SYNC.

Muita funktioon liittyviä lippuja ovat seuraavat:

• SND_NODEFAULT estää oletusäänen soittamisen.
• SND_LOOP soittaa äänitiedostoa kunnes keskeytetään.
• SND_NOSTOP palauttaa arvon False toisen äänen soittoa yritettäessä. Ensimmäinen ääni jää ennalleen.
• SND_MEMORY-lipun osoitinparametrin oletetaan osoittavan muistissa olevaan äänitiedostoon.

Äänitiedostojen suuren koon vuoksi ne ladataan aina globaaliin muistiin. Näitä on käsiteltävä huge-osoittimien avulla largen sijaan. HPSTR on LPSTR:n large-osoitinta vastaava huge-osoitin. HPSTR-objekteihin voidaan lisätä suuria kokonaislukuja (engl. long integers) ja näin osoittaa yli 64 kt:n kokoisia objekteja. HPSTR-objekti vastaa samaa kuin char huge *. Lisäksi on olemassa vastaavia tiedostofunktioita suurten tiedostojen käsittelyyn. Usean _lread-funktion kutsun sijaan voidaan koko tiedosto ladata yhdellä _hread-funktion kutsulla.

sndPlaySound-funktion käytöllä vaikuttaisi olevan rajoituksensa niin, että funktion kanssa tulisi käyttää suhteellisen pieniä äänitiedostoja. Tämä riippuu kuitenkin järjestelmän käytössä olevan muistin määrästä.

8.1.3 MCI-kutsut

Sovellusten yhteydessä yleensä paras tulos saavutetaan käyttämällä Windowsin MCI-kutsuja (Media Control Interface), joiden avulla voidaan ohjata eri laitteita. Laitteista huolehtivat laiteohjaimet, joita voidaan hallita Windowsin ohjauspaneelista. Kuitenkaan näistä kutsuista kaikki eivät sovellu kaikille laitteille.

MCI:tä voidaan käsitellä kahdella tavalla: korkean tason liittymällä välitetään tekstijonoja komentotulkille, joka suorittaa varsinaiset MCI-kutsut (työlästä C-kielessä), tai kutsua suoraan MCI-funktioita. Funktioiden suoran kutsun yhteydessä tärkeitä kutsuja ovat

• mciSendCommand, joka lähettää kutsun MCI:lle (runsaasti parametrejä), ja
• mciGetErrorString, joka ilmoittaa vian mciSendCommandin valittaessa.

MCI:tä käytettäessä äänitiedostojen soittamiseksi täytyy järjestelmän avata ääniajuri MCI-laitteena, noutaa soitettava äänitiedosto ja käynnistää sen soittaminen. sndPlaySound-funktiosta poiketen MCI palauttaa viestin soiton päättymisestä sitä kutsuneen ohjelman valittuun ikkunaan, jonka jälkeen voi päättää 'seuraavan siirron'. Useita äänitiedostoja yhteen liitettäessä voidaan ensimmäisen äänen loppumisesta ilmoittavalla viestillä aloittaa seuraavan äänen soittaminen.

Seuraavassa esimerkissä avataan MCI:n äänilaite tavanomaisella mciSendCommand-funktion kutsulla:

MCI_OPEN_PARMS mciopen;
DWORD rtrn;
char b[STRINGSIZE+1];
int id;
mciopen.lpstrDeviceType="waveaudio";
mciopen.lpstrElementName=path;
if((rtrn=mciSendCommand(0,MCI_OPEN,MCI_OPEN_TYPE | MCI_OPEN_ELEMENT,
(DWORD)(LPVOID)&mciopen)) != 0L) {
mciGetErrorString(rtrn,(LPSTR)b,STRINGSIZE);
DoMessage(hwnd,b);
return(0);
}
id=mciopen.wDeviceID;

Funktion mciSendCommand ensimmäinen parametri on laitteen ID-numero (tässä laitteen avaaminen antaa sen). Toinen parametri ilmoittaa tekemisen tarkoituksen, eli tässä avaamisen. Kolmas parametri on joukko lippuja, jotka kertovat, mitä neljännen parametrin osia täytyy katsoa. Neljäs parametri on osoitin parametrirakenteeseen. Joillakin MCI-laitteilla on esimerkiksi omia parametriobjektejaan. Funktion tarvitsemat tiedot vaaditun laitteen avaamiseen antaa sille välitetty objekti MCI_OPEN_PARMS. Tässä tapauksessa sen pitää tietää avattava ajuri (waveaudio) ja soitettava äänitiedosto (path). Kaiken sujuessa hyvin palautetaan nolla. Jos vikatilanteessa välitetään mciSendCommandin palauttama arvo mciGetErrorStringille, palauttaa se numerotiedon sijaan selkokielisen kuvauksen viasta. Tätä funktiota kutsutaan

mciGetErrorString(rtrn,b,STRINGSIZE);

jossa rtrn on mciSendCommand-funktion palauttama virhekoodi, b on ilmoituksen sisältävä merkkijonopuskuri ja STRINGSIZE on puskurin koko (voi olla ennalta määrätty: #define). DoMessage-funktio näyttää ilmoituksen (voi hoitaa myös MessageBox-funktiolla).

Kun laite on avattu, soitetaan tiedosto esimerkiksi seuraavasti:

(DWORD)(LPVOID)&mciplay)) != OL) {
mciSendCommand(soundID,MCI_CLOSE,0,NULL);
mciGetErrorString(rtrn,(LPSTR)b,STRINGSIZE);
DoMessage(hwnd,b);
return(0);
}

MCI_PLAY_PARMS-objektin alkiolle dwCallback sijoitetaan mciSendCommandille välitettävä arvo. Se on kahva HWND, joka ilmoittaa MCI:lle äänen soiton loppumisesta kertovan ilmoituksen lähetyksen paikan. Kolmannen parametrin MCI_NOTIFY-lippu kertoo MCI:lle, että dwCallback on sallittu kahva ja että funktio voi käyttää sitä.

MCI-laitteet täytyy sulkea käytön jälkeen. Sulkeminen hoidetaan toisella mciSendCommand-kutsulla

mciSendCommand(id,MCI_CLOSE,0,NULL)

Vastaaminen MCI:n lähettämään sulkemista koskevaan MM_MCINOTIFY-ilmoitukseen tapahtuu seuraavankaltaisella switch-lauseen sisältävällä käsittelyrutiinilla:

case MM_MCINOTIFY;
mciSendCommand(LOWORD(lParam),MCI_CLOSE,MCI_WAIT,NULL);
break;

jossa lParam-arvon tiedoissa on suljettavan laitteen laitenumero. Ilmoituksen lähettämistä koskevista funktioista SendMessage lähettää viestin eikä palaudu ennen ilmoituksen käsittelyä. Vastaavasti PostMessage sijoittaa ilmoituksen ilmoitusjonoon ja palautuu välittömästi sallien ilmoituksen käsittelyn sen siirtyessä jonon päähän.

8.1.4 WaveOut-kutsut

WaveOut-funktioilla voidaan ohjata äänen soittamista laitteiston toimivuuden sallimissa rajoissa. Näitä kutsuja käyttävän äänifunktion rakenne on samankaltainen kuin MCI-kutsuihin perustuvilla funktioilla. WaveOut-funktiot kuitenkin edellyttävät äänen lataamista muistiin. Tämä vaatii RIFF-tiedostojen yksityiskohtaista käsittelyä.

WaveOut-kutsuilla voidaan säätää soitettavan äänen parametrejä, kuten äänen voimakkuutta, toistonopeutta ja korkeutta. Kaikki riippuu loppujen lopuksi äänikortin tukemista piirteistä.

Seuraavassa esimerkissä oletetaan äänitiedoston olevan ladattuna muistiin, johon viitataan waveHandle-kahvalla. Ensin suoritetaan äänilaitteen avaaminen.

HWAVEOUT hwaveout;
char b[stringsize+1];
if((rtrn=waveOutOpen((LPHWAVEOUT)&hwaveout,WAVE_MAPPER,
(LPWAVEFORMAT)&waveformat,(LONG)hwnd,0L,CALLBACK_WINDOW)) != 0) {
waveOutGetErrorText(rtrn,(LPSTR)b,STRINGSIZE);
DoMessage(hwnd,b);
return(0);
}

WaveOutOpen avaa ääntä soittavan laitteen. Tämän toisena parametrina täytyy olla joko avattavan äänilaitteen laitenumero tai vakio WAVE_MAPPER (käskee Windowsin hakea äänikortin). Useamman laitteen (esim. äänikortin) sisältävässä järjestelmässä laitteet (niiden lukumäärä) voidaan testata seuraavasti:

int count;
count=waveOutGetNumberDevices();

Tähän liittyvällä waveOutGetDevCaps-funktiolla saadaan palautettua määrätyn äänilaitteen tiedot. waveOutOpenille välitetty parametri waveformat on far-osoitin PCMWAVEOUT-objektiin ja parametri hwnd on kahva ikkunaan, johon waveOutOpen voi lähettää ilmoituksia. CALLBACK_WINDOW-lippu ilmoittaa ikkunakahvan välityksestä. Toinen mahdollisuus on lähettää funktio-osoite lipulla CALLBACK_FUNCTION (funktio dynaamisessa linkkikirjastossa). 0L markkeeraa käytettävää instanssikahvaa siinä tapauksessa, että callback on funktio. Onnistuessaan waveOutOpen sijoittaa ensimmäisen parametrinsa osoittamaan HWAVEOUT-objektiin avatun laitteen tiedot.

WaveOut-funktiot palauttavat MCI-kutsujen tapaan arvon nolla, kun kaikki sujuu hyvin. waveOutGetErrorText palauttaa selväkielisen virheilmoituksen epäonnistumisesta. Se voidaan kirjoittaa seuraavasti:

waveOutGetErrorText(rtrn, (LPSTR)b,STRINGSIZE);

Äänen soittamiseksi täytyy valmistaa otsikkotieto. Tämä tapahtuu waveOutPrepareHeaderillä otsikkona WAVEHDR-objekti. waveOut haluaa jostakin syystä tämän sijaitsevan globaalissa muistissa, joten se täytyy varata dynaamisesti seuraavalla tavalla:

GLOBALHANDLE waveheader;
LPWAVEHEADER pwaveheader;
if((waveheader=GlobalAlloc(GMEM_MOVEABLE | GMEM_SHARE,
(long)sizeof(WAVEHDR))) == NULL) {
DoMessage(hwnd,"Memory locking error");
return(0);
}
if((pwaveheader=(LPWAVEHDR)GlobalLock(waveheader)) == NULL) {
GlobalFree(waveheader);
DoMessage(hwnd,"Memory locking error");
return(0);
}

Äänitiedot lukitaan seuraavasti:

if((wavepointer=(HPSTR)GlobalLock(wavehandle)) == NULL) {
GlobalFree(waveheader);
DoMessage(hwnd,"Memory locking error");
return(0);
}

WAVEHDR sisältää joukon alustettavia kenttiä. waveOutille täytyy kertoa äänitietojen sijainti ja määrä. Tietojen koko on mmioDescendin palauttaman lohkon koko siirryttäessä soitettavan äänitiedoston data-lohkoon. waveOutPrepareHeaderin kutsu on

pwaveheader->lpData=(LPSTR)wavepointer;
pwaveheader->dwBufferLength=mmSub.cksize;
pwaveheader->dwFlags=0L;
pwaveheader->dwLoops=0L;
if((rtrn=waveOutPrepareHeader(hwaveout,
pwaveheader,sizeof(WAVEHDR))) != 0) {
waveOutUnprepareHeader(hwaveout,pwaveheader,sizeof(WAVEHDR));
waveOutClose(hwaveout);
waveOutGetErrorText(rtrn,(LPSTR)b,STRINGSIZE);
DoMessage(hwnd,b);
return(0);
}

Varsinkin virhetilanteessa on tärkeää sulkea waveOut-laite. waveOutUnprepareHeader vapauttaa aiemmin varatun muistin.

Äänitiedoston varsinainen soittaminen suoritetaan funktiolla waveOutWrite, jonka kutsu on muotoa:

if((rtrn=waveOutWrite(hwaveout,pwaveheader,sizeof(WAVEHDR))) != 0) {
waveOutUnprepareHeader(hwaveout,pwaveheader,sizeof(WAVEHDR));
waveOutClose(hwaveout);
waveOutGetErrorText(rtrn,(LPSTR)b,STRINGSIZE);
DoMessage(hwnd,b);
return(0);
}

waveOutWriten palauttaessa arvon nolla, ääni on soimassa. MCI-kutsujen lailla waveOut-ajuri lähettää ilmoituksen soittamisen päättymisestä waveOutOpenissa ilmoitettuun ikkunaan.

waveOut-kutsun aloittaman äänen päättyessä lähetetään ilmoitus MM_WOM_DONE waveOutOpenissa ilmoitettuun ikkunaan. Ilmoituskäsittelijän case-lause on seuraavantyyppinen:

case MM_WOM_DONE;
waveOutUnprepareHeader((HWAVEOUT)wparam,(LPWAVEHDR)lparam,sizeof(WAVEHDR));
waveOutClose((HWAVEOUT)wParam);
if(wavehandle != NULL {
GlobalUnlock(wavehandle);
GlobalFree(wavehandle);
}
if(waveheader != NULL {
GlobalUnlock(waveheader);
GlobalFree(waveheader);
}
break;

Globaalin muistipuskurin tulee olla kelvollinen niin kauan, kun ääni soi. Sitä ei voi siis varata uudelleen ennen MM_WOM_DONE ilmoituksen lähettämistä. Käytännössä kahvasta kannattaa järjestää globaali muuttuja. Funktion waveOutReset kutsu lopettaa äänen ja lähettää ilmoituksen mm. MM_WAVE_DONE-puskurin vapauttamiseksi.

waveOutReset(hwaveout);

Yksi syy äänitiedostojen soittamiseen waveOut-kutsujen avulla MCI:n sijaan on mahdollisuus toistoon liittyvien parametrien muokkauksen mahdollisuus. Esimerkiksi äänen muokkaus onnistuu funktiolla

waveOutSetVolume(id,volume);

jossa id on laitenumero ja volume on pitkä kokonaisluku. Sanan alaosa sisältää vasemman ja yläosa oikean kanavan äänenvoimakkuuden (0-65535 tai FFFFH). Kaikki äänikortit eivät kuitenkaan tue tätä funktiota. Huomioitavaa on myös, ettei funktiolla suoritetut äänenvoimakkuuden muutokset palaudu alkuarvoihin.

WAVE_MAPPERia käytettäessä laite ei todennäköisesti ole tiedossa, mutta tämä on hoidettavissa laitenumeron HWAVEOUTista selvittävällä waveOutGetID-käskyllä seuraavasti:

WORD id;
waveOutGetID(hwaveout,(LPWORD)%id);

Onnistumisesta funktio palauttaa arvon nolla.

8.1.5 Äänilaitteiden tiedot

Äänilaitteiden tietojen perusteella nähdään tukeeko laite tiettyjä ominaisuuksia. Äänilaitteen tiedot haetaan funktiolla waveOutGetDevCaps (tallennetaan WAVEOUTCAPS-objektiin) seuraavasti:

WAVEOUTCAPS wc;
char b[STRINGSIZE+1];
int rtrn;
if((rtrn=waveOutGetDeviceCaps(0,&wc,sizeof(WAVEOUTCAPS)) != 0) {
waveOutGetErrorText(rtrn,(LPSTR)b,STRINGSIZE);
DoMessage(hwnd,b);
return(0L);
}

Funktion waveoutGetDevCaps ensimmäisenä parametrina on haluttu laitenumero. Tämän avulla järjestelmässä on mahdollista käyttää useampaakin äänikorttia. Toinen parametri on far-osoitin WAVEOUTCAPS-objektiin ja kolmantena toisen parametrin osoittaman objektin koko. WAVEOUTCAPSin sisältö näyttää seuraavanlaiselta:

typedef struct {
unsigned int wMid;
unsigned int wPid;
VERSION vDriverVersion;
char szPname[32];
DWORD dwFormats;
unsigned int wChannels;
DWORD dwSupport;
} WAVEOUTCAPS;

Tässä wMid ilmoittaa laitteen valmistajan. Nämä ovat määriteltyjä vakioita, jotka löytyvät MMREG.H:sta (löytyy Microsoftin kehitinpaketeista). Nämä on määritelty (#define) siten että mm. MM_MICROSOFTin arvo on luku 1, MM_CREATIVEn luku 2 jne.

wPid-kenttä määrittelee erinäisiä vakioita sen mukaan, mikä on wMidin arvo. Esimerkiksi MM_MICROSOFTille se on seuraavankaltainen:

#define MM_WAVE_MAPPER           2 // Wave Mapper
#define MM_SNDBLST_SYNTH         5 // Sound Blaster internal synthesizer
#define MM_SNDBLST_WAVEOUT       6 // Sound Blaster waveform output
...

vDriverVersion määrittää ajurin version numeron ja pzName ilmoittaa äänikortin valmistajan nimen. dwFormats on lippujoukko, joka ilmoittaa tiedostomuodot, joita äänikortin on mahdollista tuottaa. Tämä määrittely tapahtuu tyyliin

#define WAVE_FORMAT_1M08 0x00000001 // 11.025 kHz, monaural, 8-bit
...

wChannels kertoo järjestelmän kanavien lukumäärän (yleensä 1 tai 2). dwSupport määrittää, voiko käytettävällä kortilla säätää äänen toistoparametrejä esim. seuraavasti:

#define WAVECAPS_PITCH         0x0001 // tukee korkeuden säätöä
#define WAVECAPS_PLAYBACKRATE  0x0002 // tukee toistonopeuden säätöä
#define WAVECAPS_VOLUME        0x0003 // tukee voimakkuuden säätöä
#define WAVECAPS_LRVOLUME      0x0004 // vas.-oik. kanavan voimakkuuden
 säätö

8.1.6 MIDI ohjelmoinnissa

Tässä luvussa tarkastellaan hieman MIDI-tiedostojen käyttämistä ohjelmointiympäristössä. Luku perustuu lähinnä lähteisiin [Ri 94] ja [Ro 90].

MIDI-tiedostot koostuvat eri mittaisista lohkoista tai viipaleista (engl. chunk) samantapaisesti kuin RIFF-tiedostotkin. MIDI-tiedostossa on vain kahdentyyppisiä lohkoja niin, että jokainen tiedosto sisältää yhden otsikkolohkon (engl. header chunk) ja yhden tai useampia raitalohkoja (track chunk). Jokainen viipale alkaa neljän tavun ASCII-tyyppitunnuksella ja 32 bitin pituusluvulla, joka ilmoittaa viipaleen jatkon pituuden. Raitaviipale on jonomaisesti esitettyä MIDI-tietoa, jossa kohteena on enintään 16 kanavaa. Otsakeviipaleen tunnus on MThd ja raitaviipaleen MTrk.

Otsikkolohkon rakenne on seuraavanlainen:

typedef struct {
char MThd[4];
unsigned long length;
unsigned int format;
unsigned int tracks;
unsigned int division;
} MIDIHEADER;

Otsakeviipale koostuu tyyppitunnuksesta (MThd), pituudesta (length), muodosta (format), raitojen lukumäärästä (ntrks, tracks), ja jaosta (division). Edellä mainitut tekijät tarkemmin ilmaistuina sisältävät seuraavanlaista tietoa:

• tyyppitunnus = MThd ($4D $54 $68 $64)
• pituus = 6 ($00 $00 $00 $06)
• muoto (0, 1 tai 2)
• 0 = tiedosto sisältää yhden moniraitaisen toisteen
• 1 = yksi tai useampi rinnakkainen raita
• 2 = yksi tai useampi riippumaton yksiraitainen kuvio
• ntrks = tiedostossa olevien raitaviipaleiden lukumäärä
• jako = ilmoittaa tiedoston yhden musiikkialkion keston (metrinen tai aikakoodattu; esim. $E150 tarkoittaa 30 kuvaruutua/s bittiresoluutiolla)

Esitetään ohjelmointiesimerkki tiedostojen käsittelystä C-kielen stream-funktiolla.

unsigned int Read8(FILE *fp, long *size)
{
if(size != NULL) *size-=1;
return(fgetc(fp));
}

Seuraavaksi funktio lukee MIDI-tiedostosta 16-bittisen sanan:

unsigned int Read16(FILE *fp, long *size)
{
if(size != NULL) *size-=2;
return((fgetc(fp) << 8) + fgetc(fp));
}

Vaihtoehtoisesti voidaan myös lukea pitkä kokonaisluku

unsigned long Read32(FILE *fp, long *size)
{
if(size != NULL) *size-=4;
return(((long)fgetc(fp) << 24) +
  ((long)fgetc(fp) << 16) +
  ((long)fgetc(fp) << 8) +
  ((long)fgetc(fp) ));
}

Edellämainittu funktio lukee MIDI-tiedostosta vaihtuvanpituisen luvun. Niiden avulla voidaan tilaa tuhlaamatta tallentaa arvoja, joissa on tarvittava määrä tavuja:

unsigned long ReadVari(FILE *fp, long *size)
{
long value;
int c;
c=fgetc(fp);
if(size != NULL) *size-=1;
value = long(c);
if(c & 0x80) {
value &= 0x7fL;
do {
c=fgetc(fp);
if(size != NULL) *size-=1;
value=(value << 7)+(long)(c & 0x7f);
} while(c & 0x80);
}
return(value);
}

Raitaviipaleeseen tallennetaan varsinainen musiikkitieto. Jokainen raitaviipale sisältää erilaisten tapahtumien jonon. Tapahtumiin on aina liitetty 'delta-aika'-luku. Raitaviipale on muotoa

Raitaviipale, jossa tunnus (MTrk), pituus (length), MTrk tapahtuma, MTrk ... jne, jossa

• tunnus = MTrk,
• pituus = viipaleen loppuosan tavujen määrä, ja
• MTrk-tapahtuma = delta-aika, tapahtuma.

Tapahtumatyypit ovat seuraavat:

Metatapahtuman FFH-tavun jälkeen tuleva tavu määrittää sen, mitä tapahtuman tiedot koskevat. Metatapahtumia on seuraavanlaisia:

8.1.7 Visual Basic

Tässä luvussa käsitellään muutaman esimerkin avulla Visual Basicin äänitiedostojen käsittelyyn liittyviä perusasioita. Tarkastelun lähtökohtana on erityinen TegoSoft Inc.:n TEGOSND.DLL-tiedosto, joka sisältää esimerkeissä käytettäviä funktioita. Luku perustuu lähteeseen [Gu 94].

Proseduuri WAV-tiedostojen avaamiseksi on Form_Load(), sisältäen muuttujan FileToPlay:

Sub FormLoad ()
Dim FileToPlay As String
FileToPlay = "(polku)\*.wav"
SessionNumber=sp_OpenWaveSession(frmPlay.hWnd,FileToPlay)
If SessionNumber<0 Then MsgBox "Ei voi avata tiedostoa" + FileToPlay
End If
End Sub

Parametri frmPlay.hWnd on kahva ja parametri FileToPlay soitettava tiedosto. Funktio palauttaa kokonaisluvun, joka on tunnistenumero tiedostolle. Negatiivinen arvo kertoo avauksen epäonnistumisesta.

Klikattaessa Visual Basicilla tehdyn soittimen oletettua Play-painiketta proseduuri cmdPlay_Click()suorittaa tiedoston soittamisen. Tämä palauttaa arvonaan kokonaisluvun.

Sub cmdPlayClick ()
Dim Result As Integer
Result = sp_PlaySnd(SessionNumber, SP_START_OF_FILE,SP_END_OF_FILE)
End Sub

Funktion sp_PlaySnd ensimmäinen parametri on muuttuja Form_Load-proseduurista, toinen ja kolmas ovat erikseen määritettyjä vakioita, jotka määräävät soiton välin tavuina.

Tiedoston sulkemiseksi voidaan suorittaa proseduuri Form_Unload(), joka näyttää seuraavalta:

Sub Form_Unload (Cancel As Integer)
cmdExit_Click
End Sub

8.1.8 Muuta informaatiota

Lisää informaatiota audio-ohjelmoinnista on saatavilla mm. seuraavista kohteista

• Programmer's Guide to OSS (index) sekä
• Hannu Savolaisen lähdekoodit mm. audio.c, gus_midi.c ja pas2_midi.c hakemistossa i386/isa/sound/ Cross References fo FreeBSD:ssä.

8.2 WWW-sovellukset

Tässä luvussa perehdytään hieman Internet-verkon ja WWW-sivujen yhteyteen kuuluvaan äänitiedostojen käyttöön.

8.2.1 MIDI-tiedostot

MIDI-tiedoston lisäämiseksi WWW-sivulle voidaan kirjoittaa seuraavanlainen HTML-koodi:

<EMBED SRC="XXXX.MID" WIDTH=XXX HEIGHT=XX AUTOSTART=TRUE REPEAT=TRUE>

jossa

• SRC on lähde, esimerkiksi: <EMBED SRC="http://www.blaablaa.com/midi/esim.mid">.
• Plug-In -ohjelma-asetuksista riippuen määritykset paneelin koolle. Esim. asettamalla HEIGHT=0 voi paneelin piilottaa.
• AUTOSTART=TRUE on normaaliasetus, eli toisto käynnistyy sivun avautuesssa. AUTOSTART=FALSE -asetuksella toisto alkaa vasta Play-painiketta painettaessa.
• REPEAT=TRUE on normaaliasetus, joka aikaansaa toiston kertautumisen, kunnes Stop-painiketta painetaan. REPEAT=FALSE -asetuksella toisto loppuu yhden soittokerran jälkeen. REPEAT=2 (tai jokin muu luku) määrää toistokertojen lukumäärän.

Vanhemmille versioille Internet Explorerista koodi on seuraavanlainen:

Jos tiedosto toistetaan ainoastaan kerran, asetetaan LOOP=0.

8.2.2 WAV-, AU- JA AIFF -tyyppiset audiotiedostot

Jos WWW-sivulle halutaan lisätä jokin vuoton (non-streaming) audiotiedosto, kuten WAV-, AU- tai AIFF-tiedosto, lisätään HTML-koodiin seuraavaa:

<EMBED SRC="XXXX.wav(or .au, .aiff)"
WIDTH=144 HEIGHT=60 AUTOSTART=TRUE REPEAT=FALSE>

jossa

• SRC on tiedoston lähde.
• asettamalla HEIGHT=0 voidaan ohjauspaneeli piilottaa.
• AUTOSTART=TRUE on normaalimääritys (kts. ed. luku).
• REPEAT=TRUE jne. (kts. ed luku).

Vanhemmille versioille Internet Explorerista kirjoitetaan seuraavaa

<BGSOUND SRC="XXXX.wav" LOOP=0>

Jos tiedosto toistetaan ainoastaan kerran, asetetaan LOOP=0.

9. Yhteenveto

Tässä seminaarityössä on pyritty tuomaan esille mahdollisimman laaja katsaus digitaalisen äänen tuottamiseen ja tallentamiseen tietotekniikkaympäristössä, sekä sitä hieman sivuavissa järjestelmissä. Erillisistä osa-alueista on varmasti olemassa hyvinkin tarkkaa erikoistietoa, mutta tähän kirjoitelmaan on kerätty lähinnä pääseikkoja mahdollisimman monesta eri tapauksesta.

Kirjoitelma on tästä vielä laajennettavissa huomattavasti varsinkin tekniikan huiman kehitysvauhdin vuoksi. On selvää, ettei kirjoitelmaan ole välttämättä saatu viimeisintä tietoa, mutta edustettuna on mahdollisimman laaja otanta mahdollisimman uudesta tiedosta.

10. Lähteet ja lisämateriaalia

[Af 97] Bennett, Eric, The Cross-Platform Page: Audio Formats, Cornell University, URL: <http://www.mcad.edu/guests/ericb/xplat.aud.html>, 01.05.1997.

[AFF1 95] Universiteit Utrecht, Department of Computer Science, FAQ, Audio File Formats (part 1 of 2), URL: <http://www.cs.ruu.nl/wais/html/na-dir/audio-fmts/part1.html>, 15.08.1997.

[AFF2 95] Universiteit Utrecht, Department of Computer Science, FAQ, Audio File Formats (part 2 of 2), URL: <http://www.cs.ruu.nl/wais/html/na-dir/audio-fmts/part2.html>, 15.08.1997.

[An 97] Antex Electronics, "Audio Interchange Formats and Standards", URL: <http://www.antex.com/audioformats.html>, 30.06.1997.

[Ant 97] Antex - Software And Audio Development Kits, URL: <http://www.antex.com/software.html>, 31.05.1997.

[Ba 85] Bartee Thomas C.,"Digital computer fundamentals", Sixth edition, McGraw-Hill book company, 1985.

[Bu 93] Burger Jeff, "The Desktop Multimedia Bible", Addison-Wesley Publishing Company, 1993.

[Coas 96] Yli-Hietanen, Jari, Tampere University of Technology, Coding of audio signals, URL: <http://www.cs.tut.fi/~ypsilon/80545/CodingOfAS.html>, 20.03.1996.

[Da 95] Davis Pan, "A Tutorial on MPEG/Audio Compression", IEEE Multimedia, 1995.

[El 94] Ellis Michael G., Sr., "Electronic filter analysis and synthesis", Artech house inc., 1994.

[Fda 97] Yli-Hietanen, Jari, Tampere University of Technology, Fundamentals of digital audio, URL: <http://www.cs.tut.fi/~ypsilon/80545/FundamentalsOfDA.html>, 25.04.1997.

[FIPS] US Federal Information Processing Standard 137/NATO-STANAG-4198 2400 bps linear prediction coder (LPC-10).

[Fr 97] Frequently Asked Questions about MPEG Audio Layer-3, URL: <http://www.iis.fhg.de/departs/amm/layer3/sw/index.html>, 14.07.1997.

[Fs1] Federal Standard 1016, Telecommunications: Analog to Digital Conversion of Radio Voice by 4,800 bit/ second Code Excited Linear Prediction (CELP).

[G.711 90] G.711 Pulse code modulation (PCM) of voice frequencies. Book Fasc. III.4: julkaistu kesäkuussa 1990.

[G.722 90] G.722 7 kHz audio-coding within 64 kbit/s. Blue Book Fasc. III.4: published June 1990.

[G.726a 91] G.726 40, 32, 24, 16 kbit/s adaptive differential pulse code modulation (ADPCM). Julkaistu huhtikuussa 1991 korvaamaan G.721 ja G.723.

[G.726A 95] G.726 A Extensions of Recommendation G.726 on 40, 32, 24, 16 kbit/s adaptive differential pulse code modulation for use with uniform-quantized input and output. Kesäkuu 1995.

[G.726III/G.727II 95] G.726 III/G.727 II Appendix III/II to Recommendation G.726/G.727 - Comparison of ADPCM algorithms. Toukokuu 1995.

[G.727a 91] G.727 5-, 4-, 3- and 2-bits/sample embedded adaptive differential pulse code modulation (ADPCM). Toukokuu 1991.

[G.727A 95] G.727 A Extensions of Recommendation G.727 on 5-, 4-, 3- and 2-bits/sample embedded adaptive differential pulse code modulation for use with uniform-quantized input and output. Kesäkuu 1995.

[G.728a 92] G.728 Coding of speech at 16 kbit/s using low-delay code excited linear prediction. Julk. joulukuussa 1992.

[Gu 94] Gurewich Ori, Gurewich Nathan, "Easy Multimedia, Sound & Video for the PC Crowd", Windcrest/McGraw-Hill, 1994.

[Ida 96] Yli-Hietanen, Jari, Tampere University of Technology, Introduction to digital audio, URL: <http://www.cs.tut.fi/~ypsilon/80545/IntroductionToDigital Audio.html>, 12.01.1996.

[IE] I-ETS 300 036 European digitial cellular communications system (phase 1): Full rate speech transcoding (GSM 06-10).

[ISO10743] ISO/IEC DIS 10743 Information technology -- Document processing and related communications -- Standard Music Description Language (SMDL).

[Ja 97] Jalonen Marko, "Radio Internetissä", Internet-kurssin harjoitustyö, 1997.

[Ko 93] Koski Arto & Oesch Klaus, "PC-multimedia", Kustannusosakeyhtiö Otava, 1993.

[La] Modern Digital and Analog Communication Systems, B.P.Lathi., 2nd ed. ISBN 0-03-027933-X.

[Mi 91] Microsoft Windows Multimedia Programmer's Reference, Microsoft Corporation, Microsoft Press, 1991.

[Pa 96] Partanen, Antti, "MPEG", Seminaariesitelmä 1996, TKK.

[Ri 94] Rimmer Steve, "Windows-multimediaohjelmointi", Pagina, Gummerus, Jyväskylä, 1994.

[Ro 90] Romanowski, Otto, "MIDI 1.0", Valtion painatuskeskus, 1990.

[SM 96] 13.3 Standard Module aifc, URL: <http://python.via.ecp.fr/doc/lib/node150.html>, 06.12.1996.

[St 97] Stroud's Index of 32-bit Apps by Category, URL: <http://papa.indstate.edu:8888/CWSApps/inx32.html>, 17.09.1997.

[Str 97] Stroud's Reviews for Audio Apps, URL: <http://cws.avalon.nf.ca/32audio-reviews.html>, 11.05.1997.

[SV 96] Strategic Visions, Katsaus audio- ja videosovelluksin verkossa, URL: <http://www.nettiradio.fi/ test/digi/audvid.htm>, 10.03.1996.

[T.419] ITU-T Recommendation T.419 (1995) | ISO/IEC 8613-9 (DIS) Information technology -- Open Document Architecture (ODA) and interchange format -- Audio content architectures.

[TSC] Transmission Systems for Communications, Fifth Edition, Bell Telephone Laboratories, Incorporated.

[Wab 97] Yli-Hietanen, Jari, Tampere University of Technology, Wideband audio coding, URL: <http://www.cs.tut.fi/~ypsilon/80545/WBACoding.html>, 01.04.1997.

Liitteet:

Liite 1. AIFC:n määrittelemiä funktioita.

Module aifc defines the following function:

open(file, mode) Open an AIFF or AIFF-C file and return an object instance with methods that are described below. The argument file is either a string naming a file or a file object. The mode is either the string 'r' when the file must be opened for reading, or 'w' when the file must be opened for writing. When used for writing, the file object should be seekable, unless you know ahead of time how many samples you are going to write in total and use writeframesraw() and setnframes().

Objects returned by aifc.open() when a file is opened for reading have the following methods:

getnchannels() Return the number of audio channels (1 for mono, 2 for stereo).

getsampwidth() Return the size in bytes of individual samples.

getframerate() Return the sampling rate (number of audio frames per second).

getnframes() Return the number of audio frames in the file.

getcomptype() Return a four-character string describing the type of compression used in the audio file. For AIFF files, the returned value is 'NONE'.

getcompname() Return a human-readable description of the type of compression used in the audio file. For AIFF files, the returned value is 'not compressed'.

getparams() Return a tuple consisting of all of the above values in the above order.

getmarkers() Return a list of markers in the audio file. A marker consists of a tuple of three elements. The first is the mark ID (an integer), the second is the mark position in frames from the beginning of the data (an integer), the third is the name of the mark (a string).

getmark(id) Return the tuple as described in getmarkers for the mark with the given id.

readframes(nframes) Read and return the next nframes frames from the audio file. The returned data is a string containing for each frame the uncompressed samples of all channels.

rewind() Rewind the read pointer. The next readframes will start from the beginning.

setpos(pos) Seek to the specified frame number.

tell() Return the current frame number.

close() Close the AIFF file. After calling this method, the object can no longer be used.

Objects returned by aifc.open() when a file is opened for writing have all the above methods, except for readframes and setpos. In addition the following methods exist. The get methods can only be called after the corresponding set methods have been called. Before the first writeframes or writeframesraw, all parameters except for the number of frames must be filled in.

aiff() Create an AIFF file. The default is that an AIFF-C file is created, unless the name of the file ends in '.aiff' in which case the default is an AIFF file.

aifc() Create an AIFF-C file. The default is that an AIFF-C file is created, unless the name of the file ends in '.aiff' in which case the default is an AIFF file.

setnchannels(nchannels) Specify the number of channels in the audio file.

setsampwidth(width) Specify the size in bytes of audio samples.

setframerate(rate) Specify the sampling frequency in frames per second.

setnframes(nframes) Specify the number of frames that are to be written to the audio file. If this parameter is not set, or not set correctly, the file needs to support seeking.

setcomptype(type, name) Specify the compression type. If not specified, the audio data will not be compressed. In AIFF files, compression is not possible. The name parameter should be a human-readable description of the compression type, the type parameter should be a four-character string. Currently the following compression types are supported: NONE, ULAW, ALAW, G722.

setparams(nchannels, sampwidth, framerate, comptype, compname) Set all the above parameters at once. The argument is a tuple consisting of the various parameters. This means that it is possible to use the result of a getparams call as argument to setparams.

setmark(id, pos, name) Add a mark with the given id (larger than 0), and the given name at the given position. This method can be called at any time before close.

tell() Return the current write position in the output file. Useful in combination with setmark.

writeframes(data) Write data to the output file. This method can only be called after the audio file parameters have been set.

writeframesraw(data) Like writeframes, except that the header of the audio file is not updated.

close() Close the AIFF file. The header of the file is updated to reflect the actual size of the audio data. After calling this method, the object can no longer be used.

Liite 2. Esimerkki Antexin NuWave Digital Audio Editorista.

Antex NuWave Digital Audio Editor for Compressed Files

When it comes to editing digital audio data two things are important. First is compatibility. With NuWAVE you are assured of compatibility of virtually any Windows audio file format - including several compressed file formats. The second is speed. NuWAVE was designed with simplicity and efficiency in mind. Because you can edit in real-time, you will find NuWAVE to be one of the easiest and fastest editors available. Edit Compressed Audio Files With NuWave Take advantage of editing in more efficient compressed file formats such as Dolby AC-2, MPEG Layer I&II, MS-ADPCM. Edit these fileslike any other. File format is completely transparent to NuWAVE and the user. NuWAVE allows you to avoid conversion delays and results in no generation loss.

Why edit compressed audio files? More and more broadcast facilities, multimedia developers, and interactive/on-line applications are using compressed files. Compressed files maximize audio and video quality at a limited bandwidth, demand less from a computer's CPU and take up less disk space than non-compressed files. The ability to edit these files is more efficient and allows editing of multiple formats within a single editor.

What is non-destructive editing? Non-destructive editing is a process that records all edits in an Edit Decision List (EDL). The actual audio files/clips are never altered. The EDL actually contains a list of all audio files to be used with information on when the file will play, how much of the clip to play, and all other characteristics of the file as directed by the NuWAVE editor.

Edit 8 and 16-Bit PCM .WAV Formats Virtually all Windows digital audio files formats (.WAV) files are fully editable with NuWAVE.

True Audio Scrubbing NuWAVE allows true reel-rocking type performance for fast and precise edit point location.

Non-Destructive EDL Based Digital Audio Editing NuWAVE never alters the original audio file. Instead it creates an edit decision list which instructs the editor how to compose and playback the edited version. This speeds the editing process plus it means your library of audio clips remains intact. You can use the same clip in a multitude of files. In addition, standalone composite files can also be created from the EDL.

Four-Track Real-time Operation Simultaneous, independent operation of two stereo (four mono) audio tracks is provided. (Compatible digital audio adapters are required to take advantage of this feature). All mixing, gain adjustments, and fades (in/out) are accomplished in real-time. This is possible due to the advanced capability of DSP-based Antex digital audio adapters. You never have to wait.

Intuitive Drag-and-Drop Interface NuWAVE is extremely simple to use. Editing is easily accomplished by dragging file "regions" and dropping them into place. Standard Windows features including Cut, Copy and Paste are fully supported.

Audio Region: Waveform Mode View and edit files in Waveform view. Cropping audio regions is as simple as dragging the region's handles while holding SHIFT down.

Audio Region: Gain Mode View and edit a region's gain contour by clicking on the region while holding the SHIFT key and then dragging the fade-in, fade-out and gain adjustment handles.

Recommended Hardware Requirements 486DX-33 or above 8 MB RAM Microsoft Windows 3.1 At least 10 MB of hard disk space available Microsoft Windows compatible audio card

Liite 3. ProTrackerin formaattiesimerkki

Protracker 1.1B Song/Module Format:
-----------------------------------
Offset Bytes Description
------ ----- -----------
0 20 Songname. Remember to put trailing null bytes at the end...
Information for sample 1-31:
Offset Bytes Description
------ ----- -----------
20 22 Samplename for sample 1. Pad with null bytes.
42 2 Samplelength for sample 1. Stored as number of words. Multiply by two to get real sample length in bytes.
44 1 Lower four bits are the finetune value, stored as a signed four bit number. The upper four bits are not used, and should be set to zero.
Value: Finetune:
0 0
1 +1
2 +2
3 +3
4 +4
5 +5
6 +6
7 +7
8 -8
9 -7
A -6
B -5
C -4
D -3
E -2
F -1
45 1 Volume for sample 1. Range is $00-$40, or 0-64 decimal.
46 2 Repeat point for sample 1. Stored as number of words offset from start of sample. Multiply by two to get offset in bytes.
48 2 Repeat Length for sample 1. Stored as number of words in loop. Multiply by two to get replen in bytes.
Information for the next 30 samples starts here. It's just like the info for sample 1.
Offset Bytes Description
------ ----- -----------
50 30 Sample 2...
80 30 Sample 3... . . .
890 30 Sample 30...
920 30 Sample 31...
Offset Bytes Description
------ ----- -----------
950 1 Songlength. Range is 1-128.
951 1 Well... this little byte here is set to 127, so that old trackers will search through all patterns when loading. Noisetracker uses this byte for restart, but we don't.
952 128 Song positions 0-127. Each hold a number from 0-63 that tells the tracker what pattern to play at that position.
1080 4 The four letters "M.K." - This is something Mahoney & Kaktus inserted when they increased the number of samples from 15 to 31. If it's not there, the module/song uses 15 samples or the text has been removed to make the module harder to rip. Startrekker puts "FLT4" or "FLT8" there instead.
Offset Bytes Description
------ ----- -----------
1084 1024 Data for pattern 00. . . .
xxxx Number of patterns stored is equal to the highest patternnumber in the song position table (at offset 952-1079).
Each note is stored as 4 bytes, and all four notes at each position in the pattern are stored after each other.
00 - chan1 chan2 chan3 chan4
01 - chan1 chan2 chan3 chan4
02 - chan1 chan2 chan3 chan4
etc.
Info for each note:
_____byte 1_____    byte2_     _____byte 3_____   byte4_
/                                 \  /            \  /                                  \ /             \
0000                    0000-00000000 0000                     0000-00000000
Upper four         12 bits for            Lower four         Effect command.
bits of sam-        note period.        bits of sam-
ple number.                                      ple number.
Periodtable for Tuning 0, Normal
C-1 to B-1 : 856,808,762,720,678,640,604,570,538,508,480,453
C-2 to B-2 : 428,404,381,360,339,320,302,285,269,254,240,226
C-3 to B-3 : 214,202,190,180,170,160,151,143,135,127,120,113
To determine what note to show, scan through the table until you find the same period as the one stored in byte 1-2. Use the index to look up in a notenames table.
This is the data stored in a normal song. A packed song starts with the four letters "PACK", but i don't know how the song is packed: You can get the source code for the cruncher/decruncher from us if you need it, but I don't understand it; I've just ripped it from another tracker...
In a module, all the samples are stored right after the patterndata. To determine where a sample starts and stops, you use the sampleinfo structures in the beginning of the file (from offset 20). Take a look at the mt_init routine in the playroutine, and you'll see just how it is done.
Lars "ZAP" Hamre/Amiga Freelancers
***********************************************************************/

Liite 4. Esimerkkejä muutamista PCM-otsikkotietueista

Liite 5. Uusi formaatti lähes kaikkiin CCRMA-ohjelmistoihin.

Liite 6. DeskMaten snd-tiedostoformaattiesimerkki.