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

[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.

[MSfree]

kann man die aber kaum als PCM-Modulation bezeichnen, da die Werte der einzelnen Samples in digitalen 16-Bit-Werten gespeichert werden.

PCM bedeutet, daß der Amplitudenwert der diskret abgetasteten analogen Tonwelle als 16Bit-Wert abgespeichert wird.

RAW-Format heißen einfach nur die Rohdaten, siehe auch die Bezeichnungen bei Bild-Dateien.

Raw heißt eigentlich, daß nur die abgetasteten Amplitudenwerte hintereinander als Datenstrom auf der Datei liegen. Bei WAV befindet sich vor den Rohdaten noch ein Dateikopf, der das Datenformat (Anzahl der Audiokanäle, Bits pro Sample), die Abtastfrequenz und die Gesamtlänge beschreibt. Hinter dem Kopf kommen exakt die Rohdaten, wie bei CDDA übrigens auch. Bei Flac werden die Rohdaten noch durch eine Datenkompression geschickt, die ähnlich funktioniert, wie die Kompression in ZIP-Dateien.

Der Vergleich mit Bilddateien ist hier nicht zutreffend. Das, was die Kamerahersteller als Raw bezeichnen, hat mit Raw nicht viel zu tun, denn die Daten sind komprimiert und haben einen Dateikopf, der über Bildbreite, Bildhöhe, Belichtungszeit, Blendeneinstellung, GPS-Koordinaten etc. informiert. Das einzige, was hier halbwegs raw ist, ist die Tatsache, daß keine Glättungsfilter, Nachschärfung, Abberationskorrektur, Verzeichnungskorrektur etc. auf die Pixeldaten angewendet wurde.

[DeletedUserReAsG]

Soweit mir bekannt, liegen bei Raw-Bildern sehr wohl die konkreten Werte der einzelnen Bildpunkte vor, wie sie der Sensor geliefert hat. Dass das Ganze ’nen Header hat und komprimiert vorliegt, muss nicht heißen, dass in diesem Container keine Rohdaten stecken. Vielleicht kann man die Raws von Cams am ehesten mit FLAC vergleichen: ist komprimiert, hat einen Header, aber die ursprünglichen Rohdaten lassen sich daraus wiederherstellen. Und im Falle von FLAC können sie halt anschließend in ein Format gebracht werden, das auf die CD geschrieben werden kann, wobei keine Informationen verloren gehen sollten.

[MSfree]

Soweit mir bekannt, liegen bei Raw-Bildern sehr wohl die konkreten Werte der einzelnen Pixel vor, wie sie der Sensor geliefert hat.

Das habe ich auch nicht verneint.

Dass das Ganze ’nen Header hat und komprimiert vorliegt, muss nicht heißen, dass in diesem Container kein Rohdaten stecken.

Richtig, der Container beinhaltet Rohdaten, er ist aber nicht die rohe Datei. Diesen kleinen aber feinen Unterschied wollte ich hier deutlich machen.

Vielleicht kann man die Raws von Cams am ehesten mit FLAC vergleichen

Richtig

[TuxPeter]

Eigentlich wollte ich nur darauf hinweisen, dass "RAW" nur bedeutet, dass die Daten roh, also nicht weiter verarbeitet, vorliegen. Nach euren Beiträgen vertieft sich mein Eindruck, dass der Begriff "RAW" doch recht unscharf ist.

Bei der Betrachtung der Audio-CD sollte dann unbedingt noch erwähnt werden, dass die Aufzeichnung zwar verlustfrei, aber recht fehlerbehaftet ist, da keine CRC-Korrektur stattfindet - man hat bei der Entwicklung eben nur darauf geachtet, dass die unvermeidbaren Übertragungsfehler möglichst unhörbar und der Aufwand (für den damaligen Stand der Technik) tragbar und Consumer-tauglich bleiben. Deshalb gibt es für die Datenaufzeichnung auch ganz andere Formate. Soll man nun diesen Audio-Daten-Stream oder die zu WAV-Dateien veredelte Form als RAW-Daten bezeichnen? Vielleicht wäre es das Beste, den Begriff in Zusammenhang mit Audio ganz wegzulassen.

Und die Daten, die als "RAW" aus den Kameras fallen, sind ja, wie es scheint, auch nicht ganz RAW. (Wenn ihr sie mit FLAC vergleicht, was ja nun zwar verlustfrei, aber auch komprimiert ist)

[smutbert]

ich seh da nur ein kleines Problem mit den Begriffen, das zu Missverständnissen führen kann:

Beim Foto meint man mit dem raw-Format die Daten, wie sie vom Sensors ausgelesen wurden, aber normalerweise verlustfrei komprimiert, gegebenenfalls mit Signatur und das ganze in einer Datei mit Header verpackt, mit den ganzen Daten zum Foto und auch meist noch mit einer kleinen in der Datei eingebetteten jpg-Version des Bildes zur Anzeige als Thumbnail oä.

Bei Audio verwendet man raw auch als Bezeichnung für den reinen Datenstrom ohne Header, also zB etwa den PCM-Datenstrom wie er von der Audio-CD gelesen wird, im Gegensatz zu wav, das diesen Datenstrom, gebenenfalls (verlustfrei oder verlustbehaftet) komprimiert, dann mit einem Header in einer Datei verpackt.

[ralli]

Ich lese eine Audio CD grundsätzlich original aus, also im WAV Format. Die Größe spielt dabei keine Rolle. Davon ausgehend kann ich jederzeit mit einem Script daraus normale mp3 Dateien machen oder flac oder ogg. Ogg Format finde ich einen guten Kompromiss zwischen verlustfrei und mp3. Die Qualität ist ziemlich gut. Unter mp3 gibt es tatsächlich auch große Unterschiede was die Qualität betrifft, von grottenschlecht bis saugut. Wie ich aber schon in einem anderen Thread schrieb, wird der Hörgenuß vom menschlichen Ohr begrenzt, auch wenn das audophile Benutzer nicht gerne hören oder wahrhaben wollen.

[BenutzerGa4gooPh]

Informationsverlust und Kompression sind orthogonal zueinander.
Man kann verlustbehaftet Komprimieren, indem man z.B. jeden zweiten Wert weglaesst. Das fuert zu halber Datenmenge.
Man kann ebenso verlustlos Komprimieren (wie ZIP z.B.), indem man z.B. statt den 8 Zeichen ``aaaaaaaa'' nur die 3 Zeichen ``8*a'' hinschreibt.
Ich hoffe, das war anschaulich.
...
``keinerlei Verluste'' ist IMO ein rein theoretisches Ziel. Man sollte das differenzierter betrachen. Relevant ist die Art, das Ausmass und die Folgen von Verlust. Verlust muss aber nicht zwangslaeufig schlimm sein.

Die Überlegung finde ich informationstheoretisch nicht ganz korrekt. Redundanz ermöglicht nachträglich eine Fehlerkorrektur - oder der Verlust der reinen Redundanz während der Übertragung/Signalverarbeitung ist kein Verlust von Information. Durch Kompression werden Redundanzen entfernt. Okay, man könnte neue (für Übertragung/Speicherung sinnvollere) Redundanzen/Korrekturbits errechnen und hinzufügen.

Auf das Beispiel bezogen: U. U. kann man mit sieben "a" mehr anfangen als mit "8*x". Nur ein Zeichen wurde falsch übertragen. Die deutsche Sprache ist redundant. Oft erfasst man den Sinn einer Rede trotzdem nicht jedes Wort verstanden wurde.

Die Originaldatei (ohne jedwede Konvertierung, also minimal möglich Signalverarbeitung wg. evtl. Fehler) + sinnvolle Korrekturbits für Speicherung/Übertragung/Nachverarbeitung wäre m. E. ideal, höchstwahrscheinlich verlustfrei, jedenfalls am verlustaermsten. Selbst bei irgendeiner "verlustfreien" Konvertierung könnte ein Fehler passieren. Ist natürlich unwahrscheinlich - und die Hoerbarkeit des Fehlers noch weniger wahrscheinlich.