MP3 Tests

MP3 Tests
Inleiding
Voor de stichting Intermediair Kerkomroep Nederland (sIKN) worden verschillende kerkomroep-ontvangers ontworpen en gefabriceerd. Prototypes, nul-series en uiteindelijke productie-exemplaren zullen onder meer worden geëvalueerd wat betreft functionaliteit en bediening. De ontvangers zullen alle gaan werken met audio-streams in MP3-formaat die ze via de sIKN infrastructuur krijgen aangeboden. De Technische Commissie Kabel (TC-CAI) van de sIKN heeft een eenvoudige testomgeving gerealiseerd die niet alleen de toekomstige sIKN infrastructuur natuurgetrouw nabootst, maar ook allerlei verstoringen kan introduceren waarmee het "buitengewone" gedrag van de ontvangers kan worden geëvalueerd.
Streaming server
De testomgeving bestaat uit een "geavanceerde" HTTP- en shoutcast-compatible streaming server waarvan een publiek bereikbare versie momenteel draait op
http://panic.et.tudelft.nl:8500/<streamnaam>[.mp3]
LET OP: Deze server heeft een hard maximum van 200 clients! Draai de server liever zelf, de volledige sourcecode en alle gebruikte datafiles zijn beschikbaar.
De huidige configuratie waarmee de beschikbare streams worden gedefinieerd, staat hier.
Overzicht streams
Om snel de mogelijkheden van een ontvanger te onderzoeken, zijn de lcr<samprate><m/s><bitrate> streams beschikbaar (zie de configuratie!). Alle samplerates en bitrates die in MPEG Layer-3 audio zijn toegestaan, zijn aanwezig, zowel in mono als in stereo. (Hoewel de gesproken tekst bij een mono signaal natuurlijk niet correct is.) Alle ontvangers moeten tenminste lcr22m32 kunnen spelen, want dat is de combinatie die in eerste instantie gebruikt zal gaan worden.
De toekomstige kerkzenders zullen gebruik maken van relatief goedkope geluidskaarten. Deze geluidskaarten hebben geen nauwkeurige samplefrequentie (afwijkingen tot zeker +/- 1%), en er is momenteel nog geen ontwikkeling om dit softwarematig te compenseren! Let wel: 1% afwijking betekent 6 seconden per 10 minuten (600 seconden). Dit betekent dat een stream die zelf beweert 22050 Hz samplerate en 32 kbit/s te zijn, in werkelijkheid bijvoorbeeld 21830 Hz samplerate kan hebben, en dan dus binnen zal komen met 31680.726 bit/s. Vooralsnog is de enige correcte aanpak dat ontvangers dit zelf intern oplossen door de eigen samplerate bij te regelen.
Om het gedrag van de ontvangers bij dergelijke afwijkende samplerates/bitrates te testen, zijn (onder andere) de steady* streams beschikbaar. De steadysync is via NTP exact gesynchroniseerd aan de atoomklokken wereldwijd, en dus per definitie op de juiste sample- en bitrate. Elke ontvanger moet deze stream langdurig zonder enig probleem kunnen weergeven. Tenminste bij CAI-ontvangers moet dit geen probleem zijn wanneer gesynchroniseerd wordt aan de stabiele HF-carrier (typisch <<100 ppm).
Maar zoals boven betoogd is dit niet het enige, er zouden ook op lange termijn geen hoorbare verstoringen mogen optreden bij steady-1, steady-05, steady+05 en steady+1. Omdat problemen bij deze streams mogelijk pas na enige tientallen minuten optreden, zijn ook sterker afwijkende streams beschikbaar tot en met steady-25 en steady+25. Met deze streams kan tevens het buffer-gedrag worden bezien. Het is de bedoeling dat de buffer bij de start van de ontvangst tot halverwege wordt gevuld voordat met afspelen wordt begonnen. Bij een "underrun" moet opnieuw in stilte tot de helft worden gevuld, en bij een "overrun" moet de oudste helft actief worden weggegooid. Vooral dat laatste is iets waaraan zelden wordt gedacht. Voor deze serie streams wordt gebruik gemaakt van gesproken woord, omdat daarmee het gedrag zonder extra apparatuur eenvoudig kan worden gekarakteriseerd.
De netwerkomgeving zal in de praktijk lang niet zo rustig zijn als in de testopstelling. Dit betekent dat de streams totaal niet netjes stabiel zullen binnenkomen, maar dat de pakketjes vaak individueel een willekeurige tijd vertraagd worden door de drukte op het netwerk. Een praktisch equivalente situatie is dat de netwerkverbinding tussen server en ontvanger enige tijd geheel wordt verbroken, en dat direct na het herstel ervan de achterstand zeer snel wordt ingehaald. Elke ontvanger moet een dergelijke onderbreking tot zeker 10 seconden onmerkbaar kunnen overbruggen (dus: tenminste 10 seconden bufferen). Met shakysync kunnen deze omstandigheden goed worden nagebootst. En omdat het synchroniseren van de samplerate aan "onrustig" binnenkomende streams relatief lastig is, zijn ook vertraagde en versnelde versies shaky-25 tot en met shaky+25 beschikbaar.
Om de robuustheid van de MP3-decodering te onderzoeken, zijn enkele streams beschikbaar waarin op willekeurige momenten bitjes worden omgegooid. Dit gaat om error01, error1 en error10. In de eerste twee streams (0.1 resp. 1 bit-error per seconde) zijn nauwelijks verstoringen te merken; in de laatste wel degelijk (10 bit-errors per seconde). Ondanks de verstoringen zouden ontvangers gewoon door moeten blijven spelen, want een gestoorde uitzending is beter dan helemaal geen uitzending.
Een geval apart zijn de CRC-beschermde streams music22m32crc en music22m32crcerr. Dit betreft een "moderne" muziekcollectie die ook in verschillende andere bitrates beschikbaar is, maar nu voorzien van een applicatieniveau foutdetectiecode. Geen enkele ontvanger zou enig probleem moeten hebben met music22m32crc, want dit is een standaard stream op de exact juiste bitrate. De stream music22m32crcerr wordt echter weer voorzien van 10 bit-errors per seconde. Met behulp van de CRC-code kan de ontvanger opsporen welke MP3-frames fouten bevatten, maar correctie is niet mogelijk. Bij de MP3-decodering zijn er dan twee mogelijkheden: ofwel de foute frames negeren en niet afspelen, danwel de CRC-code negeren en alle frames gewoon afspelen met alle verstoringen van dien. In de praktijk blijkt dat zelfs 10 bit-errors per seconde nog niet zoveel verstoringen oplevert dat de begrijpbaarheid ernstig wordt geschaad, vandaar dat de voorkeur uitgaat naar de tweede mogelijkheid, dus de CRC-code negeren.
Om een indruk te krijgen van de algemene kwaliteit van de MP3-decodering kunnen alle streams worden gebruikt. De reeds genoemde spraak en muziek worden uitstekend aangevuld door de wat klassiekere istreme* streams. Onder kerktest* worden in de toekomst mogelijk meer hoge-kwaliteit opnames van volledige kerkdiensten toegevoegd.
Opgemerkt moet worden dat de gebruikte MP3-variant het uiterste vergt van de codeer-software, en dat niet altijd een vlekkeloze representatie kan worden afgeleverd. Het verdient daarom de aanbeveling de streams eerst met bekende kwaliteits-software af te spelen voordat een oordeel wordt geveld over de decodering in de ontvanger. De kwaliteit moet vanzelfsprekend vergelijkbaar zijn, maar kan nooit beter worden dan wat de codeer-software heeft afgeleverd. Vooral gesproken woord en "moderne" muziek zijn soms problematisch; kerkzang daarentegen blijkt vaak met goede kwaliteit codeerbaar te zijn. In dit verband verdienen istreme64, istreme71 en istreme74 een bijzondere vermelding, want deze streams zijn zodanig goed gecodeerd dat wanneer verstoringen hierin hoorbaar zijn, dat praktisch altijd te wijten zal zijn aan de decodering.
Naast de geluidskwaliteit speelt de betrouwbaarheid of continuiteit van de ontvangst een belangrijke rol. Mede om deze reden worden door de streaming server alle streams, na een willekeurig gekozen startpositie, continu en naadloos herhaald. Als een ontvanger niet in staat is om alle exacte-bitrate streams dagenlang probleemloos te blijven afspelen, is dat een duidelijk teken van een onzorgvuldige implementatie.
Coderen naar MP3
Het volgende is vooral van belang voor bouwers van kerkzenders, mensen die via het sIKN kerkomroep-systeem aankondigingen of muziek willen gaan uitzenden, en verder eenieder die geïnteresseerd is in zo hoog mogelijke kwaliteit MP3 met (erg) lage bitrate.
Samenvatting: lame is niet perfect, en simpel gebruik van lame leidt tot onnodig verlies van kwaliteit. Gelukkig is een eenvoudige oplossing beschikbaar.
Vooraf: onderstaande betreft 32 kbit/s MP3-codering van mono geluidssignalen. Gebruikt werd lame 3.93a en een recente versie van sox. Van de standaard samplerates werd vastgesteld dat 44100 Hz teveel vervorming door de MP3-codering oplevert, terwijl bij 11025 Hz te weinig van het audiospectrum bewaard wordt om bruikbaar te zijn. Gekozen werd daarom voor 22050 Hz samplerate wat betreft de MP3-codering. (De bekende veelvouden van 4000 Hz werden vanwege de beperkte ondersteuning niet als kandidaten beschouwd.)
De geluidskaart. Om 22050 Hz samplerate te bereiken, zou direct met die samplerate kunnen worden opgenomen met de geluidskaart. De huidige generatie goedkope geluidskaarten heeft echter een zodanig onbetrouwbare kwaliteit van filtering dat we dat in software beter en reproduceerbaarder kunnen doen. Bovendien zal blijken dat de filtering op een andere frequentie moet gebeuren dan -naar we mogen hopen- op de geluidskaart gebeurt.
Filtering? Uit de signaalverwerkings-theorie blijkt dat bij verandering van de samplerate altijd sprake is van het "omklappen" van het frequentiespectrum met de helft van de laagste samplefrequentie als kantelpunt. Dit verschijnsel genaamd "aliasing" treedt op bij digitaal resamplen, maar ook bij de overgang van geen samplerate (=analoog, eigenlijk oneindige samplerate) naar wel een samplerate (=digitaal) en vice versa. Bijvoorbeeld een toon van 13000 Hz in een analoog signaal dat wordt gesampled met 22050 Hz, zal omklappen rondom 11025 Hz en zal in het digitale signaal te horen zijn als toon van 9050 Hz. Dat was niet de bedoeling. En een toon van 440 Hz in een digitaal signaal met 12000 Hz samplerate zal bij resampling naar 44100 Hz omklappen rond 6000 Hz en in het nieuwe signaal zowel als toon van 440 als van 11560 Hz te horen zijn. Dat was evenmin de bedoeling. Vandaar dat bij samplen en resamplen altijd de ongewenste signalen worden weggefilterd. Bij neer-samplen wordt vooraf gefilterd (zodat er niets meer is wat kan omklappen) en bij op-samplen achteraf. De filtering zorgt dus steeds dat alle frequenties boven de helft van de laagste samplerate worden verwijderd -- oftewel het is een laagdoorlaatfilter "op" de halve samplefrequentie.
Terug naar de geluidskaart. Het filter wat, bij opname met 22050 Hz samplerate, op 11025 Hz zou moeten zitten, is zelden van hoge kwaliteit en zit vaak te laag (te veel weggefilterd dus onnodig kwaliteitsverlies) of te hoog (te weinig weggefilterd dus hoge tonen die gaan omklappen en op de verkeerde toonhoogte hoorbaar worden, wederom onnodig kwaliteitsverlies). Er zijn hele series geluidskaarten bekend waar dit probleem speelt. Als we op veel hogere samplerate opnemen, bijvoorbeeld 44100 of 48000 Hz, blijven die problemen in het digitale signaal praktisch altijd beperkt tot frequenties boven de grofweg 15000 Hz. En als we dan zelf gaan downsamplen naar 22050 Hz in het digitale domein, kunnen we zelf de kwaliteit van ons filter op 11025 Hz bepalen, en moeten de verstoringen vanaf 15000 Hz zowiezo verdwijnen. Op deze manier speelt de kwaliteit van het filter op de geluidskaart dus geen enkele rol meer.
Mono van stereo. Iets wat pas opvalt als we er gericht naar gaan zoeken, is dat de meeste geluidskaarten bij mono opnamen enkel kijken naar het (meestal) linkse kanaal. Dat niet gewenst als we een stereo signaal aanbieden en ook de gebeurtenissen in het rechtse kanaal willen opnemen. De oplossing is om altijd in stereo op te nemen, en vervolgens in software het gemiddelde van de twee kanalen te berekenen. Zelfs bij mono signalen is dat een goed idee, want als we op beide kanalen hetzelfde mono signaal aanbieden en vervolgens het gemiddelde van de dubbele opname berekenen, zal de interne ruis van de geluidskaart effectief worden gehalveerd. Wederom een truc om een betere prestatie te behalen met een lage-kwaliteit geluidskaart.
Lame? Samengevat is de situatie dus dat we een stereo 44100 Hz samplerate opname willen omzetten in een mono 22050 Hz samplerate MP3 stream van 32 kbit/s. Als je bekend bent met de documentatie, zul je opmerken dat lame daar prima toe in staat zou moeten zijn, want er wordt tenslotte een "--resample" optie vermeld. Helaas wijst de praktijk anders uit. Er wordt dan weliswaar enige filtering toegepast, maar die is erg "slap", en het omklappen van frequenties is goed meetbaar en vaak ook hoorbaar. Dat kunnen we dus beter apart doen.
Polyphase? Bij inspectie van de lame uitvoer valt op dat gesproken wordt over een "polyphase filter". Dit is simpelweg een truc om het MP3-resultaat te verbeteren door vooraf vast wat hoge frequenties weg te gooien. Bij 32 kbit/s zet lame dit filter echter op 7600 Hz, en dat is nogal laag gezien het feit dat we tot ca. 11025 Hz beschikbaar hebben, en dat zelfs dat al matig is wat betreft geluidskwaliteit. Gelukkig kan dit filter eenvoudig met -k worden uitgeschakeld.
Nog een filter. Zelfs wanneer we de -k optie gebruiken, blijken frequenties boven ca. 10000 Hz simpelweg te verdwijnen, met uitzondering van een klein gebiedje vlak onder de maximaal beschikbare 11025 Hz. En bij 10000 Hz wordt niet eens netjes afgekapt, maar met een relatief forse rimpel aan het einde van de doorlaatband. Waarom dit gebeurt is een raadsel, wellicht heeft dit te maken met het MP3-gebeuren op zich. Feit is dat we dus geen frequenties moeten aanbieden die vallen in de rimpel vlak onder de 10000 Hz. Oftewel, onze eigen filtering moet daarop zijn afgesteld, en niet op de halve samplefrequentie (11025 Hz).
De totaaloplossing. Met de volgende commandoregel worden alle besproken acties uitgevoerd, en een optimaal gecodeerde MP3 afgeleverd op stdout:
sox -v0.99 -r44100 -c2 -s -w -tossdsp /dev/dsp -twav -c1 - avg | sox -v0.90 -twav - -r22050 -twav - resample 0.60 | lame -b32 -q0 -k - - > ergens
Het eerste commando zorgt voor de opname met de geluidskaart in 44100 Hz stereo, en tevens de correcte middeling naar mono. Tussen de commando's wordt wav-codering gebruikt waardoor de parameters steeds intern worden doorgegeven en fouten worden vermeden. Met het tweede commando wordt de resampling plus filtering gerealiseerd. Tenslotte wordt het resultaat daarvan omgezet in 32 kbit/s MP3 met zo hoog mogelijke kwaliteit. De geringe volume-aanpassingen in de eerste twee commando's zijn bedoeld om eventueel in de opname aanwezige clipping tot een minimum beperkt te houden. Sox heeft moeite met geclipte input en kan in enkele gevallen in de output naar volledig negatief in plaats van positief clippen en omgekeerd; dit speelt sterker bij het tweede commando omdat bij de filtering faseverschuivingen kunnen optreden die tot extra clipping kunnen leiden.
De enige belangrijke parameter die nog kan worden aangepast, is de filterfrequentie, die in het bovenstaande op 0.60 (relatief t.o.v. ideaal) staat. Dit is de maximale waarde vanwege het vreemde gedrag van lame rond 10000 Hz, maar bij deze waarde blijven bij complexe audiosignalen nog zoveel frequenties over dat het simpelweg niet in de MP3 past en er vervormingen ("slis"-geluiden) op kunnen treden. Om deze in alle gevallen te vermijden zou kunnen worden overwogen om terug te gaan naar 0.50 of zelfs 0.45, waarbij effectief geluidskwaliteit (frequentiebereik) wordt ingeruild tegen geluidskwaliteit (vervorming).

-- J.A. Bezemer, ktel@opensourcepartners.nl