[g] Lossless Formate (WAV und FLAC wirklich verlustfrei?)

[smutbert]

Wenn du die CD oder eine beliebige andere digitale (PCM-)Tonquelle als Ausgangspunkt nimmst, dann ist flac definitiv verlustfrei, genauso wie alac (der Apple Losless Audio Codec) und die verlustfreie Variante von wavpack und ....

Natürlich gibt es viele Gründe verlustfreie Formate zu wählen, selbst wenn man die Verluste der verlustbehafteten nicht hört, zB kann man von flac jederzeit in ein neu aufkommendes Audioformat konvertieren, ohne die CD neu zu rippen und ohne unnötige Verluste hinnehmen zu müssen. Kodiert man dagegen von mp3 nach aac und später von aac nach was-weiß-ich-was, dann wird die Qualität immer schlechter, genauso wie beim Foto bearbeiten, wenn man die Zwischenschritte immer wieder als jpg speichert und als neuen Ausgangspunkt nimmt...

[Houbey]

Vielen Dank für eure ganzen Antworten. Ich habe eben gerade noch etwas im UU Wiki gelesen. Es gibt ja die Möglichkeit die Komprimierungsstufe einzustellen. Von -0 bis -8 und das wird im UU Wiki so beschrieben:

Code: Alles auswählen

-0 bis -8 	Komprimierungsstufen: 0 = gering, dafür schnell; 8 = stark, aber langsam 

Was wäre denn die beste Methode? -0 zwar gering komprimiert aber schneller, oder doch lieber -8 stark komprimiert aber langsamer oder welche Komprimierungsstufe verbirgt sich denn hinter --best -V ? Kann man das sagen oder eher unwahrscheinlich?

[DeletedUserReAsG]

Beim flac-Encoder? Da hängt’s ausschließlich von deinen Präferenzen ab. Ist’s dir egal, wie lange das Codieren dauert, aber du möchtest gerne möglichst kleine Files? Dann eine hohe Stufe. Oder hast du eine schwache CPU, und es soll in absehbarer Zeit fertigwerden, dafür hast du aber etwas mehr Platz zur Verfügung? Dann eine niedrigere Stufe. Auf die Audioqualität hat diese Option zumindest bei flac keinen Einfluss.

[smutbert]

Aus der Manpage von flac:

[…]
--best
Highest compression. Currently synonymous with -8.
[…]

--best und -8 ist also das gleiche, solange bis vielleicht jemand einen Weg findet, dass flac noch besser komprimiert und es mit dem Schalter -9 implementiert. Soweit ich weiß ist die (minimal) bessere Kompression, die man dadurch erreicht zwar beim Komprimieren recht aufwändig, aber der Rechenaufwand beim Dekodieren wird dadurch nicht größer, deshalb wähle ich normalerweise -8.

Die Option -V ist ganz etwas anderes und steht für --verify, da wird also das kodierte flac noch einmal dekodiert und überprüft, am Prinzip also dasselbe was man dank Prüfsumme auch später mit der Option mit -t oder --test mit den FLAC-Dateien machen kann.

[Houbey]

Der User "Mäuseturm" schrieb doch das FLAC eine Bitrate von 1411 kBit/s hat oder irre ich mich da? Ist es dann normal das ein Lied was ich mir mal eben rausgesucht habe auf dem Rechner nur eine Bitrate von 854 kBit/s als FLAC hat? Geprüft mittels rechtsklick auf das Lied im Thunar bei meinem Xfce und auf dem Reiter "Audioinfo". Dann habe ich im Terminal mittels avprobe Datei.flac getestet und da kam das gleiche raus. Heißt es ich habe da Fehler gemacht beim rippen???

Vielen Dank an alle! Aber auch an niemand und smutbert für eure Infos zu meiner letzten Frage.

[MSfree]

Der User "Mäuseturm" schrieb doch das FLAC eine Bitrate von 1411 kBit/s hat oder irre ich mich da? Ist es dann normal das ein Lied was ich mir mal eben rausgesucht habe auf dem Rechner nur eine Bitrate von 854 kBit/s als FLAC hat?

Die normale CD-Qualität ist 2 Kanäle zu 16 Bit mit 44100Hz Abtastfrequenz. Daraus ergeben sich 1411200 Bits pro Sekunde. Flac ist in der Lage, diese Daten um etwa den Faktor 1.5-2 zu komprimieren. Die 854 kBit/s ist also die Bitrate des komprimierten Datenstroms, während die 1411kBit/s die Bitrate des dekomprimierten Datenstroms ist.

[owl102]

Die 854 kBit/s ist also die Bitrate des komprimierten Datenstroms

Die durchschnittliche Bitrate, schließlich werden nicht alle Stellen des Stückes gleich gut komprimiert. Eigentlich ist die Angabe einer Bitrate beim komprimierten Datenstrom auch unsinnig, insbesondere, da sie (anders als bei mp3) nicht die Qualität des Audiosignals repräsentiert.

[wanne]

Eigentlich ist die Angabe einer Bitrate beim komprimierten Datenstrom auch unsinnig, insbesondere, da sie (anders als bei mp3) nicht die Qualität des Audiosignals repräsentiert.

Nein. Die Bitrate repräsentiert (auch bei mp3) wie gut die Kompression (und damit eben auch der encoder) ist.
Daran die Qualität des Audiosignals festzumachen ist einfach falsch. Wenn eine einkanlal mp3 mit 384kBit/s encodiert ist, dann hat das nichts mit audioqualität zu tun sondern ist das ziemlich eindeutig nur der Dummheit des Encoders zuzuschreiben.

[owl102]

Daran die Qualität des Audiosignals festzumachen ist einfach falsch.

Jein. Bei der mp3-Komprimierung kann man die Bitrate vorgeben, und die hat dann sehr wohl Einfluß auf die (hörbare) Audioqualität des Ergebnisses.

[wanne]

Bei der mp3-Komprimierung kann man die Bitrate vorgeben, und die hat dann sehr wohl Einfluß auf die (hörbare) Audioqualität des Ergebnisses.

Nein. Ein aktuelles 128kBit/s lame MP3 wird weit bessere Qualität haben als ein 196kBit/s mit dem Original encoder von Frauenhofer.
Erst wenn du auch noch Encoder und vor allem die Versionsnummer (Erscheinungsjahr oder ähnliches) dazupackst gibt das sinn.

[owl102]

Nein.

Doch

Ein aktuelles 128kBit/s lame MP3 wird weit bessere Qualität haben als ein 196kBit/s mit dem Original encoder von Frauenhofer.

Das widerspricht nicht meiner Aussage. Denn ich habe nicht gesagt, daß die Bitrate das einzige ist, was Auswirkungen auf die Audioqualität hat. (Natürlich hat die Wahl des Encoders bei mp3 ebenfalls einen Einfluß. Und natürlich die Qualität des Quellmaterials.)

[Houbey]

Flac ist in der Lage, diese Daten um etwa den Faktor 1.5-2 zu komprimieren. Die 854 kBit/s ist also die Bitrate des komprimierten Datenstroms, während die 1411kBit/s die Bitrate des dekomprimierten Datenstroms ist.

Also wäre es nun nichts schlimmes das ich mit flac worauf Rubyripper ja zurück greift, mittels "--best was dann wohl 8 entspricht" verarbeiten lassen habe? Hätte ich denn die 1411 kBit/s erreicht wenn ich Rubyripper gesagt hätte er solle das Lied mit 0 verarbeiten? Ein wenig bin ich da verwirrt. Sorry

[DeletedUserReAsG]

Die komprimierte Bitrate bei flac gibt halt nur an, wieviele von den Bits pro Zeiteinheit im komprimierten Material vorliegen. Je weniger, desto kleiner die Datei – aber es ist halt eine verlustfreie Komprimierung, so dass der Wert nicht mit der Audioqualität korreliert. Grob gesagt, wird’s, bevor es zum Soundinterface und letztlich zu den Lautsprechern geschickt wird, wieder ausgepackt und die Bitrate vom Ausgangsmaterial liegt wieder vor. Insofern hat die Zahl ausschließlich einen Einfluss auf die Größe der resultierenden Dateien und die Zeit, die’s zum Codieren benötigt.

Wie schlimm eine um einige Prozent größere Datei oder aber um einige Sekunden länger dauernde Codierung pro Datei für dich ist, musst du selbst abschätzen. Was du mit welcher Stufe erreichst, hängt auch vom Ausgangsmaterial ab – einfach mal testen und vergleichen – ein Stück hernehmen und mal mit 0 und mit 8 codieren und schauen, wie groß der Zeitunterschied beim Codieren war und wie groß die Platzersparnis im Gegenzug ist. Das sind im Grunde die beiden einzigen Faktoren, die durch die die genannte Option beeinflusst werden.

[smutbert]

Nein, auch bei -0 komprimiert flac nur eben mit relativ wenig Rechenaufwand. Die 1411200 Bit/s sind die Datenrate des unkomprimierten Datenstroms auf der Audio CD und sehr oft liegt die Musik in diesem Format vor (nur halt gelegentlich zusätzlich komprimiert, verpackt,…).

Bei mp3, ogg vorbis,… werden die Daten unter anderem dadurch komprimiert, dass vereinfach ausgedrückt unwichtige Daten weggelassen werden, aber nach dem dekodieren der mp3-Datei steht trotzdem wieder ein Datenstrom mit der ursprünglichen Datenrate von 1411200 Bit/s zur Verfügung, nur dass die Bits im Vergleich zum Ausgangsmaterial verändert wurden.

Bei flac wird zwar komprimiert, aber nach der Dekodierung der flac-Datei steht wieder genau dieselbe Abfolge von 1411200 Bit pro Sekunde zur Verfügung wie beim Ausgangsmaterial. Man erhält also zB exakt die gleiche WAV-Datei, von der die flac-Datei stammt.

Bei der Computerei hat man so etwas doch ständig, zB beim Linuxkernel. Die Version 4.0.7, die ich gerade zufällig zur Hand habe, ist im Quellcode unkomprimiert etwa 636 MB groß, sie steht aber auf https://www.kernel.org in zwei auf unterschiedliche Arten komprimierte tar-Archiven zum Download bereit [1]:

[…]

Code: Alles auswählen

linux-4.0.7.tar.xz      29-Jun-2015 19:58   79M  
linux-4.0.8.tar.gz      10-Jul-2015 16:52  118M 

[…]

Selbst das größere tar.gz-Archiv wurden also auf weniger als ein Fünftel des Datenvolumens eingedampft, tar.xz-Archive sogar auf ungefähr ein Achtel. Trotzdem erhältst du die kompletten 636 MB Quellcode 100%ig unverfälscht, wenn du die Archive entpackst. Der Kompressionalgorithmus von gzip ist dabei etwas einfacher gestrickt, weshalb er keine guten Kompressionsraten erreicht wie das neuere aufwändigere xz und genauso erreicht flac abhängig vom Aufwand den es betreibt leicht unterschiedlich hohe Kompressionsraten, ohne dass es etwas an den eigentlichen Audiodaten (in dem Vergleich dem Quellcode) ändert.

Ironischerweise lässt sich die heute leider sehr verbreitete stark dynamikkomprimierte Musik tendentiell schlechter komprimieren als gute Aufnahmen mit mehr Dynamik. Meines Wissens liegt das schlicht daran, dass Musik mit mehr Dynamik im Gegensatz zu den jetzt üblichen Mastering auch leise Passagen und damit mehr Nullen enthält und viele Nullen lassen sich leichter komprimieren als wenige Nullen (vermutlich sind auch beim miesen Material zwangsweise mindestens ungefähr 50% Nullen vorhanden, das würde diese Tatsache zumindest für mich besser verständlich machen… darüber habe ich aber noch nie wirklich nachgedacht).


[1] https://www.kernel.org/pub/linux/kernel/v4.x/

EDIT:
Das nein bezog sich natürlich auf Carlchens Frage, deinen Beitrag habe ich beim posten übersehen Niemand.

[Houbey]

Dass die Kompression mit flac verlustfrei ist, kann man recht einfach überprüfen indem man eine wav-Datei nimmt, mit

Code: Alles auswählen

$ flac meineWAV-Datei.wav -o FLAC-Date.flac

komprimiert, sie wieder zurückkonvertiert

Code: Alles auswählen

$ flac -d FLAC-Date.flac -o wieder_hergestellt.wav

und nun die Originaldatei mit der wiederhergestellten vergleicht, zB durch bilden einer Prüfsumme, dann kommt zB so etwas heraus

Code: Alles auswählen

$ md5sum meineWAV-Datei.wav 
118748f9e9a266221fafdd1b30f977bc  meineWAV-Datei.wav
$ md5sum wieder_hergestellt.wav 
118748f9e9a266221fafdd1b30f977bc  wieder_hergestellt.wav

Es hat bei mir geklappt smutbert, habe ich heute auch mal probiert und habe ein wneig hin und her umgewandelt und bekam dann wie bei dir die gleiche md5sum raus.

Sagt mal, kann mir jemand noch was beantworten? Wenn ich jetzt eine CD rippe, ich habe jetzt einmal mit morituri eine CD gerippt und muss sagen, das mir dieses Programm was im Internet auch sehr viele Positive Bewertungen in anderen Foren bekommen hat, sehr gut gefällt. Auch die AccurateRip Funktion finde ich nicht schlecht. Auf jedenfall, das zieht sich über MusicBrainz die Tags und allgemein alle Infos die im Lied gespeichert werden. Wenn ich mit picard nun das Verzeichnis was auf dem PC gerippt und erstellt wurde neu einlese und noch mehr Tags finde, diese dann einfüge und ab speicher, ist es normal das die md5sum Nummer sich auch bei der jeweiligen Dateien ändert?

[DeletedUserReAsG]

Wenn du eine Datei änderst, ändert sich deren md5-Hash. Das ist normal, ja

[Houbey]

@ niemand, da bin ich aber beruhigt. Puuh... Ich dachte schon das dies ein Fehler hätte sein können.

Aber an der Qualität wird nichts verändert dann? Bin da recht unsicher, sorry.

[smutbert]

[…]Wenn ich mit picard nun das Verzeichnis was auf dem PC gerippt und erstellt wurde neu einlese und noch mehr Tags finde, diese dann einfüge und ab speicher, ist es normal das die md5sum Nummer sich auch bei der jeweiligen Dateien ändert?
[…]

Ja, das ist selbstverständlich normal. Sobald man etwas an einer Datei ändert, ändert sich auch der md5-Hash (oder andere „normale“ Prüfsummen) - es ist ja genau der übliche Sinn einer Prüfsumme, erkennen zu können ob eine Datei auf irgendeine Art und Weise verändert wurde.

Was sich aber nicht ändern soll und darf und sind die Audiodaten. Die haben in einer Flac-Datei ihre eigene Prüfsumme in einer Art Tag gespeichert:

Code: Alles auswählen

$ metaflac --show-md5sum FLAC-Datei.flac
e38f26f24dd04e169f1a48f3a8dd0a1e

Mit dem bereits erwähnten

Code: Alles auswählen

$ flac -t FLAC-Datei.flac

wird diese gespeicherte Prüfsumme, mit einer frisch berechneten verglichen und wenn sie übereinstimmen gibt es ein »ok« am Ende der Ausgabe und diese Prüfsumme soll (darf) sich auch nicht ändern, wenn die Datei beispielsweise dekodiert und neu enkodiert wird, weil sie über die dekodierten Audiodaten gemacht wird und tatsächlich, wenn wir die intakte FLAC-Datei hernehmen

Code: Alles auswählen

$ metaflac --show-md5sum FLAC-Datei.flac
e38f26f24dd04e169f1a48f3a8dd0a1e
$ flac -t FLAC-Datei.flac 

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013  Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

FLAC-Datei.flac: ok

und dekodieren, die flac-Datei löschen und aus der WAV-Datei wieder eine flac-Datei erstellen

Code: Alles auswählen

$ flac -d FLAC-Datei.flac && rm FLAC-Datei.flac
$ flac FLAC-Datei.wav
flac 1.3.0, Copyright (C) 2000-2009, 2011-2013  Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

FLAC-Datei.wav: wrote 24179837 bytes, ratio=0,732

und nun wieder die Prüfsummen der Audiodaten anzeigen und vergleichen lassen

Code: Alles auswählen

$ flac -t FLAC-Datei.flac 

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013  Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

FLAC-Datei.flac: ok                    
$ metaflac --show-md5sum FLAC-Datei.flac 
e38f26f24dd04e169f1a48f3a8dd0a1e

stimmt die gespeicherte Prüfsumme mit der frisch berechneten überein und beide gemeinsam stimmen mit den ursprünglichen Prüfsummen überein, obwohl die md5-Summen der kompletten FLAC-Datei mit denen der Ausgangs-FLAC-Datei nicht übereinstimmt, weil sich die FLAC-Datei allein schon wegen der Tags, die bei dem Prozess verloren gegangen sind, unterscheidet, dh. eine neue FLAC-Datei, die aber nach der Dekodierung nachweislich noch immer genau dieselben Audiodaten liefert...

[Houbey]

@ smutbert, vielen Dank für deine lange Antowrt.

Ich habe das nun einmal versucht nach zustellen. Ich bin in den heute gerippten Ordner gegangen und habe mir das Lied 14 einmal woanders hin kopiert, also nicht ausgeschnitten. ^^ Hier das Ergebnis, ich hoffe das es nicht zu verwirrend ist:

Code: Alles auswählen

Original..................: 76b5d05a7b6c7eba980abcabda921134  14 - Merlins Reise.flac
Original-Kopie............: 76b5d05a7b6c7eba980abcabda921134  14 - Merlins Reise.flac

Original-Metaflac.................: 4338f4678f773795dabdaf62d95c6706  14 - Merlins Reise.flac
Original-Kopie-Metaflac...........: 4338f4678f773795dabdaf62d95c6706  14 - Merlins Reise.flac


Original..........................: flac -t 14\ -\ Merlins\ Reise.flac 

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013  Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

14 - Merlins Reise.flac: ok   


Original-Kopie...............................: flac -t 14\ -\ Merlins\ Reise.flac 

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013  Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

14 - Merlins Reise.flac: ok 


Original-Kopie................................: flac -d 14\ -\ Merlins\ Reise.flac && rm -r 14\ -\ Merlins\ Reise.flac 

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013  Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

14 - Merlins Reise.flac: done


Original-Kopie.................................: flac 14\ -\ Merlins\ Reise.wav 

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013  Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

14 - Merlins Reise.wav: wrote 28093189 bytes, ratio=0,717


Original-Kopie-Neu-erstellt.....................: flac -t 14\ -\ Merlins\ Reise.flac 

flac 1.3.0, Copyright (C) 2000-2009, 2011-2013  Josh Coalson & Xiph.Org Foundation
flac comes with ABSOLUTELY NO WARRANTY.  This is free software, and you are
welcome to redistribute it under certain conditions.  Type `flac' for details.

14 - Merlins Reise.flac: ok 


Original-Kopie-Neu-erstellt-Metaflac.............: 4338f4678f773795dabdaf62d95c6706



Vergleich:

Original-Kopie-Metaflac..........................: 4338f4678f773795dabdaf62d95c6706  14 - Merlins Reise.flac
Original-Kopie-Neu-erstellt-Metaflac.............: 4338f4678f773795dabdaf62d95c6706

War das soweit durchschaubar?

[Houbey]

Guten Morgen an alle,

ich habe mal meinen alten Beitrag wiederbelebt, da ich einmal wissen möchte, ob ich mit xfburn unter Debian 8 Jessie eigentlich meine damals gerippten Musik CDs, die im verlustfreien FLAC vorliegen, wieder ohne verluste auf einen CD-R Rohling brennen kann, ohne da natürlich einen Verlust zu haben und eine 1:1 Kopie meiner original CD wiederherzustellen?

[DeletedUserReAsG]

Ja. Umwandlungen zwischen verlustfreien Formaten sind verlustfrei.

[Houbey]

Hallo niemand,

vielen Dank für deine Antwort.

Ach so, ja stimmt, du meinst damit dann bestimmt, weil diese Musikdateien in .wav auf die CD gebrannt werden oder? Das wäre dann einleuchtend das es verlustfrei sein muss.

[DeletedUserReAsG]

Nein, als wav werden sie nicht gebrannt. Das ist noch wieder ein anderes Format. Möglicherweise wandelt xfburn die in wav um, um sie dann letztlich auf die Scheibe zu brennen – aber das ist egal, weil dann alle drei Formate verlustfrei sind.

[Houbey]

Ach so, verstehe. Ich habe das mal irgendwo gelesen im Internet, das bei Windows die Musikstücke als .cdda und bei Linux als .wav angezeigt werden wenn man eine CD einlegt und diese öffnet, daher dachte ich nun jetzt das es ein WAV Format sein müsste. Aber ist es dann auf der CD so ein RAW Format oder PCM, oder bringe ich da jetzt was durcheinander?

[TuxPeter]

RAW-Format heißen einfach nur die Rohdaten, siehe auch die Bezeichnungen bei Bild-Dateien. Soviel ich weiß, kann man die aber kaum als PCM-Modulation bezeichnen, da die Werte der einzelnen Samples in digitalen 16-Bit-Werten gespeichert werden.