Diskussion:Musepack

Transparenz

Was versteht man unter der in diesem Artikel erwähnten "Transparenz"?

Transparenz bei verlustbehafteten Codecs bedeutet ,dass das encodierte Audiosignal nicht mehr vom orginalen Audiosignal zu unterscheiden ist. -- Xorx77 23:19, 30. Mär 2005 (CEST)

Also bitte...

Wer schneidet denn komprimierte files, wenn es nicht irgendwie auch anders geht??

Ich kann mir nicht vorstellen dass es jemanden gibt der einerseits so perfektionistisch ist mpc einzusetzen und andereseits zu blöd ist das *vorher* zurechtzuschneiden.

Mann... es gibt aber auch nasen auf der welt...

Hab das als "minus" mal gefixt.

warum sollte man komprimierte Files nicht schneiden, wenn das geht? wenn nur das komprimierte File archiviert wurde (wozu MPC ja wegen seiner --xtreme Qualität prädestiniert ist) - anderer Fall, ich will mal eben ein Sample verschicken, wegen Copyright als "Zitat" also 30 s und auf 40 kBit runtergerechnet - da sind schnitt- und stripfunktionen sehr nützlich.

Ach ja, noch ganz kurz meine 2 Cent hierzu :-): Die Möglichkeit für framegenaues Schneiden ist sehr wichtig, bei Audio- genauso wie bei Videocodecs. Allerdings unterstützt die aktuelle Musepack-Version SV8 beta samplegenaues cutten, insofern hat sich die Diskussion wohl eh erledigt :D 85.176.187.39 06:06, 11. Dez. 2008 (CET)

Klangqualität

Ich höre immer viel gerede über Klanqualität Und dann stürmen tausende behauptungen herüber, jene Kodierung sei besser als andere, worauf beruhen diese behauptungen? ich habe mal einen Test gelesen in dem sowohl Laien als auch Musiker festellen sollte welches Musikstück von CD oder als mp3-Kodierung bei 128kbit, die Ergebnisse liessen eher darauf schliessen das diejenigen nicht wirklich einen Unterschied wahrnahmen. Ich fürchte subjektives Empfinden, welches durch vorgelegter Favorisierung aufgeladen ist, bestimmt hier eher. Ich fände es sehr schön wenn zu diesen behauptungen auch mal idealerweise Untersuchungen oder zumindenst die Hintergründe dieser dargestellt würden.

Überarbeitung wg. Unsachlichkeit

Ich markiere den Artikel jetzt, da er viele Behauptungen beinhaltet, die ungenau und nicht nachgewiesen sind, bzw. sogar Werbung für den Codec machen. Die Kernpunkte:

• "kleinere Dateien bei höherer Qualität im Vergleich zu anderen verlustbehafteten Codecs" - dieser Vergleich zu ungenannten Codecs ist ein Witz und die angeblich generell höhere Qualität benötigt einen Nachweis.
• "bietet Transparenz ab einer Bitrate von ca. 170 bis 200 kBit/s" - Für den Laien vielleicht (ich schließe mich da ein), allerdings ist der Begriff Transparenz erst anwendbar, wenn absolut kein Unterschied feststellbar ist. Das gewährleisten nur verlustfreie Codecs wie FLAC. "Relative Transparenz" wäre hier treffender.
• geringe "Problemanfälligkeit": Ohne Nachweis, ohne Nennung betreffender Probleme und dadurch relativiert, dass unter "Nachteile" einige gravierende Probleme aufgelistet werden.
• "sehr schnelle Kodierung/Dekodierung": Ohne Vergleich und ohne Nachweis. Jeder Codec kann bei entsprechend geringer Qualität schnell arbeiten (und mit Qualität meine ich nicht die Bitrate, sondern die Art des Codiervorgangs)
• "fast keine Hardware-Unterstützung": die genannten Beispiele beziehen sich auf Einzelfälle und sind keinesfalls repräsentativ. Hier wäre ein Verweis auf eine Liste kompatibler Player angebracht.
• "keine Spezifikation vorhanden" - eine Erklärung hierzu sowie (wie immer) ein Nachweis wäre angebracht.

Generell sollte viel mehr Fließtext als die bloße Auflistung von (unbegründeten) Fakten im Artikel auftauchen. Auch wären einige technische Details, wie sie der englischsprachigen Version des Artikels zu entnehmen sind, sehr bedeutend, um den Codec besser von Anderen abzugrenzen. Der große Textblock vor dem Inhaltsverzeichnis sollte auch auf eine grundlegende Definition geschrumpft werden, alle weiteren Details zu Geschichte, Verwendungszweck etc. brauchen einen eigenen Gliederungspunkt --Klamann 20:21, 7. Okt. 2008 (CEST)

Hab mal versucht, ein paar der angesprochenen Punkte umzusetzen. Ich hoffe, das ist so in Ordnung, bin sonst kein Autor :-) 85.176.187.39 05:45, 11. Dez. 2008 (CET)

Betr. "sehr schnelle Kodierung/Dekodierung": Die Geschwindigkeit der Dekodierung sehe ich nicht als Kriterium, solange die Audiodaten schnell genug abgespielt werden können, dass es nicht stockt - und welcher Codec kann das nicht? Wenn die Prozessorlast beim Dekodieren gemeint ist, sollte das auch geschrieben werden. Und was die Kodierung angeht: Auch damit gewinnt man heute keinen Blumentopf mehr. Ich kann bestätigen, dass Musepack ziemlich flott ist, aber der Vorteil relativiert sich doch schnell, wenn man einen aktuellen Rechner hat, und angesichts der Tatsache, dass man Dateien meisten nur einmal kodiert. -- LietIbmaSad 20:44, 5. Jun. 2009 (CEST)

*lol* da musste ich jetzt aber schmunzeln ;-) Mit schnell ist natürlich geringe CPU-Auslastung gemeint. Man könnte auch sagen, dass er vom Code her (ohne die Hardware-Leistungsfähigkeit in Betracht zu ziehen) so schnell wie möglich arbeitet, sprich, dahin gehend optimal programmiert ist. In der EDV ist es nicht unüblich ein Programm als "schnell" zu bezeichnen, hier sollte es natürlich allgemein verständlich sein. Allerdings ist die Formulierung in diesem Artikel leider noch das geringste Übel, deshalb ist das in meinen Augen ein Tropfen auf dem heißen Stein. --Erschaffung 22:31, 5. Jun. 2009 (CEST)

Ihr redet, wie ihrs versteht. Transparenz heißt offensichtlich nicht das, was ihr denkt. Und die schnelle Decodierung ist wichtig, weil mehr CPU = mehr Strom = Batterie schneller tot. (Freilich gibt es kaum mobile Geräte damit) (nicht signierter Beitrag von 92.78.14.101 (Diskussion | Beiträge) 13:25, 8. Jan. 2010 (CET))

Entwicklung / Zukunft

Wollte nur mal darauf hinweisen, dass sich der Stand der Entwicklung geändert hat - seit März 2009 ist die SV8 Final raus.

Des Weiteren habe ich ein Problem mit folgendem Satz: "Auch stehen technisch ausgereifte Codecs zweiter Generation wie AAC zur Verfügung, die eine weitere Verbreitung und mindestens vergleichbare, eher sogar bessere Klangqualität bieten." Ist doch sehr subjektiv und schwammig formuliert, und vermittelt zudem den Eindruck, Musepack sei nicht technisch ausgereift bzw. nicht so ausgereift wie AAC. Soll hier die Anzahl der an der Entwicklung beiteiligten bezahlten Experten entscheidend sein? Musepack ist technisch ausgereift und seit SV8 ebenfalls in "zweiter Generation" verfügbar. -- LietIbmaSad 20:25, 5. Jun. 2009 (CEST)

Fiel mir auch schon negativ auf und hätte Ich damals schon löschen sollen. --Gabbahead. 12:36, 16. Jan. 2010 (CET)