Diskussion:Free Lossless Audio Codec/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Free Lossless Audio Codec/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Free_Lossless_Audio_Codec/Archiv#Thema_1

Pro/Contra vs. Vorteile/Nachteile

Ich finde die Überschriften auf Deutsch („Vorteile/Nachteile“) besser. Wenn keine Einwände kommen, setzte ich die Überschriften nachher auf die deutsche Version zurück. Warum nicht einfach mal auf Deutsch? ;)--Sikilai 16:11, 7. Mai 2005 (CEST)

ich bin dafür!(Der vorstehende nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 80.171.55.245 (Diskussion • Beiträge) 16:33, 20. Okt. 2005)

"Pro/Contra" ist ja sooo ausländisch nicht - steht latein jetzt auch schon auf der abschussliste der sprachpuristen? (oh verzeihung - "puristen"!! - ich meinte "reinhalter der sprache") ;-) --84.173.82.133 00:45, 28. Jan. 2008 (CET)

aktuelle Liste der Player

wer weiss ob es weiter player unterstüzen? oder ist die Liste aktuell?(Der vorstehende nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 80.171.55.245 (Diskussion • Beiträge) 16:33, 20. Okt. 2005)

Da FLAC der meistverwendete Lossless Codec ist, ist es wahrscheinlich, dass es noch ein paar Player gibt, die .flacs abspielen können... Bekannt ist mir allerdings keiner. - Xorx77 13:17, 14. Nov 2005 (CET)

Winamp kann seit Version 5.31 FLAC standardmäßig abspielen. Deshalb sollte jemand den Bereich Abspielsoftware überarbeiten. --Overbenny 21:34, 14. Nov. 2006 (CET)

Überarbeitung

Ich hatte vor einiger Zeit mal auf der Diskussionsseite zu Ogg vorgeschlagen, die Artikel rund um Xiph.Org zu überarbeiten/erweitern/verbessern/wasauchimmer. Da die ersten Artikel so weit abgearbeitet sind, und nun FLAC langsam an der Reihe ist, wollte ich vorher noch mal hier darauf hinweisen. Vielleicht finden sich ja Helfer. Was mir zu dem Artikel grundlegend auffällt:

• es gibt ein Pro/Contra, das sollte durch eine allgemeine Betrachtung und Vergleiche mit entsprechenden Konkurrenzformaten ersetzt werden, da Pro/Contra nahezu nie NPOV dargestellt werden kann
• der genaue Zusammenhang mit der Stiftung Xiph.Org ist nicht klar
• Geschichte fehlt völlig
• Links - in-Text-Links sind selten gerne gesehen, und können weitestgehend durch Links die Firmen oder die FLAC-Homepage ersetzt werden; außerdem ist die Wikipedia auch keine Produktdatenbank

So weit, --Liquidat, ^Diskussion, 01:34, 22. Jan 2006 (CET)

Abgearbeitet, aber zur Geschichte könnte jemand wissendes ja noch was beitragen. Leider findet sich dazu nichts auf der Projektseite oder auf heise.de --Liquidat, ^Diskussion, 01:21, 27. Jan 2006 (CET)

Vergleich mit anderen verlustlosen Komprimierungsverfahren

„Komprimiert schlechter als andere moderne Audiokompressionsverfahren“
Warum ist dieser Satz rausgeflogen? -- Pemu 18:29, 29. Jan 2006 (CET)

Ist er gar nicht, er ist nur in den Abschnitt "Vergleiche zu anderen Formaten" gewandert. Dort steht er nun als "Die Kompressionsstärke liegt, verglichen mit anderen verlustfreien Audio-Codecs, im Mittelfeld [2].", wobei [2] ein Quellenverweis auf einen entsprechenden Test ist, in dem er in das Mittelfeld geordnet wird - allerdings kann man sich über die Ordnung bei dem Test streiten, da FLAC der schlechteste des Mittelfelds ist, ich habe aber erst mal die Ordnung des Tests übernommen, um sicher zu gehen. --Liquidat, ^Diskussion, 01:36, 30. Jan 2006 (CET)

Oh, habe ich wohl übersehen... -- Pemu 22:30, 30. Jan 2006 (CET)

Größenordnung der Kompression?

Es wäre gut, wenn man in den Text Durchschnittswerte der Kompression einbauen könnte. Also: "Komprimiert auf ca. 1:2 der Originalgröße oder auf 1:3 der Originalgröße". --Blubbalutsch 22:21, 15. Sep 2006 (CEST)

Das Problem ist Folgendes: Eine Aussage wie "liegt im Vergleich mit anderen Codecs im Mittelfeld" bezeichnet viel geringere Unterschiede als die Unterschiede zwischen z. B. einem zweiten Satz eines Flötenkonzerts (vielleicht auf 1/3) und einer amerikanisch-zermasterten Brickwall-Rockproduktion (vielleicht um 1/3 oder weniger). -- Pemu 01:41, 16. Sep 2006 (CEST)

mit "um 1/3" meinst du "auf 2/3 der Originalgröße"? Das ist dann natürlich ein ziemlicher Stückabhäniger Unterschied. Gibt es irgendwo vielleicht freie Referenzstücke? Ich würde die dann bei mir mal komprimieren und die Ergebnisse in den Text einarbeiten. --Blubbalutsch 22:08, 16. Sep 2006 (CEST)

Bei meinem Musikalben liegt die Dateigröße im Normalfall zwischen 50% und 75% (also 1/4 bis 1/3 komprimierung). Meistens liegt der Wert zwischen 60% und 70%. Falls noch andere Messwerte haben, könnte man diese Angaben ja in den Artikel übernehmen. --Overbenny 21:34, 14. Nov. 2006 (CET)

Gapless Playback

Im Artikel Gapless Playback steht, dass FLAC gaplessfähig ist. Was mich interessiert, ob FLAC auf festen oder variablen Blockgrößen basiert? --Trainspotter 08:25, 12. Feb. 2007 (CET)

Du schreibst, du hättest den Gapless Playback Artikel gelesen. Aber in diesem wird dir doch eindeutig eine Antwort auf deine Frage gegeben: "Verlustlose Kompressionsverfahren wie FLAC sind systembedingt unterbrechungsfrei, da die Daten nicht in Blöcken organisiert sind."

-- 217.224.109.161 13:27, 15. Aug. 2009 (CEST)

Ich glaube, dass diese Aussage nicht stimmt, da zur effizienten Codierung jeder Codec in irgendeiner Form Blöcke bilden muss. Denn letztlich wird immer innerhalb eines Blockes nach Vorhersagbarkeit bzw. Redundanz gesucht. Würde man auf Blöcke verzichten, hätte man effektiv eine Blockgröße von 1, wodurch prinzipbedingt keine Redundanz vorhanden sein kann und somit gar nicht mehr komprimiert werden kann. Die Alternative wäre natürlich, alle Daten nach Redundanz zu durchsuchen. Das machen zum Beispiel auch Packprogramme, das klappt aber nicht bei einem Radiostream, da hier prinzipbedingt nicht alle Daten vorliegen. Und übrigens setzt auch FLAC Blöcke ein (siehe Artikel), deren Größe von der Kompressionsstufe abhängt.

FLAC ermöglicht meines Erachtens Gapless Playback vor allem dadurch, dass das letzte Frame in einem Stream eine (von den anderen Frames) abweichende Blockgröße haben darf, siehe hier unter „Notes“. Damit ist die Antwort auf Trainspotters Frage eindeutig: variabel. --Uncle Pain 12:46, 17. Aug. 2009 (CEST)

Doppelt gemoppelt?

Im Arikel steht direkt untereinander:

Kompression : "Laut Angaben der Entwickler erreicht FLAC einen durchschnittlichen Kompressionsfaktor von zirka 0,5. (...)"

Kompressionsstufen: "(...) Das Verfahren reduziert das Original durchschnittlich auf etwa 60 % der Ausgangsgröße."

Sollte man das nicht vereinheitlichen? Entweder ist es 50%, oder 60%. --91.42.224.207 00:44, 21. Nov. 2008 (CET)

Codec oder Audioformat?

Ist FLAC ein Codec oder ein Audioformat oder beides? Das kommt im Artikel nicht so richtig rüber. Es wird mal in die eine dann in die andere Kategorie eingeordnet. Ist eine zusätzliche Einordnung in die Kategorie Offenes Format wie bei Vorbis sinvoll?--Trockennasenaffe 19:30, 21. Jan. 2010 (CET)

Free Lossless Audio Codec. --Tuxman 01:44, 22. Jan. 2010 (CET)

Das habe ich durchaus gelesen. Allerdings hätte gerne eine etwas fundiertere Begründung, bevor ich große Teile des Artikels, die dann falsch wären, umschreibe. Im englischsprachigen Artikel heißt es im ersten Satz: "Free Lossless Audio Codec (FLAC) is a file format for lossless audio data compression." Zum anderen wird hier auch Vorbis als offenes Format bezeichnet, wobei ich zu FLAC keinen Unterschied sehe.--Trockennasenaffe 13:29, 23. Jan. 2010 (CET)

FLAC ist eher mit OGG als mit Vorbis vergleichbar. Es kann sowohl Container als auch Audioformat sein. Ersteres wird allerdings nur selten genutzt (und m.W. auch nur in Verbindung mit dem FLAC-Audioformat). Der Codec für das FLAC-Audioformat heißt allerdings ebenfalls FLAC. --Tuxman 15:16, 23. Jan. 2010 (CET)

Nicht wirklich. Wenn Du eine Audiodatei mit dem VLC Media Player nach FLAC kodierst, ist standardmäßig (in dem Encoding-Profil "Audio - FLAC") das Containerformat "Raw" voreingestellt. "Raw" ist ein "Pseudo-Containerformat", das nichts anderes macht, als den Output des Codecs direkt (ohne weitere Metadaten) in eine Datei zu schreiben. "FLAC" als Containerformat wird nicht angeboten. MetalTux 20:07, 18. Jul. 2010 (CEST)

Keine Fließkomma Dateien unterstützt

FAQ Sourceforge: What kind of audio samples does FLAC support?

FLAC supports linear PCM samples with a resolution between 4 and 32 bits per sample. FLAC does not support floating point samples. In some cases it is possible to losslessly transform samples from an incompatible range to a FLAC-compatible range before encoding.

FLAC supports linear sample rates from 1Hz - 655350Hz in 1Hz increments. -- 217.227.182.251 20:15, 21. Mai 2010 (CEST)

Aktiv? Sommer 2010

Kurz nachgefragt: letztes Update: 17. September 2007. Ist da noch jemand aktiv? Weiß jemand etwas? Danke. --Tom Jac 11:36, 24. Jun. 2010 (CEST)

libFLAC

Der Punkt "libFLAC++, Ein Objekt-Wrapper für libFLAC++ " verwirrt mich etwas. Sollte das vieleicht so heißen : "libFLAC++, Ein Objekt-Wrapper für libFLAC" ? (Der vorstehende nicht signierte Beitrag – siehe dazu Hilfe:Signatur – stammt von 141.113.100.23 (Diskussion • Beiträge) 13:10, 14. Nov. 2005 (CET))

Kompressionszeiten und-raten

http://i51.tinypic.com/2db8m1i.png Ich habe mal versuchsweise die Kompression einer 300MB großen .wav-Datei (genre: ruhiger Ambient Black Metal) in allen Kompressionsstufen durchgeführt und graphisch dargestellt. Die Zeit für Stufe 8 betrug auf meinem relativ modernen Vierkerner 37 Sekunden. Vielleicht lässt sich der Graph ja sinnvoll in den Artikel einbetten. Zu bemerken ist des Weiteren, dass die Kompressionszeit auf einem modernen Rechner zu vernachlässigen ist, die Zeit zum präzisen Einlesen der CD mit EAC ist um 2 Größenordnungen länger. Die Zeiten beziehen sich jeweils auf die längste Dauer (37s bei Stufe 8). (nicht signierter Beitrag von 85.178.178.135 (Diskussion) 19:06, 30. Mär. 2011 (CEST))

das Problem bei der Sache ist, dass man das mit der Kompressionsrate nicht pauschalisieren kann, wie du sicherlich weißt, außerdem würde ich gerne mal wissen womit du die flac Datei erstellt hast und wieso die Kompressionstufe 3 weniger Zeit brauchst, als alle anderen und die stufe 2 mehr als die Vierte, das macht doch irgendwie keinen Sinn, kann es sein, dass dort evtl. äußere Faktoren das Ergebnis verfälscht haben z.B. anderweitige prozessorlast oder, was wahrscheinlicher ist eine zu langsame Festplatte und/oder Zugriff auf die Platte zwischendurch?

und noch was: welche Abtastrate udn Aufloesung hat die Quelldatei 8und damit auch die zieldatei) und welche Länge? und dazu wäre in der Tabelle denke ich mal auch schön anstatt der Prozentwerte dann konkrete Werte einzutragen, weil man dann weniger dneken muss *grins*

jede menge Fragen, ich weiß, prinzipiell habe ich nichts dagegen, zumindestens mit der Kompressionsrate, allerdings müssten dafür mehrere konkrete beispiele vorhanden sein, sprich von mehreren genres etc. pp, bei der Kodierungszeit gibt es leider das problem, dass neben den prozessor, der ja bei jedem unterschiedlist ist (fast) auch noch die Festplatten ein großes problem sind, weil der prozessor locker auf Kompressionsstufe 0 das ein- bis zweihundertfache schaffen sollte ( wenn er nicht gerade von anno zwieback ist versteht sich ) das wären pi mal Daumen bei einer 1411er wave Datei sag ich mal zwischen 30 und 60 Megabyte die Sekunde, schafft eine Platte im idealfall durchgängig, klar aber bei fragmentierung und beim schreiben ist sie langsam und wenn die Quell udn Zieldatei auf einer Platte ist stört es die geschwindigkeit extrem (zumindestens bei mir, wenn ich das auf zwei Platten verteile geht es flott also Zieldatei nciht auf der Platte von der Quelldatei), da wäre eine schnelle SSD meiner meinung nach bessere für geeignet, grüße und danke fürs Lesen des Romans -- Moehre 20:07, 30. Mär. 2011 (CEST)

Moin, natürlich habe ich mich über die kürzere Zeit bei Stufe 3 auch gewundert und den Test wiederholt, mit gleichem Ergebnis, somit schließe ich Prozessorlast als Ursache mal aus, es fanden auch keine nennenswerten Nebenaktivitäten statt. Die Platte ist eine moderne SSD. Die Begründung liegt, denke ich, in verschiedenen Verfahren(-sschritten) bei den unterschiedlichen Stufen.

Nun habe ich einmal eine andere, direkt von CD in .wav übertragene, Datei (20:45 min., 1411kb/s) genommen, wieder mit gleichem Ergebnis. Die flac.exe (Beilage von EAC) wurde per Batch direkt aufgerufen, und die Zeiten geloggt. Weitere Informationen hier: http://i56.tinypic.com/n5ovtj.png (Tabelle, Batchcode, Diagramm, ...). Der Graph war nicht allgemeingültig gemeint, sondern eher als Visualisierung des textlich beschriebenen Zusammenhanges zwischen Kompression und Komprimierungszeit. Ich hätte es auch noch mal mit Popmusik probiert, aber sowas besitze ich nicht, außerdem hielt ich ein langes Stück für geeigneter, da somit der Einfluss von "Initialisierungszeit" gegenüber reiner Kompressionszeit in den Hintergrund rückt. Die Prozentdarstellung habe ich gewählt, damit keine systemabhängigen Daten vorkommen. Gruß, -- 92.225.25.178 16:29, 5. Apr. 2011 (CEST)

Na, das ist ja shconmal wunderbar vorgekaut, ich werde bei meinen etwas älteren rechner ( athlon 67 3700+, 3GiB RAM mal testen, ob das auch so ist,allerdings nicht per sdd, sondern eher im Arbeitsspeicher oder - falls nötig mit zwei (schnellen) Festplatten, das mit der Allgemeingültigkeit ist zwar meiner Meinung nach schön und gut, aber die Tabelle würde ich persönlich auch dazu nehmen, damit der Leser auch mal so auf dem Bildschirm sieht wie lange das dauert, wenn so zahlen wie 00:00:06 (also sechs Sekunden) sagen auch eine menge aus, aber naja darüber kann man diskutieren, danke schonmal, ich werde wenn ich die Gelegenheit habe es mal bei mir testen, dann aber nicht per EAC, sondern mit dem flac frontend decoder, übrigens, was für einen Prozessor hast du? wäre meiner Meinung nach auch angebracht, wenn man dies dazuschreibt, sonst wundert sich der Leser möglicherweise, dass er eine viel höhere Differenz zwischen den zeiten hat und auch länger braucht ( stufe 0 geht bei mir recht schnellm, 8 dauert recht lange bei mir), Grüße -- Moehre 16:42, 5. Apr. 2011 (CEST)

Oh, das ging ja fix mit der Antwort. Core i7 870, 2,93GHz, 8GB RAM. Und ich habe nicht mit EAC direkt gearbeitet, sondern lediglich recht minimalistisch die mitgelieferte flac.exe benutzt. Gruß, -- 92.225.25.178 16:53, 5. Apr. 2011 (CEST)

achso okay, nette Hardware :-D womit hast du denn die Zeiten geloggt? EAC macht das zwar, ist mir aber zu floed der flac frontend encoder macht das nicht :( -- Moehre 17:04, 5. Apr. 2011 (CEST)

habe deine Batch Datei gerade mal abgeschrieben und dies auch versucht (batchdatei, quellwav und flac.exe in einem ordner), allerdings sagt der bei mir dann flac-0, flac-1 usw kontne nicht gefunden werden? :S habe auch mal von EAC die flac.exe kopiert, da es eine andere ist als die vom Frontend (R:\>flac-6 test.wav-o "MM-6.flac" -f Der Befehl "flac-6" ist entweder falsch geschrieben oder konnte nicht gefunden werden. ) -- Moehre 17:15, 5. Apr. 2011 (CEST)

Leerzeichen hinter flac (flac -0 test.wav -o "MM-0.flac" -f); eine direkte Zeitmessung ist per Batch aber leider nicht möglich, soweit ich weiß, deswegen muss man sich mit den Zeitstempeln behelfen. --92.225.25.178 17:31, 5. Apr. 2011 (CEST)

jo, klappt, danke, komme auf ähnliche Ergebnisse, Kompression auf 67 bis 62% (live Lied, rock, mit ruhigen passagen 1411kbit/s, 12:11) kompressionszeit ist bei Stufe drei niedriger als bei stufe zwei und vier aber nicht so niedrig, wie 0 und 1, aber ok der langsame prozessor haut besonders bei stufe 7 und 8 etlich viel zeit weg( bis zu 40 sekunden in etwa ), gut gut, nur die Frage ist, was man da so als referenz nehmen kann, weil die Kompressionsrate ja auch varriert ich bin der Meinung, dass man am besten mehrere Beispiele nimmt so drei Stück (z.B. rock, pop, metal) und das dann z.B. wie du in eine Tabelle machen, dann aber inschreiben was die 100% bei der Tabelle sind (Zeit/Größe) dann sind mit evtl. kurzer hardware angabe (prozessor sollte genügen), was meinst du? -- Moehre 19:02, 5. Apr. 2011 (CEST)

übrigens, alle vier Kerne sind bei dir nciht ausgelastet oder? wenn ich mcih recht erinnere läuft das nur auf einem kern? -- Moehre 19:04, 5. Apr. 2011 (CEST)

Ich denke, das Ganze zu wissenschaftlich auszuführen mit Tabelle etc. würde den Rahmen des Artikels sprengen. Unterschiede zwischen verschiedenen Musikgenres wären indes interessant, jedoch habe ich keine Lust, da Versuchsreihen durchzuführen, das liefe sicher auf weit über 50 Musikstücke hinaus, um einigermaßen aussagekräftige Ergebnisse zu erzielen. Ich fände ein beispielhaftes Diagramm sinnvoll, um die Unterschiede in Kompressionszeit- und raten bei den verschiedenen Stufen anschaulich darzustellen. Dass die absoluten Kompressionszeiten auf modernen Rechnern auch auf höchster Stufe kaum ins Gewicht fallen, vor Allem im Vergleich zu den Einlesezeiten beim Rippen einer CD, könnte dann kurz im Fließtext erwähnt werden. Auch der Dekompressionsaufwand bei den verschiedenen Stufen wäre interessant, weil sich das ja auch auf den Stromverbrauch bei mobilen Abspielgeräten auswirkt.

Hab noch mal nachgeschaut, es wird jeweils nur ein Kern bei der Kompression verwendet. Gruß, -- 85.178.178.179 12:10, 7. Apr. 2011 (CEST)

japs, das stimmt, deshalb sagte ich ja einfach so drei beispiele oder so, die so total ins Klischee passen (rock - laut und so ^^, pop langweilig halt :-D und metal dacht ich an was schnelles hartes), weil die Rate doch ncoh relativ unterschiedlich ist *denk* aber das kann ich wnen ich mal zeit habe durchtesten - der Dekompressionsaufwand ist verschwindend gering soweit ich weis unter dem einer mp3 datei...

das mit dem Prozessor habe ich mir gedacht, sollte man nämlich auch erwähnen..., ich werde mir diesbezüglich über alles mal gedanken machen, gruß -- Moehre 13:23, 7. Apr. 2011 (CEST)

mhm, ich dneke mal das kann man so übernehmen, allerdings fände ich 'ne zweite bzw. dritte Meinung mal gut. -- Moehre 18:37, 28. Apr. 2011 (CEST)

Meinung wozu? Hier gibt es doch nur Richtig und Falsch?
-- Tuxman 21:08, 28. Apr. 2011 (CEST)

Weiterentwicklung?

Die aktuelle Version 1.2.1 ist vom Sep. 2007. Wird flac nicht mehr weiterentwickelt oder ist es schon perfekt? --188.103.42.251 15:21, 2. Mai 2012 (CEST)

Vorteile gegenüber WAV?

Eigentlich sind wav-Dateien doch seit Jahrzehnten der Standard für verlustfreie Audiosognale. Was hat FLAC da für einen Vorteil? Wie viel kleiner sind denn Dateien gegenüber WAV? (nicht signierter Beitrag von 139.20.53.46 (Diskussion) 07:35, 27. Jun. 2012 (CEST))

Flac braucht so zirka die Hälfte ( [1])? Ein repräsentatives Ergebnis zu erstellen und hier bei Wikipedia einzubinden wäre allerdings auch nicht falsch. --McZusatz (Diskussion) 08:55, 27. Jun. 2012 (CEST)

Dazu gibt es doch im Artikel bereits ein eigenes Kapitel (Kompression), inkl. mehrerer Vergleichstests als Einzelnachweise. Wenn da von einer Reduktion um 50 % gesprochen wird, ist die Ausgangsgrösse immer die des WAVs. --YMS (Diskussion) 10:10, 27. Jun. 2012 (CEST)

Stimmt, dort hab ich gar nicht gesucht, denn ich dachte 139.20.53.46 hat den Artikel bereits gelesen. --McZusatz (Diskussion) 11:57, 27. Jun. 2012 (CEST)

Hardwareunterstützung/Mobiltelefone

Blackberry Geräte können ebenfalls FLAC Dateien nativ wiedergeben, jedenfalls trifft das auf Blackberry OS 7.1 zu, allerdings habe ich keine Quelle dazu gefunden, sondern es lediglich durch Ausprobieren herausgefunden. Sollte jemand eine Quelle dazu finden, bitte den Abschnitt ergänzen. (nicht signierter Beitrag von 77.2.95.21 (Diskussion) 20:14, 14. Okt. 2012 (CEST))