Allg. Gelaber zu Jitter etc.! Früher: cplay und cmp = cmp²

Um jetzt mal die Missinterpretation eines gewissen Users und DMA aufzuklären :

Zwischen Mainboard und Festplatte sorgt die IDE-Schnittstelle für die reibungslose Datenübertragung. In diesem Zusammenhang sind zwei Begriffe von Bedeutung: PIO und UltraDMA. Die ATA-Spezifikationen beschreiben diese Grundfunktionen sehr ausführlich, sind jedoch schwer nachvollziehbar. Daher haben wir hier die wichtigsten Punkte kurz und verständlich zusammengefasst.
Der PIO-Mode steht für programmierte Ein- und Ausgabe und UltraDMA-Mode für schnellen direkten Speicherzugriff. Der entscheidende Faktor zwischen den beiden Übertragungsmodi ist die Geschwindigkeit.
Beim PIO-Mode steuert die CPU alle Datenzugriffe über die Schnittstelle. Im UltraDMA-Modus dagegen erfolgt die Datenübertragung direkt in den Systemspeicher. Die CPU fungiert lediglich als Initiator vor jedem Datentransfer. Aus diesem Grund musste man für den UltraDMA-Modus ein eigenes Übertragungsprotokoll mit neuen Leitungsbezeichnungen einführen.

Die Initialisierungsphase für die die CPU verantwortlich ist beginnt, indem das Gerät vom Host durch Setzen des Signals DMARQ einen UltraDMA-Lesezugriff anfordert. Kurz darauf muss #DIOW und #DIOR auf High, CS0, CS1 und DA(2:0) auf Low gehen. Erwidert jetzt der Host den Lesezugriff mit dem Setzen der #DMACK-Leitung, ändern sich die Bezeichnung und die Bedeutung einiger Leitungen. Nach einer Umschaltzeit von 20 bis maximal 55 ns wechseln die neu bezeichneten Signalleitungen STOP und #HDMARDY ihren Zustand. Nach maximal 90 ns (Mode 5) wird die DSTROBE-Leitung auf Low gelegt. Mit diesem Vorgang werden die ersten gültigen Daten vom Host eingelesen. Die Initialisierungsphase ist damit abgeschlossen, der UltraDMA-Data-In-Burst beginnt.

Eine wichtige Neuerung ist mit Einführung der UltraDMA-Modi 0 bis 5 hinzugekommen. Am Ende eines jeden UltraDMA-Bursts wird eine Fehlererkennung des übertragenen Datenstroms durchgeführt. Durch diese CRC-Prüfsumme erhöht sich die Sicherheit der Datenübertragung enorm. Der Host sowie das Gerät berechnen nach einem im ATA-4 festgelegten Algorithmus (G(X)=X16+X12+X5+1) die CRC-Prüfsumme.

Fazit :

Wie kommt man denn nun zu dem Schluss, auf cMP² bezogen dass die CPU irrelevant wäre ? Die CPU ist der Anfang, der Initiator und somit ist es schon wichtig dass sie diesen Job so gut wie möglich macht um kleine fehler die ansonsten anhand eines festgelgten Algorythmus wieder korrigiert werden müssten zu vermeiden. Das abschalten zusätzlicher Windowsdienste die die Arbeit der CPU möglicherweise beeinflussen ist also sinnvoll.

j!more schrieb:

By the way: Betreibst Du die DAC-Chips "nackt"? Dein Profil lässt das vermuten. :?

Wie schließt Du von meinem Profil darauf, dass ich DACs nackt betreibe? Da steht bei Hobbies doch nichts von FKK oder Sauna?

Fidelity_Castro schrieb:

Wie kommt man denn nun zu dem Schluss, auf cMP² bezogen dass die CPU irrelevant wäre ? Die CPU ist der Anfang, der Initiator und somit ist es schon wichtig dass sie diesen Job so gut wie möglich macht um kleine fehler die ansonsten anhand eines festgelgten Algorythmus wieder korrigiert werden müssten zu vermeiden. Das abschalten zusätzlicher Windowsdienste die die Arbeit der CPU möglicherweise beeinflussen ist also sinnvoll.

Jetzt sag bitte bitte bitte, das du das nicht ernst meinst.

Fidelity_Castro schrieb:

In diesem Zusammenhang waren vor einigen Jahren zwei Begriffe von Bedeutung: PIO und UltraDMA.

Fixed.

ZeeeM schrieb:

Jetzt sag bitte bitte bitte, das du das nicht ernst meinst.

Natürlich meine ich das toternst, oder meinst du diejenigen die sich den ( vermutlich groben ) CRC Algorythmus zur Korrektur ausgedacht haben haben auch nur im geringsten auf Audiophile feinheiten geachtet ?

Eigentlich ging es mir nur darum zu beweisen dass die CPU nicht so unwichtig ist wie es von den Zweiflern hier propagiert wird. Das was zwischen 1 und 0 passiert, aslso Jitter kann ganz einfach vom Algorythmus nicht beachtet werden und wird somit durchgereicht. Deswegen sollte man ganz am Anfang dafür sorgen dass er garnicht erst ensteht.

Lotion schrieb:

j!more schrieb: By the way: Betreibst Du die DAC-Chips "nackt"? Dein Profil lässt das vermuten. :? Wie schließt Du von meinem Profil darauf, dass ich DACs nackt betreibe? Da steht bei Hobbies doch nichts von FKK oder Sauna? :?

Da steht: "DAC: PCM1793 und TDA1543"

Beides "nackte" DAC-Chips. Die nehmen so weder digitale Signale an noch geben sie analoge wieder. Ohne Strom und a bisserl Peripherie machen die gar nichts. Du verstehst was ich meine?

Fidelity_Castro schrieb:

Wie kommt man denn nun zu dem Schluss, auf cMP² bezogen dass die CPU irrelevant wäre ? Die CPU ist der Anfang, der Initiator und somit ist es schon wichtig dass sie diesen Job so gut wie möglich macht um kleine fehler die ansonsten anhand eines festgelgten Algorythmus wieder korrigiert werden müssten zu vermeiden. Das abschalten zusätzlicher Windowsdienste die die Arbeit der CPU möglicherweise beeinflussen ist also sinnvoll.

Bei der Audiowiedergabe muss man eher aufpassen, dass sich die CPU nicht zu Tode langweilt und schlafen legt. Da ab und zu "mach mal" (Initiator) zu sagen, ist keine echte Herausforderung.

Ich höre ja schon seit einiger Zeit Musik nur noch über den PC, mittlerweile ist schon die dritte Generation an Hardware im Musik PC und Hauptrechner verbaut.

Je schneller die Kisten wurden, desto problemloser klappte die Wiedergabe, das BS, die Abspielsoftware und auch Asio4All wurden dabei immer übernommen.
Aussetzer und Knackser verschwanden nach und nach völlig, ev. hat sich auch der Klang des Aqvox verbessert, darauf pochen möchte ich allerdings nicht.

Das Gehör kann einem oft einen üblen Streich spielen, bin deshalb sehr vorsichtig mit solchen Festlegungen geworden.

Also ist der Sinn von cmp2 den Computer soweit runterzutakten, das die CPU beim Übertragen von hochwertigen Audiodaten voll ausgelastet ist und nix anderes tut bzw. sich ggfs sogar noch schlafen legt?

Sorry, fidelity aber das meiste, was Du in diesem Thread bisher gepostet hast, is voll Pfosten. Du hast keine Ahnung von Digital Technik Computer etc. und weist eigentlich nicht was Du da machst.

Grüße

NX4U schrieb:

Also ist der Sinn von cmp2 den Computer soweit runterzutakten, das die CPU beim Übertragen von hochwertigen Audiodaten voll ausgelastet ist und nix anderes tut bzw. sich ggfs sogar noch schlafen legt?

Irgendwie widersprichst du dir, ne vollausgelastete CPU die sich schlafen legt... das ist vollpfosten...

Sorry, fidelity aber das meiste, was Du in diesem Thread bisher gepostet hast, is voll Pfosten. Du hast keine Ahnung von Digital Technik Computer etc. und weist eigentlich nicht was Du da machst. Grüße

Na hauptsache du weißt was du machst, einen Beweis dafür dass cMP nix bringt ist hier immernoch jeder der so groß rumtönt wie du schuldig geblieben, keiner von euch hat es jemals wirklich ausprobiert und stützt sich nur darauf dass es aus Prinzip nichts bringen kann. Würdest du dich mit Digitaltechnik so gut auskennen hättest du sowieso wichtigeres zu tun als hier zu posten...

Außerdem muss man auch nicht alles wissen um Spass mit Computern zu haben, dass ich einen PC nach bedarf zusammenbauen, konfigurieren und absolut lautlos bekommen kann reicht mir vollkommen aus. Jeder der will kann im nullkomma nix auf den Wissenstsand kommen um euch Klugscheißer in Grund und Boden zu reden.

Fidelity_Castro schrieb:

NX4U schrieb: Also ist der Sinn von cmp2 den Computer soweit runterzutakten, das die CPU beim Übertragen von hochwertigen Audiodaten voll ausgelastet ist und nix anderes tut bzw. sich ggfs sogar noch schlafen legt? Irgendwie widersprichst du dir, ne vollausgelastete CPU die sich schlafen legt... das ist vollpfosten...

Der Satzbau ist von mir bestimmt nicht perfekt gewählt, aber wenn Du ein wenig drüber nachdenkst kommste auch drauf.

Fidelity_Castro schrieb:

...einen Beweis dafür dass cMP nix bringt ist hier immernoch jeder der so groß rumtönt wie du schuldig geblieben...

Aja, umgekehrt wird doch wohl eher ein Schuh draus. Beweis mir das es Software induzierten Jitter gibt und wie er ggfs. das Abspielergebnis beeinflusst.

Fidelity_Castro schrieb:

Würdest du dich mit Digitaltechnik so gut auskennen hättest du sowieso wichtigeres zu tun als hier zu posten...

Du wirst es nicht glauben, ich bin so gut in meinem Job, das ich hier den ganzen Tag posten kann.

Fidelity_Castro schrieb:

Jeder der will kann im nullkomma nix auf den Wissenstsand kommen um euch Klugscheißer in Grund und Boden zu reden.

Das hast Du bisher aber noch nicht bewiesen.

Fidelity_Castro schrieb:

Eigentlich ging es mir nur darum zu beweisen dass die CPU nicht so unwichtig ist wie es von den Zweiflern hier propagiert wird. Das was zwischen 1 und 0 passiert, aslso Jitter kann ganz einfach vom Algorythmus nicht beachtet werden und wird somit durchgereicht. Deswegen sollte man ganz am Anfang dafür sorgen dass er garnicht erst ensteht. :P

AUWEIA!!!!!

Mein Kommentar dazu.....

j!more schrieb:

Bei der Audiowiedergabe muss man eher aufpassen, dass sich die CPU nicht zu Tode langweilt und schlafen legt. Da ab und zu "mach mal" (Initiator) zu sagen, ist keine echte Herausforderung.

Die muss das doch auf wenige Picosekunden genau machen, sonst gehen die Vorhänge zu, die Füße hören auf zu wippen und die Ehefrau/Freundin bleibt in der Küche.
Da kann man sich gleich Twisterstops auf die Northbridge kleben.

NX4U schrieb:

Der Satzbau ist von mir bestimmt nicht perfekt gewählt, aber wenn Du ein wenig drüber nachdenkst kommste auch drauf.

Hättest du dich auch nur ein bisschen mit cMP² befasst wüsstest du das ein auf 1ghz underclockte und auf 0,8v undervolteter core 2 duo beim upsampling ca. zu 60% ausgelastet ist. Von daher ist das was du geschrieben hast eh irrelevant.

Aja, umgekehrt wird doch wohl eher ein Schuh draus. Beweis mir das es Software induzierten Jitter gibt und wie er ggfs. das Abspielergebnis beeinflusst.

Habs zwar schonma gepostet... http://www.cicsmemoryplayer.com/index.php?n=CMP.03Jitter

Jetzt beweis du dass er im unrecht ist. Oder haste Schiss ?

Du wirst es nicht glauben, ich bin so gut in meinem Job, das ich hier den ganzen Tag posten kann.

Das hast Du bisher aber noch nicht bewiesen.

Man iesst sich entweder Cics ausführungen durch oder diese. Ich könnte dort einfach Zeilen rauskopieren aber irgendwie ist es den Zeitaufwand nicht wert da dann wieder das Totschlagargument von den Holzköpfen kommt dass derjenige der den Artikel verfasst hat eh keine Ahnung hat und so geht es immer weiter...

Fidelity_Castro schrieb:

Hättest du dich auch nur ein bisschen mit cMP² befasst wüsstest du das ein auf 1ghz underclockte und auf 0,8v undervolteter core 2 duo beim upsampling ca. zu 60% ausgelastet ist. Von daher ist das was du geschrieben hast eh irrelevant.

Ich hatte das vorhin spasseshalber mal mit jriver probiert: Musik mit Upsampling auf 96kHz (weil mein X2 keine 192kHz verarbeitet) lastet bei mir die core2duo CPU zwischen 40 und 15 bis 20 Prozent aus - 40 zum Start, 15 bis 20 dann beim Abspielen.

Die CPU bekommt dabei 0,950 Volt und läuft mit 850 bis 1000 MHz. Das alles ohne "Undervolten", sondern im Rahmen der Intel-Spezifikationen. Bei zu wenig Stoff kann sich so eine CPU nämlich schon mal vertun.

Edit: Auslastung im Betrieb korrigiert.

Fidelity_Castro schrieb:

Das hast Du bisher aber noch nicht bewiesen. Man iesst sich entweder Cics ausführungen durch oder diese. Ich könnte dort einfach Zeilen rauskopieren aber irgendwie ist es den Zeitaufwand nicht wert da dann wieder das Totschlagargument von den Holzköpfen kommt dass derjenige der den Artike aberl verfasst hat eh keine Ahnung hat und so geht es immer weiter... :KR

Ne ist schon richtig so was das steht.

Das du den Link hier geschrieben hast zeigt nur das du

a) die Beiträgen hier auf den letzten paar Seiten garnicht gelesen hast
oder
b) du ein ganz schlechtes Gedächtnis hast
oder
c) du nix davon verstanden hast was ich und einige andere hier so geschrieben haben



EDIT: mir wird das hier langsam zu blöd hier, ich werd nicht mehr weiter lesen. euch noch viel spaß ^^

Fidelity_Castro schrieb:

Hättest du dich auch nur ein bisschen mit cMP² befasst wüsstest du das ein auf 1ghz underclockte und auf 0,8v undervolteter core 2 duo beim upsampling ca. zu 60% ausgelastet ist. Von daher ist das was du geschrieben hast eh irrelevant.

Lies dochmal Post 360, dann mein Post 362, beachte das und komm aus der Schmollecke. Dann bekommst Du das von mir geschenkt:
<<>>/eeiiiinnoorr (Komplettbausatz Ironie-Tags)

Fidelity_Castro schrieb:

Habs zwar schonma gepostet... http://www.cicsmemoryplayer.com/index.php?n=CMP.03Jitter Jetzt beweis du dass er im unrecht ist. Oder haste Schiss ?

Kindergarten!
Hier wurde schon soviel zum Thema gepostet, such Dir was raus. Es gibt keinen Software induzierten Jitter. Der Jitter der Datenübertragung ist nicht relevant z.B. bei isochroner Übertragung in den Eingangspuffer des DAC. Nur der Jitter beim D/A-Wandler (und dessen Clock) interessiert und dort greifen, je nach verwendetem Gerät, diverse Gegenmassnahmen. Und und und
Allgemeingültig belegbar:
http://de.wikipedia....#Isochroner_Transfer
http://de.wikipedia.org/wiki/Jitter
http://de.wikipedia.org/wiki/Digitales_Signal

Zeig mir einen relevanten Beitrag ausserhalb von cmp2 in dem von Software Induced Jitter gesprochen wird.

j!more schrieb:

Lotion schrieb: j!more schrieb: By the way: Betreibst Du die DAC-Chips "nackt"? Dein Profil lässt das vermuten. :? Wie schließt Du von meinem Profil darauf, dass ich DACs nackt betreibe? Da steht bei Hobbies doch nichts von FKK oder Sauna? :? Da steht: "DAC: PCM1793 und TDA1543" Beides "nackte" DAC-Chips. Die nehmen so weder digitale Signale an noch geben sie analoge wieder. Ohne Strom und a bisserl Peripherie machen die gar nichts. Du verstehst was ich meine?

Profil angepasst!

Ich weiss nicht, ob das hier schon mal erwähnt wurde, aber Norton Internet Security mag cicsmemoryplayer.com nicht:

Norton Safe Web hat cicsmemoryplayer.com auf Sicherheit und Sicherheitsprobleme analysiert. Unten sehen Sie ein Beispiel der gefundenen Bedrohungen. cicsmemoryplayer.com Bedrohungsbericht Gesamtzahl gefundener Bedrohungen: 2 Small-whitebg-red Viren (Was ist das?) Gefundene Bedrohungen: 2 Hier ist eine vollständige Liste: Name der Bedrohung: Trojan Horse Adresse: http://cicsmemorypla..._1_2_final_setup.exe Name der Bedrohung: Trojan Horse Adresse: http://www.cicsmemor..._1_2_final_setup.exe

Ich würde das zwar nicht allzu ernst nehmen, aber irritierend ist das schon.

j!more schrieb:

Ich würde das zwar nicht allzu ernst nehmen, aber irritierend ist das schon.

Das liegt daran, das Norton da eine Behaviourengine hat, die fälschlicherweise anspringt.
Zumindestens auf einem audiophilen Rechner hat ein Virenscanner aus klanglicher Sicht nichts zu suchen.

Diese Nachricht wurde automatisch erstellt!

Das Thema wurde aufgeteilt und einige themenfremde Beiträge wurden verschoben. Das neue Thema lautet: "Keine objektive Moderation?"

Ich denke wir haben hier endlich den herbeigewünschten Nachweis des datenindzuierten Jitters: er steckt im Trojanischen Pferd ...

Hearmaster schrieb:

Zumindestens auf einem audiophilen Rechner hat ein Virenscanner aus klanglicher Sicht nichts zu suchen.

Weil Viren dem Klang weniger schaden als ein Virenscanner? Das ist unverantwortlicher Blödsinn. Nicht nur wegen der Gefahren für das eigene System, sondern auch wegen der dadurch entstehenden neuen Übertragungswege.

j!more schrieb:

Hearmaster schrieb: Zumindestens auf einem audiophilen Rechner hat ein Virenscanner aus klanglicher Sicht nichts zu suchen. Weil Viren dem Klang weniger schaden als ein Virenscanner? Das ist unverantwortlicher Blödsinn. Nicht nur wegen der Gefahren für das eigene System, sondern auch wegen der dadurch entstehenden neuen Übertragungswege.

Naja, wenn man aus "audiophilen" Gründen die Rechenleistung des Rechners soweit beschneidet, das sie mit dem Abspielen fast voll ausgelastet ist, dann mag das schon sein.

Ich frage mich gerade, warum man bei cmp/cplay auf Windows setzt und nicht eine passende Linuxdistribution angepasst hat.
Das man sich nicht mehr in den Quellcode schauen lassen will, das ist auch schon bemerkenswert.

Wenn man den Abspiel-Rechner offline betreibt und die Daten die draufkommen vorher gecheckt wurden, warum nicht?
Es kommt immer auf das Konstrukt an.

Ich persönlich würde es nicht machen, da ich nichts davon halte den Rechner so zu kastrieren und auf die Annehmlichkeiten zu verzichten.

Grüße

@Zeem

Ja, ist schon komisch für ein Open Source Projekt. Das Linux oder BSD für so ein Projekt sinnvoller wären, hatte ich ja auch schon erwähnt.
Bisher hab ich mich unter Linux noch nicht für einen Player entscheiden können, verwende zumeist SW die auf allen Systemen vorhanden ist (MacOS, Win, Linux=VLC, XBMC etc.)

Grüße

NX4U schrieb:

Wenn man den Abspiel-Rechner offline betreibt und die Daten die draufkommen vorher gecheckt wurden, warum nicht? Es kommt immer auf das Konstrukt an.

Einverstanden. Ich kann mir in diesen Tagen allerdings kein realistisches Konstrukt mehr vorstellen, in dem ein Rechner konsequent offline betrieben würde.

j!more schrieb:

Einverstanden. Ich kann mir in diesen Tagen allerdings kein realistisches Konstrukt mehr vorstellen, in dem ein Rechner konsequent offline betrieben würde.

Die meisten CD Player hängen ja auch nicht am Netz. Ich packe auch nur die wirklich guten Aufnahmen als Flac oder .wav auf den cMP pc. Der Rest wird eh in Mp3 vbr umgewandelt und weiterhin vom HTPC abgespielt. Die meisten die sich nen cmp pc bauen haben ehmehrere Rechner in Betrieb.

Hearmaster schrieb:

Zumindestens auf einem audiophilen Rechner hat ein Virenscanner aus klanglicher Sicht nichts zu suchen.

Langsam ist zu befürchten, dass dir deine wunderhübsche Reinsilber-Feinsicherung durchgebrannt ist. Das, was du hier bisher abgesondert hast, ist so unfassbar hanebüchener Bullshit ohne jegliche Substanz, dass ich es nicht verstehen kann, dass die Moderation nicht endlich auch inhaltlich aktiv wird. Man stelle sich nur mal vor, es kommt ein unbedarfter Newbie, führt sich diesen Thread zu Gemüte und glaubt auch noch, was er hier liest. Ich bin endgültig raus hier, werde auch versuchen mich mit Einzeilern zurückzuhalten.

Fidelity_Castro schrieb:

Die meisten CD Player hängen ja auch nicht am Netz.

Das ist natürlich ein Argument!

Fidelity_Castro schrieb:

Ich packe auch nur die wirklich guten Aufnahmen als Flac oder .wav auf den cMP pc. Der Rest wird eh in Mp3 vbr umgewandelt und weiterhin vom HTPC abgespielt.

Du vermeidest die Ansteckung quasi durch Enthaltsamkeit. Kann man natürlich auch so machen.

Fidelity_Castro schrieb:

Die meisten die sich nen cmp pc bauen haben ehmehrere Rechner in Betrieb.

Und das sagt uns bezüglich der Viren was?

j!more schrieb:

Das ist natürlich ein Argument!

Fidelity_Castro schrieb:

Du vermeidest die Ansteckung quasi durch Enthaltsamkeit. Kann man natürlich auch so machen.

Es wird von cics empfohlen den cmp Rechner nicht ans Netz zu hängen bzw. braucht man dann natürlich auch keinen Virenscanner. Das sind eben Punkte die man im vorfeld beachten sollte bevor man so ein Ding plant zu bauen. Es ist nicht für jedermann geeignet da es ein Konzept ist und nicht nur irgend ein Player den man sich mal eben schnell installiert. Dafür gibt´s ja Foobar und Konsorten.

Ich kann die Einwände von fe-lixx auch nicht nachvollziehen,sollen denn hier im Forum wirklich ausschließlich Einsteigerkompatible Lösungen diskutiert werden und nichts für Enthusiasten ?

Und das sagt uns bezüglich der Viren was?

Ich wollte eigentlich nur damit sagen dass man für online Inhalte dann eben seinen anderen Multimedia Rehner einsetzt. Solange man weiß wasman tut hat man mit Viren keine Probleme.

Fidelity_Castro schrieb:

...sollen denn hier im Forum wirklich ausschließlich Einsteigerkompatible Lösungen diskutiert werden und nichts für Enthusiasten ?

Natürlich nicht, aber mache Lösungen und Vorschläge sollten dann eindeutig gekennzeichnet werden. Etwa so:

Fidelity_Castro schrieb:

Solange man weiß wasman tut hat man mit Viren keine Probleme.

Genau das ist das Problem: Nicht jeder weiss, was er tut.

j!more schrieb:

Genau das ist das Problem: Nicht jeder weiss, was er tut.

Und nicht jeder der meint zu wissen, was er tut, weiss wirklich was er tut. Meine Erfahrung aus 20 Jahren IT.

ZeeeM schrieb:

Und nicht jeder der meint zu wissen, was er tut, weiss wirklich was er tut. Meine Erfahrung aus 20 Jahren IT.

Schlimmer ist, dass sie sich nicht erinnern, was sie getan haben, wenn sie etwas getan haben. Oder Fehlermeldungen routiniert wegklicken.

j!more schrieb:

ZeeeM schrieb: Und nicht jeder der meint zu wissen, was er tut, weiss wirklich was er tut. Meine Erfahrung aus 20 Jahren IT. Schlimmer ist, dass sie sich nicht erinnern, was sie getan haben, wenn sie etwas getan haben. Oder Fehlermeldungen routiniert wegklicken.

Überall die selben Erfahrungen. Wie schön, ich bin nicht allein!

Fidelity_Castro schrieb:

Natürlich meine ich das toternst, oder meinst du diejenigen die sich den ( vermutlich groben ) CRC Algorythmus zur Korrektur ausgedacht haben haben auch nur im geringsten auf Audiophile feinheiten geachtet ? :D

Warum erinnert mich das so an Pippi Langstrumpf:

2 x 3 macht 4 Widdewiddewitt und Drei macht Neune !! Ich mach' mir die Welt Widdewidde wie sie mir gefällt ....

Nur dumm, dass die Hai-Ender das auch noch ernst meinen...

Tach,

Fidelity_Castro schrieb:

ZeeeM schrieb: Jetzt sag bitte bitte bitte, das du das nicht ernst meinst. Natürlich meine ich das toternst, oder meinst du diejenigen die sich den ( vermutlich groben ) CRC Algorythmus zur Korrektur ausgedacht haben haben auch nur im geringsten auf Audiophile feinheiten geachtet ? Eigentlich ging es mir nur darum zu beweisen dass die CPU nicht so unwichtig ist wie es von den Zweiflern hier propagiert wird. Das was zwischen 1 und 0 passiert, aslso Jitter kann ganz einfach vom Algorythmus nicht beachtet werden und wird somit durchgereicht. Deswegen sollte man ganz am Anfang dafür sorgen dass er garnicht erst ensteht. :P

das hat mir wenig Ruhe gelassen also hab ich mal ausserhalb vom Wiki (böse Bücher, son fiesen Mathekram den die Geheimniskrämer sich ausdenken sollte man nicht unvorbereitet angucken, wobei CRC vergleichsweise harmlos ist) nach dem CRC Algorithmus geguckt, da gibts schlichtweg keinen Raum für sonstwie grobes Arbeiten, im Gegenteil das ganze ist so einfach genial das es für Fehler kaum Raum gibt und bei Fehlern kann man natürlich die Daten neu anfordern, ausser man arbeitet am Rand der Übertragungsrate in einem zeitkritischen Prozess.

Zum Beispiel highspeed Kameras mit hoher Auflösung und Bildverarbeitung hintendran, die bringen dann schonmal nen pcie Bus zum schwitzen.

Aber es wird viel besser, angenommen der proklamierte Jitter würde den Klang verändern, dann müsste er eigentlich auch die CRC Summe ändern was (bis auf in sehr unwahrscheinlichen Einzelfällen) zu einer falschen Prüfsumme, damit fehlerhafter Datenübertragung führt und Neuanforderung derselben!
Zumindest gilt das solange die Daten im PC sind, am DA Wandler passieren dann andere Dinge. edit: Statt DA Wandler eigentlich Soundkarte.

Fazit: Der Jitter müsste den Inhalt der Daten selbst vor oder nach der Weitergabe an den Bus verändern oder ein PC kann unmöglich Musik und ähnliche Daten abspielen, letzteres ist nicht der Fall.

Geschützter Hinweis (zum Lesen markieren): Vorausgesetzt die Doors spielen nicht nur in meinem Kopf, aber ich bin stocknüchtern weswegen ich das einfach ausschließe

rille2 schrieb:

2 x 3 macht 4 Widdewiddewitt und Drei macht Neune !! Ich mach' mir die Welt Widdewidde wie sie mir gefällt ....

Wirklich eine kreativ cooler Versuch die Stimmung hier wieder anzuheizen ! Da bekommt man ja glatt Pipi in den Augen bei solch coolen Sprüchen

Dann erkläre uns doch mal wie sich eine ("vermutlich grobe") CRC-Prüfung bei der Übertragung der Daten von der Festplatte auf den Klang auswirkt.

Möglicherweise kommt die Diskussion nicht weiter, weil Clock-Daten und Audio-Daten in einen Topf geworfen werden und einfach als "Daten" oder "Signal" bezeichnet werden.

Audio-Daten gehen meist nicht verloren, denn unvollständige Audio-Daten würden sich als Knacken oder Aussetzer bemerkbar machen; ein fehlerhaftes Taktsignal/ Clock-Daten lässt (von groben Fehlern abgesehen) den Stream durchaus weiterlaufen aber eben mit mehr oder weniger hörbaren Phasenverschiebungen.

Grüße
Fujak

rille2 schrieb:

Dann erkläre uns doch mal wie sich eine ("vermutlich grobe") CRC-Prüfung bei der Übertragung der Daten von der Festplatte auf den Klang auswirkt.

Kannst du dir das nicht denken ?

Der JITTER huscht dort einfach hindurch wenn er vorher nicht möglichst vermieden wird ! *duckundweg`*


ot :

Übrigens schöner DAC der Y2, war schon drauf und drann Mr. X zu fragen ob er mir einen baut...

fujak schrieb:

...; ein fehlerhaftes Taktsignal/ Clock-Daten lässt (von groben Fehlern abgesehen) den Stream durchaus weiterlaufen aber eben mit mehr oder weniger hörbaren Phasenverschiebungen.

Und woher kommt der Takt wenn nicht von einer Clock/einem Quarz der nicht von einer Software beeinflusst wird. Im Idealfalle bestimmt auch noch die Wandler Clock den Fluss des Datenstroms zum Puffer vor dem Wandler. Sehe da wenig Spielraum für Klangbeeinfussung, die Daten liegen bis zu dem Zeitpunkt digital vor.

Grüße

Ich gebe Boettgenstone 100% recht, und außerdem warte ich immer noch auf eine Antwort auf diesen inzwischen uralten Beitrag:

http://www.hifi-foru...13807&postID=133#133

Alles, was an möglichen Zeitverschiebungen vor der Soundkarte bzw. dem DAC passiert, spielt überhaupt KEINE, ja KEINE KEINE KEINE Rolle! Ist so, basta, aus, punkt. Stichwort: Buffer, Puffer, nur die Reihenfolge der Daten und die Richtigkeit spielt eine Rolle, die wird durch CRC sichergestellt.

Kapiert das die Voodoo-Fraktion hier endlich mal???

tststs....

jopl schrieb:

Alles, was an möglichen Zeitverschiebungen vor der Soundkarte bzw. dem DAC passiert, spielt überhaupt KEINE, ja KEINE KEINE KEINE Rolle! Ist so, basta, aus, punkt.

Von mir aus kannst du es machen wie Brian und die Mauern von Jerusalem damit vollschmieren, solange User einen Unterschied zwischen cMP² und Foobar hören ist das ganze theorethische Suppenbrain geplärre absolut unbedeutsam...

Damit ist endgültig klar, dass ihr absolut beratungsresistent seid, da kann man dann wohl leider nichts machen...

Tut mir wirklich leid, ich habs wirklich versucht. Dann müsst ihr halt in euer Unglück laufen. Ich meine jetzt nur finanzielles und zeitliches Unglück, nicht dass das wirklich schädlich wäre, aber es bringt halt nix.

Und diskutieren wollt ihr offensichtlich auch nicht, jedenfalls offensichtlich nicht mit mir, nur mit Argumenten, die euch offensichtlich in den Kram passen.

Na gut, was solls, Pech gehabt.

@jop!
Das haben diverse Leute hier schon versucht plausibel zu machen, aber dann kurz vor der Hürde der Erkenntnis wird gezuckt und eine Rolle rückwärts gemacht wie eben bei Fiedel.
Überzeugungsarbeit kannste vergessen, ist vergebene Liebesmüh. Jedem das Seine und mir die Ruh.

@fiedelity
es ging grad nicht um den Unterschied zwischen foobar und ner anderen Abspielsoftware. Takt, Jitter usw. war das Thema. Und wenn cmp2 anders klingt als foobar woran liegt das? An der festgestellten höheren Lautheit z.B.


Grüße

Ging mir heute so eine Theorie durch den Kopf:

Wenn ein cmp2 Beführworter Jitter sagt meint er vielleicht Latenz!

Möglich?

Bei fehlendem technischen Verständnis ist ALLES möglich.

Man sollte vielleicht wirklich erst mal den Begriff Jitter erklären.