Gehe zu Seite: |vorherige| Erste 2 3 Letzte |nächste|

Optischer Ausgang am CD-Player alt gegen neu

+A -A
Autor
Beitrag
cr
Inventar
#102 erstellt: 04. Jul 2013, 19:40
Weit interessanter für die Praxis wäre gewesen, die Startmarkendrift in den Griff zu bekommen, als solche angeblich subtilen Unterschiede, die nicht wirklich verifiziert werden konnten.
Die Startmarkendrift war nämlich in der Tat ärgerlich. Bei der Kopie der Kopie hat man es häufig schon nachweislich hören können, dass einige 10 ms fehlen, wenn im Original die Startmarken sehr knapp gesetzt waren, manchmal sogar schon bei der ersten Generation.
Axel_Hucht
Hat sich gelöscht
#103 erstellt: 04. Jul 2013, 20:24

cr (Beitrag #102) schrieb:
Weit interessanter für die Praxis wäre gewesen, die Startmarkendrift in den Griff zu bekommen, als solche angeblich subtilen Unterschiede, die nicht wirklich verifiziert werden konnten.
Die Startmarkendrift war nämlich in der Tat ärgerlich.....


Genau dazu gab es seit dem Aufkommen des CDR1 / CDR610 etc. von HHB den "CDR-Indexer".

Dieses Gerät hatte zum Vorkompensieren der Reaktionszeiten der Software im Recorder ein einstellbares
Delay für die Audiodaten, welches mehr als grosszügig dimensioniert war.
Damit konnte man auch locker "Überkompensieren", so dass Startmarken sogar noch vorgezogen werden konnten.

Ähnliches Gerät gab es auch von Audio&Design.

Meine Wenigkeit hatte mehrere geeignete Produkte wie den Copyprocessor ICP2-pro oder den
Copyprocessor ICP1-Insert
im Programm, die zusammen mit einem handelsüblichen
digitalen Delay ( mit digitalen I / O ) das Problem ebenfalls lösen.

Hatte diese Produkte allerdings jahrelang wie Sauerbier angeboten und dann wegen mangelnder Nachfrage
die Fertigung eingestellt.

Also bitte nicht so tun, als hätte es keine Lösungen gegeben !

Die Drift der Startmarken ist kein unlösbares Problem gewesen, es gab in fast jedem besseren Tonstudiobedarfsgeschäft dagegen Geräte zu kaufen.



[Beitrag von Axel_Hucht am 04. Jul 2013, 21:21 bearbeitet]
pelmazo
Hat sich gelöscht
#104 erstellt: 04. Jul 2013, 21:48

Axel_Hucht (Beitrag #101) schrieb:
Ich kann das zum Teil aus eigener Erfahrung bestätigen. Hatte ich bereits klar mitgeteilt:

http://www.hifi-foru...ad=5821&postID=20#20

Allerdings hatte ich auch klipp und klar geschrieben, dass ich den Effekt eher als subtil und gerade
wahrnehmbar ( und nur im direkten A-B-Vergleich ) empfunden habe, aber keinesfalls so drastisch wie die STEREO
das 1996 dargestellt hatte.

Ist offenbar eine ziemlich plumpe Promo für irgendein "aktives Digitalkabel" einer Firma SWOBODA gewesen. ( das Produkt ist mir unbekannt ).


Ah ja, aber die plumpe Promo war dann doch gut genug um von Dir als Untermauerung Deiner angeblichen Hörerfahrung herzuhalten.


Der Inhaber hatte mich damals schriftlich darauf hingewiesen, dass es nach seiner Erfahrung klangliche Unterschiede zwischen Toslink-Verbindungen und Koaxkabeln beim CDR1 gibt.

Ebenso Unterschiede zwischen verschiedenen CDR-Rohlingssorten.


Dann wäre es zuallererst darauf angekommen, zu überprüfen ob die Brände auch bitidentisch waren. Das wäre auch schon im Jahr 2000 gegangen, denn CD-ROM-Laufwerke konnten auch damals schon zum Rippen benutzt werden.

Über das beschriebene A/B-Vergleichsverfahren kann man auch nicht gerade sagen, daß da bei subtilen Unterschieden zuverlässige Ergebnisse herauskommen.


Bevor jetzt wieder der Standard-Einwand kommt, ob bei den CDR-Aufnahmen denn die Bitgleichheit mit den Originaldaten ( in diesem Fall DAT-Bänder ) bzw. zwischen den verschiedenen "Bränden" überprüft worden sei:
[...]
Aus der Tatsache, dass mit diesen CDRs problemlos und fehlerfrei die Diaschauen synchronisierbar waren, ergibt sich die Bitgleicheit sowohl zwischen Aufnahme und Zuspielband wie auch zwischen den CDRs untereinader bereits automatisch..


Tut mir leid, Du hast auch schon in der Vergangenheit oft genug gedankliche Fehlleistungen ersten Ranges gezeigt, zuletzt Deine Rauschargumentation im Zusammenhang mit dem "optimalen Jitter", so daß ich ohne genaueres Verständnis dessen was bei diesem Codierverfahren passiert, nicht davon ausgehen würde daß dadurch Bitfehler ausgeschlossen sind.


Die Frage nach der "Bitgleicheit" ist ja erfahrungsgemäss erstmal der Strohhalm derjenigen, die auf irgendeine Weise doch noch die beobachtbaren Klangunterschiede wegdiskutieren wollen.


Das ist kein Strohhalm, sondern das was man in solchen Fällen zuallererst überprüft.


Zwei verstaubte Marantz CDR1-Recorder müsste ich noch irgendwo im Hängeboden stehen haben.
Wenn die nach nunmehr zwanzig Jahren noch funktionsfähig sind, dann könnte man den Versuch mit den Toslink-Strippen ja nochmal kurz wiederholen, sollte ja kein allzugrosser Aufwand sein.


Das wäre die richtige Antwort gewesen.


Einen AV-Copyprocessor RSP-pro habe ich noch hier, damit könnte man sich dann beim Abhören der CD-R in Echtzeit von Bitgenauigkeit der Aufzeichnung überzeugen ( durch schlichtes Beobachten einer leuchtenden / nichtleuchtenden LED ....)


Es wäre weniger obskur und auch für Andere nachvollziehbar, wenn Du die gebrannten CDRs hernach am PC rippen würdest, und so die Bitgleichheit nachweist. So macht's der Rest der Welt nicht ohne Grund.

Und sei schon mal vorgewarnt: Es wird nichts nutzen wenn Du dann behauptest: Ich habe die Scheiben im A/B-Vergleich gehört und subtile Unterschiede gehört. Ich überlassse es Dir, zu erraten warum mir (uns) das nicht reichen wird.


Ich hatte übrigens auch nie den Eindruck gewonnen, dass diese Leute ihr Wissen aus HiFi-Blättchen beziehen.


Und ich habe aus der Lektüre der von Dir gezeigten Schnipsel den Eindruck, daß es mit seinem Wissen nicht weit her ist. Was für einen Marketingmitarbeiter nichts Ungewöhnliches wäre. Das ist schlicht nicht sein Job.
cr
Inventar
#106 erstellt: 04. Jul 2013, 21:55
Hatte der CDQ1-IHF irgendeinen Einfluß auf die Startmarkendrift?
Unterschieden sich die handelsüblichen Brenner da eigentlich im msek-Bereich?


Die Drift der Startmarken ist kein unlösbares Problem gewesen, es gab in fast jedem besseren Tonstudiobedarfsgeschäft dagegen Geräte zu kaufen.

Es hat sich einfach erübrigt, da ich dann auf PC-Brenner umgestiegen bin. Hier existiert das Problem ja nicht.
Es ist nicht einzusehen, dass nicht gleich Audiobrenner gebaut wurden, die das beherrschen, außer ein paar Spezialgeräte, und man dauernd Zusatzgeräte benötigt, um überhaupt das zu erreichen, wofür das Gerät eigentlich gedacht ist. Ich kann mich auch nicht erinnern, dass die Startmarkendrift in HiFi-Zeitungen, wo sonst jede Banalität zum Problem hochstilisiert wird, je ein Thema war.....

Für alle, die nicht wissen, worums geht: Unter Startmarkendrift verstehe ich nicht den analogen Aufnahmevorgang mit dem Problem der Ansprechschwellen, sondern das Problem besteht auch dann, wenn man eine CD durchgängig digital kopiert, weil anscheinend die Subcodes verzögert sind, sodass die Startmarken zu spät kommen
Axel_Hucht
Hat sich gelöscht
#107 erstellt: 04. Jul 2013, 23:38

cr (Beitrag #106) schrieb:
Hatte der CDQ1-IHF irgendeinen Einfluß auf die Startmarkendrift?


Nein, das Gerät CDQ1-IHF arbeitet in beiden Varianten ( CDQ1-IHF und CDQ1-IHF / LP ) praktisch in Realtime und verschiebt den
SPDIF User-Channel, der die Informationen über die Titelanfänge enthält, gegenüber den Audiodaten in keiner Weise.

Edit: für Leser, die dieses Gerät nicht kennen: gemeint ist hier der HUCHT Copyprocessor CDQ1-IHF( Anti-Kopierschutzgerät / Errorbit-Monitor / Schnittstellenumsetzer für SPDIF-Signale, gebaut 1999 - 2003 )

Die Schreibvorgänge passieren "on the fly" und direkt auf Modulationsebene im Biphase-Mark-Signal.


CD-Recorder mit serienmässigem Puffer für die Audiodaten und automatischer Neugenerierung von Titelwechseln,
die auch wirklich vor dem Einsetzen der Musik liegen und einen Abstand davon laut Redbook haben,
die gabs bereits in den 90ern, z.B. den SONY CDR-W66. ( Habe dieses Modell selber einige Jahre genutzt ).

Werksfoto:




Der CDR-W66 wertet den SPDIF-Subcode nach Startmarken aus und platziert den Titelwechsel dann nach Auswertung der Audiodaten:

-- wird eine Pause mit "Digital Null" detektiert, dann wird der neue Titel einige Frames vor dem ersten von Null verschiedenen Sample gesetzt

-- wird eine Startmarke innerhalb eines Titels detektiert, dann wird eine konstante Korrektur für die Reaktionszeit der Software
angewendet und der Titelwechsel entsprechend der Startmarke übernommen.


[Beitrag von Axel_Hucht am 05. Jul 2013, 09:56 bearbeitet]
cr
Inventar
#108 erstellt: 05. Jul 2013, 00:23
Ok, danke.
Eigentlich erstaunlich, dass ausgerechnet von Sony, die der CD-Brennerei ja immer recht reserviert gegenüberstanden wegen Minidisk und ihrer eigenen Contentindustrie, ein wirklich durchdachtes Gerät am Markt war. Bei Tascam ist zumindest in den Manuals nichts dergleichen angeführt.... und mein Marantz Prof. Rec. macht das auch nicht....
Axel_Hucht
Hat sich gelöscht
#109 erstellt: 05. Jul 2013, 00:47

pelmazo (Beitrag #104) schrieb:

Der Inhaber hatte mich damals schriftlich darauf hingewiesen, dass es nach seiner Erfahrung klangliche Unterschiede zwischen Toslink-Verbindungen und Koaxkabeln beim CDR1 gibt.
Ebenso Unterschiede zwischen verschiedenen CDR-Rohlingssorten.


Dann wäre es zuallererst darauf angekommen, zu überprüfen ob die Brände auch bitidentisch waren. Das wäre auch schon im Jahr 2000 gegangen, denn CD-ROM-Laufwerke konnten auch damals schon zum Rippen benutzt werden.


Mann merkt deutlich die Unaufmerksamkeit beim Lesen....

Ich hatte doch klar geschrieben:


Der beschriebene "Toslink-Effekt" ist übrigens nicht erst seit 1996 bekannt, vielmehr hatte mich da einer meiner früheren
Vertriebspartner schon über ein Jahr zuvor drauf aufmerksam gemacht


Also, die Untersuchungen waren aus den Jahren 1993 und 1994.

Ich kann mich nicht entsinnen, dass es da schon CD-ROM-Laufwerke gegeben hatte.


pelmazo (Beitrag #104) schrieb:
Tut mir leid, Du hast auch schon in der Vergangenheit oft genug gedankliche Fehlleistungen ersten Ranges gezeigt, zuletzt Deine Rauschargumentation im Zusammenhang mit dem "optimalen Jitter", so daß ich ohne genaueres Verständnis dessen was bei diesem Codierverfahren passiert, nicht davon ausgehen würde daß dadurch Bitfehler ausgeschlossen sind.


Liegt aber im Design des Verfahrens begründet:

Wenn nicht sowohl die Aufzeichnung wie die Wiedergabe bitgenau sind, dann lassen sich aus den Audiodaten ( 16 Bit )
die eingebetteten Hilfskanäle überhaupt nicht mehr dekodieren und man erhält an den Ausgängen für LTC und die Überblendsignale einfach ein Rauschsignal.
Der Decoder verhält sich in so einem Fall wie ein Maximallängen-Sequenz-Rauschgenerator.

Treten bei der Wiedergabe der CDR ( bzw DAT ) nichtkorrigierbare Lesefehler , d.h. Interpolation auf, dann wird in demjenigen Audiokanal,
in dem die Interpolation passiert ist, am Ausgang des betreffenden Hilfskanals für die Dauer von 24 Audiosamples Zufallswerte ( Rauschen ) ausgegeben, was durch praktisch jeden seriösen Timecode Reader sofort als ERROR angezeigt wird.
Dasselbe gilt genauso für die Überblend-Steuergeräte: die zeigen ebenfalls unmittelbar einen Lesefehler an.

Wer sich für die RSP-pro-Kodierung interessiert:

Prof. Dr. Kolb vom physiologischen Institut der Uni München hatte in den 90ern dieses Verfahren für ein Forschungsprojekt eingesetzt und darüber Publikationen herausgegeben.

Wie bei jedem CRC-basiertem Verfahren gibt es auch beim RSP-pro bestimmte Konstellationen von Mehrfachfehlern, die nicht erkannt werden können.
Das bedeutet, dass bei massig hinternander auftretenden Interpolationen der Audiodaten mit einer ganz geringen Restwahrscheinlichkeit in dem dann bei den Hilfskanälen ausgegebenen Rauschsignal für die Dauer von einem Audiosample die Werte low und high ihre Plätze tauschen können, was im Ergebnis aber immer noch ein Rauschsignal ist und auch genauso von angeschlossenen Geräten als solches erkannt wird.
Für alle praktisch relevanten Fälle kann also damit die "Bitgleicheit über Alles" sichergestellt werden.


Übrigens sollten Leute, die die Addition von Rauschspannungen und die Addition von Rauschleistungen nicht auseinanderhalten können, etwas vorsichtiger bei der Anwendung des Begriffes "Fehlleistung" sein.....




pelmazo (Beitrag #104) schrieb:


Einen AV-Copyprocessor RSP-pro habe ich noch hier, damit könnte man sich dann beim Abhören der CD-R in Echtzeit von Bitgenauigkeit der Aufzeichnung überzeugen ( durch schlichtes Beobachten einer leuchtenden / nichtleuchtenden LED ....)


Es wäre weniger obskur und auch für Andere nachvollziehbar, wenn Du die gebrannten CDRs hernach am PC rippen würdest, und so die Bitgleichheit nachweist. So macht's der Rest der Welt nicht ohne Grund.


Wie es "der Rest der Welt " macht, das interessiert mich sonstwas !

Was habe ich vom Nachweis, dass der "Brand" bitgenau erfolgt ist, wenn dann gleich der nächste Hansel ankommt und
dann fragt, woher ich die Bitgenauigkeit bei der Wiedergabe im CD-Player weiss ????

Dann kann ich doch lieber gleich eine Aufnahme mit dem RSP-pro Verfahren machen und z.B. für beide Hilfskanäle einfach eine Gleichspannung mit 0 Volt verwenden, d. h einfach beide Eingänge für die Hilfskanäle bei der Enkodierung offen lassen..
Bei fehlerfreier Dekodierung ergibt sich dann auch für beide Ausgänge der Hilfskanäle jeweils eine Gleichspannung von 0 Volt.

Jeder dort auftretende Puls ist dann das Ergebnis eines Lesefehlers und kann mit so einem Gerät über darin enthaltene Leuchtdioden problemlos und durch zeitliche Dehnung auch sicher abgelesen werden.

Die RSP-pro-Copyprocessoren sind in schon ordentlichen Stückzahlen weltweit verkauft worden und für Profis im Bereich der AV-Technik wohlbekannt. Da ist absolut nichts "obskur" dran.


[Beitrag von Axel_Hucht am 05. Jul 2013, 01:20 bearbeitet]
-scope-
Hat sich gelöscht
#110 erstellt: 05. Jul 2013, 09:26

Also, die Untersuchungen waren aus den Jahren 1993 und 1994. Ich kann mich nicht entsinnen, dass es da schon CD-ROM-Laufwerke gegeben hatte.


Zwar OT, aber 1994 bekam ich meinen ersten SCSI CD Recorder für den PC. Das war allerdings auch der erste (?) für den Consumermarkt. Der Philips CDD521...Der brennt heute noch. Verkauft wurde er bereits ab 1992 für damals 10.000 DM.

Zum Thema CDR Hörbarkeit (Klang der Rohlinge usw) möchte ich ebenfalls noch etwas schreiben, da ich mich mit diesem Thema ebenfalls praktisch beschäftigt habe.

Bitidentische CD(R) werden oft als eine Art Voraussetzung für identischen "Klang" genannt. Bitidentität ist natürlich eine "zu begrüssende Sache", aber strenggenommen nicht notwendig, um einen gleichen "Klang" zu ermöglichen. Nehmen wir doch einfach mal an, eine CD mit einem Testtrack von 1 Minute und 441000 Blöcken enthält Brennfehler oder Oberflächenfehler, die beispielsweise 70 der 7350 Blöcke in der 46en Sekunde so beschädigen, dass sie von den Korrekturstufen 1 & 2 nicht mehr behoben werden können. Dann wird für ca 1/100 Sekunde der Interpolator im Decoder verwendet.

Bitidentität ist dann nicht mehr vorhanden....Aber will denn jemand vom Fach ernsthaft berhaupten, das man davon als Hörer etwas mitbekommt?

Ich habe Tests durchgeführt, in denen es zwischen 500 und 1000 defekte Blöcke pro Sekunde gab....Dann fängt es bei kritischem Musikmaterial an, etwas "harsch" in den Höhen zu klingen.

Was ich zum Ausdruck bringen möchte: Der Begriff "Bitidentität" ist mir bei Audio-CD zu schwammig


Was habe ich vom Nachweis, dass der "Brand" bitgenau erfolgt ist, wenn dann gleich der nächste Hansel ankommt und
dann fragt, woher ich die Bitgenauigkeit bei der Wiedergabe im CD-Player weiss ????


Das ist keine unberechtigte Frage, obwohl man die beinahe schon vernachlässigen kann. gepflegte CD und CDR werden auf intakten Geräten in den wirklich allermeisten Fällen so fehlerarm wiedergegeben, dass selbst vereinzelte CU´s (ein paar Samples alle 5 Minuten z.B.) keine Rolle spielen.

Ich habe über die Jahre mehrere, willkürlich gewählte CD-Spieler vermessen und kann mich nicht daran erinnern, dass einer davon laufend CU´s von einem fehlerfreien CDR grelesen hat. Es gab lediglich verschiedenes Aufkommen von C1 und C2.

Einen fiesen Burst Error habe ich übrigens noch nie auf einer unbeschädigten CD oder CDR entdeckt. So häufig sind die nicht.


@A.Hucht: Gesetzt den Fall, dass die gebrannten CDR unterschiedlicher Hersteller bitidentisch sind, und auch bitidentisch vom CDP gelesen werden.....

Welchen Einfluss machst du für den angeblichen CDR Klang verantwortlich, sofern du ihn trotz bitidentität noch für möglich hälst?


[Beitrag von -scope- am 05. Jul 2013, 09:55 bearbeitet]
pelmazo
Hat sich gelöscht
#111 erstellt: 05. Jul 2013, 09:55

Axel_Hucht (Beitrag #109) schrieb:
Mann merkt deutlich die Unaufmerksamkeit beim Lesen....

Ich hatte doch klar geschrieben:


Der beschriebene "Toslink-Effekt" ist übrigens nicht erst seit 1996 bekannt, vielmehr hatte mich da einer meiner früheren
Vertriebspartner schon über ein Jahr zuvor drauf aufmerksam gemacht


Also, die Untersuchungen waren aus den Jahren 1993 und 1994.


Unaufmerksamkeit?

Du hattest in #101, als Antwort auf Beitrag #99 von drSeehas, auf Deinen Beitrag #20 in diesem Thread verwiesen, wo ich auch jetzt noch "etwa 2000" lesen kann. Ist das ein Wahrnehmungsproblem auf meiner Seite?


Wer sich für die RSP-pro-Kodierung interessiert:

Prof. Dr. Kolb vom physiologischen Institut der Uni München hatte in den 90ern dieses Verfahren für ein Forschungsprojekt eingesetzt und darüber Publikationen herausgegeben.


Ich würde erwarten daß die Publikationen über sein Forschungsprojekt waren, und nicht über die Kodierung. Aus welchem Grund sollte er die Details des Kodierungsverfahrens beschreiben? Wo findet man übrigens diese Publikationen? Eine kurze Suche im Web hat nichts Brauchbares ergeben.


Wie bei jedem CRC-basiertem Verfahren gibt es auch beim RSP-pro bestimmte Konstellationen von Mehrfachfehlern, die nicht erkannt werden können.
Das bedeutet, dass bei massig hinternander auftretenden Interpolationen der Audiodaten mit einer ganz geringen Restwahrscheinlichkeit in dem dann bei den Hilfskanälen ausgegebenen Rauschsignal für die Dauer von einem Audiosample die Werte low und high ihre Plätze tauschen können, was im Ergebnis aber immer noch ein Rauschsignal ist und auch genauso von angeschlossenen Geräten als solches erkannt wird.
Für alle praktisch relevanten Fälle kann also damit die "Bitgleicheit über Alles" sichergestellt werden.


Warum würde man ein CRC-basiertes Verfahren verwenden, wenn man damit nicht etwa größere Kommunikationssicherheit bekommt, sondern größere Unsicherheit? Wozu brauche ich dann CRC? Tut mir leid, ohne ein paar Detailinformationen kommt mir das eher obskur vor.


Übrigens sollten Leute, die die Addition von Rauschspannungen und die Addition von Rauschleistungen nicht auseinanderhalten können, etwas vorsichtiger bei der Anwendung des Begriffes "Fehlleistung" sein.....


Unaufmerksamkeit beim Lesen? Ich habe niemanden hier gesehen, der das nicht auseinanderhalten konnte, ich habe bloß jemanden gesehen, der die Parallelschaltung von Rauschquellen nicht von der Serienschaltung unterscheiden konnte, und das bist Du.


Was habe ich vom Nachweis, dass der "Brand" bitgenau erfolgt ist, wenn dann gleich der nächste Hansel ankommt und
dann fragt, woher ich die Bitgenauigkeit bei der Wiedergabe im CD-Player weiss ????


Dann sagst Du ihm, daß Du für die Wiedergabe den gleichen Player verwendest wie beim Überspielen, damit sollte der Einwand erledigt sein.


Dann kann ich doch lieber gleich eine Aufnahme mit dem RSP-pro Verfahren machen und z.B. für beide Hilfskanäle einfach eine Gleichspannung mit 0 Volt verwenden, d. h einfach beide Eingänge für die Hilfskanäle bei der Enkodierung offen lassen..
Bei fehlerfreier Dekodierung ergibt sich dann auch für beide Ausgänge der Hilfskanäle jeweils eine Gleichspannung von 0 Volt.

Jeder dort auftretende Puls ist dann das Ergebnis eines Lesefehlers und kann mit so einem Gerät über darin enthaltene Leuchtdioden problemlos und durch zeitliche Dehnung auch sicher abgelesen werden.


Das mag sein, ich würde bloß nach meinen bisherigen Erfahrungen mit Dir noch immer keinen Pfifferling darauf wetten daß das auch wirklich so ist.


Die RSP-pro-Copyprocessoren sind in schon ordentlichen Stückzahlen weltweit verkauft worden und für Profis im Bereich der AV-Technik wohlbekannt. Da ist absolut nichts "obskur" dran.


Außer daß ich nirgends eine technische Beschreibung gesehen habe, aus der nachzuvollziehen wäre wie das Ding genau funktioniert. Du scheinst auch wenig Neigung zu haben, uns das hier leicht zu machen.
Sal
Inventar
#112 erstellt: 05. Jul 2013, 10:47
Noch was zum Empfänger:
Der Sabre ESS9018 D/A Wandler wirbt damit, das Taktsignal der Quelle nicht zu nutzen und es stattdessen aus dem Datenstrom neu zu generieren - vom Jitter er Quelle also unabhängig zu sein.
Twistedpearaudio ist eine Firma, welche Bausätze mit diesem DAC vertreibt .
Ich nutze ihn selber und er hat -für meine Ohren- klanglich mit Leichtigkeit einen Parasound DAC 1500 ausgestochen.
McIntosh verwendet den ESS9018 zum Beispiel.


[Beitrag von Sal am 05. Jul 2013, 10:48 bearbeitet]
-scope-
Hat sich gelöscht
#113 erstellt: 05. Jul 2013, 11:12

ch nutze ihn selber und er hat -für meine Ohren- klanglich mit Leichtigkeit einen Parasound DAC 1500 ausgestochen.


Der DAC 1500 ist auf der Analogseite extrem aufwendig aufgebaut. Man könnte beinahe behaupten, dass das Gerät wegen seiner Menge an Hardware und dem geringen Integrationsgrad zumindest messtechnisch über die eigenen Füsse fällt, denn messtechnisch hinkt das Gerät hinter modernen, hochintegrierten SMD-Designs hinterher. Daran ändern auch 3 Netztrafos und mindestens 2 dm² Netzteilsektion nichts. Das Gerät ist +über 20 Jahre alt!

Für meine Ohren "klingt" das Gerät übrigens sehr gut und hat sich klanglich auch von messtechnisch besseren Designs bisher nicht ausstechen lassen.

Es steht also "subjektiv unentschieden"


[Beitrag von -scope- am 05. Jul 2013, 11:16 bearbeitet]
pelmazo
Hat sich gelöscht
#114 erstellt: 05. Jul 2013, 11:32

Sal (Beitrag #112) schrieb:
Der Sabre ESS9018 D/A Wandler wirbt damit, das Taktsignal der Quelle nicht zu nutzen und es stattdessen aus dem Datenstrom neu zu generieren - vom Jitter er Quelle also unabhängig zu sein.


Wie ist das zu verstehen? Die meisten D/A-Wandler (als Gerät, nicht als Chip) rekonstruieren das Taktsignal aus dem Datenstrom, denn für ein separates Taktsignal müßte man ja von der Quelle zum Wandler eine zweite Leitung ziehen. Diese Rekonstruktion passiert zwar normalerweise nicht im D/A-Wandler-Chip, sondern typischerweise im AES/SPDIF Empfängerchip (plus evtl. weitere Taktaufbereitungshardware), aber im Ergebnis läuft das auf weitgehend das Gleiche hinaus.

So weit ich das sehe macht damit der DAC-Chip von ESS im Grunde nur im DAC-Chip das was Andere mit externen Chips machen. Man braucht so weniger Chips, aber einen prinzipiellen Qualitätsvorteil erkenne ich darin nicht. Es kommt eher darauf an wie die Jitterunterdrückung genau funktioniert. Mag sein daß man da bei ESS einen Vorteil hat, aber das läßt sich bloß meßtechnisch klären.
Sal
Inventar
#115 erstellt: 05. Jul 2013, 13:33

Wie ist das zu verstehen?


Hab´mich ungenau ausgedrückt. Mehr unter Abschnitt III
http://www.esstech.com/PDF/sabrewp.pdf


[Beitrag von Sal am 05. Jul 2013, 13:35 bearbeitet]
pelmazo
Hat sich gelöscht
#116 erstellt: 05. Jul 2013, 13:46
Ah, offensichtlich läuft das auf eine asynchrone Abtastratenwandlung hinaus, die in das Oversamplingfilter integriert ist. Für die Details müßte man wohl das Patent lesen. In diesem Fall braucht man den Takt aus der Quelle natürlich nicht. Ich kann mir durchaus vorstellen, daß es Vorteile hat diese Abtastratenwandlung ins Oversamplingfilter zu integrieren, anstatt das vorgängig zu machen, wie das andere DAC-Hersteller tun ("Upsampling").
cr
Inventar
#117 erstellt: 06. Jul 2013, 02:25

Dann wird für ca 1/100 Sekunde der Interpolator im Decoder verwendet.

Bitidentität ist dann nicht mehr vorhanden....Aber will denn jemand vom Fach ernsthaft berhaupten, das man davon als Hörer etwas mitbekommt?


Mit Musik wird das gut verdeckt, mit einem Sinus von 10 kHz hört man es aber sofort. Oder 20 kHz, noch besser, weil man ihn nicht hört, aber die Störungen.

Nicht wirklich geklärt wurde jemals, ob man die Interpolationen bei destruktiv kopiergeschützten CDs hört
Axel_Hucht
Hat sich gelöscht
#118 erstellt: 07. Jul 2013, 13:56

pelmazo (Beitrag #111) schrieb:

Wer sich für die RSP-pro-Kodierung interessiert:
Prof. Dr. Kolb vom physiologischen Institut der Uni München hatte in den 90ern dieses Verfahren für ein Forschungsprojekt eingesetzt und darüber Publikationen herausgegeben.


Ich würde erwarten daß die Publikationen über sein Forschungsprojekt waren, und nicht über die Kodierung. Aus welchem Grund sollte er die Details des Kodierungsverfahrens beschreiben? Wo findet man übrigens diese Publikationen? Eine kurze Suche im Web hat nichts Brauchbares ergeben.


Ich hatte Dr. Kolb die geheimen Details des RSP-pro-Kodierverfahrens offengelegt, damit er das Verfahren
in eine Software zum Synchronisieren von Ereignissen mit CD-Wiedergabe implementieren und als Hardware dann fertige Decoder aus meiner ehemaligen Fertigung verwenden konnte.

Zu dem Vorgang habe ich in meinem Archiv heute nur noch spärliche Informationen, aus denen aber zumindest hervorgeht, dass Dr. Kolb speziell über die in seiner Software implementierte Synchronisationsmethode, also mein RSP-pro-Verfahren, einen Vortrag zu halten hatte.
In einem der diversen Telefonate hatte er auch erwähnt, dass er darüber eine Publikation herausgegeben hätte. Wo genau, das kann ich heute nicht mehr sagen.



Dr. Kolb hatte mir Monate später noch mitgeteilt, dass er von seiner Software quasi als Spin Off eine abgespeckte Version für Mitglieder eines bestimmten Film-Clubs als Freeware zur Verfügung gestellt hätte und mir eine kurze schriftliche Info darüber zukommen lassen.




pelmazo (Beitrag #111) schrieb:

Warum würde man ein CRC-basiertes Verfahren verwenden, wenn man damit nicht etwa größere Kommunikationssicherheit bekommt, sondern größere Unsicherheit? Wozu brauche ich dann CRC?

Tut mir leid, ohne ein paar Detailinformationen kommt mir das eher obskur vor.

.... Außer daß ich nirgends eine technische Beschreibung gesehen habe, aus der nachzuvollziehen wäre wie das Ding genau funktioniert.


Das kann ich gut nachvollziehen, mir würde das ebenfalls "obskur" vorkommen, zumal der Kern des RSP-pro-Verfahrens geheim gehalten wird..

Das RSP-pro -Verfahren ist im Zuge einer patentrechlichen Auseinandersetzung mit einem Mitbewerber entstanden und vom rein technischen Standpunkt her erstmal überhaupt nicht naheliegend.

Ohne Kenntnis der Geschichte derartiger Verfahren und der Patentsituation ( ziemlich vermientes Gebiet ! ) kann man meine Lösung sicherlich nicht leicht einordnen und auch leicht für etwas "wundersam" halten.

Das ist natürlich jetzt schwer OT, aber da ich nun konkret danach gefragt wurde, ein kleiner geschichtlicher Rückblick:

Im Jahr 1986 wurde der Firma Philips ein europaweites Patent erteilt ( Erfinder: B.Blüthgen ), in dem die Nutzung von bestimmten Bits ( wie z.B. des LSB ) in einem Audiodatenstrom zur Bereitstellung von zusätzlichen, eingebetteten Hilfskanälen geschütz wurde ( "Bitstellenzweckentfremdungs-Verfahren" )

Ende der 80er Jahre konnte man bei der Vorstellung des DAT-Systems auf der Internationalen Funkausstellung hier in Berlin ( IFA ) einen portablen DAT der Firma AIWA bewundern, der neben der Audioaufzeichnung auch noch optional Videoaufnahmen aufzeichnen konnte.
Dazu wurden dann die untersten acht Bit der 16 Bit langen Audiodatenwortr für die Videoaufzeichnug "zweckentfremdet", womit dann das "Bitstellenzweckentfremdungs-Verfahren" praktisch Stand der Technik war.

Im Jahr 1991 kam eine Firma BÄSSGEN ( Freiburg ) auf die Idee, das bereits allgemein bekannte "Bitstellenzweckentfremdungs-Verfahren" für die Einbindung / Einbettung von Überblendsteuersignalen für Diaprojektoren in digitale Audiodaten zu verwenden.
Das geschah dann mit einer speziellen Software und einer speziellen PCI-Karte im PC.
Die PCI-Karte und der PC waren dazu zwingend notwendig.

Die Wiedergabe geschah dann über DAT bzw CDR, wobei die Audiosignale für die PA verwendet wurden und das Signal des digitalen Ausgangs in das Projektor-Überblendsteuergerät eingespeist wurden.

In 1993 erhielt ich Anfragen von zwei Firmen ( Firma STUMPFL, Österreich und AVVB BÜCHELER, Landshut ), ob ich derartige Funktionalitäten nicht auch in meine stand-alone-Kopierschutzentferner integrieren könnte und so ein universelles externes Interface für die Überblendsysteme verschiedener Hersteller anbieten könnte.

Mit der Firma AVVB wurde dann eine Kooperation eingegangen, Fa STUMPFL hatte sich dann selbst an die Entwicklung gemacht, wobei jedoch klar erkennbar gewisse "Anleihen" von meiner Entwicklung übernommen wurden.

Eine Vorgabe von AVVB war, das das zu bauende Interface zwei unabhängige eingebettete Kanäle für Hilfsdaten bereitstellen können müsste und zudem die Datenträger mit der Kodierung der Firma BÄSSGEN lesen / decodieren können müsste.

BÄSSGEN verwendete damals das "Bitstellenzweckentfremdungs-Verfahren" mit Zweckentfremdung der LSB ( in seiner Notation das 16. Bit ) der Aududiodatenworte, an das sich dann auch aus Gründen der Kompatibilität die Firmen AVVB BÜCHELER, STUMPFL und später noch Hilger&Bremen sowie CREAMWARE Datentechnik angeschlossen hatten. Naheliegenderweise hatte ich das Verfahren dann auch implementiert.

Die Aufzeichnug der Hilfsdaten geschah dabei durch direkte Übernahme des aktuellen Pegels der digitalen Hilfsdaten ( also "low" oder "high" ) in die "zweckentfremdete" Bitstelle.

Meine Konstruktion arbeitete jedenfalls dann ebenfalls -- nach dem Stand der Technik !! -- mit der Verwendung der "16ten Bits" für zwei unabhängige Hilfskanäle ( HB II - Verfahren = HUCHT / BÜCHELER-Verfahren, zweikanalig ).

Etwas unschön dabei ist, dass bei sehr leisen Audiosignalen bzw sogar völliger Stille der pegelmässige Abstand zu den Hilfskanälen bei Wiedergabe der Tonsignale über PA gerade in Nähe der Lausprecher nicht gross genug ist und manchmal die eingebetteten LTC ( Linear Time Code ) leise hörbar werden können. LTC erzeugt ein penetrantes Störgeräusch.

Die naheliegende Idee war da, die eingebetteten Hilfskanäle in eine Pseudo-Zufallsfolge umzusetzen, so dass das Störsignal bei der Wiedergabe rauschähnlich ist und damit weniger stört.

Leider durfte ich auf einem Vortrag auf der AES Convention 1993 hier in Berlin erfahren, dass für die Randomisierung der mit "Bitstellenzweckentfremdung" eingebetteten Hilfsdaten bereits ein Patent erteilt worden war.

Diesen Vortrag konnte ich dann 1995 nochmal als Langfassung im AES Journal nachlesen, das ich damals als
AES-Mitglied regelmässig erhalten hatte.






Meine Geräte AV Copyprocessor HB II ( Encoder / Decoder ) und AV Digitaldecoder HB II kamen 1993 erstmal als preiswerte Geräte für Hobbyanwender auf den Markt, wurden mehrfach in der Fachpresse getestet und vorgestellt und waren am Anfang im Vertrieb der Firma AVVB Bücheler.

Siehe z. B. :

STEREOPLAY 4/1994 und 8/1994
Foto&Labor 4/1994
Dia-Magazin 3/1994
Diaporama-Report 1994 etc.

Ab 1994 waren meine Interface dann im Vertieb der Firma DATATON Steuerungstechnik Deutschland und wurden damit auch mehr für den professionellen Anwenderkreis vermarktet.
Fa DATATON wollte meine Produkte auf der Photokina ( Köln 1994 ) präsentieren, ein Vergleichstest zwischen meinen Produkten, den zwischenzeitlich erhältlichen Geräten von STUMPFL und der ursprünglichen Konstruktion von BÄSSGEN war bereits in der in Anwenderkreisen renomierten Fachzeitschrift Foto&Labor erschienen. ( April 1994, S 54 ff )

Die Fertigung der ersten Serie war abgeschlossen, das Lager voll, aber nach der Rückkehr aus dem Betriebsurlaub gabs eine böse Überraschung in Form eines Anwaltsbriefes der Firma Bässgen ( nur wenige Wochen vor der Messe Photokina ).

Was war passiert?

Der Herr Bässgen war rotzfrech zum Patentamt marschiert und hatte sich dort als der "Erfinder" des "Bitstellenzweckentfremdungs-Verfahrens" ausgegeben. Eigentlich schon geradezu dummdreist...

Und hatte doch tatsächlich daraufhin ein ( deutsches ) Patent erhalten !!!!! ( für ein längst etabliertes und dem Stand der Technik entsprechendes Verfahren ).
Ich habe keine Ahnung wie er die Prüfer beim Patentamt hinters Licht geführt hatte, jedenfalls hatte der Herr "Erfinder" die gleiche Tour dann nochmal beim Europäischen Patentamt versucht, wo er aber letztlich komplett abgeblitzt war.

Jedenfalls wollte er mir, der Firma STUMPFL und noch weiteren Anbietern ( von Software ) das weitere Inverkehrbringen von Produkten untersagen, die angeblich sein "Patent" verletzen würden.

Dass dieses Patent überhaupt erteilt worden war, das hatte in der Szene überhaupt niemand mitbekommen, da der Herr "Erfinder" das erteilte "Patent" für sechs Monate hatte in der Schublade verschwinden lassen, genau so lange, bis die sechsmonatige Einspruchsfrist, so wie sie gesetzlich betroffenen Mitbewerbern zusteht, abgelaufen war und somit nur noch eine Patentanfechtungsklage möglich war.


In dieser Situation durfte ich dann innerhalb kürzester Zeit ein Kodierverfahren aus dem Hut zaubern, das weder das "Patent" der Firma BÄSSGEN noch das von Gerzon et al in dem AES Journal beschriebene Patent verletzt und möglichst auch noch über verbesserte Klangeigenschaften verfügen musste.

Unter mehreren Ansätzen hatte ich dann das RSP-pro getaufte Verfahren ausgewählt und durch eine kurzfristig und unter hohem finanziellen Aufwand mit einer Upgrade-Platine in die bereits produzierten Copyprocessoren nachgerüstete Platine realisiert und auf den Markt gebracht.

Ich hatte es mir natürlich nicht nehmen lassen, in das Upgrade eine automatsche Formatwandlung für vorliegende Daten nach dem bisherigen "Bitstellenzweckentfremdungs-Verfahren" in das neue RSP-Pro-Datenformat zu intergieren, womit der Anwender dann bereits vorliegende Produktionen mit dem Format von BÄSSGEN und STUMPFL und HB II in mein neues Format übersetzen kann -- und das sogar bei noch gleichzeitiger Verbesserung der Audioqualität durch diesen Konvertierungsprozess.

Eine Rückkonvertierung wäre technisch auch leicht zu realisieren gewesen, die war aber selbstredend NICHT ( !!! ) in meinen Geräten implementiert ( das hatte der Herr "Erfinder" dann von seiner Ablinkerei: die Anwender konnten Produktionen, die mit BÄSSGEN-Technik erstellt war, dann ins HUCHT-Format
konvertieren, welches Firma BÄSSGEN aber weder lesen ( !!!!! ) noch generieren konnte.

Ich brauche ja wohl nicht extra zu erwähnen, dass die Details der RSP-pro-Kodierung strengstens geheim waren / sind und erst zig Jahre nach Einführung genau zwei Anwendern im Detail zugänglich gemacht wurden:
der Firma STUMPFL im Jahr 1997 zur Implementierung in deren Hard- und Software zur Vereinheitlichung der diversen Datenformate im Bereich der Multimediasynchronisation und dem Herrn Dr. Kolb von der Uni München unter der Auflage, dass die genauen Details geheim zu halten sind.

Der "Erfinder" BÄSSGEN hatte es jedenfalls bis zur Photokina 1994 nicht geschafft, die Verletzung seines "Patentes" durch meine neuen RSP-pro Processoren in irgendeiner Weise zu beweisen, so dass die Geräte dann noch pünklich auf der Messe präsentiert werden konnten und im Anschluss daran unbehindert weltweit vermarktet werden konnten.

Der "Erfinder" hatte sich an dem "TTL-Grab" mit abgeschliffenen ICs wohl totgesucht, jedenfalls hatte er nicht herausbekommen, wie das Verfahren im Detail funktioniert...
Und ich habe es ihm natürlich auch in keiner Weise verraten. Geschieht ihm ganz recht !

Mit meinem Vertrieb DATATON hatte der Herr "Erfinder" es dann wohl doch nicht gewagt sich anzulegen....

Nachdem er dann letztlich beim Europäischen Patentamt abgeblitzt war hatte einer seiner "Vertrauten" ( Breutmann ) eine rührselige Story veröffentlich ( "Patent-Episode ( sic! ) hat ein Ende" ) und der "Erfinder" hatte sich dann vom Acker gemacht...

Zur Sicherheit war das RSP-pro-Verfahren dann noch weiterhin geheim.

Ich hatte keinen Wert darauf gelegt, dass gleich der Nächste ankommt und mir irgend ein Patent unter die Nase hält, welches ich angeblich "verletze".

Ich hatte damals wie heute den Standpunkt vertreten, dass eine angebliche Patentverletzung vom jeweiligen Patentinhaber konkret an meinen Produkten nachgewiesen werden müsste, wozu natürlich auch gehört, dass derjenige erstmal die Funktionsweise meiner Geräte bis ins Detail selbst ermittelt.

Diese technischen Details brauche ich niemanden kostenlos auf dem Silbertablett zu präsentieren.

Wer als Inhaber einer kleinen Manufaktur für elektronische Geräte schonmal solche Erfahrungen machen durfte und / oder Opfer von Konkurrenzspionage und /oder unautorisierter Produktnachahmung geworden ist, der wird auch unmittelbar die Geheimhaltung von zentral wichtigen Funktionsdetails verstehen ( sog. Geschäftsgeheimnis ).














So war jedenfalls das RSP-pro-Verfahren auf die Welt gekommen.

Hier ein AV-Copyprocessor HB II mit RSP-pro-Upgrade und aktualisierter Frontplatte aus 1994:



Das Flachbandkabel musste aufwändig manuell nachgerüstet werden und dient zum Anschluss des RSP-pro-Upgrade-Platinchens ( huckepack montiert, hier fürs Foto entfernt )



Hier mit dem RSP-pro -Upgrade.
Es handelt sich um eines der Labormuster, deshalb ist im Gegensatz zu den Seriengeräten die Bezeichnung nicht von den ICs entfernt.
Man sieht am Aufbau, dass das Gerät eher für Anwendungen im Consumer- / Hobbybereich vorgesehen war.
Diese Version des Upgrades kann im Gegensatz zur Serie auch eine Rückkonversion der Daten ins alte Format vornehmen ( kleiner horizontaler Kippschalter, hier rein experimentell )



Die ganze Schaltung wurde dann gründlich überarbeitet und als "1-Platinen-Version" für eher professionelle Anwendungen neu designed.
Dieser Aufbau ( AV-Copyprocessor RSP-pro CE ) ist dann ab 1995 als CE-konforme Version und durch ein akreditiertes Prüflabor nach Prüfkriterien für industrielle Umgebung getest auf den Markt gekommen.

Bei dieser Version sind z.B. alle ( !! ) elektrischen Ein- und Ausgänge potentialfrei über Transformatoren herausgeführt.
Das Modell hält ( genau wie der passende Decoder dazu ) neben der Anforderung "industrielle Umgebung" zusätzlich noch das verschärfende "Prüfkriterium A" bei den Störfestigkeitsprüfungen ein.
( Meines Wissens nach als einziger AV-Processor am Markt, die Mitbewerber und "Erfinder" hatten das nicht hingekriegt...)

Dass das Modell auch vom Jitter her optimiert ist brauche ich ja eigentlich garnicht extra erwähnen...

Hier der Aufbau mit abgenommener Frontplatte ( die ist gleich wie beim zuvor gezeigten Gerät )






Das hier ist der dazu passende Decoder ( Rev 3.0 CE-konform, Betrieb mit Stecker-NT, ab 1995 gefertigt )
Der Decoder unterstützt eingangsseitig SPDIF und AES/EBU-Format und enthält genau wie Copyprocessor einen Decoder für das ERRORBIT im Subcode des Eingangssignals.
Das ERRORBIT wird zeitlich gedehnt angezeigt damit auch kurze Fehler sicher abgelesen werden können.
Auch hier sind die elektrischen Ein- und Ausgänge alle über Transformatoren potentialfrei herausgeführt.
Der Decoder decodiert standardmässig das RSP-pro-Format, kann aber intern durch Umstecken eines Jumpers auf das alte HB II-Format konfiguriert werden.



Wenn ich solch einen Aufbau einer recht komplexen Statemachine sehe und wüsste, dass die äusserst stabil und zuverlässig funktioniert, dann würde ich erstmal davon ausgehen, dass der Konstrukteur der Baugruppe schon hinreichend genau weiss, was er da tut.

Es soll aber Leute geben, die das anders sehen....




pelmazo (Beitrag #111) schrieb:


Dann kann ich doch lieber gleich eine Aufnahme mit dem RSP-pro Verfahren machen und z.B. für beide Hilfskanäle einfach eine Gleichspannung mit 0 Volt verwenden, d. h einfach beide Eingänge für die Hilfskanäle bei der Enkodierung offen lassen..
Bei fehlerfreier Dekodierung ergibt sich dann auch für beide Ausgänge der Hilfskanäle jeweils eine Gleichspannung von 0 Volt.

Jeder dort auftretende Puls ist dann das Ergebnis eines Lesefehlers und kann mit so einem Gerät über darin enthaltene Leuchtdioden problemlos und durch zeitliche Dehnung auch sicher abgelesen werden.


Das mag sein, ich würde bloß nach meinen bisherigen Erfahrungen mit Dir noch immer keinen Pfifferling darauf wetten daß das auch wirklich so ist.


Wer was auf die Funktionsweise meiner Konstruktion wettet, das ist mir letztlich völlig egal.

Es sind genügend Geräte davon im Umlauf, z.B. auch als Leihgeräte bei verschieden Diaporama-Clubs, so dass sich jeder bis ins Detail von den Eigenschaften der Teile selbst überzeugen kann, z.B. durch Einspeisung geeigneter Testdaten.

Es wird sich dann unmittelbar zeigen, dass ein Datenwort mit einem Bitfehler in den obersten 16 der 24 übertragenen Audio-Bits ( bzw einer ungeraden Anzahl von solchen Fehlern in diesen 16 Bits des selben Wortes ) zu einem Ausgangssignal in der beschriebenen Weise führt.
Datenworte mit einer geraden Anzahl von Bitfehlern führen zu keinem Ausgangssignal, d.h., beim Vorliegen eines Ausgangssignals hat auch ein fehlerhaftes Datenwort vorgelegen, wobei allerdings nicht jedes fehlerhafte Datenwort auch ein Ausgangssignal hervorruft.

Bei Wiedergabe einer Aufnahme mit einer ursprünglich fehlerfreien RSP-pro-Kodierung können fehlerhafte Datenworte im Player nur durch Muting bzw. Interpolation bei nichtkorrigierbaren Fehlern vorkommen, was durch jeden halbwegs seriösen CD-Player durch Errorflags im SPDIF-Subcode übermittelt wird.

Nicht betrachtet werden sollen systematische Ausgabefehler bzw -Probleme beim SPDIF-Digitalausgang, die eine nicht bitgenaue Ausgabe aller 16 Bit der Audiodatentworte des Abspielmediums bewirken ( wie z.B. Ausgabe von nur 15 Bit bei bestimmten PC-Soundkarten etc.) und bei denen die AV-Processoren bzw. Decoder auf Grund ihrer Konstruktion überhaupt nicht funktionieren.

Sowohl die AV-Copyprocessoren wie die AV-Digitaldecoder aus meiner Fertigung ( Bilder s. o. ) werten diese Errorflags aus und zeigen das Vorliegen einer Fehlersituation gut ablesbar mit einer LED ( "Error" = Errorbit ) an.

Damit wären insgesamt alle Lesefehler erkennbar.


Natürlich kann man auch den "trivialen Test" machen:

In einen AV-Copyprocessor im Schreibmodus wie oben beschrieben ein SPDIF-Signal mit beliebigen Audiodaten einspeisen und am digitalen SPDIF-Ausgang des Processors statt eines CD-Recorders gleich einen AV-Digitaldecoder anschliessen und sich dessen Ausgangssignal anschauen.

Egal wie die Audiodaten auch sind, ob digital Null, irgendwelche Musik oder Overloads, völlig egal, man wird am Ausgang des Decoders bei den eingespeisten RSP-pro -Originalsignalen ( d.h. fehlerfreien Daten ) stets eine Gleichspannung erhalten, genau so wie ich das angegeben hatte, und kann bis zum Skt.Nimmerleinstag warten bis da irgendein Puls herauskommt..

Jeder darf sich gerne selbst davon überzeugen.

Notfalls hätte ich selbst auch noch einige Leihgeräte hier stehen.


[Beitrag von Axel_Hucht am 11. Jul 2013, 12:37 bearbeitet]
pelmazo
Hat sich gelöscht
#119 erstellt: 07. Jul 2013, 14:52
Mit anderen Worten, Du schreibst einen langen Beitrag mit diversen Bildern von abgescannten Dokumenten, nur um zu erklären daß Du die Funktionsweise des Verfahrens hier nicht erklären wirst, weil sie geheim ist? Sorry, aber die ganze Geschichte interessiert mich nicht die Bohne!

Ich dachte aus der Beschreibung worum's geht ohnehin schon von Beginn an "what's the fuzz about?", denn angefangen mit Gerzon/Craven waren mir die entsprechenden Ideen im Wesentlichen bekannt. Ich wäre bloß im Traum nicht auf die Idee gekommen, einfach das unterste Bit direkt herzunehmen, wie Du in Deinem HB-Verfahren, weil mir klar war daß das hörbare Konsequenzen haben kann.

Entscheidend für unser Thema hier ist doch bloß ob das Verfahren erlaubt, Bitfehler im Audio zu erkennen, und da sind wir keinen Millimeter weiter. Für den Zweck der Unterbringung des Timecodes im Audio ist das sicher nicht nötig, und wie ich schon andeutete sogar tendenziell kontraproduktiv, weil dann sogar Fehler in Audiobits, die mit dem Timecode nichts zu tun haben, zu Timecode-Fehlern führen.

Folglich: Du hast mal wieder einen enormen Textschwall zur eigenen Glorie, aber nicht zur Erhellung der eigentlichen Frage produziert. Wie üblich bei Dir, muß man inzwischen sagen.
-scope-
Hat sich gelöscht
#120 erstellt: 07. Jul 2013, 15:44

Folglich: Du hast mal wieder einen enormen Textschwall zur eigenen Glorie, aber nicht zur Erhellung der eigentlichen Frage produziert. Wie üblich bei Dir, muß man inzwischen sagen.


Das machen Politiker ja ebenso, wenn man ihnen eine Frage stellt

Micht interessiert vielmehr, wie es zu unterschiedlichem Klang zwischen CD-R kommen kann (soll) , wenn man "weitgehende" Bitidentität und den selben Brenner etc. voraussetzt.


[Beitrag von -scope- am 07. Jul 2013, 19:18 bearbeitet]
Axel_Hucht
Hat sich gelöscht
#121 erstellt: 11. Jul 2013, 13:56

pelmazo (Beitrag #119) schrieb:
...Entscheidend für unser Thema hier ist doch bloß ob das Verfahren erlaubt, Bitfehler im Audio zu erkennen, und da sind wir keinen Millimeter weiter. Für den Zweck der Unterbringung des Timecodes im Audio ist das sicher nicht nötig, und wie ich schon andeutete sogar tendenziell kontraproduktiv, weil dann sogar Fehler in Audiobits, die mit dem Timecode nichts zu tun haben, zu Timecode-Fehlern führen.


Die Möglichkeit Bitfehler zu erkennen halte ich für hinreichend geklärt.

Ich hatte auch bereits geschrieben, dass RSP-pro aus den ausführlich dargelegten Gründen nicht ( !! ) mit dem "Bitstellenzweckentfremdungs-Verfahren" arbeitet.

Die Hilfsinformationen wie LTC oder CUE können aus keiner Bitstelle decodiert werden.

Vielmehr ist ein Sample der jeweilgen Hilfsinformation in allen 16 Bits des Datenwortes des rechten bzw linken Audio-Subchannels eingebettet. Die Hilfdaten werden mit der Audio-Abtastfrequenz gesampled.

Zu Decodierung von RSP-pro sind dementsprechend alle 16 Bit der Datenworte zwingend nötig, womit logischerweise auch keine "Bitstellenzweckentfremdung" mehr vorliegt, da die Musik ja weiterhin in so gut wie unverminderter Qualität abgespielt werden kann.

Bei "Bitstellenzweckentfremdung" der ganzen 16 Bit gäbe es gar keine Musik mehr zum Wiedergeben, womit die Patente nach BLÜTHGEN/Philips, BÄSSGEN und Gerzon/Craven zum "Bitstellenzweckentfremdungs-Verfahren" hier überhaupt nicht greifen.


".... Audiobits, die mit dem Timecode nichts zu tun haben"

... gibt es bei RSP-pro garnicht, eine derartige Betrachtungsweise ist schlichtweg unzutreffend.


Die Erkennung von Bitfehlern bei der Wiedergabe von Datenträgern, die fehlerfrei mit einer korrekten Kodierung von Hilfsdaten mit konstantem Dateninhalt bespielt wurden, ist sowohl bei der ursprünglichen Kodierung im HB II -Format ( BÄSSGEN, STUMPFL, CREAMWARE, HILGER&BREMEN, HUCHT-BÜCHELER und weitere Anwender ) wie auch im RSP-pro Format problemlos möglich:

Die Entscheidung, ob das Wiedergabegerät ( CD-Player / DAT etc ) in systematischer Weise den Datenträger nicht richtig wiedergeben kann oder ob die Aufzeichnung nicht korrekt erfolgt ist, die kann man bei beiden Formaten ganz einfach treffen, indem man für einen der Hilfskanäle den konstanten Wert "low" kodiert und in den anderen den konstanten Wert "high" und sich die Ausgangssignale des jeweiligen Decoders bei der Wiedergabe ansieht.

Beim HB II- Decoder zeigen dann konstante Ausgangssignale, die nicht diesen low und high-Werten entsprechen ( wie z.B. zweimal low oder gar ein Rauschsignal ) unmittelbar an, dass das verwendete Wiedergabegerät für diese Zwecke unbrauchbar bzw. defekt ist.

Das ist dann der direkte Beweis, dass die Wiedergabe nicht bitidentisch erfolgt.

Was ein RSP-pro-Decoder in solcher Situation ausgibt hatte ich bereits angegeben.

Mit so einem Decoder lässt sich auch unmittelbar zeigen, dass eine Wiedergabe nicht bitidentisch ist.



Der noch übrig bleibende Fall ist, dass ein einwandfreies Wiedergebegerät gelegentlich Fehler nicht korrigieren kann und dann Schätzwerte ausgibt ( Interpolation bzw Mute ).

Das führt dann bei Wiedergabe von Musik in etwa 50% der Fälle mit Schätzwerten zu einem fehlerhaften Ausgangssignal der Hilfskanäle wie man bei HB II statistisch erwarten würde und wie ich bereits in den 90ern durch Messungen bestätigt hatte.

Der RSP-pro -Decoder verhält sich auch in ca 50% der Fälle so, wobei dann allerdings kein fehlerhaftes einzelnes Sample, sondern ein Burst von 24 fehlerhaften Samples der Hilfsdaten ausgegeben wird, was von einem Timecode Reader aber letztlich genauso als Error interpretiert wird.
Hier egeben sich also in der Praxis keine Unterschiede..

Die "Ansprechwahrscheinlichkeit" von ca 50% ist nach meinen Messungen aber für beide Verfahren praktisch gleich,
die Ansprechkriterien für den RSP-pro-Decoder hatte ich bereits angegeben.

Das RSP-pro-Verfahren ist in dieser Beziehung nicht schlechter als das HB II-Verfahren, nichtmal "tendenziell"...

Zusätzlich erhält man dann noch eine ERROR-Anzeige des Errorbit-Decoders, der in allen meinen AV-Copyprocessoren und AV-Digitaldecodern zur serienmässigen Ausstattung gehört.

Im laufenden Wiedergabebetrieb können somit Interpolationen über zwei verschiedene Auswertungen angezeigt werden, also sogar teilweise redundant.


[Beitrag von Axel_Hucht am 11. Jul 2013, 14:30 bearbeitet]
pelmazo
Hat sich gelöscht
#122 erstellt: 12. Jul 2013, 17:56

Axel_Hucht (Beitrag #121) schrieb:
Die Möglichkeit Bitfehler zu erkennen halte ich für hinreichend geklärt.


Das ist so dreist wie sinnlos. Für wie blöd hältst Du die Mitleser hier?


Ich hatte auch bereits geschrieben, dass RSP-pro aus den ausführlich dargelegten Gründen nicht ( !! ) mit dem "Bitstellenzweckentfremdungs-Verfahren" arbeitet.


Das war mir klar. Du hast meinen Text offenbar nicht verstanden, wenn Du es für nötig hältst, das zu betonen. Ich sehe keinen Sinn darin, auf diese sinnlose Klarstellung zu antworten.


Das ist dann der direkte Beweis, dass die Wiedergabe nicht bitidentisch erfolgt.

Was ein RSP-pro-Decoder in solcher Situation ausgibt hatte ich bereits angegeben.

Mit so einem Decoder lässt sich auch unmittelbar zeigen, dass eine Wiedergabe nicht bitidentisch ist.


Die Frage ist, ob sich damit zeigen läßt daß sie bitidentisch war. Ich gestehe Dir ja ohne Weiteres zu daß ein Fehler in der kodierten Hilfskanal-Information zeigt, daß die Wiedergabe nicht bitidentisch ist. Das ist eine Trivialität, die ich nicht für der Erwähnung wert halten würde. Die Frage ist aber, ob die Wiedergabe als bitidentisch nachgewisen ist, wenn es keinen Fehler im Hilfskanal gab. Dazu müßte nämlich jeder beliebige Bitfehler im Audiosignal dazu führen, daß die Information im Hilfskanal ungültig wird. Weder ergibt sich das von selbst, noch hast Du das argumentativ gezeigt. Der folgende von Dir beschriebene Fall zeigt mir sogar, daß das eben nicht gilt, und damit mein Einwand weiter besteht.


Der noch übrig bleibende Fall ist, dass ein einwandfreies Wiedergebegerät gelegentlich Fehler nicht korrigieren kann und dann Schätzwerte ausgibt ( Interpolation bzw Mute ).

Das führt dann bei Wiedergabe von Musik in etwa 50% der Fälle mit Schätzwerten zu einem fehlerhaften Ausgangssignal der Hilfskanäle wie man bei HB II statistisch erwarten würde und wie ich bereits in den 90ern durch Messungen bestätigt hatte.


Wenn man dieser statistischen Schätzung folgen mag, dann bedeutet das wohl, daß man nur im Mittel die Hälfte der Wiedergabefehler durch einen korrumpierten Hilfskanal bemerken würde, und eben nicht alle. Ich bin aber weit davon entfernt, solche Schätzungen aus Deiner Feder für ernst zu nehmen, angesichts der Böcke die Du regelmäßig schießt.


[Beitrag von pelmazo am 12. Jul 2013, 17:58 bearbeitet]
Axel_Hucht
Hat sich gelöscht
#123 erstellt: 12. Jul 2013, 20:10

pelmazo (Beitrag #122) schrieb:
...dann bedeutet das wohl, daß man nur im Mittel die Hälfte der Wiedergabefehler durch einen korrumpierten Hilfskanal bemerken würde, und eben nicht alle.


Genau so hatte ich das gemessen: bei einer mit HB II bzw. RSP-pro kodierten Audio-CDR bei Wiedergabe des Audiotracks im CD-Player mit einem am Digitalausgang angeschlossenen AV-Digitaldecoder in einem der Audio-Subchannel die Anzahl der Errorflags und die Anzahl der fehlerhaften Samples der Hilfsdaten mit zwei Impulszählern über die Spieldauer des Testracks (einige Minuten) die Pulse aufsummiert.

Die Brennqualität war dabei sehr lausig ( Rohling für höhere Brenngeschwindigkeiten auf altem CD-Recorder für Rohlinge mit 1 x Speed aufgezeichnet ) und es ergaben sich bei Wiedergabe mehrere hundert Interpolationen. Es gab aber keine Aussetzer durch Mute.

Bei beiden Kodierverfahren war die Anzahl der fehlerhaften Samples der Hilfsdaten etwa die Hälfte der Zahl der Errorflags.

Bei RSP-pro wurde die Fehlerbedingung in einem Schaltungsteil abgefragt, der vor dem Teil liegt der den Fehlerburst von 24 Samples erzeugt ( damit diese Fehler nicht mehrfach gezählt werden ).

Daraus ergibt sich z.B. dass das LSB bei ca 50% der Interpolationen seinen Wert wechselt.



Aus welchem Grund wird eigentlich hier jetzt so penetrant auf der Frage rumgeritten, ob sich nun auch wirklich jedes fehlerhafte Audiodatenwort mit einem "Schnelltest" mit RSP-pro nachweisen lässt?

Das ist für die Ausgangsfrage doch überhaupt nicht wirklich wichtig.

Es lässt sich mit diesem RSP-pro-Test bei Wiedergabe einer CDR, die zum Zwecke des klanglichen Vergleichs zwischen zwei verschiedenen Verbindungsleitungen aufgenommen wurde, doch unmittelbar ermitteln, ob irgend ein gravierendes Problem mit der Aufnahme, dem Datenträger oder dem Abspielgerät besteht.

In diesem Fall erhält man bei den RSP-pro-Hilfsdaten Fehlerraten von zigtausend pro Sekunde und damit praktisch ein Dauerleuchten der bereits genannten Anzeige-LEDs.
Dabei ist es doch wirklich unerheblich, ob ich dabei jeden oder im Mittel nur jeden zweiten Fehler erfasse.

Dauerleuchten bleibt Dauerleuchten.

Damit kann ich zumindest sicher sagen, dass ich den Hörvergleich garnicht erst beginnen brauche, weil etwas grob nicht stimmt. Und genau darum ging es.

Genau zu diesem Zweck hatte ich die Anwendung von RSP-pro-kodierten Testtracks und die Verwendung eines die Wiedergabe begleitenden AV-Digitaldecoders vorgeschlagen:
weil sich damit die Kompatibilität des Datenträgers mit dem verwendeten Abspielgerät blitzschnell überprüfen lässt.

Wenn ich dann feststelle dass die Wiedergabe über das konkrete Abspielgerät ( in diesem Falle wohl ein CD-Player ) ok ist, dann können im laufenden Wiedergabebetrieb höchstens noch gelegentliche Interpolationen bei nicht korrigierbaren Lesefehlern auftreten.

Das dürften bei einer ordentlich gebrannten CD-R und einem Testtrack von wenigen Minuten wohl eine Anzahl sein, die ich mit ein paar Fingern abzählen kann.

Über deren klangliche "Relevanz" möchte ich mich hier nicht auslassen.

Welchen ach so gravierenden Nachteil hätte ich dann in der Praxis, wenn dann während der Spieldauer des Tracks die Anzeige für das ERROR-Bit dann z.B. 9 x aufleuchten würde, ich aber nur z.B. 5 x eine Fehlersituation bei den Hilfsdaten sehen würde?

Meiner Ansicht nach gar keinen, ist wie mit dem Sack Reis in China.

Aber Haupsache ein für die Ausgangsfrage völlig unbedeutendes Detail gefunden, auf dem sich wieder vortrefflich rumreiten lässt...


[Beitrag von Axel_Hucht am 12. Jul 2013, 20:24 bearbeitet]
-scope-
Hat sich gelöscht
#124 erstellt: 12. Jul 2013, 20:32

Das dürften bei einer ordentlich gebrannten CD-R und einem Testtrack von wenigen Minuten wohl eine Anzahl sein, die ich mit ein paar Fingern abzählen kann.


Unter den genannten Bedingungen sind es dann exakt "null" Interpolationen.


Über deren klangliche "Relevanz" möchte ich mich hier nicht auslassen.


Aber ich : Sie ist dann "null".
pelmazo
Hat sich gelöscht
#125 erstellt: 12. Jul 2013, 23:07

Axel_Hucht (Beitrag #123) schrieb:
Daraus ergibt sich z.B. dass das LSB bei ca 50% der Interpolationen seinen Wert wechselt.


Das wiederum ist ebenfalls wieder ein triviales Ergebnis, das so zu erwarten gewesen war.


Aus welchem Grund wird eigentlich hier jetzt so penetrant auf der Frage rumgeritten, ob sich nun auch wirklich jedes fehlerhafte Audiodatenwort mit einem "Schnelltest" mit RSP-pro nachweisen lässt?

Das ist für die Ausgangsfrage doch überhaupt nicht wirklich wichtig.


Es ist aber wichtig für die Frage, was an Deinen Ausführungen Hand und Fuß hat. Es ist schließlich nicht ganz so einfach, aus Deinen ausschweifenden Selbstdarstellungen die handfesten Aussagen herauszudestillieren, und folglich zu beurteilen welche Schlußfolgerungen von Dir für bare Münze zu nehmen sind, und welche nicht.

Es ist leider erheblich anstrengender als es sein müßte, und die Ausbeute an Substanz ist enttäuschend.


Es lässt sich mit diesem RSP-pro-Test bei Wiedergabe einer CDR, die zum Zwecke des klanglichen Vergleichs zwischen zwei verschiedenen Verbindungsleitungen aufgenommen wurde, doch unmittelbar ermitteln, ob irgend ein gravierendes Problem mit der Aufnahme, dem Datenträger oder dem Abspielgerät besteht.


Das war aber gar nicht die Frage, sondern es ging darum ob die Möglichkeit zuverlässig ausgeschlossen wurde, daß für wahrgenommene Klangveränderungen auch Bitfehler verantwortlich gewesen sein können. Darüber hast Du ein Riesenbrimborium angezettelt, das die Frage letztlich doch nicht überzeugend geklärt hat.

Ob das hörbar war ist in der Tat noch ein davon getrennt zu betrachtender Punkt, an dem Du noch erheblich schlechter aussiehst, denn dazu fällt Dir außer empörtem Getue überhaupt nichts ein.
cr
Inventar
#126 erstellt: 13. Jul 2013, 01:00
Apropos Dauerleuchten: So ganz einleuchtend war mir das Verhalten der ErrorLED beim CDQ1 noch nicht:
Bei manchen kopiergeschützten CDs leuchtete es zB regelmäßig, aber nur alle paar Sekunden kurz auf. Laut Analyse mit Plextor sind aber laufend Unkorrigierbare in größerer Menge vorhanden.
Wieso gab es bei einigen solchen CDs also nur vereinzeltes Leuchten, bei anderen aber fast durchgehendes Leuchten.
(welche das waren, das müßte ich mühsam herausfinden, es ist schon Jahre her....)

Wie sicher leuchtet die LED vom CDQ1 überhaupt bei vereinzelten Fehlern? Werden die alle angezeigt?


[Beitrag von cr am 13. Jul 2013, 01:01 bearbeitet]
Axel_Hucht
Hat sich gelöscht
#127 erstellt: 19. Aug 2013, 11:48

cr (Beitrag #126) schrieb:

Wie sicher leuchtet die LED vom CDQ1 überhaupt bei vereinzelten Fehlern?
Werden die alle angezeigt?

JA ! ( wie bei allen meinen Produkten mit Errorbit-Anzeige, also ab 1992 )
Die Errorflags der rechten und linken Subframes aus dem SPDIF- bzw AES/EBU-Subcode triggern einen retriggerbaren
monostabilen Multivibrator mit etwa 100 ms Haltezeit, der dann die LED antreibt.

Ein einziges Errorflag reicht zum Triggern.

RTFM: Siehe Bedienungsanleitung CDQ1, Seite 3, Abschnitt "Anzeigefunktionen", Absatz "Errorbit-LED":

".... Bereits ein einzelnes Error-Bit reicht zum Auslösen der Anzeige...."


Bei manchen kopiergeschützten CDs leuchtete es zB regelmäßig, aber nur alle paar Sekunden kurz auf.
Laut Analyse mit Plextor sind aber laufend Unkorrigierbare in größerer Menge vorhanden.


Was für ein CD-ROM-Laufwerk als unkorrigierbar erscheint, das muss anscheinend für einen Audio-CD-Player noch
lange nicht unkorrigierbar sein.

Das war ja ( soweit ich mich entsinne ) die Grundidee dieses Verfahrens mit den künstlich erhöhten Fehlerraten,
mit dem ja gerade das Auslesen mittels CD-ROM- bzw. DVD-Laufwerken erschwert werden sollte.


[Beitrag von Axel_Hucht am 19. Aug 2013, 15:05 bearbeitet]
cr
Inventar
#128 erstellt: 19. Aug 2013, 13:09
Jedenfalls hat diese LED viel Freude bereitet, weil sie bei normalen CDs und auch meinen CDR/Ws nie aufleuchtete, während ich vorher immer Zweifel hatte, ob wirklich alles korrekt gelesen wird.
Den Copy-Prozesser lasse ich immer noch parallel zum CDP laufen wegen der LED........ bzw. als SPDIF-Verteiler bzw. Opto/Koax-Wandler und umgekehrt auch gut zu gebrauchen......

War auch hilfreich beim Kauf neuer CDPs. Bin dann mit dem Prozessor und einigen nicht optimal gebrannten CDRs in den Laden gegangen und habe geschaut, was der CDP macht. Manche lesen nicht perfekte CDRs wirklich schlecht!


[Beitrag von cr am 19. Aug 2013, 13:12 bearbeitet]
Axel_Hucht
Hat sich gelöscht
#129 erstellt: 19. Aug 2013, 15:36

cr (Beitrag #128) schrieb:
Jedenfalls hat diese LED viel Freude bereitet....

Den Copy-Prozesser lasse ich immer noch parallel zum CDP laufen wegen der LED........
bzw. als SPDIF-Verteiler bzw. Opto/Koax-Wandler und umgekehrt auch gut zu gebrauchen......

War auch hilfreich beim Kauf neuer CDPs. Bin dann mit dem Prozessor und einigen
nicht optimal gebrannten CDRs in den Laden gegangen und habe geschaut, was der CDP macht....


Ja, genau so soll es ja auch sein:

das sind ja auch genau die Hauptfunktionen ( !! ), für die das Produkt seinerzeit "entworfen, hergestellt und beworben" wurde.....

Und nicht etwa das "Ermöglichen, Erleichtern oder Verschleiern" von "Verletzungen von Rechten Dritter", so wie mir interessierte Kreise das immer böswillig unterstellt hatten....

Deshalb wurde der CDQ1 ja auch letztlich noch zur Klarstellung in ERRMO-EU umbenannt ( Errorbit-Monitor, konform mit EU-Richtlinien ). ( 2002 )

Genützt hatte das letztlich nix, die Hetzkampangne der interessierten Kreise und die "Drohbriefe" an die Fachzeitschriften hatten dann doch zum Bankrott meiner früheren Firma geführt:

Hier z.B. der liebenswürdige Doc Spiesecke in der Fachpresse ( ca 2003 ) und ein bekannt gewordener Drohbrief der IFPI:



Also nochmal:

"rot-grün" hatte 203 das Urhebergesetz aktualisiert, um "vor allem" irgendwelchen Kleinkrauterbuden, in denen am Küchentisch irgendwelche Daten-Interface für digitales Audio zusammengelötet werden, "das Handwerk zu legen"....

Also, um gestandene Kleinunternehmer nach etwa fünfzehn Jahren erfolgreicher Entwicklung und Fertigung praktisch über Nacht auf eine Stufe mit Einbrechern, Bankräubern, Hühnerdieben, Kinderporno-Fans und "alten Omas die Handtasche-Klauern" zu stellen...

Das Ergebnis der Drohbiefe war jedenfalls für mich wirtschaftlich fatal:

Zuerst wurde ich danach fortan in den Hifi-Blättern nur noch als der Bösewicht dargestellt ( "drei Jahre Haft für...." ) und darauf hin garnicht mehr, also totgeschwiegen....

( Dafür hat jetzt heute dieser Staat einen Hartz-IV-Empfänger mehr...)



Jaja, dank der heldenhaften "rot-grünen" Gesetzgebung herrscht jetzt endlich wieder "Hucht und Ordnung" in diesem Lande.


[Beitrag von Axel_Hucht am 20. Aug 2013, 11:53 bearbeitet]
cr
Inventar
#130 erstellt: 19. Aug 2013, 15:44
Als ob die CD-Kopien (in Relation zum Download) je das große Problem gewesen wären......
Und die Kopien per Audiorekorder, die stets nur ein Nischendasein fristeten, im Speziellen..... wobei hier die Verbraucher eh noch mit der GEMA-Abgabe auf CDRs abgezockt wurden
Und das Rippen per PC konnte sowieso nie verhindert werden. Praktisch jeder brauchbare Brenner rippt jede CD ohne Probleme, ohne spezielle Software. Er braucht nur Redbook-konform zu lesen (Interpolation und Ignorieren der 2. Session und das wars)
Axel_Hucht
Hat sich gelöscht
#131 erstellt: 09. Dez 2013, 17:59

-scope- (Beitrag #58) schrieb:
...... Auch die "plem-plem-Mikrofonie" auf die der Quartz reagiert, kann man vergessen.

Spinnerte Esoterikdesigns, in denen der gesamte Oszillator aufwendig an Gummibändern im Gehäuse baumelt sind eher eine traurige Nummer.



Da haben sich jetzt doch tatsächlich irgendwelche plem-plem Esoterikspinner bis in die professionelle Mikrowellentechnik eingeschlichen
und hängen doch tatsächlich irgendwelche Schwingungserzeuger ( YIG-Oszillatoren ) in plem-plem - Gummibändern auf....

Einfach nur völlig plem-plem...... "Mikrofonie", die gehören doch in die Klapse !

Kann man total vergessen, einfach nur Schwachsinn sowas....



-scope-
Hat sich gelöscht
#132 erstellt: 09. Dez 2013, 18:08
delete


[Beitrag von -scope- am 09. Dez 2013, 18:10 bearbeitet]
-scope-
Hat sich gelöscht
#133 erstellt: 09. Dez 2013, 18:09

Einfach nur völlig plem-plem...... "Mikrofonie", die gehören doch in die Klapse !


Du wirst es mit 100%iger Sicherheit nicht nachvollziehen, aber die Summe der Aufwendungen richtet sich nach dem jeweiligen Einsatzzweck bzw. Einsatzbereich.
Solche Geräte müssen z.B. auch in rauhen "Feldeinsätzen" oder Industrieumgebungen noch innerhalb der Toleranzen funktionieren. Dazu kommt natürlich noch die Tatsache, dass sich Phasenrauschen oder Mikrofonie in den gemessenen Ergebnissen finden lassen. (es sind Messgeräte, keine Musikgeräte)


Ich habe grundsätzlich "nichts dagegen" , wenn man einen Oszillator auch in einem CD-PLayer irgendwie beruhigt. Es sind vielmehr die ausgesprochen bescheuerten Behauptungen über die Sterigerung des "Musikgenusses" , die in diesem Zusammenhang von Tunern gerne abgesondert werden.


[Beitrag von -scope- am 09. Dez 2013, 18:22 bearbeitet]
Sal
Inventar
#134 erstellt: 11. Dez 2013, 15:44
Nun, ich hoffe solch eine seitenlange Diskussion hat sich mit cdparanoia relativ erledigt?

http://wiki.hydrogenaudio.org/index.php?title=Cdparanoia
cr
Inventar
#135 erstellt: 11. Dez 2013, 17:28
Die Diskussion hat sich einerseits mit EAC schon erledigt oder andererseits durch die Plextor-Laufwerke ab dem Plextor SCSI-CDROM, die auch so fehlerfrei lesen. Eigentlich ist die Geschichte seit dem Jahr 2000 gegessen, aber bei manchen halt bis jetzt noch nicht angekommen......
Sal
Inventar
#136 erstellt: 11. Dez 2013, 20:31
Oooch, ich mag es aber schon, eine CD noch in einem klassischen Player abzuspielen
Der haptische Verlust von der Schallplatte zur CD war durch den klangliche Gewinn zu verschmerzen, aber von der CD zur Festplatte - und auch die verlieren nach 4 jahren Dauerbetrieb rasch an Daten, was aber durch recht frühe Backups zu vermeiden ist.

http://www.extremete...es-actually-live-for
Axel_Hucht
Hat sich gelöscht
#137 erstellt: 19. Dez 2013, 12:07

cr (Beitrag #135) schrieb:
Die Diskussion hat sich einerseits mit EAC schon erledigt oder andererseits durch die Plextor-Laufwerke ab
dem Plextor SCSI-CDROM, die auch so fehlerfrei lesen.
Eigentlich ist die Geschichte seit dem Jahr 2000 gegessen, aber bei manchen halt bis jetzt noch nicht angekommen......


nun, das ist aber schon heftig OT.

Es ging dem Themenersteller in keiner Weise darum, wie man irgendwelche Daten von einer CD auf eine Festplatte
oder sonstigen Datenträger umkopiert, sondern ausschliesslich um eine Echtzeitanwendung, nämlich das Ansteuern
eines externen D/A-Wandlers über den optischen SPDIF-Digitalausgang eines etwas älteren CD-Players.

Also letztlich um die Frage, ob es bei der technischen Weiterentwicklung von CD-Payern klanglich relevante Fortschritte
bei den Digitalausgängen gegeben hat ( wohl mit dem Hintergrund, ob sich die Anschaffung eines neuen CD-Players
klanglich lohnt ).

Der Betrieb von externen D/A-Wandlern ist immer noch eine absolute Standardanwendung im Bereich der digitalen
Audiotechnik, heute noch millionenfach im Einsatz und ganz sicher noch Lichtjahre davon entfernt, "seit dem Jahr 2000 gegessen"
zu sein.

Da dem TE offenbar ein klanglich gutes Ergebnis vorschwebte, hatte ich ihm aus meiner praktischen Erfahrung der ganzen
Jahre, in denen ich mich damals selbst mit dieser Problematik beschäftigt hatte, einige praktische Tipps gegeben.

Das hatte ja dann -- wie man in dieser "seitenlangen Diskussion" nachlesen kann -- sofort ein Protestgeheul der
selbsternannten Obergutachter der Forumpolizei hervorgerufen, die da meinten, mich mich allen möglichen Pöbelleien
und Beleidigungen überziehen zu müssen.

Wie ich kürzlich gelesen habe, hat sich ja einer dieser "alles-und-jedes-besser-Wisser" nun hier vom Acker gemacht.

Menschlich sehe ich das "Ausscheiden" eher als Bereicherung des Forums, aber fachlich eher schade, ich hätte da noch
einige Fragen zu den diversen hier vorgetragenen Behauptungen gehabt-- und natürlich noch viel mehr zu an anderen
Stellen gemachten Aussagen, die ich aber erst gerade vor einigen Tagen gelesen hatte.

Nun gut, weg ist weg...
-scope-
Hat sich gelöscht
#138 erstellt: 19. Dez 2013, 12:30


Menschlich sehe ich das "Ausscheiden" eher als Bereicherung des Forums


Gerade "menschlich" ist er dir doch nie zu nahe getreten. Er hat lediglich deine "fachlichen" Behauptungen, und vor allem die damit in Verbindung stehenden, angeblich hörbaren Verbesserungen in Frage gestellt.

....völlig zu Recht.

Für die entsprechenden Themenbereiche des Forums ist sein Austritt ein großer Verlust...Würdest DU dich hier löschen, wäre das ganz sicher nicht der Fall.


[Beitrag von -scope- am 19. Dez 2013, 12:33 bearbeitet]
drSeehas
Inventar
#139 erstellt: 19. Dez 2013, 19:46

Axel_Hucht (Beitrag #137) schrieb:
... Der Betrieb von externen D/A-Wandlern ist immer noch eine absolute Standardanwendung im Bereich der digitalen
Audiotechnik, heute noch millionenfach im Einsatz und ganz sicher noch Lichtjahre davon entfernt, "seit dem Jahr 2000 gegessen"
zu sein...

Externe D/A-Wandler werden heute über USB angeschlossen.

Wie ich kürzlich gelesen habe, hat sich ja einer dieser "alles-und-jedes-besser-Wisser" nun hier vom Acker gemacht.

Menschlich sehe ich das "Ausscheiden" eher als Bereicherung des Forums, aber fachlich eher schade, ich hätte da noch
einige Fragen zu den diversen hier vorgetragenen Behauptungen gehabt-- und natürlich noch viel mehr zu an anderen
Stellen gemachten Aussagen, die ich aber erst gerade vor einigen Tagen gelesen hatte.

Nun gut, weg ist weg...

Es handelt sich wohl um pelmazo.
Axel_Hucht
Hat sich gelöscht
#140 erstellt: 19. Dez 2013, 22:03

drSeehas (Beitrag #139) schrieb:
Externe D/A-Wandler werden heute über USB angeschlossen.


Wo bekomme ich einen CD-Player mit USB-Ausgang ? Bitte wenigstens ein aktuell erhältliches Modell nennen !
drSeehas
Inventar
#141 erstellt: 19. Dez 2013, 23:59

Axel_Hucht (Beitrag #140) schrieb:
... Wo bekomme ich einen CD-Player mit USB-Ausgang ? Bitte wenigstens ein aktuell erhältliches Modell nennen !

CD-Spieler sind Geräte aus dem letzten Jahrhundert, sowas benutzt man heute nicht mehr.
cr
Inventar
#142 erstellt: 20. Dez 2013, 00:25

Axel Hucht schrieb:
nun, das ist aber schon heftig OT.


Was soll daran off-topic sein? Die Antwort bezieht sich auf die Anfrage zum Extraktionstool cdparanoia.
Ich denke nicht, dass der Fragesteller das Tool als Mediaplayer nützt, auch wenn es durchaus Extraktionstools gibt, die das können (zb Plextools).
Axel_Hucht
Hat sich gelöscht
#143 erstellt: 20. Dez 2013, 18:55

drSeehas (Beitrag #141) schrieb:

Axel_Hucht (Beitrag #140) schrieb:
... Wo bekomme ich einen CD-Player mit USB-Ausgang ? Bitte wenigstens ein aktuell erhältliches Modell nennen !

CD-Spieler sind Geräte aus dem letzten Jahrhundert, sowas benutzt man heute nicht mehr.


Danke für die Belehrung, aber die beantwortet nicht meine Frage.

USB ist auch aus dem letzten Jahrhundert, hatte ich mitsamt Standardtreibern für USB-Audiodevice schon bei Windows 98.
Oder war das sogar schon bei Windows 95 drin ? Egal, jedenfalls Schnee von vorvorgestern....


Ich kann an jeder Ecke CD-Spieler in allen möglichen Ausführungen und Preisklassen erwerben. Offensichtlich werden die sehr wohl noch benutzt.

Also nochmal meine Frage:

wie bekomme ich von einem CD-Spieler die Daten in den USB-Eingang eines externen D/A-Wandlers ?

Benötige ich dazu einen SPDIF --> USB-Wandler ? Wenn ja, bitte ein Modell nennen !


[Beitrag von Axel_Hucht am 20. Dez 2013, 22:44 bearbeitet]
drSeehas
Inventar
#144 erstellt: 20. Dez 2013, 19:08

Axel_Hucht (Beitrag #143) schrieb:
... Ich kann an jeder Ecke CD-Spieler in allen möglichen Ausführungen und Preisklassen erwerben. Offensichtlich werden die sehr wohl noch benutzt.

Ir­re­le­vant.
Du kannst an jeder Ecke jeden Sch... kaufen.

... wie bekomme ich von einem CD-Spieler die Daten in den USB-Eingang eines externen D/A-Wandlers ? ...

S. o.
Wer benutzt denn heute noch so was Überholtes wie einen CD-Spieler?
trekkie65
Ist häufiger hier
#145 erstellt: 20. Dez 2013, 19:27
Wer benutzt denn heute noch so was Überholtes wie einen CD-Spieler?[/quote]

Ich, und zwar täglich , mit einem 20 Jahre alten Player!

Gruss trekkie
drSeehas
Inventar
#146 erstellt: 20. Dez 2013, 19:35

trekkie65 (Beitrag #145) schrieb:
... täglich , mit einem 20 Jahre alten Player! ...

Und welchen externen D/A-Wandler benutzt du damit?
cr
Inventar
#147 erstellt: 20. Dez 2013, 19:45
Ein externer Wandler zum CDP ist sowieso sinnlos, es sei denn, man hat überhaupt einen Wandler als Vorverstärker (wie von emotiva oder so, zB). Was soll das sonst bringen? Damit zwei Kisten herumstehen?
Ah ja, jeder Wandler klingt ja anders wegen dem Jitter
drSeehas
Inventar
#148 erstellt: 20. Dez 2013, 19:52

cr (Beitrag #147) schrieb:
Ein externer Wandler zum CDP ist sowieso sinnlos, ...

Naja, wie du oben lesen kannst, finde ich heutzutage schon einen CDP sinnlos...
Ggf. rippen und gut ist.

Das mit dem externen D/A-Wandler habe ich ja nur geschrieben, weil sich dieser ganze Thread darum dreht (drehen sollte).


[Beitrag von drSeehas am 20. Dez 2013, 19:55 bearbeitet]
cr
Inventar
#149 erstellt: 20. Dez 2013, 19:56
Ich habe auch alles gerippt und habe trotzdem noch jede Menge CDPs. Warum nicht? Es tut mit nicht weh, eine CD einzulegen, und ich habe auch nicht immer Lust, wenn ich einen Packen neuer CDs habe, die erst mal zu rippen.
Soll jeder machen, was er will, vieles im Leben ist sinnlos, und man macht es doch. Es ist auch sinnlos, auf den Berg zu gehen, und dann wieder herunter, oder mit Skilift hinaufzufahren, um dann herunterzufahren.
Insofern kann man natürlich auch nicht dagegen argumentieren, wenn wer meint, zum CDP dazu noch einen externen Wandler haben zu müssen, weil dieser besser klingt. Nur mir persönlich erscheint das halt noch eine Stufe sinnloser, als einen CDP zu haben.


[Beitrag von cr am 20. Dez 2013, 19:58 bearbeitet]
drSeehas
Inventar
#150 erstellt: 20. Dez 2013, 20:02

cr (Beitrag #149) schrieb:
Ich habe auch alles gerippt und habe trotzdem noch jede Menge CDPs...

Ich vermute, die sind von früher übriggeblieben.
Aber würdest du heute noch einen CDP kaufen?

Ich habe noch mehrere DVD-/BD-Spieler. Aber reine CD-Spieler? Schon lange nicht mehr.
-scope-
Hat sich gelöscht
#151 erstellt: 20. Dez 2013, 20:55

Aber würdest du heute noch einen CDP kaufen?


Ich würde auf jeden Fall noch einen kaufen. Das hat aber damit zu tun, wie man das "Hobby" mir der Musikkonserve betreibt, und was man überhaupt darunter versteht.

Ich orientiere mich dabei gerne an "Star Trek the next Generation" . Jean Luc Picard (der Kapitän) betritt sein "Zimmer" und spricht :

Musik......Einen Tango........Stop ! .....nicht so laut.....Ja!....so ist´s gut.

Das stelle ich mir sehr "übel" vor. Dieser ganze Streaming-Müll ändert nichts an der letztendlichen Wiedergabequalität, aber er "dematerialisiert" das Hobby zunehmend....
Wer will schon in einem "virtuellen Sportwagen" fahren?....Ich zumindest nicht. Auch dann nicht, wenn ich mindestens genauso, wenn nicht sogar schneller ankommen würde. Da ist der Weg das Ziel....
Musik in perfekter Klangqualität aus einer kleinen Plastikdose mit Netzwerkanschluss und 8" Touchscreen ? Bei mir? Niemals..... Zumidndest nicht in absehbarer Zeit.

Da prallen Welten -und möglicherweise auch Generationen- aufeinander. Da wird es auch kein, oder eben wenig gegenseitiges Verständnis geben.


[Beitrag von -scope- am 20. Dez 2013, 20:58 bearbeitet]
drSeehas
Inventar
#152 erstellt: 20. Dez 2013, 21:02

-scope- (Beitrag #151) schrieb:
... Touchscreen ? Bei mir? Niemals..... Zumindest nicht in absehbarer Zeit.

Da prallen Welten -und möglicherweise auch Generationen- aufeinander. Da wird es auch kein, oder eben wenig gegenseitiges Verständnis geben.

Zumindest beim Touchscreen sind wir uns einig.
Mit den Generationen wäre ich mir, zumindest in meinem Fall, nicht so sicher...
trekkie65
Ist häufiger hier
#153 erstellt: 20. Dez 2013, 21:42

drSeehas (Beitrag #146) schrieb:

trekkie65 (Beitrag #145) schrieb:
... täglich , mit einem 20 Jahre alten Player! ...

Und welchen externen D/A-Wandler benutzt du damit?



Na, die der Vorstufen! Der Kenwood hängt digital an beiden, da ich ab und zu auch mit Prologic hören möchte. Ausserdem macht es mir Spass, etwas Physisches in der Hand zu haben, die CD einzulegen und Play zu drücken., Cover anzuschauen.

LG trekkie
Suche:
Gehe zu Seite: |vorherige| Erste 2 3 Letzte |nächste|
Das könnte Dich auch interessieren:
cd player alt gegen neu
frank_frey am 26.05.2011  –  Letzte Antwort am 25.11.2013  –  23 Beiträge
Vergleich - Alt gegen Neu - CD Player
cola am 28.10.2015  –  Letzte Antwort am 26.11.2015  –  21 Beiträge
CD Player alt vs. neu
Mister_McIntosh am 04.08.2010  –  Letzte Antwort am 11.08.2010  –  53 Beiträge
alt gegen neu
Gunny4214 am 26.09.2014  –  Letzte Antwort am 21.10.2014  –  35 Beiträge
CDP Optischer Ausgang
chromlazi am 07.03.2005  –  Letzte Antwort am 08.03.2005  –  3 Beiträge
Yamaha CD Player alt oder neu?
MasterofPuppets am 14.09.2012  –  Letzte Antwort am 17.09.2012  –  12 Beiträge
CD-Player kaufen; neu oder alt ?
driesvds-1 am 19.01.2015  –  Letzte Antwort am 21.02.2015  –  31 Beiträge
CD Player Überempfindlich gegen Stösse.
Cassie am 31.03.2004  –  Letzte Antwort am 05.04.2004  –  26 Beiträge
TosLink Ausgang am CD Player funktioniert nicht
Austin_p am 01.05.2005  –  Letzte Antwort am 02.05.2005  –  4 Beiträge
Decodierung und Protokoll der SPDIF / optischer Schnittstelle beim CD Player
chrisfn_2302 am 24.11.2007  –  Letzte Antwort am 24.11.2007  –  2 Beiträge

Anzeige

Aktuelle Aktion

Partner Widget schließen

  • beyerdynamic Logo
  • DALI Logo
  • SAMSUNG Logo
  • TCL Logo

Forumsstatistik Widget schließen

  • Registrierte Mitglieder925.669 ( Heute: 9 )
  • Neuestes MitgliedCDCzc
  • Gesamtzahl an Themen1.550.899
  • Gesamtzahl an Beiträgen21.533.433

Hersteller in diesem Thread Widget schließen