Gibt es Klangunterschiede bei Rippern?

Das ist Unsinn, jedenfalls wenn in ein verlustfreies Format (FLAC, ALAC, WAV) gerippt wird. Die Ergebnisse aller Programme, die es schaffen, bitgenau zu kopieren (und das kann EAC wie schon der Name sagt wohl sehr gut,) können gar nicht anders als gleich zu kingen. Unterschiede kann es je nach verwendetem Encoder höchstens bei komprimierten Formaten (mp3) geben, wobei das bei modernen Encodern und gleicher Bitrate auch eher Theorie ist.

Ist eventuell nachvollziebar, was sich aber letztendlich wie so vieles nicht beweisen lässt.

Ich habe jahrelang mit dem Programm Magix Audio Cleaning gearbeitet und gedacht, da musst du dir keine Gedanken machen, ist ja alles digital, bis ich dann wieder Audacity genommen habe. Allerdings nicht zum Rippen, sondern zum Schneiden, was aber auch in diese Richtung geht.

Ich wollte das erst nicht glauben, und habe mehrmals Vergleiche zwischen Magix und Audacity vorgenommen. und was ist das Ergebnis?

Und dabei ist Audacity noch free

8Quibhirfd8 (Beitrag #3) schrieb:

Ist eventuell nachvollziebar, was sich aber letztendlich wie so vieles nicht beweisen lässt.

Mathematisch beweisen lässt sich in jedem Falle, dass zwei Ripper, die ihre Resultate mit der AccurateRip-Datenbank abgleichen und dabei zu identischen Ergebnissen kommen, mit an Sicherheit grenzender Wahrscheinlichkeit bitidentisch rippen. Wem diese checksummenbasierte Wahrscheinlichkeit nicht reicht oder wer ernsthaft glaubt, dass zwei Dateien, die vom ersten bis zum letzen Bit überein stimmen, trotzdem unterschiedlich klingen können, findet in Goldohren-Foren oder -Zeitschriften natürlich immer eifrige Kopfnicker - schließlich verdienen die ja mit nichts anderem ihr Geld.

Im übrigen möchte ich auch mal darauf hinweisen, dass Mathematik und Informatik nicht umsonst Wissenschaften sind und dass sich im Bereich des - vielerorts ebenfalls wissenschaftlich betriebenen - digitalen Audio (z.B. im Bereich von Datenkompression oder Checksummen-Fingerabdrücken) durchaus eine ganze Menge beweisen lässt! Hören darf am Ende natürlich trotzdem jeder, was er will oder kann, aber zur Kenntnis nehmen sollte man das schon ...

Also bitgleich ist bitgleich. Wenn allerdings Verluste und Fehlerkorrekturen beim Rippen greifen, könnte da theoretisch schon ein Unterschied bestehen. Aber wie gesagt, mit dem Datenbankabgleich oder Checksummen wäre das dann obsolet.

Was aber am Beispiel Magix / Audacity sein kann, sind irgendwelche Filter usw. die auf die Datei angewendet werden, dann ändert sich natürlich einiges. Ich vermute hier mal die Ursache. Gerade bei Magix sind bestimmt irgendwelche Limiter, Extender, Normalizer o. ä. am Werk, wie der Name Audio CLEANER schon sagt. Hat Audacity zwar auch, aber diese Filter muss man gezielt einsetzen und sind ggf. auch besser. Man weis es nicht Nur weil was digital ist, ist es ja nicht verlustfrei, sobald man Hand anlegt.

Lossless komprimierung ist lossless, da ist der Encoder egal.
Bei verlustbehaftetem Komprimieren wie MP3 o. ö. ist der Encoder wichtig!

Wichtig ist beim Abspielen von komprimiertem Material (teilweise auch lossless) der decoder und die Software, also der Player. Denn im Gegensatz zum Komprimieren ist das beim Abspielen auch wieder eine Frage der Softwaremäßigen Interpretation und ggf. diverser versteckter Filter, auch manchmal bei Lossless (hier eher die Playersoftware als der decoder selbst)... Das fängt schon bei einer einfachen softwaremäßigen Lautstärkeregelung zum Abspielen an... Da hilft eigentlich nur wieder auf CD-Brennen und vergleichen. dann sollte (bei lossless) alles wieder identisch sein...

Ich rede auch nur von minimalen Unterschieden bei Magix/Audacity, die ein anderer vielleicht gar nicht hört, weil ihm die Hifi-Anlage dazu fehlt. Effekthaschereien die es auf beiden Seiten gibt sind natürlich ausgeschaltet, wenn nicht doch noch im Hintergrund was eingeschaltet ist, dann hat man aber keinen Einfluss darauf.

Dann würde ich eher darauf tippen, das Audacity noch ein Filter eingebaut hat, in deren Endergebnis die Musikdatei insgesamt ausgewogener klingt als bei Magix.

8Quibhirfd8 (Beitrag #6) schrieb:

die ein anderer vielleicht gar nicht hört, weil ihm die Hifi-Anlage dazu fehlt

Wie groß dein Schwanz ist, spielt bei dem Thema überhaupt keine Rolle. Das hatte shaboo eigentlich schon gesagt... NEIN! DOCH! OOH!!

8Quibhirfd8 (Beitrag #6) schrieb:

Dann würde ich eher darauf tippen, das Audacity noch ein Filter eingebaut hat, in deren Endergebnis die Musikdatei insgesamt ausgewogener klingt als bei Magix.

Niemals, Audacity hat offenen Quellcode, da wären sicher kontroverse Diskussionen bekannt, man kennt doch seine Pappenheimer...

Mich würde mal interessieren, was Du genau mit den Programmen machst. Nur rippen? wenn ja wie, mit welchen Einstellungen, Format, etc.

8Quibhirfd8 (Beitrag #3) schrieb:

...bis ich dann wieder Audacity genommen habe. Allerdings nicht zum Rippen, sondern zum Schneiden, was aber auch in diese Richtung geht.

Nach dem Schneiden findet immer eine Art Neucodierung statt in dem Format, in dem nach dem Schnitt gespeichert wird. Mit Bitgenauem Rippen kann man das nicht vergleichen.

Ich wüsste nicht wie Audacity bei Rippen die "Nullen" und "Einsen" veredeln sollte, damit sie in der gleichen Reihenfolge gespeichert einen klanglichen Effekt haben sollten (mathematischer Beweis: Abgleich mit AccurateRip-Datenbank). Treten beim Rippen Veränderungen der digitalen Daten auf, führt dieses nicht zu Klangveränderungen, sondern zu Wiedergabefehlern an solchen Stellen, da die Logik der Daten zerstört ist.
Klangveränderungen können somit nur durch einen gezielten Eingriff in die Datenstruktur erfolgen, die unmöglich das zufällige Ergebnis unterschiedlicher Qualität beim Rippen sein kann. Unterschiede ansonsten nur beim Abspielen in unterschiedlicher Konfiguration oder mit unterschiedlicher Technik auftreten.

Slati

Leben diese Zeitschriften nicht davon, dass die Leute "fehlinformiert" sind?
So wie Cosmopolitans Tipps um eine Beziehung zu verbessern das krasse Gegenteil bewirken, um so die Frauen weiterhin an das Käseblatt zu fesseln?

Meiner Erfahrung nach gibt es keine Unterschiede, und das wurde hier zur Genüge erklärt. (Vergleich der Checksum mit der aus der Accurip DB)

Der Grund eigentlich, wieso ich hier was schreibe: Was haltet ihr, im Bezug auf rippen und encoding zu flac, von FLACCL? Ausprobiert? Jemals davon gehört?
Ich persönlich nutze das Tool gerne. Wenn ich von der Einen auf die andere SSD einen Stoß an WAVs konvertiere, dauert das unter Umständen keine 8 oder 9 Sekunden pro CD. Dagegen sieht meine CPU aus, wie ein Spielzeugauto neben einem Panzer.

DEAF-RUSH (Beitrag #10) schrieb:

Was haltet ihr, im Bezug auf rippen und encoding zu flac, von FLACCL? Ausprobiert? Jemals davon gehört?

Nichts halte ich davon. Das hat aber nichts mit einem derartigen Programm zu tun (ich kenne es nicht), sondern schlichtweg damit, dass beim rippen das Auslesen der CD der geschwindigkeitsbestimmende Schritt ist. Das Auslesen eines Tracks mit einem optischem Laufwerk dauert um ein Vielfaches länger, als ihn hinterher umzuwandeln. Von daher ist selbst bei dem Standardencoder der Prozessor fast immer im Leerlauf und wartet, bis Daten nachkommen.

Von einem anderen Format nach Flac zu transkodieren trat bisher bei mir nur vereinzelt auf und ist für mich erstmal vernachlässigbar.

Aus diesem Grunde habe ich mir mal vor zig Jahren ein Kenwood 72x CD-ROM gekauft. Leider hat es das zeitliche gesegnet und gebraucht ist es nicht mehr zu bekommen...
Ist immer noch das schnellste CD-ROM, was je gebaut wurde, zu Zeiten als die Konkurenz noch mit 32x oder so rumgekrebst hat, was eigentliche heute noch standart ist (ok, 52fach)... Und das nicht erst ab mitte der CD, sondern schon früher, d. h. am Anfang einer CD hatte das schon 40fach, Standart heute: 16fach... Hatte nur ein Lebensdauerproblem

Das ist halt bei den aktuellen Preisen von knapp 15 € für ein Laufwerk nicht mehr drin, da mehrere Leseeinheiten reinzubauen...

Und über schnellere Rotation geht es nicht. Die Scheiben sind jetzt schon am Ende. Mir hat es mal bei 52x eine CD im Laufwerk zerlegt (hatte keine sichtbaren Schäden vorher). Ergebnis: CD kaputt, Laufwerk kaputt.

Jap, gibt's leider nicht mehr... Wobei, wenn Kenwood ein neues TrueX Laufwerk auflegen würde, nur vieleicht etwas haltbarer, würde ich dafür einen odentlichen Preis bezahlen... Muss nicht mal zwingend DVD oder BD können... Obwohl dann sicher der Absatz höher wäre, könnte sich schon fast lohnen...

Bin in der IT-Branche, habe schon viele "Rotationsopfer" gesehen

Aber wir sind abgedriftet

DEAF-RUSH (Beitrag #10) schrieb:

Der Grund eigentlich, wieso ich hier was schreibe: Was haltet ihr, im Bezug auf rippen und encoding zu flac, von FLACCL? Ausprobiert?

Die Idee ist super, ich bin nur skeptisch, was die 100% kompatibilität zur Referenz Implementierung vom FLAC Encoder angeht. Leider wird FLACCL nicht mehr weiter entwickelt, wenn ich das richtig sehe.

Wenn du eine halbwegs aktuelle CPU besitzt, kannst du auch eine der optimierten FLAC Encoder Versionen nehmen, die im Umlauf sind. Siehe z.B. hier: http://www.hydrogena...=869483&#entry869483
In dem Thread schreibt auch jemand, dass damit die Geschwindigkeit in vergleichbare Regionen von FLACCL rückt.

Ich selbst verwende nur die letzte offizielle Version, eben weil es mir viel mehr um Kompatibilität geht als um Geschwindigkeit.

Hab zwar null Ahnung, aber von meinem Verständnis her dürfte es da keine Probleme geben, was Kompatiblität angeht, weil für FLAC ja keine eventualitäten, Modi, Bitraten o. ä. unterschiedlich sein können. Ist halt einfach bitecht komprimiert, quasi (wenn auch andere Technik) wie ein Zip-File...

Ganz so einfach ist es leider nicht, FLAC hat da einige Stellschrauben und bietet deshalb auch so viel Potential zur Optimierung. Es gibt z.B. noch einen weiteren Encoder, Flake, der sogar vom gleichen Entwickler stammt wie FLACCL, wenn ich mich nicht täusche (aus dem CueTools Dunstkreis). Der bietet auf Wunsch noch höhere Kompressionsstufen als 8, nämlich bis zu 12. Technisch und laut Spezifikation ist das immer noch FLAC, das sich von allen standardkonformen Decodern mit genug Power auch dekodieren lässt. Es wurden aber immer wieder Probleme mit verschiedenen Playern berichtet. Im Zusammenhang mit FLACCL ist mir da konkret nichts bekannt, aber ich möchte bei meinen eigenen Rips da einfach kein Risiko eingehen.

Gehört habe ich von FLACCL auch schon, aber da ich nur mit CUETools direkt von CD rippe und in FLAC konvertiere und da da natürlich das Einlesen der CD und das Erstellen der Metadaten der Flaschenhals ist, habe ich nicht wirklich Verwendung dafür. Ansonsten nutze ich aus Kompatibilitätsgründen auch die libFLAC-Einstellung und verzichte da lieber auf irgendwelche Experimente. Generell sind heutige PCs so leistungsfähig und Massenspeicher so billig, dass ich eigentlich wenig Bedarf für etwas anderes als die Standard-Stufe-8-Komprimierung sehe, aber es ist natürlich trotzdem schön, wenn Leute weiter an FLAC herumbasteln und optimieren. Schließlich hoffe ich, dass es irgendwann vielleicht doch mal alle anderen Formate vom Markt fegen wird