Digitális átvitel, USB, jitter, bithibák

A következőkben kicsit mélyebb vizekre szeretnék evezni, a digitális átvitelt szeretném boncolgatni, kicsit részletesebben az USB Audio-t és az ezzel kapcsolatban szóba kerülő jittert és bithibákat.
Ezzel kapcsolatban szeretnék megosztani egy rövid történetet, ami velem esett meg pár évvel ezelőtt egy híres budapesti kábelforgalmazó üzletben. Pár csatlakozót szerettem volna vásárolni, és várakozás közben hallottam, ahogy az eladó megpróbálja rávenni a másik vásárlót arra, hogy a nemrég vásárolt hálózati médialejátszójához vegyen jobb minőségű UTP kábelt a jobb hangminőség érdekében.

Akkor annyira meglepődtem, hogy hirtelen nem tudtam, mitévő legyek, inkább elengedtem a dolgot. Ma már valószínűleg elmagyaráznám az eladónak, hogy az a hálózati lejátszó ugyanolyan hibajavítással rendelkező hálózati protokollt használ, mint bármelyik számítógép, és az 500 Ft-os teszkós noname UTP kábelen pontosan ugyanolyan minőségben fog közlekedni az adat, mint az általuk 10-100-szoros áron forgalmazott UTP kábeleken.

Egy akármilyen kábel standard bithiba-aránya körülbelül tíz a mínusz tizediken, azaz kb. minden 10 milliárd bitből egy lesz hibás a kábel tökéletlensége miatt. A könnyebb érthetőség érdekében, minden 1 GB adatból 1 bit hibás lesz, amit természetesen a hálózati protokoll villámgyorsan javít, így az adat bitpontosan fog megérkezi a célhoz. Ez a TCP/IP protokollra igaz, viszont a csavar a történetben az, hogy az USB Audio átvitel nem használ semmiféle hibajavítást, tehát itt a bithibák javítatlanok maradnak. Ez így igaz. De ugye 10 milliárd bitből 1 hiba a kábel miatt még nem adna okot az aggodalomra.
Itt jön be a történetbe a rettegett jitter, ami nagyon röviden egy összefoglaló elnevezés a digitális jelfolyamok időbeli pontatlanságára.

A jitter tisztán digitális átvitel esetén adott esetben egy vagy több bithibát okozhat, attól függően, hogy éppen mennyire volt elcsúszva a mintavételezés időpontja az elvárthoz képest, és mi a következő bit. A jitter természetesen nem okoz problémát a számítógépes hálózatoknál, hiszen a hibaellenőrző és javító algoritmus kiküszöböli ezt a problémát. De mivel USB Audio esetén ilyen nincs, ezért ott a bithiba az sajnos hibás átvitelt fog eredményezni. Az alábbiakban azt szeretném bemutatni, hogy egy vagy több bithiba milyen hatással van a zenére, és hallható-e egyáltalán, de még mielőtt elmélyednénk a bitekben, fontos leszögezni, hogy ez a jitter a digitális átvitelt érintő jitter. A digitális-analóg konverziókor fellépő jitter egy teljesen más történet, ezt az alábbi ábra mutatja meg.

Az alábbiakban azt vizsgáljuk majd, hogy mi történik akkor, ha az interface jitter miatt bithibás adat érkezik meg a DAC-ba. Ennek bemutatására egy 10 másodperces részletet vágtam ki az MP3 teszthez használt hanganyagból, a fájl neve: cz_10s.wav.
A teszthez azért szükséges WAV fájlt használni, mivel a WAV egy PCM (Pulse-code modulation) konténer, a PCM pedig maga az audio hullámforma leíró fájlja. Ha valaki szeretne, akkor az alábbi linken utánanézhet a WAV fájlok felépítésének: http://soundfile.sapp.org/doc/WaveFormat/

Egy 32 bites WAV fájl esetén a konténer fejléc után következik maga az adat, minden egyes sample 32 biten tárolva (16 bit a jobb és 16 bit a bal csatornának), tehát 1 sample összesen 4 byte, például 8901 8500 amely egy adott mintavételi pontban reprezentálja a hang hullámformáját. Ezt vissza is tudjuk számolni, ha megnézzük a 10 másodperces tesztfájl méretét byte-ban, azt látjuk, hogy 1764362 byte a mérete.

Gyors számolás után ki is jön a matek: 44100-as mintavételi frekvencia mellett, 32 biten tárolt minták, 10 másodpercen keresztül: 10*32*44100=14112000 bit osztva 8-cal: 1764000 byte a tiszta PCM adatfolyam. A maradék 362 byte pedig a WAV konténer fejléce plusz a metaadatok (előadó, számcím stb…). Kis adalék, hogy a microsoftos WAV little endian byte sorrendet használ, tehát a legutolsó byte a legmagasabb helyiértékű byte, míg az Apple PCM konténere, az AIF pont fordítva, big endiant használ. Én az elterjedtebb windowsos formátumot fogom használni, a WAV-ot. A DAC chipek általában mindkét formátumot le tudják játszani.

Első körben fordítva közelítem meg a bithiba jelenséget, és kiválasztok egy sample-t a 10 másodperces adatfolyamban, amit az Audacity hangszerkesztőben csúnyán “elrontok”. Ennek az az értelme, hogy így pontosan fogom látni a hangszerkesztőben a hiba helyét, és pontosan tudni fogom, hogy a fájlban melyik sorban okoztam eltérést az adatfolyamban, amit később szerkesztve szintén tudni fogom, hogy hol keressük a hibát a hangszerkesztőben. Az alábbi képen látható ahogy egy sample-t kijelölve +10 dB erősítést teszek erre az egy mintára.

Ez a teljes hanghullámra nézve is jelentős kiemelés, és “messziről” is látszik:

A hangfájlt elmentem más néven, a későbbi szerkesztés és összehasonlítás miatt cz_10s_amp.wav néven. Ha esetleg hasonlóval próbálkoztok, fontos, hogy a hangszerkesztő beállításaiban kapcsoljátok ki a Ditheringet az exportálásnál, különben a hangszerkesztő végigereszt egy dithering algoritmust a hanghullámon, és nem lesz bithelyes a két fájl változatlanul hagyott része.
Mivel egy sample-t változtattunk meg a hanghullámban, azt várjuk a most elmentett WAV fájltól, hogy egy darab 32 bites részen különbözzön az eredeti WAV-tól. Ezt OSX illetve Linux alatt könnyedén lehet ellenőrizni parancssorból. Először átalakítjuk hexadecimális formába a WAV fájlokat az xxd parancs segítségével:

xxd cz_10s.wav > cz_10s.hex
xxd cz_10s_amp.wav > cz_10s_amp.hex

Majd a diff paranccsal megnézzük a kettő közötti különbséget:

diff cz_10s_amp.hex cz_10s.hex
62253c62253
< 000f32c0: 160e a108 3a0e 8108 4f2d 9c1a 6d0e 4708 ....:...O-..m.G.
---
> 000f32c0: 160e a108 3a0e 8108 540e 6a08 6d0e 4708 ....:...T.j.m.G.

Ahogy vártuk, 32 biten azaz 4 byte-on találunk eltérést, a 000f32c0 sorban: a “540e 6a08” minta megváltozott erre: “4f2d 9c1a”
Meg is hallgathatjuk a változást, egy ronda pattanást fogunk hallani a zenében. Bitekre lefordítva mit is jelent ez?
A 540e 6a08 binárisan: 0101 0100 0000 1110 0110 1010 0000 1000
A 4f2d 9c1a binárisan: 0100 1111 0010 1101 1001 1100 0001 1010

Én itt 14 bithibát számolok a 32-ből. Igen, ezzel egy ronda jittert szimuláltunk, nem is kell hozzá nullteszt, hogy bármin halljuk ezt a sorozatos bithibát. De mi van akkor, ha csak egy bithiba történik az eredetihez képest? Ezt is tudjuk szimulálni, egy HEX editorba betöltjük az eredeti WAV fájlt, rákeresünk a “540e 6a08” mintára (jó eséllyel ebből pontosan egy lesz majd), és átírjuk “540e 6a88”-ra, ezzel a little endian bytesorrend miatt, a legnagyobb helyiértékű byte (08) legnagyobb helyiértékű bitjét írjuk át 0-ról 1-re.
Hiszen a hexadecimális 08 binárisan így írható fel: 0000 1000, a hexa 88 pedig így: 1000 1000. Látható, hogy pontosan 1 bit az eltérés a két fájl között.
Ezzel az ezen a mintán, egy bithibával elkövethető legnagyobb eltérést okozzuk majd.

Ezt a fájlt elmentjük cz_10s_1bit_error.wav néven, majd betöltjük a hangszerkesztőbe, hogy meghallgassuk, és megnézzük az eredményt. Azt hiszem, elég egyértelműen látszik az alábbi képen, hogy hol követtünk el bithibát. A meghallgatás is egyértelmű eredményt fog hozni, szintén egy pattanást fogunk hallani. Nagyon fontos megérteni, hogy egy 1,8 MB-os hangfájlban mindössze egyetlen bitet írtunk át, ami ezt a hibát okozta.

Ezzel a teszttel tehát kétséget kizáróan megmutattuk, hogy ha az átviteli jitter miatt bithibás felvételt hallunk, akkor pattogó hangot fogunk hallani, de semmiképpen sem olyan formában hallunk bithibát, hogy a hegedű hangja kevésbé élettel telt, sem pedig olyan formában, hogy eltűntek a mélyek, sem pedig olyan formában, hogy pontatlan lett a sztereó tér, hiszen a véletlenszerű hibák egy PCM adatfolyamban a hibás mintán egy teljesen más hullámformát fognak eredményezni.

A cikk még nem ért véget, kérlek, lapozz!