Zenelejátszó program – Média alapok
PapÃron bármilyen hanganyag lejátszása egyszerű: be kell tölteni a fájlt és meg kell szólaltatni a hangkártyán. Azonban az ördög itt is a részletekben rejlik…
Fájlok betöltése
Az elsÅ‘ ilyen fontos részlet a fájl betöltése. A médiafájlok közül számtalan létezik ugyanarra a célra. Eltérés „csak” a kódolásban van, de ez a „csak” valójában az egyik legfontosabb részlet.
Azért az egyik legfontosabb és nem a legfontosabb, mert a médiafájlok esetén valójában konténer formátumról és kódolásról beszélhetünk. Ez azt jelenti, hogy vannak olyan fájlformátumok (pl. mp4), amik többféle kódolású hanganyagot is tartalmazhatnak, illetve az mp4 konténerformátum a hang mellett videó hordozására is képes.
Nem kell azonban ennyire fejlett formátumról beszélnünk, már a jó öreg WAV formátum is valójában egy konténer, ami tartalmazhat többféle kódolást, PCM-et, ADPCM-et, de akár még MP3-at is.
Illetve ekkor még nem beszéltünk a különbözÅ‘ kódolások altÃpusairól. Az egyszerűség kedvéért beszéljünk a PCM kódolásról. Ott 3db jellemzÅ‘ befolyásolja az olvasandó és feldolgozandó adatmennyiséget: mintavételezési frekvencia, bitmélység, csatornák száma. Azonban van egy negyedik tényezÅ‘ is, a bitsorrend.
A hangkártyán, vagy különállóan található DAC az ilyen PCM kódolású hanganyag analóg átalakÃtására képes, ezért lényegében minden komolyabb konténer formátumból a hanganyagot ebbe a formátumba kell dekódolni.
A kódolásokat alapvetően két csoportba lehet sorolni. Vannak a veszteséges és a veszteségmentes formátumok. Értelemszerűen a veszteségmentes formátumok a legjobbak, hiszen az eredeti hanganyagból minden megmarad a kódolás végén és a dekódolás után is az eredeti hanganyagot kapjuk vissza.
Azonban ennek ára van, amit memóriában vagy tárhelyben fizetünk meg. A veszteségmentes tömörÃtések hatásfoka legjobb esetben is 50% környékén kimerül, de ez nagymértékben függ a bemeneti jeltÅ‘l. A veszteséges tömörÃtésnél is árat fizetünk, ami itt a minÅ‘ség romlása. A nevébÅ‘l adódóan egy veszteséges tömörÃtésnél sosem fogjuk visszakapni az eredeti jelet extra torzÃtás és zavar nélkül. Az ilyen algoritmusok esetén az algoritmus jóságát a dekódolás esetén keletkezÅ‘ zaj mennyisége mutatja.
Legyen bármilyen jó is az algoritmus, minden esetben keletkezni fog némi torzÃtás a veszteséges tömörÃtésnek köszönhetÅ‘en. Cserébe azonban az Ãgy kódolt fájlok kevesebb memóriát vagy tárhelyet igényelnek.
De mégis mennyi memóriáról beszélünk? Vegyük alapul például a CD minÅ‘séget. Ez 44,100kHz-es mintavételezést alkalmaz, 16 bit felbontással 2 csatornán. 1 másodperc hanganyag tárolásához Ãgy 44100 * (16/8) * 2 byte kell, ami ~172,2kiB adatot jelent. 60 perc esetén ~605,6MiB.
Ha DVD hangminőségről beszélünk, 48kHz mintavételezéssel, akkor ugyanez az egy óra ~659,1MiB memóriát igényel és ez még sehol sincs a nagy felbontású stúdió minőségtől, amit általában 192KHz-en és 24 biten mintavételeznek. Ebben a minőségben 1 másodperc sztereó hang már ~1,09MiB adatot jelent.
De a legtöbb esetben nincs szükség ilyen minÅ‘ségre, Ãgy még a mai napig a legelterjedtebb a 44,1kHZ-es mintavételezés 16 bites felbontással.
MegjelenÃtés
Ha a hanganyag dekódolásán túl vagyunk, jöhet annak a megjelenÃtése. Ehhez beszélgetnünk kell a hangkártyával valamilyen API-n keresztül. API tekintetében Windows esetén több is rendelkezésre áll.
Van a DirectSound, ami az egyik legrégebbi. Ez még a Windows 95 környékén jelent meg, Ãgy rengeteg program használja vagy használta. Manapság már elavultnak számÃt, de még mindig működÅ‘képes.
A DirectSound leváltásra azért volt szükség, mert ha két eszköz eltérÅ‘ bitmélységgel és felbontással akarta használni ugyanazt az eszközt, akkor az elsÅ‘ alkalmazás formátuma nyert, mivel közvetlenül a hangkártyával kommunikált a rendszer. Ezt a limitációt a korabeli eszközök hardverbÅ‘l és hozzá tartozó driver-bÅ‘l elfedték, de az AC97 szabvány lehetÅ‘vé tette a hang chip-ek alaplapra integrálását és lényegében a hangkártya olcsósÃtását azáltal, hogy szinte minden szoftverbÅ‘l történt.
Ez a gyártóknak csak jó, mivel kevesebb chip-et kell integrálni az eszközbe, Ãgy lényegében kisebb tud lenni a gép. Cserébe viszont ezeknek a hangeszközöknek a minÅ‘sége valahol a rossz és a közepes között mozgott. Éppen ezért az AC97-et váltotta a HDAudio, ami már jobb minÅ‘séget képvisel, de azért ettÅ‘l sem kell világmegváltó minÅ‘séget várni.
A DirectSound utódja a Vista-ban bemutatkozott WASAPI, ami azóta a Windows hangrendszere. A DirectSound-ot használó programok is ezen az API rendszeren keresztül mennek, Ãgy lényegében tényleges hardverelérésre DirectSound esetén Windows Vista óta nincs lehetÅ‘ség.
Ez lényegében a hardveres mixert helyettesÃti szoftverbÅ‘l. ExkluzÃv üzemmódban Å‘ egyedül használja a hangkártyát és minden kérés, ami a hang felé irányul, azt Å‘ akár újramintavételezi és keveri más hangokkal is.
Ez a mintavételezés és keverés nem minden esetben a legjobb, mivel extra késleltetést visz a rendszerbe. Éppen ezért a rendszer megengedi, hogy exkluzÃv üzemmódban csak egy dedikált programnak legyen hozzáférése az eszközhöz, kikerülve a mixert és az esetleges újramintavételezést.
Ezt az üzemmódot leginkább stúdió hangszoftverek használják, bár Å‘k leginkább ASIO-n kommunikálnak, ami a WASAPI-hoz hasonlóan egy program számára biztosÃt hozzáférést a hangeszközhöz alacsony késleltetéssel. Az ASIO leginkább annak köszönheti elterjedését, hogy hamarább jelent meg, mint ahogy a WASAPI bekerült volna a Windows-ba és nem utolsó sorban Mac eszközök esetén is rendelkezésre áll.
Ezt mind magunktól?
A bevezetÅ‘t még bonyolÃtani tudnám millió apró és fontos részlettel, de csak azt érném el vele, hogy még lehetetlenebb feladatnak tűnjön a program elkészÃtése. Jó hÃr azonban, hogy nem kell feltalálnunk a kereket.
Egyik alapvetÅ‘ szoftverfejlesztési tétel a DRY, ami a Don’t Repeat Yoursef szavak rövidÃtése. Ez jelen pillanatban nem feltétlenül a leghelyesebb kifejezés, de a lényeg az, hogy csak akkor álljunk neki valaminek az újraimplementálásának, ha tényleg indokolt.
Erre médiafájlok esetén a legtöbbször szinte nulla szükségünk van, mivel számos projekt létezik a célra.
Ezek közül a legnépszerűbb az FFmpeg projekt, ami mindenbÅ‘l is mindenbe tud dekódolni és konvertálni. Erre számos lejátszó épül, amit felhasználva mi is készÃthetünk lejátszókat. Az egyik ilyen projekt a magyar gyökerekkel rendelkezÅ‘ MPlayer. Az MPlayer fejlesztése az utóbbi idÅ‘ben belassult, helyét a különbözÅ‘ forkok vették át. Ezek közül nap, mint nap én az mpv nevezetűt használom videók lejátszásra.
A zenelejátszó programunk azonban nem mpv és FFmpeg alapú lesz, mivel az jelen esetben drámaian leegyszerűsÃtené a dolgokat, hiszen szinte mindent kulcsra készen ad, valamint egy mpv build 50-60Mb környékén van, ami bÅ‘ven az ágyúval a verébre kategória lenne.
A jövőben, ha időm engedi, akkor lesz szó majd FFmpeg és mpv használatáról, de addig is maradjunk a jelenlegi projektnél.
Bass.dll
Számos hang lejátszására képes projekt létezik eltérÅ‘ tudással. Egyik ilyen az NAudio. Ez egy .NET-ben Ãrt hangkezelÅ‘ könyvtár, ami Ãgéretes, de támogatott fájlok tekintetében még mindig limitált a tudása.
Éppen ezért a választásom a Bass.dll komponensekre esett. Ez egy audio könyvtár, amely több platformon is használható. A projekt célja, hogy a fejlesztÅ‘knek hatékony módot biztosÃtson hangfájlok kezelésére. A projekt lényegében az XMPlay zenelejátszó újrafelhasználható motorja.
Az XMPlay-rÅ‘l azt kell tudni, hogy nagyjából egy idÅ‘s a Winamp projekttel, de valahogy sosem lett annyira népszerű. Viszont a Bass.dll motor számos kereskedelmi és ingyenes szoftverbe beépÃtésre került.
Maga a Bass.dll nem nyÃlt forráskódú, de egészen addig amÃg nem kereskedelmi célra értékesÃtett szoftverben használjuk fel (az-az ingyenes a programunk), addig licenc költségek nélkül használható.
Mivel ez egy natÃv dll fájl, illetve natÃv dll fájlokból álló csomag .NET esetén Platform invoke segÃtségével használható. Ez azonban nem azt jelenti, hogy nekünk kellene elkészÃteni az összes dll funkcióhoz a C# wrappert, mert ezt már mások megtették helyettünk.
Két projekt létezik erre a célra, amirÅ‘l én tudok. Az elsÅ‘ a Bass.Net, ami szó szerint az elsÅ‘ projekt volt erre a célra. Szintén nem ingyenes kereskedelmi célra, de ami idegesÃtÅ‘bb, hogy a nem regisztrált változatok indÃtáskor a saját logójukat jelenÃtik meg a programunkban.
A másik projekt a ManagedBass. Ez egy nyÃlt forráskódú implementáció, ezért ezt fogjuk alkalmazni.
Lehetne arról vitatkozni, hogy mennyire jó döntés a Bass.dll használata, de megmondom Å‘szintén ebben van a legnagyobb tapasztalatom, mivel ezt már anno Delphi 6.0 alatt is alkalmaztam zenelejátszó készÃtésre.
Folytatása következik…
