Digitale Audiospeicherung: Rohdaten, verlustfreie und verlustbehaftete Komprimierung

[livebox]

Angeregt durch eine Diskussion zum Thema mp3 im https://www.musiker-board.de/pa-mischpulte-pa/492986-behringer-x32-userthread.html habe ich mal ein bisschen was zusammengeschrieben.


Theorie

Bei digitalen Audio-Formaten unterscheidet man nach Rohdaten, verlustfreier Komprimierung und verlustbehafteter Komprimierung.

Rohdaten sind Daten, die vom Analog-Digital-Wandler kommen, genannt Samples. Also einzelne Zahlenwerte, die die Lautstärke des jeweiligen Samples repräsentieren. Bei 24 Bit hat man also 2²⁴ --> etwa 16 Millionen Raster zur Einteilung der Lautstärke. Die müssen nicht unbedingt linear sein (zur Optimierung der SNR), aber das interessiert uns an der Stelle nicht. Und bitte nicht verwechseln: Hier reden wir von Fixed Point Signalverarbeitung, wie sie für die Speicherung auf Datenträgern genutzt wird. Die 40 Bit Floating Point, mit denen das x32 intern arbeitet, können damit nicht verglichen werden.
Ein Rohformat schreibt also pro Sekunde einen Haufen Samples (wie oft hängt von der Abtastrate ab, also z.B. 48.000 mal bei 48 kHz) irgendwo auf ein Speichermedium. Jetzt gibts noch verschiedene Formen, wie die Samples geschrieben werden - z.B. ob die Zahl von vorn nach hinten geschrieben wird oder umgedreht. Deshalb gibt es auch verschiedene Rohdaten-Formate.
Die Datenmenge kann man sich ausrechnen, in dem man die Wortbreite (Bitrate) mit der Abtastrate multipliziert - gibt die Datenmenge für eine Sekunde pro einem Kanal - und das ganze dann mit der Anzahl der Kanäle und der Zeit verrechnet. Die Verwaltungsdaten, die da nebenbei anfallen, fallen größenmäßig unter den Tisch.


Bei komprimierten Formaten ist das aber etwas anders. Um die Datenmenge zu reduzieren, gibt es verschiedene Wege.

Verlustfreie Komprimierung funktioniert ähnlich wie z.B. das Zip-Format: Vereinfacht gesagt wird in einem Haufen vorliegender Daten nach (durchaus sehr komplexen) wiederkehrenden Mustern gesucht. Das Muster muss man nur ein mal abspeichern und kann an den entsprechenden Stellen daruaf verweisen --> spart Daten. Die Audio-Qualität bleibt voll erhalten. Der maximal mögliche Komprimierungsgrad hängt von der Art der Musik, aber auch von der Wortbreite und Abtastrate ab. FLAC kann z.B. zwischen 75 % und 30 % komprimieren. Für maximale Komprimierung wird aber auch Zeit und Rechenpower benötigt, um die entsprechenden Muster zu finden. Wichtig bei komprimierenden Audio-Codecs (egal ob verlustbehaftet oder nicht) ist aber auch, dass die Datenstruktur so aufgebaut ist, dass die Nutzdaten in Echtzeit decodiert (entpackt) werden können - sonst könnten diese Formate ja nur verzögert abgespielt werden.

Für verlustbehaftete Komprimierung reicht die Datenreduzierung aber noch nicht. Deshalb werden hier noch diverse psychoakustische Tricks angewandt, um Daten herauszuschneiden, die das Gehirn sowieso nicht wahrnimmt. Bei mp3 z.B. wird der Maskierungseffekt auf die Frequenzbreite und soweit ich weiß auch im Zeitspektrum angewandt. Dazu gehört auch ein LowPass, der die Töne über einer bestimmten Frequenz abschneidet, da sie sowieso nicht mehr hörbar sind.

Diese Parameter zur Datenreduzierung kann man jetzt natürlich bis zur Grenze und darüber hinaus treiben. Spätestens seit es youtube gibt, wissen wir alle, wie das (nicht) klingt.

Übrigens wird bei komprimierten Formaten Qualität nicht mehr in Wortbreite und Abtastrate angegeben (wie auch?!), sondern in der Menge von Durchlaufdaten - in Kilobit pro Sekunde (kbps). Dass damit die Qualität angegeben wird, ist streng genommen nicht mal richtig. Wie oben geschrieben hängt der Komprimierungsgrad auch von der Art der Musik ab. Zwei Audioschnipsel mit gleichem Datendurchsatz und unterschiedlichem Komprimierungsgrad haben also eine unterschiedliche Qualität. Was bedeutet, dass eine mp3 mit fester Bitrate im Song selbst eine schwankende Qualität hat. Deshalb wurden variable Bitraten eingeführt, bei denen man nicht die Bitrate, sondern eine (ohne Erfahrung wenig aussagekräftige und nicht mit andern Encodern* vergleichbare) Qualitätsstufe angibt. Aber nicht vergessen: Wir sind hier im Theorie-Teil...

*im Zweifelsfall nicht mal mit anderen Versionen desselben Encoders Vergleichbar



Praxis

Ich hatte mich mal für eine Studienarbeit hingesetzt und einen Vergleich gemacht. Einen geeigneten Song (volles Frequenzspektrum, klare Transienten, knackige Bässe) im FLAC Format genommen, davon eine mp3 mit 256 kbps fixer Bitrate und eine Ogg Vorbis mit vergleichbarer Qualität (auch fixer Bitrate) erstellt und die 3 miteinander verglichen - also jeweils FLAC mit mp3, FLAC mit ogg und mp3 mit ogg.
Fazit: Bei aktuellen Encodern ist die schlechte Auflösung und der dumpfe Sound Geschichte (vorausgesetzt es werden die höheren Bitraten benutzt). Klangliche Unterscheide sind trotzdem da. Bei beiden verlustbehaftet komprimierten Formaten war der Brillanzbereich und etwas darüber überbetont im Vergleich zum Original (also der FLAC Datei). Ich vermute, dass damit versucht wird, das Hirn von der LowPass-Filterung abzulenken.
Im Endeffekt waren die Unterschiede alle nur sehr klein. Ohne Direktvergleich könnte ich die Formate niemals voneinander unterscheiden (wenn man nicht zufällig grade einen Song hat, in dem bei gewissen Passagen Komprimierungsartefakte auftreten - kommt hin und wieder vor). Ogg klang im Vergleich zu mp3 etwas besser und war auch näher am Original. Aber alles, wie gesagt, nur sehr minimal.

Test-Equipment war ein TC Electronics Interface der Konnekt Serie, betrieben mit 44,1 kHz; daran eine Syrincs M3 220 und ein Beyerdynamic DT 770 pro. Abgespielt wurden die Files von Reaper - also die versteckte Auto-Verschönerung mancher Media Player ausgeschlossen.


An dieser Stelle soll noch gesagt werden, dass das menschliche Ohr die wahrgenommene Lautstärke über die Summe aller Tonsignale bestimmt. Damit sind verlustbehaftet komprimierte Audiodateien (aus denen bestimmte Töne herausgeschnitten wurden) im Vergleich zum Original per Definition leiser. Auswirkungsbereich: eher im homöopathischen Bereich - möglicherweise spürbar. So wirklich hörbar nicht.


Es ist wohl unnötig zu erwähnen, dass die Konvertierung einer Datei in ein qualitativ besseres Format sinnlos ist - das wäre als ob man ein kleines Bild groß zoomen würde.



Korrekturen bitte per PN an mich.

 

[livebox]

Nachtrag:

Ich wurde gefragt, welchen Song ich für den Vergleich verwendet habe. Das war "9,000 Miles" von Pendulum. Auf den Song gekommen bin ich durch den Chef-Lautsprecherentwickler einer HiEnd-PA-Bude, der u.a. den Song benutzt, um seine Boxen zu "kitzeln". Ich denke, der eignet sich auch ganz gut, um Encodern mal genauer auf den Zahn zu fühlen.

Ich hatte außerdem noch ein klassisches Stück im Test mit drin - habe leider vergessen, welches. Aber die Ergebnisse waren dieselben.

MfG. livebox

 

[livebox]

Da mir grade auffiel, dass ich im x32 Thread die Datenmenge für 1 Stunde Aufnahme falsch berechnet habe, hier gleich noch mal ein Beispiel dafür, wie s richtig geht.

Annahme: Die Aufnahme erfolgt im Rohformat mit 24 Bit Wortbreite bei 44,1 kHz Abtastrate.

Ziel: Den Speicherplatz berechnen, den 1 Stunde Aufnahme im Rohformat benötigt.


Hz steht bekanntlich für "pro Sekunde". Der A/D-Wandler liefert also pro Sekunde 44.100 mal eine Menge von 24 Bit, die gespeichert werden soll.

44.100 * 24 Bit = 1.058.400 Bit

Um von Bit in Byte umzurechnen, muss die Zahl durch 8 geteilt werden.

1.058.400 Bit entsprechen also 132.300 Byte.

Um von der Datenmenge einer Sekunde auf die Datenmenge einer Stunde zu kommen: Logisch, einfach 2 mal mit 60 multiplizieren.

132.300 Byte * 60² = 476.280.000 Byte
Die Zahl ist etwas unhandlich - also wandeln wir sie gleich in Gigabyte um.

MERKE: Der Physiker glaubt, ein Kilobyte entspräche 1.000 Byte. Der Informatiker glaubt, ein Kilometer habe 1.024 Meter.

Der Umrechungsfaktor von Byte zu kB, von kB zu MB usw. ist 1024. Das kommt vom Binärsystem, das der kompletten (aktuellen) Computertechnologie zugrunde liegt. 2¹⁰ sind nun mal 1.024.

476.280.000 Byte / 1024³ = 0,443... GB
Okay, war etwas zu viel des Guten - MB wären vielleicht passender? 0,412 GB sind aber NICHT 412 MB!
476.280.000 Byte / 1024² = 454,... MB
...was das gleiche ist wie 0,443570316 GB * 1024


Eine kleine Bemerkung zum Schluss: Ein kleines b ist die Abkürzung für Bit, eine großes B die Abkürzung für Byte.
Die Angabe erfolgt in Bit, wenn es um Datendurchsatz geht: Bei A/D-Wandlern, Netzwerkkarten, USB-Anschlüssen,... oder auch beim Datendurchsatz, den eine mp3-Datei pro Sekunde hat - deshalb kbps mit kleinem b!
Byte wird für Speichergrößen benutzt.

 

[Goti]

Hey,

müsste es nicht 44.100 * 24 Bit = 1.058.400 Bit sein?

 

[livebox]

Hallo Goti,

richtig - ich hab, weiß der Geier warum, mit 41 kHz gerechnet?!? Werde die Zahlen gleich korrigieren - vielen Dank für den Hinweis!

MfG, livebox

 

[thomas r]

Wer mag kann auch folgendes in eine Textdatei kopieren. Diese Datei in rechner.html umbenennen und dann in einem Webbrowser aufmachen.

Es ist ein einfaches Javascript dass ich immer nutze um die Umrechnung von Hz, Bit, h:m:s, Spuren zu Speicherplatzbedarf durchzuführen.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html><head><title>PCM Speicherplatz Rechner</title>
<meta name="robots" content="noindex, nofollow, noarchive">
<meta http-equiv="content-type" content="text/html; charset=us-ascii">
</head><body>
<script type="text/javascript">
function calculate (rate,bit,ch,len) {

    var rex=/^([0-9]+):([0-9]+)(:([0-9]+))?$/g;
    var res=rex.exec(len);
    
    if( res == null )
        document.getElementById('size').value = 'Zeit muss in "h:m[:s]" sein!';
    
    var len = (parseInt(res[1])*60 + parseInt(res[2]))*60 + parseInt(res[4]==null?'0':res[4]);
    
    var size = len * parseInt(rate) * parseInt(bit)/8 * parseInt(ch);
    
    if( size > 1024*1024*1024 )
        document.getElementById('size').value = size/(1024*1024*1024) + ' GiB';
    else if( size > 1024*1024 )
        document.getElementById('size').value = size/(1024*1024) + ' MiB';
    else if( size > 1024 )
        document.getElementById('size').value = size/(1024) + ' KiB';
    else
        document.getElementById('size').value = size + ' B';
}
</script>
<form action="">
Abtastrate: <input name="rate" id="rate" value="44100" type="text"><br>
Bit Tiefe: <input name="bit" id="bit" value="24" type="text"><br>
Spuren: <input name="ch" id="ch" value="2" type="text"><br>
Zeit: <input name="len" id="len" value="0:01" type="text"><br>
<button type="button" onclick="calculate(this.form.rate.value,this.form.bit.value,this.form.ch.value,this.form.len.value)">Berechnen</button><br>
Speicherplatz: <input name="size" id="size" readonly="readonly" type="text"><br>
</form>
<noscript>
Javascript muss aktiviert sein!
</noscript>
</body></html>

- - - Aktualisiert - - -

ich hab, weiß der Geier warum, mit 41 kHz gerechnet?!?

Wahrscheinlich weil es im Text falsch ist:

Der A/D-Wandler liefert also pro Sekunde 41.000 [...]

 

[livebox]

Wahrscheinlich weil es im Text falsch ist

Danke - ist korrigiert!

Nette Idee mit dem JS. Darf ich noch 2 kleine Anmerkungen machen?
- Die Eingabe der Zeit könntest du vielleicht in einzelne Felder für h, m, s umbauen - dann gibts auch keine Fragen bzgl. der Eingabesyntax
- bei der Ausgabe der Datenmenge: Entweder das Ergebnis kürzen (z.B. Math.round()) oder die Einheit gleich hinter das Feld schreiben lassen. Im Moment ist sie nicht sofort ersichtlich, weil zu viele Nachkommaziffern. (Im zweiten Fall könntest du die Einheiten auch gleich ganz ausschreiben. Ich persönlich bin sowieso kein Freund der - ich glaube amerikanischen? - Schreibweise mit GiB... ich hab lieber GB oder dann gleich Gigabyte.)

MfG, livebox

 

[thomas r]

Nette Idee mit dem JS. Darf ich noch 2 kleine Anmerkungen machen?
- Die Eingabe der Zeit könntest du vielleicht in einzelne Felder für h, m, s umbauen - dann gibts auch keine Fragen bzgl. der Eingabesyntax
- bei der Ausgabe der Datenmenge: Entweder das Ergebnis kürzen (z.B. Math.round()) oder die Einheit gleich hinter das Feld schreiben lassen. Im Moment ist sie nicht sofort ersichtlich, weil zu viele Nachkommaziffern. (Im zweiten Fall könntest du die Einheiten auch gleich ganz ausschreiben. Ich persönlich bin sowieso kein Freund der - ich glaube amerikanischen? - Schreibweise mit GiB... ich hab lieber GB oder dann gleich Gigabyte.)

Ich muss sagen ich bin da nicht richtig gut drinnen habe das auch nur aus einem anderen Forum abgegriffen und ins Deutsch übersetzt. Leider gibt es das Original nicht mehr. Ist jetzt auch schon mehrere Jahre her.
Aber wenn jemand das verbessern möchte kann es das gerne tun.

Wegen GiB und GB: G bedeutet (wie du oben schon angemerkt hast) 10⁹. Gi bedeutet 2³⁰ . Ist auch internationalisiert, siehe: http://de.wikipedia.org/wiki/Binärpräfix
Leider verwenden viele einfach das dezimal Präfix G, M, K und man kann dann selber schauen was gemeint ist.
Aber da könnten wir uns jetzt tagelang streiten was besser ist.

P.S. Wenn es was amerikanisches wäre dann wäre es eine 1 bile = 1760 bards, 1 bard = 3 beet, 1 beet = 12 binches, 12 binches = 1 bit

 

[livebox]

Tatsächlich, jetzt wo du's sagst... dezimal und binär... stimmt, hab ich mal von gehört, aber wieder vergessen.

Hm, vielleicht nehm ich mir irgendwann mal Zeit dafür, das bisschen Script ist ja nicht wirklich groß / kompliziert. Will aber nichts versprechen.

 

[livebox]

Hm, vielleicht nehm ich mir irgendwann mal Zeit dafür

Hier. Die Überprüfung, ob in den Eingabefeldern tatsächlich was sinnvolles drin steht, ist weggefallen. Das Ergebnis wird aber entsprechend sinnlos, wenn man z.B. Buchstaben eingibt...

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
	<html>
		<head>
			<title>PCM Speicherplatz Rechner</title>
		</head>
		
		<body>
			<script type="text/javascript">
				function calculate (rate,bit,ch,hour,minute,sec)
				{					
					var len = parseInt(hour)*3600 + parseInt(minute)*60 + parseInt(sec);
					
					var size = len * parseInt(rate) * parseInt(bit)/8 * parseInt(ch);
					
					if( size > 1024*1024*1024 )
						document.getElementById('size').value = (size/(1024*1024*1024)).toFixed(3) + ' GiB';
					else if( size > 1024*1024 )
						document.getElementById('size').value = (size/(1024*1024)).toFixed(3) + ' MiB';
					else if( size > 1024 )
						document.getElementById('size').value = (size/(1024)).toFixed(3) + ' KiB';
					else
						document.getElementById('size').value = (size).toFixed(3) + ' B';
				}
			</script>
			
		<form action="">
			<table cellpadding="3">
				<tr>
					<td>Abtastrate:</td>
					<td><input name="rate" id="rate" value="44100" type="text" size="6"> Hertz</td>
				</tr>
				
				<tr>
					<td>Wortbreite:</td>
					<td><input name="bit" id="bit" value="24" type="text" size="3"> Bit</td>
				</tr>
				
				<tr>
					<td>Spuren:</td>
					<td><input name="ch" id="ch" value="2" type="text" size="3"></td>
				</tr>
				
				<tr>
					<td>Zeit:</td>
					<td><input name="hour" id="hour" value="1" type="text" size="3"> h <input name="minute" id="minute" value="0" type="text" size="2"> min <input name="sec" id="sec" value="0" type="text" size="2"> sec</td>
				</tr>
			</table>		
			<br/>
			<button type="button" onclick="calculate(this.form.rate.value,this.form.bit.value,this.form.ch.value,this.form.hour.value,this.form.minute.value,this.form.sec.value)">Berechnen</button><br>
			<br/>
			Speicherplatz: <input name="size" id="size" readonly="readonly" type="text" size="12"><br>
		</form>
		
		<noscript>
		Javascript muss aktiviert sein!
		</noscript>
	</body>
</html>