Rippen, Taggen und Dateien schaufeln – wie mache ich das?

[Mister Cool]

Für mich ist die zentrale Frage, wie das Timing ruckelfrei schon auf das Speichermedium kommt, von dem dann ebenso ruckelfrei aus dem Rechner kommt. Da die CPU keinen jitterfreien Systemtakt bekommt, ist zu erwarten, dass auch hier sich Fehler einschleichen (allesamt auf der Zeitebene). Bleibt noch der Einfluss der Schnittstellen, wo das gespeicherte Dateiformat den Rechner konvertiert verlässt (getaktet oder asynchron)...

Hi,

ich bin nur ein gelernter Bergmann und kein Elektroniker oder Physiker, aber meine einfache Logik fragt nach dem Grund warum das Timing ("Ruckelfrei") schon beim Aufschreiben der Einser und Nuller auf das Speichermedium eine Rolle spielen sollte. Die "Qualität" der Einser/Nuller wird dadurch nicht anders. Hier denke ich auch an die Rip-Geschwindigkeit, die man je nach System/Tool von 1x bis 24x oder noch höher wählen kann. Also wo steckt die "Ruckelfreiheitinsformation" in den Rips? Hier denke ich auch and die Rips, die wir im Internet (z.B. über HDTracks oder andere Online Dienste) kaufen/downloaden/streamen.

Also meiner Meinung nach, in den Diskusionen darüber werden zwei Dinge vermischt/verwechselt:

- Ripvorgang und INFORMATIONSGEHALT einer geripten Datei (einfach eine besstimmte Folge von Einser und Nuller) -> ohne Einfluß auf die Wiedergabe und resistent auf das Ripping Tool (meine Anname -> egall womit gerippt wird, die Inhalte sind Bitgenau gleich)

- Auslesevorgang und Verarbeitung des informationsgehaltes, der sehr wohl durch das Timing sprich Jitter (und vielleicht wenn man darauf anlegt und in die Haarspalterei einsteigt, durch die Schwellwerte zwischen Digital Null oder Eins, oder Anfälligkeit der Übertragungstrecke, oder...) Einfluß auf den AUSLESEVORGANG und die VERARBEITUNG aber nicht auf die verarbeiteten, sprich auf die bereits gerippten INFORMATIONSINHALTE haben

Ich stelle mir das einfach vor. Es ist egal, ob ich eine Reihe von Einser nud Nulen mit einem Kugelschreiber oder Filzstifft in einem karierten oder linierten oder glatten Heft aufschreibe. Auch die grösse der Schrift und die Abstände der Nullen/Einser sind egal. Inhaltlich werden sie bombensicher hundertprozentig identisch. Das verstehe ich unter Rippen.

Aber es macht schon ein Unterschied, ob jetzt die Folge der Nullen und Einser eine Leserate vorliest, oder ein Legasteniker (der die zehnfache Zeit dafür braucht) oder ich, wenn ich schon wieder meine Brille vergessen habe und jede dritte Zahl erraten muß. Und das nenne ich Timing/Wiedergabe (die mit dem Rippen nichts zu tun haben).

Grüsse,
Alwin

[Hans-Martin]

Aber es macht schon ein Unterschied, ob jetzt die Folge der Nullen und Einser eine Leserate vorliest, oder ein Legasteniker (der die zehnfache Zeit dafür braucht) oder ich, wenn ich schon wieder meine Brille vergessen habe und jede dritte Zahl erraten muß. Und das nenne ich Timing/Wiedergabe (die mit dem Rippen nichts zu tun haben).

Grüsse,

Hallo Alwin,
also wenn der Legastheniker manche Partien schneller, andere fehlerbehaftet lies und nochmal wiederholt, dann ist die Kontinuität dahin. Und das Zuhören wird anstrengend.
Jetzt gibt es Pufferspeicher, die Daten sammeln, das Ruckeln ausgleichen, unsere gestiegenen Ansprüche sind aber höher als die Leistung der Hardware befriedigt.
Der Puffer darf nicht leerlaufen, aber auch nicht überlaufen, beides wird mit PLL geregelt. Sobald ein gewisser Füllungsgrad errreicht ist, wird gestoppt, sobald ein gewisser Entladezustand erreicht ist, wird wieder angefordert. First In First Out sagt sich so leicht, aber man solte die Rechnung nicht ohne den Kontrolleur machen.
Das Neutakten der Daten wird später auch per PLL geregelt, irgendwo zwischen PC und Abspielgerät. Einer digitalen PLL sagt man einen Jitterfilter von Faktor 100 nach, also auf 1% herunter, mehr ist nicht drin.
Wer zuviel idealisiert landet statt bei 1% bevorzugt bei einer glatten 0, stellt sich vor, dass beim Neutakten sämtliche Fehler auf einen Streich behoben werden. Das war m.E. bisher noch nicht der Fall, als Beispiel nenne ich gerne Fujaks kaskadierte Mutec MC-3+, wo 2, ja sogar 3 hintereinandergeschaltet weitere Steigerung brachten als nur 1 Gerät.
Wenn ich den Abspielvorgang so betrachtet habe, sehe ich auch beim Rippen zwischen Auslesen und auf das Speichermedium ablegen keinen großen Unterschied, auch hier gibt es Pufferspeicher, die ausgleichend zwischen den unterschiedlichen Geschwindigkeiten wirken.
Auch mein Brennprogramm hat Pufferspeicher, die mit Balkenanzeige optisch verdeutlichen, wie mehr und auch mal weniger Daten im Zwischenspeicher liegen.
Im Prinzip eines wie das andere.
Frankl hat mit seiner Software einen Teil des Systems überlistet. Wie er das genau macht , weiß ich leider nicht.
Dass es eine hörbare Verbesserung gibt, wurde mehrfach bestätigt. Es gibt also Unterschiede, wo man sich keine vorstellen kann.
Ob man eine gründliche Suche als Haarspalterei bezeichnen würde, bezweifle ich.
Grüße
Hans-Martin

[Dilbert]

Hallo Hans-Martin

bei normalen Dateien ist es vollkommen egal, wann die Daten zum Abspeichern angekommen sind, wichtig ist nur, daß die Reihenfolge genau eingehalten wird. Bei, aus Deiner Sicht, sicherlich vereinfachter Betrachtung, könnte ein Rippprozeß sogar unterbrochen werden, solange ich es schaffe die Reihenfolge wieder genau so zu organisieren, daß sie identische ist mit dem des Originals.
Wie gesagt, daß ist die vereinfachte Sichtweise, bei genauerer Betrachtung der in Wirklichkeit viel komplexeren Prozesse bei der Speicherung von Audiosignalen muß man annehmen, das ein Fluidum zwischen den Bits die Pausen speichert, die sich beim Ripvorgang ergeben haben. So können auch die Zeitinformationen des Rippvorgangs verlustfrei gespeichert werden. Ich gebe zu, das ist ein spannendes Thema, das weiterer Experimente bedarf.

Grüsse

Frank

[Mister Cool]

Hi,

Was ist das das Fluidum, und wo/in welcher Form ist die Information über die Pausen zwischen den Bits gespeichert?

Grüsse,
Alwin

[FraKtiv]

Dass es eine hörbare Verbesserung gibt, wurde mehrfach bestätigt. Es gibt also Unterschiede, wo man sich keine vorstellen kann.

Also ich war ja beim vergangenen Forumstreffen dabei, bei dem Frank das vorgeführt hat. Ich konnte einen leichten Unterschied hören.

Aber: das war es dann auch schon. Keiner weiß, warum - welche Ursachen der Grund für diese Unterschiede sind. (Und nach meinem Gefühl wollte das auch keiner wirklich wissen - ist halt so).

(Nur mal eine Theorie meinerseits auf die Schnelle: Frank hat die Daten auf dem USB-Stick mehrfach überschrieben. Ein SSD-Controller sorgt ja dafür, dass die Bits gleich verteil über alle Zellen des Mediums gespeichert werden (weil jede Zelle nur eine begrenzte Lebensdauer hat). Nun könnte ich mir vorstellen, dass das mehrfache Überschreiben zu einer komplexeren Verkettung der Speicherzellen führt, was wiederum zu einer längeren Auslesen der Zellen führt. Das wiederum könnte zu Timing-Fehlern führen, was wiederum die Unterschiede erklären ließe. Ist aber wie gesagt nur eine fixe Idee; ich bin halt Informatiker, kein Mikroelektrotechniker).

Wie dem auch sei; ich fände es schon spannend herauszufinden, warum. Mich würde alleine einmal der Unterschied im analogen Digitalsignal direkt vorm DAC interessieren. Aber vermutlich kann man das gar nicht so richtig messen, oder?

Viele Grüße,
Frank.

[Hans-Martin]

Was ist das das Fluidum, und wo/in welcher Form ist die Information über die Pausen zwischen den Bits gespeichert?

Moin,
für mich gibt es neben den Daten und dem Timing noch eine Größe "X", die sich aus vielerlei Komponenten unterschiedlichen Ursprungs zusammensetzen mag. Die vielen Beobachtungen sind wie Gleichungen, in denen das X vorkommt, darin liegt die Chance es einzukreisen, aber anders als in der Algebra fehlen uns hier verlässliche Skalierungen, um damit konkret rechnen zu können.
Noch 1986 schrieb STEREO (sinngemäß), man verzichte auf Klangbeschreibungen bei CD-Playern, weil die Digitaltechnik identischen Klang gewährleiste. Viele Erkenntnisse haben seither ein neues Bild ergeben.
Bei der Suche nach weiteren Verbesserungen sind Personen, die die Unterschiede für geringfügig bis bedeutungslos halten, eher weniger hilfreich.
Grüsse,
Hans-Martin

[Mister Cool]

Auch mein Brennprogramm hat Pufferspeicher, die mit Balkenanzeige optisch verdeutlichen, wie mehr und auch mal weniger Daten im Zwischenspeicher liegen.
Im Prinzip eines wie das andere.

Hi,

für mich ist es definitiv nicht „vom Prinzip eines wie das gleiche“. Die ganzen Ausführungen und Beispiele beantworten nicht mal ansatzweise, wo und wie die bechaupteten Unterschiede, die aus unterschiedlicher Pufferung, oder Riptechnik oder Anzahl der kaskadierten Reclocker oder was auch immer, letztendlich in dem Endprodukt, sprich in einer FLAC, WAV, AIFF, ALAC,... Datei kodiert/gespeichert werden. Denn nur wenn die Information darüber in dem (wie es hier so schön von Frank genannt Wurde) Fluidum vorhanden ist, kann sie zu Differenzierung benutzt werden. Wie soll man Unterschiede erkennen, wenn es dafür keine Differenzierungsmerkmale gibt?

Grüsse,
Alwin

[Hans-Martin]

Wie soll man Unterschiede erkennen, wenn es dafür keine Differenzierungsmerkmale gibt?

Alwin,
wer die Unterschiede im Klangvergleich nicht wahrnimmt, braucht darüber auch nicht nachzudenken.
Wer sie hört, stößte in der Diskussion auf Zweifler, Spekulanten, Nichttechniker mit Ohren, technische Vereinfacher und Ungläubige, die es nicht selbst gehört haben, etc, eine Gemengelage, deren konstruktive Beiträge so ausgeprägt sind wie die wahrgenommenen Effekte.
Grüsse,
Hans-Martin

PS.
viewtopic.php?p=68644#p68644

[Dilbert]

Tja, es ist ja auch schon hanebüchend, was den armen unschuldigen Bits da angetan wird auf dem Weg von CD-Laufwerk bis hin zur Festplatte. Immer wieder in dunkle Puffer-Keller geworfen. von bösartigen Controllern in eine Reihe aufgestellt und in dunkle Röhren gepresst. Dabei häufig den Kontakt mit den jeweiligen Nachbarbits verloren. Wenn sie dann letztendlich auf der Festplatte landen, dann sind das einfach nicht mehr die unschuldigen Bits, als die man sie von der CD kannte, die schlimmen Erfahrungen haben tiefe Spuren in den Bits hinterlassen. Und deshalb hört man auch, ob das System vorsichtig mit den armen Bits umgegangen ist, oder einfach nur brutal und effizient gehandelt hat.

Grüsse

Frank

[Hans-Martin]

Ich habe unterschiedlich gerippte Musik anhand des Klangs unterscheiden können, diese auf meine Homepage hochgeladen und wieder heruntergeladen. Danach konnte ich keine Unterschiede mehr ausmachen, sie klangen aber auch nicht mehr so prägnant wie von der ersten Speicherung, dagegen irgendwie etwas weichgespült.
Ich traue deshalb dem Internetstreaming nicht, wenn es um bestmögliche Qualität gehen soll.
Das meint natürlich nicht HighResolution gegen 44/16 oder gar mp3.
Die Unterschiede von WAV und FLAC lassen sich auch hören (wenn sie on the fly umgerechnet werden), obwohl der Rechner keinen Unterschied feststellen kann, das Ohr scheint da noch Unterschiede auflösen zu können, die ein reiner Quersummenvergleich nicht hergibt.
Grüße
Hans-Martin

[Dilbert]

Hallo Hans-Martin

nachdem ich nochmal ein paar Fäden nachgelesen habe, die sich im weitesten Sinne mit Klangunterschieden bei bitidentischen Audio-Dateien beschäftigen, denke ich, daß du da einer ganz grossen Sache auf die Spur gekommen bist.

Was ich noch so unspezifisch als Fluidum bezeichnet habe, würde ich jetzt als Emotional-Lotion bezeichnen. Es scheint so, das es einigen Programmieren z.B. von jPlay oder HQ-Player gelungen ist, diese Emotional-Lotion zu lesen, zu interpretieren und den Informationsgehalt dem Musikstream hinzuzufügen. Das erklärt auch die eklatanten Unterschiede bei Software-Playern und warum rein technische Player wie Foobar-2K einfach nicht die Emotionen in der Musik rüberbringen, sondern technisch kühl klingen und flach klingen.

Und es würde auch erklären, warum Deine Musikfiles nach der Speicherung in der Cloud anders klingen, als vorher. Der Wechsel von der heimischen, familiären Festplatte zu einem anonymen unpersönlichen Storage-system mit Billionen von Bits führt zu Depressioen bei deinen armen Bits. Das spiegelt sich in der Emotional-Lotion und kann auch ausgewertet werden. Natürlich ist das nicht so eindeutig wie bei binären Signalen, und somit klingen auch die Software-Player, die die Emotional-Lotion lesen können, bei genauerem hinhören und auf einer adäquaten Kette nicht gleich.

Es versteht sich von selbst das die Emotional-Lotion von Standard-SW, insbesondere von auf binär-Ebene arbeiteten Tools, nicht mal erkannt wird.

Grüsse

Dilbert

[Thor_7]

Der gute alte AH-Humor

[FST]

Hallo,

ich hole diesen Thread mal wieder wegen folgender Frage hoch, die mich beschäftigt. Ich rippe mit dBpoweramp auf eine SSD. Bis dato habe ich in den Einstellungen von dBpoweramp unter Bit Depth und Sampel Rate jeweils [as source] ausgewählt. Die Wiedergabe läuft bei mir derzeit über HQ-Player und Roon. Dort gebe ich in 176,4 wieder.

Macht es Sinn schon beim Rippen die Bit Depth und Sampel Rate anzupassen, sodass der Rechner nachher weniger zu tun hat?

Grüße
Fabian

[Melomane]

Hallo Fabian,

ich selber habe das nie getestet. Im Bekanntenkreis stellte sich bei einem Vergleich von Samplerateconvertern der von DBPoweramp als nicht so gelungen heraus. Allerdings weiß ich nicht, ob sich das bei aktuellen Versionen vielleicht anders darstellt.

Also: Versuch macht kluch.

Viele Grüße

Jochen

[Buschel]

Halo Fabian,

Macht es Sinn schon beim Rippen die Bit Depth und Sampel Rate anzupassen, sodass der Rechner nachher weniger zu tun hat?

Aus meiner Sicht würde ich immer in der originalen Bittiefe und Samplerate rippen. So liegen die Daten auf dem Medium vor. Anschließend kannst du diese Originaldaten je nach Gusto und verfügbaren Tools weiterverarbeiten.

Die Weiterverarbeitung kann dann entweder "offline" (also vorab) erfolgen, so dass eine zweiter Datensatz entsteht. Oder die Verarbeitung findet "online" (also in Echtzeit während der Wiedergabe) statt. Vorteil der Vorab-Verarbeitung ist, dass der Rechner weniger stark beansprucht wird. Nachteile sind der höhere Speicherverbrauch auf dem Festspeicher und die geringere Flexibilität, falls man die Verarbeitung z.B. auf eine andere Samplingrate ändern möchte. In diesem Fall müssen alle Titel noch einmal vorab prozessiert werden.

Ich persönlich verwende "offline"-Vorverarbeitung nur für HDCDs und CDs mit pre-emphasis, wobei ich immer noch die Originaldaten als Backup behalte. Alle anderen Schritte wie Raumkorrektur, Samplingratenanpassung und Dither laufen in Echtzeit. Damit verschwende ich keinen Festspeicher und bleibe flexibel bei Anpassungen (ich spiele ja gerne mit Parametern und Tools).

Viele Grüße,
Andree