Diskussion:Audiodatenkompression

unkomprimiertes Ausgangsmaterial

Ich finde es ja durchaus problematisch, wenn eine Audio-CD als unkomprimiertes Ausgangsmaterial bezeichnet wird. Wirklich unkomprimiert ist nur das analoge Ausgangssignal (insofern eines vorhanden ist). Wäre eine CD unkomprimiert, was wäre dann SACD bzw. DVD-A? Talosasphere 20:38, 18. Jul 2005 (CEST)

Du verwechselst Kompression mit Digitalisierung. CDs sind unkomprimiert und digital, SACD/DVD-A genauso, aber mit höherer Genauigkeit. --84.191.240.58 21:27, 2005-08-07

Kompression, Komprimierung (Begriffsverwirrung)

Einiges kommt mir merkwürdig vor (vielleicht bin ich aber auch nur zu blöd). Die Begriffe "Kompression" und "Komprimierung" werden hier gleichbedeutend verwendet. Möglicherweise sind sie das ja auch, aber einheitliche Begriffe wären besser. Dann werden die Überschriften "verlustfreie" und "verlustbehaftete Kompression" eingeführt, obwohl doch zuvor zwischen "Kompression" und "Reduktion" unterschieden wurde. In der Einleitung wird außerdem die Kompression als Dynamikkompression (s. "Kompressor") bezeichnet. Soweit ich das bisher verstanden habe, sind das zwei verschiedene Dinge (die zufällig gleich benannt werden). Kann jemand mit besserem Fachwissen diese Ungereimtheiten aufklären, damit wir dann gemeinsam den Artikel verbessern können? --subsonic68 04:05, 17. Jan 2006 (CET)

Ich habs mal ergänzt und korrigiert, ohne jedoch den gesamten Text neu zu schreiben (sprich Anmerkungen und Unterschied von Kompressor für Dynamik und Kompressor zur Dateneinsparung) - Micha

Bin mal wieder zufällig vorbeikommen. So ist es gut! --subsonic68 08:34, 26. Jun 2006 (CEST)

Freut mich :)

Micha

Die beiden Begriffe werden nun eindeutig unterschieden unter Audiokompression -- Fairway 10:36, 22. Jan. 2007 (CET)

Ogg

Meiner Meinung nach hat Ogg hier nichts zu suchen, da es sich nicht um eine Methode zur Audiokompression handelt, sondern um ein Multimedia-Container. -- Anhi 19:39, 25. Jan 2006 (CET)

Richtig.... es sollte Vorbis dastehen. - Xorx77 19:42, 25. Jan 2006 (CET)

vorbis stand ja schon da, jedoch wurde auch zu ogg gelinkt - hab es mal abgeändert. --Kristjan' 15:52, 26. Jan 2006 (CET)

Auftrennung

Ich halte es für sinnvoll, den Artikel aufzutrennen und separate Artikel zur verlustbehafteter und verlustfreier Kompression anzulegen. Es handelt sich hier zum einen um völlig unterschiedliche Techniken, zum anderen ist innerhalb jedes Bereiches so viel Differenzierung notwendig, dass es einen Artikel sprengt, unübersichtlich macht... Bessere Gliederungen, getrennte Weblinks, ... - ich finde das eine sinnvolle Anschaffung. Gesagt - getan, macht er sich ans Werk... hoffe, ich werde wiedermal möglichst bald brutal angeschrien, wenn jemand das für Unfug hält... --Speck-Made 04:07, 20. Nov. 2006 (CET)

Ja, ich halte das für Unfug. Der bisherige Artikel sprengte bei weitem noch nicht den Rahmen. Wenn Du es nicht glaubst, vergleiche mit einem nahezu beliebigen exzellenten Artikel. Im übrigen: Wenn über das Thema Audiokompression zu viel für einen einzelnen Artikel zusammen gekommen ist, dann sollte es für das Lemma keine BKL-Seite geben, sondern einen Übersichtsartikel. Dieser Übersichtsartikel sollte dann für genauere Ausführungen auf die Lemmata "Audiokompression (verlustbehaftet)" und "Audiokompression (verlustfrei)" verweisen. Schau Dir als Beispiel die Relativitätstheorie an. Deine Lösung ist aus Lesersicht schlechter als der vorherige Zustand. (War das jetzt brutal genug?)---<(kmk)>- 01:21, 23. Nov. 2006 (CET)

Und ich hoffe, jetzt auch eine gute Lösung für die Begriffsverwirrung gefunden zu haben. Allerdings verbunden mit halben Monsternamen... (Ja, Feedback bitte!) --Speck-Made 04:21, 20. Nov. 2006 (CET)

Insbesondere sind diese "Monsternamen" im restlicehn Sprachgebrauch nicht üblich. Damit betreibst Du Begriffsbildung und verstößt gegen eine der elementaren Richtlinien von Wikipedia. Da bleibt eigentlich nur Revert.---<(kmk)>- 01:21, 23. Nov. 2006 (CET)

Schlag' mir was kürzeres vor, was präzise zutrifft... Das war das präziseste, was ich finden konnte. --Speck-Made 00:27, 25. Nov. 2006 (CET)

Auftrennung scheint stattgefunden zu haben. Deci 14:33, 9. Jan. 2007 (CET) s. Wikipedia:Redundanz/Januar_2007#Audiokompression_-_Verlustfreie_Audiodatenkompression_bzw_Audiokompression_-_Verlustbehaftete_Audiodatenkompression

Also hier ist nach wie vor Vieles durcheinander. Siehe das Argument "viele ungleiche Samples hintereinander". Musicproducer (Diskussion) 04:06, 22. Jun. 2022 (CEST)

Begriffsfindung Audiodatenkompression

Hallo Speckmade. Du bist offensichtlich gerade dabei, flächendeckend jede Erwähnung von "Audiokompression" in "Audiodatenkompression" zu ändern. Unter anderem hast Du dazu den regulären Artikel Audiokompression durch eine BKL-Seite ersetzt, der auf einen neuangelegten Stub Audiodatenkompression zeigt. Der reguläre Artikel Audiokompression ist dabei verloren gegangen. Nun ist aber "Audiokompression" im Deutschen der allgemein akzeptierte Begriff. Die Googlestatistik ist mit 50.000 zu 174 Fundstellen in diesem Fall mehr als eindeutig. Eine vom allgemeinen Sprachgebrauch abweichende Schreibweise in WP ist Begriffsfindung und damit von den allgemeinen Richtlinien nicht gedeckt. Bitte mache Deine Änderungen wieder rückgängig.---<(kmk)>- 09:27, 20. Nov. 2006 (CET)

Es ging nichts verloren, ich habe den Artikel nur aufgeteilt (in Audiodatenkompression, Verlustfreie Audiodatenkompression und Verlustbehaftete Audiodatenkompression). Die Aufteilung erschien mir sinnvoll, da es die Verfahren grundlegend verschieden sind und neben dem recht konfusen, wenig aussagekräftigen alten Text vieles zu diesen Themen zu sagen ist, was in separaten Artikeln mit z.B. eigenen Weblinks übersichtlicher möglich ist. So kann sich der allgemeine Artikel auf allgemeine Aussagen beschränken und wird nicht gesprengt durch die ausführliche Abhandlung zweier unterschiedlicher recht umfangreicher Themenkomplexe, wobei er gleichzeitig noch allgemeines... Es erscheint mir deutlich sinnvoller so...

Keine Frage, dass "Audiokompression" ein allgemein akzeptierter Begriff ist, er bezeichnet jedoch zwei grundverschiedene Dinge: Einmal die Kompression eines Signales, eine Dynamikverengung, und zum anderen das platzsparende Verpacken von Audioinformationen. Hier ist ganz klar eine Begriffsklärung angebracht. Und wenn sich sinnvollerweise ein Artikel dann auf eines dieser Themengebiete beschränkt, so ist es auch sinnvoll ihn eindeutig zu benennen - ich habe das gemacht, indem ich, anstatt verkürzt nur Audiokompression zu verwenden, Audiodatenkompression daraus gemacht; das ist eindeutig, genau davon handelt er. Eine andere Möglichkeit wäre vielleicht der Titel "Audiokompression (Datenkompression)". Das gefällt mir nicht sonderlich, denn es gibt ja einen eindeutigen Begriff, den man verwenden kann.

Inzwischen sehen die ehemaligen Teile dieses Artikels auch schon sehr verändert aus, ich habe mich jedoch bemüht, möglichst wirklich alle Informationen drinzulassen und sie nur zu berichtigen, umzustellen und zu ergänzen (zu großen Teilen war es ein recht unstrukturierter Müllhaufen...)

Ich hoffe, dieser Roman klärt alles auf...

Das Konzept hat in meinen Augen jetzt Hand und Fuß. Sollte jemand aus irgendeinem Grund nicht damit leben können, bitte ich um Alternativvorschläge. Ich kann jedenfalls nicht mit der alten Lösung leben, denn es war keine... --Speck-Made 03:33, 21. Nov. 2006 (CET)

Und die beiden Artikel hast du alle ganz allein geschrieben?

Oder doch einfach mal kurz entgegen der GFDL das Ganze per copy&paste ohne Nennung der Autoren o.ä. gemacht?

Sprich doch einfach solche Änderungen zuerst mal auf der Diskussionsseite an, bevor du loswurschtelst. --fubar 04:21, 21. Nov. 2006 (CET)

Es liegt - soweit brauchbar - dieser Artikel hier zugrunde, doch mittlerweile dürfte kaum noch etwas vom ursprünglichen Wortlaut vorhanden sein, zumal auch nicht gerade reichhaltige Infaormationen vorhanden waren, die z.T. auch nichteinmal genau stimmten. Und ja: Ich habe alles alleine gemacht. --Speck-Made 00:35, 25. Nov. 2006 (CET)

Hallo Speckmade! (komisch jemanden so anzureden ...) Ich finde es absolut unnötig den Artikel über Audiokompression (ah. ...daten...) in zwei separate Artikel aufzuspalten. So umfangreich war der Artikel eigentlich nicht, dass er aufgeteilt werden müsste. Man könnte sich für den Sinn und Zweck von einem solchen Unterfangen *im Vorfeld* mal die Wikilinks auf diesen Begriff unter die Lupe nehmen. Wird bei den Referenzen oft zwischen den beiden Aspekten unterschieden oder ist es eher nebensächlich, dass man genau angibt ob es verlustfrei oder -behaftet ist. Wie ich gezählt habe wird nur in verhältnismäßig wenigen Fällen unterschieden: 67 - 4 - 7.

Oft wird Audiodatenkompression verwendet, wenn die verlustbehaftete gemeint ist, was dann aus dem Kontext klar wird oder es wird verwendet, als gäbe es nur diese eine Art. Ich habe mich zu der Trennung nicht aufgrund der bestehenden Informationen entschieden, sondern da es beiden Arten/Sorten/Begriffen bislang kaum etwas gesagt wurde und es zu beidem seitenweise (gut: genaue Angaben sind hier im Voraus natürlich schwierig) Grundlegendes zu sagen gibt. Und dann sind es eben in vieler Hinsicht nicht zwei Aspekte des gleichen Themas - sondern von der Zielsetzung und der Technik her wirklich - wie gesagt - grundverschiedene Dinge. --Speck-Made 01:43, 25. Nov. 2006 (CET)

Ähnliche Artikel zu Rate zu ziehen wäre vielleicht auch nicht verkehrt, wie z.B. Datenkompression. Außerdem finde ich dass der Begriff Audiokompression für etwas anderes als der urprüngliche Artikel es beschrieben hatte, gar nicht geläufig ist. (Wenn nicht gar eine "Wortneuschöpfung", kann ich aber nicht so beurteilen) Wenn ich mich auf Google beziehe, dann finde ich nur Referenzen zum Thema Audiokompression im Sinne von Datenkompression (google: "-wikipedia" versteht sich) [1]. Klar man kann sich nicht ausschließlich auf Google berufen, aber von den 100 ersten Treffern (auch von den Treffern 400 bis 500) habe ich keinen einzigen gefunden, in dem von etwas anderem die Rede ist. Im wissenschaftlichen Umfeld bei Google Scholar (indiziert wissenschaftliche Publikationen) finde ich auch nichts, was deine Behauptung untermauern würde [2]. Nicht einmal der Artikel Kompressor (Musik) auf den du verweist benutzt den Begriff Audiokompression. Es wäre echt nett von dir wenn du vorher mit anderen darüber sprechen würdest bevor du solche Aktionen startest ..., das würde sowohl dir als auch anderen viel Arbeit ersparen ... Viele Grüße -- Meph666 ^{→ post} 20:35, 21. Nov. 2006 (CET)

Ich habe mich vor meinen Aktionen auf der Diskussionsseite gemeldet - allerdings nur recht unmittelbar davor, denn nach meiner Erfahrung wartet man lange auf Antworten zu nochnicht gemachten Änderungen. Ohne das Risiko, dass es jemand eine Änderung sauer aufstößt, kann man meiner Meinung nix bewegen. Und so habe ich frei nach dem Motto be bold die Ärmel gekrempelt und gebastelt, da es einiges ausräumte, was mir bei dem Vorhaben der Erweiterung dieses Artikels im Wege stand. Ich fand die Trennung schon allein deshalb wichtig, da sie Klarheit schafft. Wie ihr hier auf der Diskussionsseite sehen könnt, war die von mir beschriebene Begriffsverwirrung schonmal Thema und wurde mit recht witzlosen Einflickungen "gelöst", die das allgemeine Durcheinander in diesem Artikel noch weiter nährten. --Speck-Made 01:43, 25. Nov. 2006 (CET)

Hallo Speck-Made. Die Tatsache, dass Du ohne Rücksprache auf der Diskussionsseite einen Artikel aufgeteilt hast, ist ein eher kleineres Problem. Flächendeckend einen Begriff durch eine äußerst unübliche Variante zu ersetzen, ist dagegen Vandalismus. Es ist erklärtermaßen nicht Ziel der Wikipedia die "richtigen" Begriffe zu verwenden, sondern die in der Rest-Welt üblichen. Bitte lies in den Wikipedia-Richtlinien den Abschnitt über Theoriefindung und handle danach. Für Begriffe, die mehr als eine Bedeutung haben, gibt es die Vorlage zur Begriffsklärung und alternativ die Einrichtung einer Begriffsklärungsseite.---<(kmk)>- 03:37, 22. Nov. 2006 (CET)

Tja, diese Richtlinie habe ich bisher nochnicht gekannt, danke für den Hinweis. (Die ist mir entsetzlich unverständlich - gibt es denn dazu noch Texte, die die Entstehungsdiskussion dokumentieren? Würde mir vielleicht den Sinn dahinter enthüllen...) "nicht [..] die "richtigen" Begriffe [...] verwenden" (ich versteh's nicht, in mir sträubt sich alles...) - nun, was folgt daraus: Es soll ein populärer Begriff einem "richtigen", treffenden, sogar auch bestehenden Begriff vorgezogen werden - verstehe ich das richtig? Dann müsste ich in Einbeziehung dieser neuen (in meinen Augen bislang schwachsinnigen (das macht's mir irgendwie schwer...)) vorschlagen, von den (zumindest nach meiner Ansicht) "richtigen" Begriffen Weiterleitungen auf den populären, verwirrenden Titel anzulegen und die damit bezeichneten unterschiedlichen Themen mit Klammerzusätzen auseinanderzuhalten. Wäre das eine passende Lösung? Hieße konkret etwa beispielsweise: Audiodatenkompression -> Audiokompression (Datenkompression), bei Verlustfreie Audiodatenkompression könnte man sich den Klammerzusatz sparen, da die Kompression des Signales nicht verlustfrei sein kann, also vielleicht Verlustfreie Audiokompression, und die Verlustbehaftete Audiodatenkompression klärt vielleicht auch schon durch das explizite "verlustbehaftet" worum es nur gehen kann, daher nach gleichem Muster -> Verlustbehaftete Audiokompression. Wäre das eine annehmbare Lösung? --Speck-Made 01:43, 25. Nov. 2006 (CET)

Die Aufteiltung ist durchaus auch ein Problem, da er sie entgegen der GFDL einfach per copy&paste [3] [4] gemacht hat (siehe oben) und somit die gesamte History nicht mehr verfügbar ist, siehe auch WP:URV und WP:AV. --fubar 04:18, 22. Nov. 2006 (CET)

Das war mir die einzige ersichtliche praktikable Lösung. Wenn das so einen Mangel hat und Du es besser weißt, sehe ich es an Dir hier zu ergänzen und am Besten noch mir zu sagen, wie das besser geht. Nach dem "sei mutig!"-Grundsatz kann es nicht anders funktionieren, als dass sich der nichtwissende dadurch nicht hindern lässt und der Besserwissende berichtigt und belehrt. --Speck-Made 01:43, 25. Nov. 2006 (CET)

Ok. Die Sache mit der History war mir bisher noch nicht so bewusst. Es ist also beides ein echtes Problem.---<(kmk)>- 01:05, 23. Nov. 2006 (CET)

Hallo zusammen! Habe mal den letzten Revert von Speckmade rückgängig gemacht. Jetzt sollten wir schauen, dass die Änderungen, die er an den separaten Artikel gemacht hat, in den ursprünglichen Artikel fließen, sofern sie sinnvoll sind. Dann sollten wir die neuen Artikel entweder auf den ursprünglichen umleiten oder gar löschen, weiß nicht was besser ist. Umleiten ist natürlich mit viel weniger Aufwand verbunden, aber ob man solch unüblichen Begriffe überhaupt braucht ist eine andere Frage. Für mich hört sich Audiodatenkompression eher wie eine schlechte Übersetzung aus dem Englischen an ... Wenn wir die neuen "Speckmaden-Begriffe" löschen würden (ohne redirect), dann müssten wir auch die ganzen Referenzen aus anderen Artikeln (67 Stk.) umbiegen. Gibt es da keine Tools/Bots/etc., die dabei helfen könnten, ich kenne mich da nicht so aus. Und Speckmade, es wäre schön wenn du uns dabei helfen würdest, die Suppe, die du uns eingebrockt hast, auch auszulöffeln. Viele Grüße -- Meph666 ^{→ post} 11:33, 23. Nov. 2006 (CET)

Das wäre ja dann doch fast meine Aufgabe... :-| --Speck-Made 00:45, 25. Nov. 2006 (CET)

Also: Ich will und werde jedenfalls weitermachen an diesem Thema. Je nach Ergebnis unserer Diskussion muss ich die neuen Inhalte dann eben umsortieren, umstrukturieren, anderswo einordnen, wie auch immer... Ich will hier nicht durch die Diskussion gelähmt werden, hoffe das ist verständlich...

(Und ich würde mir ja wünschen, dass von manchem etwas positiver gedacht würde und mehr guter Wille unterstellt würde. Nur mit positiver Denke geht bei einem freien Projekt etwas - anders verplempern wir nur sinnlos unsere Kraft, mit der wir produktiv sein könnten, indem wir uns aufreiben und gegenseitig platt machen. Davon hat niemand was - außer denen, die schon immer wussten, das Freiheit nicht funktionieren kann - und denen gibt es auch nur billige Selbstbefriedigung.)

Soweit - ich hoffe, wir kommen voran. --Speck-Made 01:52, 25. Nov. 2006 (CET)

Ich glaube durchaus, dass du es gut gemeint hast, aber gut gemeint ist leider nicht immer gut gemacht. So umfangreiche Änderungen sollten vorher diskutiert werden, dann kann man das auch viel einfacher gemeinsam lösen (eben zB mit einem Bot-Lauf für die Edits). IMHO ist die Aufteilung in zwei Artikel nicht erforderlich, das kann auch schön und vollständig in einem Artikel abgehandelt werden. Falls doch eine Aufteilung sinnvoll sein sollte, muss sie unbedingt wiki- und GFDL-Konform mit der History erfolgen, siehe zB WP:AV und WP:URV (Ist zwar etwas aufwändinger, aber dafür sauber und v.a. nachvollziehbar). --fubar 02:13, 25. Nov. 2006 (CET)

---

Auch wenn mein Beitrag evtl. Speck-made in seinem Aktionismus "lähmen" mag, ich bringe ihn trotzdem.

Also, auch mit einigen Wochen Abstand zu Eurer Diskussion und nur als "Mitleser" unterwegs, kann ich nicht wirklich nachvollziehen, warum "unbedingt" und zwingend ein Eingriff erforderlich war. Das was hier als notwendige Präzisierung deklariert wird, hätte doch auch als Anmerkung in den Artikel einfliessen können. Auch kommen Wissenschaft und Forschung übrigens mit "Audiokompression" (trotz seiner angeblich fehlenden Präzision) bestens zurecht. Dies wäre evtl. ein sehr viel nützlicher Masstab als die blosse Google-Treffermenge, zumal auch der Bedeutungsghalt der englischsprachigen Formulierung "audiocompression" durchaus Beachtung verdient. Erst recht, da außerhalb des "Wikiversums" international der Bedeutungsgehalt noch mal um einiges höher ist und die Übersetzung in "Audiokompression" naheliegend und keinesfalls falsch sein ist. So ehrenwert und "gut" die Motive einer Person sein mögen, die sie zu einem Eingriff verleiten mögen und auch mit aller gebotenen Höflichkeit, viel zu oft ist das "Gegenteil von gut, genau das was gut gemeint war". Allerdings bin ich völlig offen für überzeugende Argumente und würde sie auch gern ebenso wie viele andere hier und vielleicht auch im Artikel lesen wollen, damit ich ebenso überzeugt zukünftig statt in der *Audiokompression* eben in der "Audiodatenkompression" interagieren kann. Sobald man den durch die Änderung erkennbaren Mehrwert hinsichtlich einer auf die Zukunft ausgerichteten größeren Entwicklungsfähigkeit erklärt, wird die Sache sicher auch transparenter. Immerhin wird hier auch an weitverbreiteten Arten des Zugangs zum thema über ein suchwort und auch an semantischen Fragen "herumgebogen", dies sollte ausreichend erklärt werden, was meiner Meinung nach bisher nur unzureichend geschah. Außer einer etwas konstruiert wirkenden "Notwendigkeit" ist jedenfalls so richtig Überzeugendes und Zukunftsweisendes noch nicht bei rumgekommen. Die "Rückkehr" zu einer Seite unter dem Titel "Audiokompression" durch Mithilfe von Speck-Made ist bisher auch noch nicht geschehen, deshalb melde ich mich hier eigentlich auch zu Wort. Gruß Lego@audiohq

zum Punkt TECHNIK/VORHERSAGE und ENTROPIECODIERUNG

Tatsächlich wird durch einen sogenannten Prädiktor eine Vorhersage über den jeweils nächsten Abtastwert getroffen. Dieser geschätzte Wert (meist wird einfach der vorherige Abtastwert vorausgesetzt) wird dann mit dem tatsächlich im Originalsignal vorliegenden Abtastwert verglichen indem die Differenz aus beiden gebildet wird. Nur dieser Differenzwert wird gespeichert. Richtig ist, dass dieses Verfahren Korrelationen zwischen den Abtastwerten ausnutzt. Auch wenn der Begriff Korrelation bezogen auf die Ähnlichkeit von lediglich zwei Zahlen etwas hochgegriffen erscheint. Bei Audiosignalen führt diese differentielle Codierung zu wenig Bandbreitengewinn, da die Signalform im Gegensatz zu beispielsweise Bildsignalen durch beständiges Schwingen charakterisiert ist. Das nach dem Prädiktionsvorgang vorliegende Signal ist die Ableitung des Originalsignals, stellt also die Steigung der Signalflanken dar. Es handelt sich hierbei nicht um weisses Rauschen. Wäre dies der Fall, könnte die folgende Entropiecodierung eben gerade nicht gute Ergebnisse liefern. Bei Tönen und besonders Musik handelt es sich um vielfach periodisch wiederholte Frequenzen, das bedeutet, dass in einem Musiksignal bestimmte Steigungswerte sehr häufig vorkommen werden. Diese Häufigkeit wird bei der Entropiecodierung ausgenutzt indem diesen Werten kurze Bitfolgen zugeordnet werden und dafür selten auftretenden Werten entsprechend längere Bitfolgen. Im Unterschied zum Originalsignal, bei dem allen Werten gleich lange Bitfolgen spendiert wurden (Bsp. CD: 16Bit) unabhängig davon, wie häufig sie auftreten, wird nun effizienter mit den Bits umgegangen. Das zugrundeliegende Prinzip kurze Codewörter für häufig verwendete Symbole zu verwenden ist seit dem Altertum bekannt und z.B. im Morsealphabet realisiert (Der Buchstabe E erscheint im Englischen am häufigsten, sein Morsecodewort ist nur ein . )

-- 213.39.149.103

Das mit dem Rauschen ist mir eben auch aufgestoßen, habe den Abschnitt daher gekürzt. -- Pemu 01:27, 18. Feb. 2010 (CET)

Die Entropiekodierung nutzt doch hier die Tatsache eines geringen Pegels des Restsignales aus, der eine erhöhte Häufigkeit kleinerer Werte im PCM-Restsignal mit sich bringt und ist unabhängig von Charakteristiken wie der Frequenzverteilung des Rauschens, die sehr wohl in Richtung eines weißen Rauschens geht.--Dvaer 16:27, 8. Okt. 2010 (CEST)

Qualitätseinschätzung

Nach meiner laienhaften Vorstellung ist die EInheit für Bitraten bit/s, ggf. mit dem Präfix k für Kilo. Ist mit den Angaben im Abschnitt Qualitäts(!)einschätzung (kbit, Kbit) tatsächlich etwas anderes gemeint, oder ist das nur schlampig geschrieben?

--pjt56 10:19, 24. Mär. 2008 (CET)

Wohl letzteres. Sei mutig! ;-) Heiko242 11:30, 12. Feb. 2009 (CET)

MP3

Der Artikel zu MP3 führt 1982 als Zeitpunkt für den Beginn der Entwicklung auf und nicht 1987, wie in diesem Artikel angegeben.

--Fabian (nicht signierter Beitrag von 79.223.142.224 (Diskussion | Beiträge) 18:31, 3. Jul 2009 (CEST))

Frequenzfolgen

„Schallwellen lassen sich ihrer Natur nachim Allgemeinen schwer vereinfachen ohne eine zwangsweiseverlustbehaftete Konvertierung in Frequenzfolgen, wie sie immenschlichen Ohr stattfinden.“

Diesen Satz versteheich nicht. Da ich mich nicht für dumm halte, habe ich {{Überarbeiten}} gesetzt. -- Pemu 01:27, 18. Feb. 2010 (CET)

Eine nähere Erklärung würde wohl den Rahmen hier sprengen und existiert bereits in einem spezielleren Artikel, den ich jetzt verlinkt habe. Hoffentlich ist das eine zweckmäßige Abhilfe...--Dvaer 21:25, 8. Okt. 2010 (CEST)

96 - 128 kbps ≠ CD Qualität

Ich habe mal den Überarbeitungs-Baustein gesetzt, weil die Hörtests sehr kurios scheinen. Schon bei einer einfachen Stereoanlage hört man, dass 96 / 128 kbps AAC / MP3 Dateien nicht vergleichbar mit einer Audio CD sind. --CherryX ^sprich! 16:02, 20. Jun. 2011 (CEST)

stimme dem zu und so 'n gutes Gehör hab ich nun eig auch nicht *denk* -- Moehre 16:18, 20. Jun. 2011 (CEST)

Bei 128 kbps ist der Qualitätsunterschied deutlich hörbar. --Jossi 16:48, 20. Jun. 2011 (CEST)

ich finde gut, dass ich bei der Ansicht nicht alleine bin; mein Anstoß war folgende Textstelle: "[..] bei ~128 kBit/s für die deutliche Mehrheit der Hörer bereits eine transparente, also von der Originalaufnahme nicht unterscheidbare Qualität. [..] Eine vergleichbare Qualität ist mit dem AAC-Format [..] bereits mit 96 kBit/s zu erreichen. [..] sehr gute Qualität bereits bei 96 bis 128 kBit/s erreicht werden kann, die für die deutliche Mehrheit der Benutzer nicht von der CD zu unterscheiden ist." --CherryX ^sprich! 17:10, 20. Jun. 2011 (CEST)

Ich habe das mal zum Anlass genommen, über unseren subjektiven Höreindruck hinausgehend die Beleglage zu prüfen. Sie zeigt sich keineswegs so simpel, wie das im Artikel dargestellt ist. Zunächst einmal werden alle diese "Public Listening Tests", von denen es sehr viele gibt, von denen der Artikel aber nur einige, noch dazu sehr alte, zitiert, nicht unter standardisierten Bedingungen von geschulten Hörern durchgeführt, sondern von einer Zufallsstichprobe anonymer Internetnutzer, die meist recht klein ist (typischerweise um die 20 Leute) und bei denen man nichts über ihre individuelle Hörfähigkeit und die Qualität ihres Audio-Equipments weiß. Außerdem wird das Ergebnis dieser Tests von der gewählten Musikrichtung beeinflusst; klassische Musik ist typischerweise gegenüber Pop- und Rockmusik unterrepräsentiert. Das vorausgeschickt, zeigen die Tests mehrheitlich keineswegs, dass 128 kbps-MP3 „transparent“, also von unkomprimierter Musik nicht zu unterscheiden ist. Bei dieser Bitrate gilt das allenfalls für AAC- oder Vorbis-Kompression, aber nicht für MP3. In diesem Test von 2004 lagen die Ergebnisse bei 3,0-3,7 (transparent ist 5), in diesem Test eines einzelnen Hörers von 2003, ausschließlich mit Barockmusik, kam keiner der Encoder bei 128 kbps über 4,1 hinaus, und gerade die AAC-Codecs schnitten miserabel ab. Dieser Test vom Oktober 2008 kommt zu deutlich schwächeren Ergebnissen als der im Artikel zitierte Test vom Dezember 2005. Die Tests bei Sound Expert ergeben bei 128 kbps ebenfalls nur für AAC und Vorbis ein transparentes oder annähernd transparentes Ergebnis, nicht für MP3. Erst bei 192 kbps ergeben sich hier für alle Encoder keine hörbaren Unterschiede mehr, während bei 64 kbps alle deutlich hinter dem Original zurückbleiben. Zu diesem Ergebnis kommt auch der neueste Test vom März 2011. Die Knowledge Base von Hydrogenaudio kommt bezüglich MP3 zu dem Ergebnis: Sometimes, maximum bitrate (320kbps) isn't enough ... Unusable for high definition audio (sampling rates higher than 48kHz).

Alles in allem ist die Darstellung im Artikel insofern deutlich einseitig, als sie die Klangtreue komprimierter Audiodaten zu undifferenziert übertreibt. Da müsste zumindest sehr viel genauer zwischen den verschiedenen Codecs unterschieden werden, damit nicht, wie jetzt bei uns, der Eindruck entsteht, 128 kbps-MP3 sei klanglich nicht vom Original zu unterscheiden. Der QS-Baustein ist also nur zu berechtigt. --Jossi 18:06, 20. Jun. 2011 (CEST)

Noch eine letzte subjektive Bemerkung: Diese Hörtests scheinen sich alle auf das Auftreten von „artifacts“ wie Zischen u. dgl. zu konzentrieren. Für mich ist der wesentliche Unterschied zwischen höheren und niedrigeren Bitrates, dass bei 128 kbps die Musik einfach „flacher“ klingt, mit weniger Obertönen und weniger räumlicher Tiefe. --Jossi 18:15, 20. Jun. 2011 (CEST)

das Mit den Obertönen sollte man Hier gut sehen können ;-) -- Moehre 18:21, 20. Jun. 2011 (CEST)

hui, da wird jetzt aber doch so einiges durcheinander geworfen, wie ich meine. ich muss jetzt deshalb ein wenig ausholen:

• gerade auf "einfachen stereoanlagen" sollten aller logik folgend mögliche kompressionsartefakte kaum bzw. weniger zu tage treten als auf irgendwelchen high-end-geräten. nicht umsonst werden encoder-tests zumeist mit hochwertigen kopfhörern vorgenommen, um möglichst viele details heraushören zu können.
• "so 'n gutes Gehör hab ich nun eig auch nicht" - wenn das nicht einfach nur so dahingesagt sein sollte, dann passt das ja auch exakt so: wer ein "schlechtes" bzw. geschädigtes hörvermögen hat, bei dem "passt" das psychoakustische modell, das den encodern zugrunde gelegt wurde, nicht mehr. einfach ausgedrückt: ein kaputtes ohr wird schneller eine kompression bemerken als ein "normales".
• aussagen wie "Bei 128 kbps ist der Qualitätsunterschied deutlich hörbar" sind in dieser allgemeinheit einfach quatsch (ebenso: "sehr kuriose Hörtests.. auf einer gewöhnlichen Stereoanlage hört man klare Unterschiede zwischen >160 kbps MP3 / AAC und Audio-CD". a) eine solche aussage läuft WP:NPOV und WP:KTF zuwider. b) man darf keinesfalls (auto)suggestion und einbildung unterschätzen; ohne ausgiebiges ABXing sollte man so etwas gar nicht erst behaupten. c) moderne encoder sind heutzutage bei 128kbit/s so gut, dass für otto normal kein unterschied mehr "deutlich" hörbar ist (mehr dazu gleich).
• auf die formulierung "bei ~128 kBit/s [ist] für die deutliche Mehrheit der Hörer bereits eine transparente, also von der Originalaufnahme nicht unterscheidbare Qualität" kann schwerlich nach etwas recherche per "die Tests [zeigen] mehrheitlich keineswegs, dass 128 kbps-MP3 „transparent“, also von unkomprimierter Musik nicht zu unterscheiden ist" reagiert werden. der artikel behauptet nichts gegenteiliges: "transparenz" ist immer hörerbezogen und steht nie für sich. wenn nun eine "deutliche mehrheit der hörer" bei 128kbit/s keine unterschiede mehr feststellen kann, dann ist die musik eben auch "transparent" für eben jene. dass geübte^(*) hörer oder hörer mit hörschädigungen trotzdem noch die quellen bis zu einem gewissen grad unterscheiden können, beißt sich also nicht mit der anderen aussage. im artikel wird auch nicht behauptet, dass mit 128kbit/s komprimierte stücke nicht mehr zu unterscheiden wären.
• ^(*) kleiner abstecher zum thema "geübte" hörer: es gibt extra ausgewählte "schwierige" soundfiles, mit denen bestimmte encoder an ihre grenzen gebracht werden können. durch mehrfaches hören kann man sich im folgenden auf die typischen fehler/artefakte "einschießen"; man erlernt also sozusagen überhaupt erst, so etwas wahrzunehmen. in foren tauschen sich leute mittlerweile darüber aus, wie man dieses "wissen" am besten wieder löschen kann, um den spaß an der musik wieder finden zu können...
• die oben befindliche erklärung "transparent ist 5" kann ebenso nicht unterschrieben werden; eine "5" würde bei den zitierten darstellungen lediglich bedeuten, dass alle hörtest-teilnehmer mit einer mind. 95%igen sicherheit die stücke nicht mehr sicher voneinander unterscheiden konnten. "0" dementsprechend: alle hörtest-teilnehmer konnten mit einer mind. 95%igen sicherheit die stücke richtig zuordnen. es sollte sich also jedermann erst einmal überlegen, was es bedeutet, wenn bei dem "test mit deutlich schwächeren Ergebnissen" lame 3.98.2 in der abschließenden zusammenschau auf einen gesamtwert von 4,51 kommt...
• in die gleiche kerbe schlägt diese aktuelle übersicht, die angeblich "nur für AAC und Vorbis ein transparentes oder annähernd transparentes Ergebnis, nicht für MP3" attestieren würde. lame erreicht hier einen wert von 4,59; der untenstehende abschnitt "How to read the ratings" verrät uns, dass man ab einem wert von 4,0 lediglich "faintly discernible sound artifacts" wahrnehmen könne, über der 5,0-grenze heißt es da: "all sound artifacts will be beyond threshold of human perception". was heißt das also für 4,59? sicherlich nicht das, was hier zuvor verlautbart wurde.
• wenn schon vorhandene ABX-test-ergebnisse herangezogen werden, so muss natürlich auf möglichst aktuelle zurückgegriffen werden. z.b. ist der lame-mp3-encoder von 2003 in keinster weise mehr mit dem seit 2010 empfohlenen v3.98.4 zu vergleichen. ich hasse es normalerweise, wenn mir jemand mit wikipedia-erkenntnissen ohne weitere quellenangaben ankommt, aber hier zitiere ich einfach mal, weil man es einfach von a bis z unterschreiben kann: "Audio-Codecs wurden immer wieder verschiedenen Hörtests ... unterzogen. ... Die Community auf Hydrogenaudio.org testete Lame und andere Encoder in regelmäßigen Hörtests. Dabei flossen die Ergebnisse direkt in die Entwicklung von Lame ein, so dass der Encoder stetig verbessert werden konnte. Als Beispiel sei hier die Kodierungsqualität bei 128 kbit/s genannt ... So erreichte Lame in der Version 3.95 bei einem Test 3,74 Punkte, die Folgeversion Lame 3.96 in einem anderen Test bereits 4,18 Punkte und Lame 3.97b2, wiederum in einem anderen Test, 4,60 von jeweils 5 Punkten. ... Die Ergebnisse lassen sich ... nicht direkt aufeinander übertragen, bieten aber dennoch einen Einblick in die Entwicklung des Codecs, der sich in der Qualität tendenziell deutlich steigern konnte. Konnte man im Jahr 2002 bei 128 kbit/s nur von ausreichender Qualität sprechen, so ist 2007 die Qualität für die meisten Hörer schon transparent."
• "das Mit den Obertönen sollte man Hier gut sehen können" – ja: sehen, aber nicht hören.

gruß, --JD {æ} 02:56, 23. Jun. 2011 (CEST)

• ein durchschnittlicher Hörer ab einer Bitrate von 160 kbps für MP3 und ab 128 kbps für AAC das Gehörte nicht mehr vom Originalsignal unterscheiden kann
• moderne Vertreter verlustbehafteter Codecs in der Lage, so genannte transparente Qualität zu liefern. Das heißt, auch bei konzentriertem Hören ist es nahezu unmöglich, Unterschiede zum Original auszumachen.
• [http://www.box-designs.com/inhalt/de/download/PJ-BD-StreamBox-Tipps-Pi-0811122-DE.pdf Vermeiden Sie verlustbehaftet komprimierte Dateiformate, wie MP3 oder AAC, da erst mit

Datenraten von 320kbit/sec eine Tonqualität ähnlich der CD möglich ist.]--Oursana (Diskussion) 10:33, 23. Okt. 2013 (CEST)

Die LAME Dokumentation behauptet nirgends, dass 128 kbs transparent sei. Es werden mit Verweis auf Hydrogenaudio VBR Modi empfohlen: -V0 bis -V3. Zu -V4 (avg. 160 kbps) wird gesagt, dass es nahezu transparent sei. CBR 128 (soundcloud, radio streams) sind auf durchschnitlichem Equipment grauenvoll, von guten Anlagen oder Kopfhörern ganz zu schweigen und das liegt wohl eher nicht an kaputten Ohren oder Einbildung. Was soll diese Desinformation zu schlechter Qualität? Speicherplatz und Bandbreiten sind heutzutage nicht mehr das Limit und ein guter Kopfhörer kostet werniger als ein Smartphone. --Stepwiz (Diskussion) 18:09, 20. Jan. 2017 (CET)

• es wird auch nirgendwo im artikel behauptet, dass 128kbps-LAME-files transparent seien.
• dass "CBR 128 ... auf durchschnitlichem Equipment grauenvoll" seien, ist nichts weiter als deine behauptung und angesichts unzähliger tests (siehe auch weiter oben) keine haltbare aussage.
• "Was soll diese Desinformation zu schlechter Qualität?" --- auf was beziehst du dich mit dieser frage?
• ob speicherplatz heute günstig zu haben ist oder nicht, ist für diesen enzyklopädischen artikel übrigens ziemlich irrelevant. --JD {æ} 19:05, 20. Jan. 2017 (CET)

Gut dann kann man: "Eine MP3-Datei mit einer Bitrate von ~128 kBit/s klang 1997 noch sehr bescheiden. Die versprochene CD-ähnliche Qualität wurde damals noch nicht erreicht. Im Jahr 2005, so belegen aktuelle Hörtests,[2] bietet der Encoder LAME für dasselbe Format bei ~128 kBit/s für die deutliche Mehrheit der Hörer bereits eine transparente, also von der Originalaufnahme nicht unterscheidbare Qualität." und: "Aktuell (August 2007) lässt sich also festhalten, dass mit einem qualitativ guten Encoder und dem richtigen Format bereits bei 96 bis 128 kBit/s eine Qualität erreicht werden kann, die für die deutliche Mehrheit der Benutzer nicht von der CD zu unterscheiden ist." ja löschen. Denn das propagiert 128 kbits und behauptet es sei transparent. LAME wird explizit genannt und es entspricht nicht den Aussagen der LAME Dokumentation. --Stepwiz (Diskussion) 19:49, 20. Jan. 2017 (CET)

mit verlaub - das ist doch quatsch. lies bitte genau und verdrehe nicht artikelaussagen nach gutdünken. --JD {æ} 19:58, 20. Jan. 2017 (CET)

was verstehst Du jetzt nicht? LAME Doku: "while -V4 should be close to perceptual transparency" nicht "bei ~128 kBit/s" (nicht signierter Beitrag von Stepwiz (Diskussion | Beiträge))

und weiter? steht im artikel "LAME gilt allgemein bei 128kbps als transparent und behauptet auch, dies zu sein"? --JD {æ} 20:12, 20. Jan. 2017 (CET)

wie wäre es mit der Verneinung: "...Qualität, während LAME allerdings bei 128kbps als nicht transparent gilt und die Dokumentation [Quelle] dafür höhere variable Bitraten (preset standard oder mindestens -V4) empfiehlt. --Stepwiz (Diskussion) 20:28, 20. Jan. 2017 (CET)

weder gibt es einen grund, hier in diesem artikel gerade LAME so in den vordergrund zu stellen noch wüsste ich was zitierfähiges, das das von dir behauptete/vorgeschlagene belegen würde. --JD {æ} 20:32, 20. Jan. 2017 (CET)

Soso LAME löschen, nein. LAME richtig stellen, auch nein. Mit Dir ist sachlicher Austausch offenbar schwierig. Zu diesem Abschnitt haben sich hier schon bald mehr Leute kritisch geäussert, als an dem zitierten Hörtest mit gemacht haben, mit dem er seine Aussagen zu belegen versucht. Jeder Versuch der Richtigstellung wird hier als "quatsch" abgetan und persönliche Meinungen werden nicht zugelassen, obwohl auch der Hörtest auf subjektiver Meinung beruht und es sich hier um die Diskussionsseite handelt. Der Artikel sollte jedenfalls keine einseitige Darstellung aufweisen. Das ist leider nicht der Fall. --Stepwiz (Diskussion) 21:36, 20. Jan. 2017 (CET)

hast du irgendwas handfest-zitierfähiges, das deine ausführungen stützt? ansonsten klinke ich mich hier jetzt aus; auf konkrete nachfragen gehst du nicht ein, aussagen im text verdrehst du. --JD {æ} 22:16, 20. Jan. 2017 (CET)

Die verlinkten Quellen sind veraltet und nur noch im Webarchiv verfügbar. Oben in der Diskussion sind die Hydrogenaudio Hörtests verlinkt. Zu der Kategorie "MP3 Listening Test @ 128 kbps (October 2008):" sind detaillierte Codec Settings genannt: [5]. Mitnichten ist dies CBR 128 kbit/s wie im Artikel suggeriert, sondern immer VBR mit mittlerer Qualitätsstufe. Im falle von LAME -V5, was nach aktueller Doku avg. 130 kbps bedeutet. Den Resultaten nach kann man nicht behaupten, dass sämtliche Codecs nahe 5, also bei transparent liegen [6]. Somit sollte die Aussage im Artikel dass "bereits bei 96 bis 128 kBit/s eine Qualität erreicht werden kann, die für die deutliche Mehrheit der Benutzer nicht von der CD zu unterscheiden ist." nun endgültig widerlegt sein. Eine durchschnittliche VBR Rate von 130 kbps ist nicht dasselbe wie CBR 130. Durchschnittlich bedeutet einen Durchschnitt über eine grosse Anzahl von Liedern. Ein einzelnes Lied kann bei -V5 auch mit durchschnittlich 138 kBit/s oder dergleichen kodiert worden sein. An problematischen Stellen ist bei VBR eine deutlich höhere Bitrate erlaubt. Der Abschnitt im Artikel suggeriert, jedes beliebige Sample ließe sich mit 96 bis 128 kBit/s in quasi CD Qualität kodieren. Das ist Falsch.--Stepwiz (Diskussion) 00:14, 21. Jan. 2017 (CET)

ich hatte dir oben schon einmal mitgeteilt, dass du dinge herausliest bzw. interpretierst, die nicht im artikel stehen und dich gebeten, genauer vorzugehen. weder geht es im von dir zitierten abschnitt des artikels explizit um LAME noch wird dort eine unterscheidung CBR/VBR vorgenommen und schon gar nicht behauptet, dass "sämtliche codecs nahe 5, also bei transparent liegen", sondern eben lediglich, dass "bei 96 bis 128 kBit/s eine Qualität erreicht werden kann, die für die deutliche Mehrheit der Benutzer nicht von der CD zu unterscheiden ist" - von wegen "Der Abschnitt im Artikel suggeriert, jedes beliebige Sample ließe sich mit 96 bis 128 kBit/s in quasi CD Qualität kodieren". ansonsten zitiere ich mich einfach mal selbst (vgl. weiter oben vor gut fünf jahren:

• [...] "transparent ist 5" kann [...] nicht unterschrieben werden; eine "5" würde bei den zitierten darstellungen [...] bedeuten, dass alle hörtest-teilnehmer mit einer mind. 95%igen sicherheit die stücke nicht mehr sicher voneinander unterscheiden konnten. "0" dementsprechend: alle hörtest-teilnehmer konnten mit einer mind. 95%igen sicherheit die stücke richtig zuordnen. es sollte sich also jedermann erst einmal überlegen, was es bedeutet, wenn bei dem "test mit deutlich schwächeren Ergebnissen" lame 3.98.2 in der abschließenden zusammenschau auf einen gesamtwert von 4,51 kommt...
• in die gleiche kerbe schlägt diese aktuelle übersicht [...]. lame erreicht hier einen wert von 4,59; der untenstehende abschnitt "How to read the ratings" verrät uns, dass man ab einem wert von 4,0 lediglich "faintly discernible sound artifacts" wahrnehmen könne, über der 5,0-grenze heißt es da: "all sound artifacts will be beyond threshold of human perception". was heißt das also für 4,59? sicherlich nicht das, was hier zuvor verlautbart wurde.

--JD {æ} 12:29, 21. Jan. 2017 (CET)

Der Abschnitt beginnt mit "Eine MP3-Datei mit einer Bitrate von ~128 kBit/s klang 1997 noch sehr bescheiden." 1997 gab es kein VBR. Somit wird hier über MP3 CBR 128 geredet. Der nächste Satz erwähnt explizit LAME und sagt in dem Hörtest 2005 war "bei ~128 kBit/s" quasi Transparenz erreicht. Obwohl dort im Satz LAME steht, behauptest Du es ginge nicht um LAME in dem zitierten Abschnitt. Da dort ein konkreter kBit/s Wert steht, geht es weiterhin um CBR, wohingegen LAME ganz klar VBR Modi empfiehlt. Aber für diese "Behauptung" empfindest Du Hydrogenaudio und die LAME Dokumentation als nicht zitierfähig. Selbst der zitierte Hörtest verwendete VBR (-V5 --vbr-new), wird also in falschem Kontext von CBR 128 erwähnt und ist damit irreführend und falsch. Das nennt Du meine Interpretation. Bei VBR wird versucht eine gewisse Qualität zu erreichen und die konkret erreichte Bitrate ist irrelevant. Das machen auch andere moderne Encoder so. MP3 CBR 128 klingt weiterhin "noch sehr bescheiden". Das ist ein Zitat aus dem Artikel über 1997 - jedem der hier auftaucht und 15-20 Jahre später sagt "Bei 128 kbps ist der Qualitätsunterschied deutlich hörbar." wirfst Du vor es sei Einbildung oder eine unhaltbare Behauptung und untermauerst dies mit Hörtests, die allesamt VBR Encoder oder modernere Verfahren als MP3 verwenden. MP3 CBR 128 ist immer noch das MP3 Format schlechthin (z.B. auch weiterhin der default wenn man lame ohne weiteren Parameter aufruft) und wird leider auch heute noch viel zu oft eingesetzt, z.B. beim von mir erwähnten soundcloud oder in radio streams. Deswegen ist das hier keine Diskussion über Spitzfindigkeiten und Vergangenes ohne Realitätsbezug: MP3 CBR 128 ist heutzutage "sehr bescheiden" und dieser Artikelabschnitt trägt nicht dazu bei dahingehend Aufklärung zu leisten sondern ist absolut irreführend und missverständlich formuliert. Es muss klarer dargestellt werden, dass modernere Einstellungsvarianten und Verfahren existieren. Bitte, im Deiner aktuellen Übersicht, wo ist der Hörtest für MP3 CBR 128?--Stepwiz (Diskussion) 17:20, 21. Jan. 2017 (CET)

quantiSieren oder quantiFIZieren?

1. Im Artikel steht an EINER Stelle das Wort quantifizieren (3.-letzte Zeile des Abschnitts Psychoakustik. Ist da nicht auch quantisieren gemeint?
--Sun-kid (Diskussion) 17:35, 29. Apr. 2015 (CEST)

Würde ich so stehen lassen. Es geht um das "Ausmessen" und "Einschätzen" des Signalanteils und nicht um ein Quanteln = Stückeln. --Musicproducer (Diskussion) 04:13, 22. Jun. 2022 (CEST)

Datenraten mono/stereo

2. Grundsatzfrage zu mono/stereo: Sind Datenraten in kbps immer pro Kanal (links/rechts) gemeint oder total? Oder kommt das auf das Verfahren an? Wenn ich eine mp3-Datei von 128kbps zu mono konvertiere, ist sie ja nur noch 64kbps, aber die Qualität "pro Kanal" ist wohl immer noch gleich. Diese Frage vor allem wegen DAB-Stationen. Die Sendestationen geben z.B. an "48kbps mono". Wäre die Abgabe "96kbps stereo" also 192kbps total? --Sun-kid (Diskussion) 17:36, 29. Apr. 2015 (CEST)

Kritik

Gehört die Inkompatibilität (z. B. zwischen MP2 und AAC) der verlustbehafteten Audiodatenkompressionsformate in den Artikel? --2003:D2:4F33:C54D:61C0:FC15:F6DD:55CC 14:35, 9. Okt. 2022 (CEST)