HIFI-FORUM » PC, Netzwerk & Multimedia » PC & Hifi » CD-Sammlung archivieren, aber welches Format ? | |
|
CD-Sammlung archivieren, aber welches Format ?+A -A |
||
Autor |
| |
Menjuel
Ist häufiger hier |
15:17
![]() |
#1
erstellt: 12. Okt 2013, |
Hallo liebes HiFi-Forum, ich habe vor meine Sammlung auf Festplatte zu archivieren. Die Simple Frage die sich mir nun stellt ist folgende: In welchem Format soll ich meine Musik abspeichern ? Ich möchte von vornherin klarstellen, dass die Dateigröße nicht die geringste Rolle spielt und ich im Optimalfall die CD 1:1 abspeichern kann. Platz aber sinnlos verschwenden möchte ich natürlich nicht, Ich weiß, dass dafür eig. nur FLAC oder WAV in Frage kommen. Das FLAC bitgleich mit WAV ist weiß ich auch, aber ich verstehe nicht, wie man eine Datei von der Größe her fast halbieren kann, ohne etwas zu "verlieren"? Danke im vorraus Menjuel |
||
Kumbbl
Inventar |
09:05
![]() |
#2
erstellt: 13. Okt 2013, |
du vertraust also der technik und der Wissenschaft nicht, soso ![]() Nun, du benutzt doch sicherlich am Computer auch Zip-programme - mindestens mal benutzt du das unbewußt, denn wann immer dur dir ein Programm installierst, dann kommt das "komprimiert" aus dem netzt auf deine Platte und wir dort wieder "ausgepackt" - da ist dann auch wieder jedes Bit so wie es vor dem Komprimieren war - garantiert und immer, denn sonst würde das programm nicht mehr funktionieren, wenn auch nur ein Bit falsch ist - zumindest besteht die Möglichkeit.. als das sind schlichtweg mathematische Algorithmen, die funktionieren beweisbar... bei Flac kannst du es dir so vorstellen (extrem stark vereinfacht): Der Flac-Algorithmus geht so vor, dass er anstelle alle 16-Bit Samples 1:1 hintereinander abzulegen (so wie bei WAV) nur Unterschiede speichert. wie du sicher weißt, speichert das CD-Format 44100 mal pro Sekunde ein 16-Bit Wort ab (also 2 Byte) - wie genau, ist hier jetzt irrelevant. Nehmen wir nun mal an, wir hätten ein sehr simples Musikstück, welches 2 sekunden lang ist und in der ersten Sekunde einen bestimmten Ton mit einer Lautstärke X und in der zweiten Sekunde den gleichen Ton mit der doppelten Laustärke. Dies bedeutet Im WAV-Format: 88200 x 16-Bit abzuspeichern Im Flac Format: 1 x 16 Bit für den Ton, ein paar wenige Bits für die Information, dass nun in den nächsten 44099 Samples der gleiche Ton nochmal kommt, 1 x 16 Bit für den Ton in doppelter Lautstärke, ein paar wenige Bits für die Information, dass der doppelt so laute Ton nun die nächsten 44099 mal kommt ... usw. usf... das zusammen dürfte nur extrem wenig Speicherplatz verbrauchen i.Vgl. zum WAV Beim Abspielen von Flac weiß nun der Decodierungs-Algorithmus von Flac, wie der Codierungsalgorithmus vorgegangen ist und kann somit 1:1 bis aufs letzte Bit die Original-Samples wieder herstellen, ganz so, als ob es in WAV gespeichert worden wäre.. 2 Bemerkungen noch: - richtige Musik ist weitaus komplexer als das Beispiel da oben, so dass sich letztendlich eben nur KOmpressionsraten von ca. 60% ergeben - der Flac-Agorithmus macht noch einige weitere tricks und ist deutlich komplizierter als ich das oben dargestellt habe - aber im wesentlichen kannst du es dir so vorstellen.... Und, glaubst du nun, dass man auch Musik bei speichern so komprimieren kann, dass bei abspielen trotzdem wieder das Original entsteht? ![]() BTW: diese art von Komprimierung hat rein gar nix zu tun mit der Art von Kompression, die z.B. MP3 macht - letztere geht nach psychoaksustischen Modellen vor und enrfernt tatsächlich Frequenzen auf nimmer wieder sehen aus der Musik (ob man das dann wirklich hört, sei dahin gestellt, da gibt wahre Glaubenskriege dazu ![]() Hope this helps... EDIT: ach so, vergessen, die antwort auf deine eigentliche Frage: speichere alles in Flac, das hat schlichtweg keinerlei Nachteile... (und lass dir von niemand was anderes einreden - auf keinen Fall von sog. und selbsternannten Klanggurus ![]() [Beitrag von Kumbbl am 13. Okt 2013, 09:07 bearbeitet] |
||
|
||
odradek
Ist häufiger hier |
09:19
![]() |
#3
erstellt: 13. Okt 2013, |
Kann dem vorigen Beitrag nur zustimmen, ganz klar, FLAC ist die erste Wahl, (und wurde in seiner Funktion auch wunderbar erklärt! :-) ), da hat man zwei Vorteile, 1:1 Qualität zur CD und Tagmöglichkeit, was bei WAV nicht vorgesehen ist. |
||
Menjuel
Ist häufiger hier |
12:21
![]() |
#4
erstellt: 13. Okt 2013, |
Vielen Dank Kumbbl für die wirklich verständliche Erklärung. Ein weiser Mann hat mal gesagt:"Wenn du es nicht einfach erklären kannst, verstehst du es nicht gut genug." Wie du schon sagst, ist das Ganze weitaus komplizierter, aber ich wollte nur einen Ansatz hören wie das machbar ist ![]() Ich werde die Sammlung jetzt definitiv in Flac anlegen, eben, weil ich keinen Platz verschwenden möchte. Außerdem ist die Taggbarkeit ja nur von Vorteil! Danke Menjuel |
||
Kumbbl
Inventar |
19:52
![]() |
#5
erstellt: 13. Okt 2013, |
nur der vollständigkeit halber: WAV kann prinzipiell genauso gut getagged werden wie Flac...es wird nur von extrem wenig Software unterstützt und ist meines wissen nicht standardisiert... (Foobar z.B. kann auch WAV-Dateien problemlos taggen) allerdings ändert das nix an der bereits gegebenen Empfehlung für Flac, denn WAV bietet ggü. Flac tatsächlich keinerlei* Vorteile sondern braucht einfach knapp doppelt so viel Platz... und für große Musiksammlungen kann das auch bei den niedrigen Plattenpreisen immer noch relevant sein und gehörig ins Geld gehen, denn man muss ja den benötigten Backup-Platz auch noch mit einkalkulieren (und damit bezahlen)... und ob ich jetzt 3 x 2-TB-Platten brauche oder 3 x 4-TB Platten macht immerhin preislich das ca. doppelte aus, derzeit auch immerhin mehr als 200€ differenz** - die ich lieber in Musik investiere ![]() * einzige kleine einschränkung dieser Aussage: WAV wird prinzipiell von den meisten Mobilen Playern (Smartphones etc.) unterstützt, wogegen dies bei Flac leider immer noch nicht der Fall ist...aber sich deutlich bessert die Situation...wohingegen dieser vermeintliche Vorteil von WAV fast wieder zunicht wird, weil wohl kaum ein Mobile Player mit getaggten WAVs umgehen kann... ** auch wenn natürlich 200€ absolut gesehen jetzt auch nicht die Welt sind... aber der preis muss ja auch alle 4 - 7 jahre in etwa wieder neu investiert werden... so rein statistisch gesehen...Platten können nun mal kaputt gehen... also, lange Rede kurzer Sinn: Flac und aus die Maus. [Beitrag von Kumbbl am 13. Okt 2013, 19:53 bearbeitet] |
||
Menjuel
Ist häufiger hier |
21:50
![]() |
#6
erstellt: 13. Okt 2013, |
Nur gut, dass mein Sansa zip clip mit Rockbox, wirklich alles mitmacht ![]() |
||
Radiowaves
Inventar |
15:12
![]() |
#7
erstellt: 17. Okt 2013, |
Es gibt wunderbare Analogien zwischen Bilddateiformaten und Audidateiformaten. Wave entspreicht Bitmap: es wird je Sample (beim Bild Pixel) der komplette Amplitudenwert (Helligkeitswert in den 3 Farbkanälen) abgespeichert, und zwar mit voller "Zahlenlänge", auch wenn der Wert eine simple 0 sein sollte. Führende Nullen werden also immer mitgespeichert. Deshalb kann man einfach rechnen: Audiodateigröße = Anzahl der Kanäle (2) × Auflösung (16 Bit) × Abtastrate (44100/s) / 8 Bit/Byte + ein kleinwenig Header Bilddateigröße = Breite in Pixeln × Höhe in Pixeln × Farbtiefe in Bit (z.B. 3 mal 8 für rot, grün blau) / 8 Bit/Byte + ein kleinwenig Header Ergebnis Ton: ein kanalgetrennt unabhängiges, voll ausgesteuertes Rauschsignal nimmt genauso viel Platz weg wie die gleiche Zeit Stille oder ein Sinuston. Ergebnis Bild: eine einfarbig weiße Fläche (synthetisch erzeugtes Bild mit Füllung "weiß") belegt genausoviel Platz wie ein Foto eines herbstlichen Laubbaumes mit der gleichen Pixelzahl. Verlustfreie Kompression: sucht Redundanzen (Gleichheiten) in der Datei und nutzt diese geschickt aus, um die Dateigröße verlustfrei zu verringern. Bau Dir mal eine Wave-Datei mit echter Stille oder einem echten Sinus, speichere sie ab und zippe sie mit Winzip oder 7zip oder was-auch-immer ein. Gigantische Packrate. Es steht immer wieder das gleiche in der Datei - bei Stille sowieso, bei einem Sinus wiederholt sich die Bitstruktur nach jeder Periode, da kann der Packalgorithmus einen Sinus abspeichern und sich danach vermerken "das jetzt beim Auspacken bitte zehn Millionen mal wiederholen". Dann bau Dir mal eine weiße Bildfläche in Paint und speichere die als Bitmap. Sie ist so groß wie oben berechnet. Zippe die mal ein. Wiederum gigantische Packraten, aus dem gleichen Grund. Jedes Pixel hat FF FF FF in den Farbkanälen stehen (rot, grün und blau voll hell). Es ist einfach, zur vollständigen Rekonstruktion davon eine Anweisung zu schreiben. Nun mal was sehr chaotisches ohne Wiederholungen, also ohne Redundanzen: bau Dir mal in einem Audioeditor eine Wave-Datei mit kanalgetrenntem, voll ausgesteuerten weißen Rauschen. Mach sie genauso lang wie das Wave-File mit der Stille oder dem Sinus. Sie wird dann exakt genauso groß sein - unabhängig vom Inhalt wird immer der gesamte mögliche Zahlenvorrat abgespeichert. Nun zippe die mal ein... Packrate vermutlich unter 1%, wenns ein kanalgetrennt unabhängiges File war. Der Packer findet keine Regelmäßigkeiten oder Gemeinsamkeiten, die er zum Platzsparen verwenden könnte. Das gleiche geht beim Bild: nimm ein Foto als Bitmap, was schön fein detailliertes, eine Nahaufnahme eines Tierfells oder einen Baum. Wenn die Pixelanzahl der der weißen Fläche von oben entspricht und die Farbtiefe auch, sind die Dateien gleich groß. Aber das Zippen scheitert wie beim Rauschen kapital: da ist nix, was man als Regelmäßigkeit hernehmen könnte. Packrate vermutlich unter 5-10%, wenn überhaupt. Verlustbehaftete Datenreduktionsalgorithmen arbeiten grundlegend anders, egal ob beim Ton (MP2, MP3, AAC, ATRAC, ...) oder beim Bild (JPG). Ihnen sind die feinen Strukturen egal - sie werden soweit "weggeschliffen" und zermatscht, bis der Rest mit der zugewiesenen Bitrate beschreibbar ist. Verluste sind da von Anfang an vorgesehen und kein Mangel, sondern Absicht. Man erreicht dadurch wesentlich höhere Packraten. Diese grundunterschiedliche Arbeitsweise von verlustfreien Packern (Zip, RAR, FLAC beim Ton, LZW-TIFF beim Bild) und verlustbehafteten Datenreduktionen (MP3, JPG) sieht man auch schön an folgendem: weise einen verlustfreien Packer an, möglichst hohe Packraten zu erreichen - er kommt je nach zu packendem Inhalt nicht über eine bestimmte Rate hinaus und braucht umso länger, je kleiner er packen soll. Er muß dann mehrfach gründlich nach Redundanzen suchen, die er nutzen kann. Weise einen verlustbehafteten Reduktionsalgorithmus an, möglichst kleine Dateien zu erzeugen - er wird immer schneller. Er rotzt da einfach nur noch das rudimentäre Grundgerüst hin, für mehr bliebe ohnehin kein Platz. Und das geht halt schneller. Bei FLAC wird der Output übrigens nahezu (wenn auch nicht ganz) halb so groß, wenn das Ausgangsfile in beiden Kanälen identisch, also echtes Mono ist. Auch das weiß er zu nutzen. [Beitrag von Radiowaves am 19. Okt 2013, 19:30 bearbeitet] |
||
Menjuel
Ist häufiger hier |
13:21
![]() |
#8
erstellt: 19. Okt 2013, |
Auch sehr schön erklärt. Danke ![]() |
||
Kumbbl
Inventar |
15:07
![]() |
#9
erstellt: 19. Okt 2013, |
vielleicht eine kleine Ergänzung zu diesem abschnitt der ansonsten sehr schönen Darstellung: Vom prinzip her ist das natürlich schon korrekt dargestellt, aber die gewählte Formulierung wird meiner Ansicht nach der resultierenden Qualität nicht gerecht, zumindest nicht in den jeweils hohen Qualitätseinstellungen der verlustbehafteten Ton- bzw. Bildkomprimierer - "weggeschliffen" mag noch gehen, aber "zermatscht" trifft sicherlich nur auf mittlere bis niedrige Qualitätsstufen zu... Bild: Ein JPG erzeugt mit Qualitätseinstellung von 90 bis 92% ist nur mit sehr sehr viel Mühe vom nicht komprimierten "Original" zu unterscheiden, in 99,9% der Fälle gar nicht, denn es sind keine Artefakte erkennbar, auch bei angeführten Problembildern wie Fell kaum... Ton: MP3s und noch mehr AACs (Äqivalent von Apple) mit einstellung VBR ~ 220 oder höher sind vom original im Blindtest auch nur noch sehr sehr schwer und in vielen Fällen nicht reproduzierbar (d.h. mit substantiell höherer Erkennunsrate als 50%) vom Original unterscheidbar...** in obigem beitrag nicht erwähnt: MP3 verschleift nicht nur sondern eliminiert Frequenzen, die unter psychoakustischen Aspekten nicht wahrnehmbar sind, also wenn zum beispiel ein zarter Triangelton im Musikstück von einem gleichzeitigen heftigen Bassdrum-Schlag komplett überdeckt wird (wieder sehr stark vereinfacht), dann kann man den auch entfernen und braucht ihn nicht platzfressend speichern... beide Verfahren berücksichten auf sehr schlaue Weise eben die Auflösungsfähigkeiten von Auge bzw. Ohr...das sind schon alles sehr sehr intelligente Algorithmen, meiner Ansicht nach verdient ein verfahren wie MP3 schon das Attribut "genial" - oder besser die Erfinder am fraunhofer Institut verdienen das Attribut ![]() In beiden fällen werden im Vgl. zum Original substantiell niedrigere Dateigrößen erzielt, auch bei den hohen Qualitätsstufen... mein Beitrag ist aber nicht als Contra zum obigen sehr schönen Beitrag von Radiowaves zu sehen, sondern mehr als Präzisierung oder kleine Klarstellung... ![]() ** Um einem aufkeimenden Glaubenskrieg pro und contra MP3 vorzubeugen: ich behaupte damit nicht, dass MP3 in allen Fällen und immer 100% transparent ist, d.h. nicht mehr vom Original unterscheidbar... je nach Musik und Ohr ist es manchmal möglich, aber wie gesagt, sehr sehr schwer und ..s.o.... |
||
Radiowaves
Inventar |
19:35
![]() |
#10
erstellt: 19. Okt 2013, |
@ Kumbbl Da habe ich doch gar nichts zu widersprechen. ![]() Ich habe es bewußt sehr drastisch dargestellt. Bei mir ist normalerweise schon bei 192 kbps LAME (aber bitte unter Ausklammerung der Versionen ab 3.94 bis einschließlich 3.98) Schluß mit der Unterscheidbarkeit. 192 kbps reicht für mich also vollkommen für unterwegs und zur Hintergrunbeschallung. Als Archivformat kommt es freilich bei mir nicht in Frage, aus rein prinzipiellen Erwägungen (wieso mit viel Aufwand ein Archiv aufbauen, wenns dann nicht die Originalqualität besitzt?) und auch aus einer praktischen: manchmal mach ich was mit Rundfunk und da gehe ich nicht mit bereits datenreduzierten Files in die Produktion. |
||
Kumbbl
Inventar |
20:27
![]() |
#11
erstellt: 19. Okt 2013, |
dito |
||
cr
Inventar |
01:37
![]() |
#12
erstellt: 20. Okt 2013, |
Kann das wer mit dem weißen Rauschen verifizieren? Ich glaubve nämlich nicht, dass Flac nicht auch hier eine Einsparung von 20-30% bringt. Zwar stellt weiße Rauschen den ganzen Zahlenraum ohne Regelmäßigkeiten dar (Zufallssignal), aber man wird dennoch Einsparungen haben, wenn man immer nur die Differenz zwischen zwei Stützpunkten speichert anstelle der absoluten Stützpunktwerte. Die andere Frage, wo die Antwort zwar immer behauptet, aber nie auch der Beweis gezeigt werden konnte, ist, dass ein datenreduziertes Signal genauso stabil ist, wenn Fehler vorliegen. Fällt bei WAV ein Stützpunkt um, ist das kein Drama, denn er wird sich nicht allzu von den beiden benachbarten unterscheiden. Fällt bei FLAC ein Stützpunkt um, fallen n Folgewerte genauso um...... |
||
stoske
Inventar |
09:24
![]() |
#13
erstellt: 20. Okt 2013, |
> Kann das wer mit dem weißen Rauschen verifizieren? Ich glaubve nämlich nicht, dass Flac > nicht auch hier eine Einsparung von 20-30% bringt. Zwar stellt weiße Rauschen den ganzen > Zahlenraum ohne Regelmäßigkeiten dar (Zufallssignal), aber man wird dennoch Einsparungen > haben, wenn man immer nur die Differenz zwischen zwei Stützpunkten speichert anstelle > der absoluten Stützpunktwerte. Das muss man nicht verifizieren, das ist mathematisch und logisch völlig unstrittig. Die Bildung einer Differenz hat keinerlei Einsparung zur Folge, die Datenmenge bleibt identisch. Das ist lediglich eine Zusammenfassung von spatialer oder temporaler Redundanz zur Verbesserung der folgenden Kompression. Folgen gleicher Zahlen werden numerisch kleiner, ebenso ansteigende oder abfallende Folgen. Da es bei einem Signal ohne jede Redundanz aber weder gleiche Zahlenfolgen, noch ansteigende/abfallende Folgen gibt, ist die Differenzbildung völlig funktionslos. > Die andere Frage, wo die Antwort zwar immer behauptet, aber nie auch der Beweis gezeigt... Die "Stabilität" eines Signal ist im Fehlerfalle bei komprimierten Daten grundsätzlich kleiner, weil sie sich auf eine verringerte Menge bezieht, ausserdem sowohl temporale als auch spatiale Abhängigkeiten hinzukommen. Es sei denn, es gibt Mechanismen die genau dem entgegenwirken, was aber die Fähigkeit der Kompression um denselben Anteil verringert. |
||
Radiowaves
Inventar |
11:38
![]() |
#14
erstellt: 20. Okt 2013, |
Und hier die Zahlen dazu. Wave Datenmenge der Samples 60 Sekunden @ 44.1 kHz, 16 Bit: 44100 × 16 × 2 ×60 / 8 = 10584000 Byte 60 Sekunden kanalgetrenntes weißes Rauschen 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 10584044 Byte 60 Sekunden kanalidentisches weißes Rauschen 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 10584044 Byte 60 Sekunden Sinus 1 kHz identisch in beiden Kanälen, 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 10584044 Byte 60 Sekunden Sinus 1 kHz identisch in beiden Kanälen, -12 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 10584044 Byte 60 Sekunden Stille in beiden Kanälen @ 44.1 kHz, 16 Bit, stereo: 10584044 Byte -> keine Einsparung bei identischen Kanälen, Wave speichert unabhängig vom Inhalt immer alle Samples ab. -> keine Einsparung bei redundanten Inhalten (Sinus, Stille), Wave speichert unabhängig vom Inhalt immer alle Samples ab. WinZip 60 Sekunden kanalgetrenntes weißes Rauschen 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 10490882 Byte -> 99.1% noch da 60 Sekunden kanalidentisches weißes Rauschen 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 9787574 Byte -> 92.5% noch da -> Das Packen des weißen Rauschens scheitert komplett, da sind keine Redundanzen drin. WinZip erkennt aber auch die Identität der Kanäle im zweiten File nicht und kann den potentiellen Kompressionsvorteil von 50% nicht nutzen. 60 Sekunden Sinus 1 kHz identisch in beiden Kanälen, 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 2854193 Byte -> 27% noch da 60 Sekunden Sinus 1 kHz identisch in beiden Kanälen, -12 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 2853572 Byte -> 27% noch da -> WinZip kann beim File mit -12 dBFS keinen Vorteil aus der niedrigeren Aussteuerung ziehen. Es sind allerdings auch alle 16 Bit in Benutzung, es wird kein Bit ständig "leer" herumgeschleppt. Immerhin erkennt WinZip, daß hier Redundanzen im File sind. Siehe Ergänzung ganz unten. 60 Sekunden Stille in beiden Kanälen @ 44.1 kHz, 16 Bit, stereo: 10458 Byte -> 1 % noch da -> immerhin erkennt WinZip hier, daß nur "Nullen" übertragen werden. Dafür läßt sich eine einfache Anweisung zum Entpacken erstellen. FLAC (flac.exe -8 ...) 60 Sekunden kanalgetrenntes weißes Rauschen 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 10310992 Byte -> 97.4% noch da 60 Sekunden kanalidentisches weißes Rauschen 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 5189893 Byte -> 49% noch da -> Da kann auch FLAC nichts mehr machen: das vollausgesteuerte kanalunabhängige Rauschen ist so redundanzfrei, da kann man nichts mehr packen. Das ist das Wesen des weißen Rauschens. Nur aus der Tatsache, daß das zweite File in beiden Kanälen gleichen Inhalt hat, holt FLAC die erwartete Packrate von 50%. FLAC erkennt diese Struktur, Zip ist darauf nicht optimiert und übersieht die auffällige Redundanz. 60 Sekunden Sinus 1 kHz identisch in beiden Kanälen, 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 1716795 Byte -> 16.2% noch da 60 Sekunden Sinus 1 kHz identisch in beiden Kanälen, -12 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 1499252 Byte -> 14.2% noch da -> FLAC erkennt sowohl die regelmäßige Struktur des Sinus als auch die WinZip verborgen bleibende Identität der Stereokanäle und kann daraus höheren Gewinn erzielen (packt auf 16% statt auf nur 27%). Niedrigere Aussteuerung bringt nochmals geringfügigen Vorteil, aus das weiß FLAC zu nutzen. Viel ist da aber nicht zu holen, alle Bits sind in Benutzung. 60 Sekunden Stille in beiden Kanälen @ 44.1 kHz, 16 Bit, stereo: 17958 Byte -> 0.12% noch da -> Hier hält FLAC nur noch einen Mindest-Datenstrom aufrecht, da FLAC auch zu streamen sein muß. Selbst Zip kommt da nicht mit. Und der Vollständigkeit halber: das whitenoise_stereo.flac wieder in Wave konvertiert (Winamp -> Diskwriter) und bitweise mit dem Original verglichen -> identisch. Alles andere wäre ja auch schlimm gewesen. MP3 Bitrate wählen (und damit Originalgetreuegrad wählen) und dann mit der Bitrate die Dateigröße ausrechnen. 128 kbps: 9.3% noch da 160 kbps:11.6% noch da 192 kbps 13.9% noch da (packt auf 1/7) 256 kbps: 18.6% noch da 320 kbps: 23.2% noch da Ist je Bitrate bei CBR unabhängig vom Inhalt, hier wird die erreichbare Qualität angepaßt. Die absolute Stille bleibt absolute Stille (=identisch), der Sinus wird ein etwas angerauschter Sinus und das "weiße" Rauschen wird je nach Encoder deutlich unter 22.05 kHz bandbegrenzt, ggf. sind sogar Stufen von den einzelnen Bandfiltern zu erkennen, die Artefakte werden ebenfalls je nach Encodermodell mal hier, mal dorthin geschoben im Frequenzbereich. Es ist jedoch nie Originalqualität, egal mit welcher Bitrate man eindampft. Und da wirds dann irre: bestimmte Strukturen (Sinus) bekommt man mit FLAC (und nahezu auch mit Zip) verlustfrei auf Größen gepackt, die man mit MP3 zwar auch leicht erreichen kann, aber halt mit Qualitätsverlust. Analoge Betrachtungen kann man mit Bilddateien machen. Setze WAV -> BMP, FLAC -> LZW-TIF oder PNG, Zip -> Zip. Wer das weiß, wird Screenshots von Programmen, solange sie nur Text und grafische Felder, aber keine "chaotische" Hintergrundfläche enthalten, nie wieder als JPG posten. Das PNG oder LZW-TIF ist 100% Original und oft viel kleiner als das JPG, siehe das FLAC vom Sinus oder der Stille als Analogie. Ergänzung: Da kommt mir gerade eine Idee: der von mir verwendete Sinus mit 1 kHz ist zwar "gedacht" hübsch periodisch, aber bei einer Abtastrate von 44.1 kHz ergeben sich im digitalen keine identischen Samples in jeder Periode. Das müßte zu deutlich schlechteren Packraten bei WinZip führen verglichen zu einem Sinus, der tatsächlich in jeder Periode identische Samples hat. Ich packe auch noch mal einen vollausgesteuerten Sinus mit 11.025 kHz Frequenz ein. Der erzeugt in jeder Periode identische Samples, und zwar nur noch 4 Stück (bei Startphase 0° sind dies 2^15, 2^16 - 1, 2^15 und 0, vielleicht aber auch 2^15 - 1, 2^16 - 1 , 2^15 - 1 und 0, keine Ahnung, habe jetzt keinen Hexeditor hier und weiß nicht, ob die analoge Nullinie nun 2^15 oder 2^15 - 1 ist). 60 Sekunden Sinus 11.025 kHz identisch in beiden Kanälen, 0 dBFS peak @ 44.1 kHz, 16 Bit, stereo: 10584044 Byte WinZip: 1342676 Byte -> 12.7% noch da Holla! Da kann WinZip deutlich mehr mit anfangen als mit dem nicht so redundanten Sinus veon 1 kHz. Dort kamen 27% Datenmenge raus. FLAC: 1115595 Byte -> 10.5% noch da Auch FLAC profitiert von der deutlich höheren Redundanz. [Beitrag von Radiowaves am 20. Okt 2013, 13:10 bearbeitet] |
||
cr
Inventar |
17:51
![]() |
#15
erstellt: 20. Okt 2013, |
Danke für die Beispiele. 2,5% hat FLAC irgendwie beim weißen Rauschen doch noch abgepreßt....... Was Musik betrifft: Bei Klassik spare ich mit FLAC in etwa 60% ein, bei Pop/Rock (neueren Datums mit hoher Aussteuerung/Loudness War) 30%, bei älterem Pop/Rock eher 50%....... |
||
|
|
Das könnte Dich auch interessieren: |
Welches Format? Bluestealth am 14.01.2010 – Letzte Antwort am 09.03.2010 – 12 Beiträge |
Vinylplatten auf CD archivieren rolandvinylfreak am 21.02.2005 – Letzte Antwort am 24.02.2005 – 17 Beiträge |
Verlustfreie Musik erstellen - welches Format? Crusader82 am 02.04.2009 – Letzte Antwort am 09.04.2009 – 37 Beiträge |
Welches Format zum rippen? Chris19993 am 15.01.2009 – Letzte Antwort am 22.01.2009 – 75 Beiträge |
CD auslesen: Welches Format verwenden Radiosender? darkphan am 28.09.2018 – Letzte Antwort am 14.10.2018 – 7 Beiträge |
Audio-CDs verlustfrei archivieren hewimeddel am 22.08.2007 – Letzte Antwort am 26.04.2011 – 4 Beiträge |
Tonträger verlustfrei archivieren Kakapofreund am 09.10.2007 – Letzte Antwort am 19.10.2007 – 33 Beiträge |
DVD rippen. Welches Format? Ubuntux am 28.11.2008 – Letzte Antwort am 29.11.2008 – 16 Beiträge |
CD-Sammlung digitalisieren Dr.Acula am 09.02.2017 – Letzte Antwort am 17.02.2017 – 24 Beiträge |
CD-Sammlung digitalisieren ThomasRo am 13.10.2007 – Letzte Antwort am 06.01.2014 – 225 Beiträge |
Foren Archiv
2013
Anzeige
Produkte in diesem Thread
Aktuelle Aktion
Top 10 Threads in PC & Hifi der letzten 7 Tage
- Kann ich den Laptop an den SAT- Receiver anschließen und damit TV sehen?
- Was ist WASAPI und ASIO?
- Kein 5.1 Dolby Digital / DTS über HDMI nur Stereo
- AV-Receiver mit PC verbinden Optisch/HDMI
- Passiv-Lautsprecher an Audiointerface
- DIY: Blindtest MP3 V0/320 vs FLAC (inklusive hörbarer Ergebnisse)
- Knistern/Knacken beim Abspielen von Ton
- Externe Soundkarte und 5.1 System
- Upmix von Stereo auf 5.1 für PC Audio
- Audio-CD lässt sich nicht mehr rippen
Top 10 Threads in PC & Hifi der letzten 50 Tage
- Kann ich den Laptop an den SAT- Receiver anschließen und damit TV sehen?
- Was ist WASAPI und ASIO?
- Kein 5.1 Dolby Digital / DTS über HDMI nur Stereo
- AV-Receiver mit PC verbinden Optisch/HDMI
- Passiv-Lautsprecher an Audiointerface
- DIY: Blindtest MP3 V0/320 vs FLAC (inklusive hörbarer Ergebnisse)
- Knistern/Knacken beim Abspielen von Ton
- Externe Soundkarte und 5.1 System
- Upmix von Stereo auf 5.1 für PC Audio
- Audio-CD lässt sich nicht mehr rippen
Top 10 Suchanfragen
Forumsstatistik
- Registrierte Mitglieder926.801 ( Heute: 10 )
- Neuestes MitgliedSirch
- Gesamtzahl an Themen1.553.994
- Gesamtzahl an Beiträgen21.603.739