guten morgen!


sehe ich anders. das könnte man zwar glauben, aber die definition sagt hier etwas anderes. verlustfreie kompression erlaubt auch eine verlustfreie widerherstellung. mit einem decoder/encoder, der verlustfrei komprimieren kann, kann man ebenfalls verlustfrei dekomprimieren.
deswegen schreibt dts ja auch im whitepaper (war das da drinnen?), dass der stream am ende (also am avr) wieder genau die selben infos enthält, wie am mischpult - übertrieben ausgedrückt.
die komp-dekomp routine sind technisch gesehen immer die selben und müssein eingehalten werden. (außer es ist was anderes vorgesehen in den spezifikationen).
zu langsame speicherbausteine oder ähnliches gehört inzwischen der vergangenheit an. ich bau zwar selber keine reciever (noch nicht :rofl:), allerdings kann ein alter pentium75 einen dts-hd core live entpacken, schließlich hat er max 6-7mbit, was ja nichtmal 1 MB/s darstellt.

wie schon gesagt gibt es in jeder komp/dekomp routine prüfziffernabgleiche, die sicherstellen, dass der stream unverfäsclht ankommt. jetzt ist die frage: wird ein fehler festgestellt - bricht der avr das entpacken dann ab, oder macht er einfach weiter? ein dts-techniker wäre langsam hilfreich hier. :rofl:


oben schreibst du, dass die hd tonformate keine fehlerkorrektur besitzten?
ich sehe das nicht als theoretischen vorteil. wenn bei einer komprimierten tonspur ein teil fehlt, fehlt an der stelle deutlich mehr als bei der unkomprimierten. wenn die fehlübertragung zb 100kbyte ausmacht, macht das auch im pcm stream 100kbyte aus, in der dts-hd/true-hd spur macht das aber gleich das 3fache aus zb.
oben schreibst du ebenfalls, dass die hardware bzw speicher eventuell zu langsam sind, um alles schnell gengug zu entpacken - und 2 absätze weiter drunter soll dann der selbe chip ne fehlerkorrektur schaffen?


ich glaube, wir diskutieren hier sowieso um dem kaiser seinen bart. die unterschiede bzw fehler sind heutzutage extrem gering - sieht man ja daran, dass man nicht ununterbrochen bildausfälle hat.
wenn man nun ausfälle im bild nicht warnimmt - die aber deutlich leichter warzunehmen sind als im ton - warum reden dann alle über falschübertragung etc... beim ton und dass man jeden kleinen pfurz raushört?
und interessanterweise hört auch noch jeder diese unregelmäßigkeiten - das finde ich immer am allerbesten: im stream kommen 5bytes nicht an - und einfach ALLE können genau diese fehlenden bytes raushören.
respekt - ohren wie ein luchs :thumb:

Guten Morgen Patrick,

solange es in einer Diskussion um Fakten geht, ist das doch völlig okay. :)

Ein paar Anmerkungen zu deinem Beitrag:
- "Verlustfrei komprimiert" bedeutet, dass man den Originaldatenstrom wiederherstellen kann. Das heißt noch lange nicht, dass das auch immer gelingt, weil das von vielen Faktoren abhängig ist, die nichts mit dem Format des komprimierten Datenstroms zu tun haben. Entscheidend ist aber, was nach der Dekomprimierung passiert. Wie z.B. die Synchronisierung mit dem Bildsignal vorgenommen wird. Wenn die Dekomprimierung "auf Kante genäht" ist, also auf gerade noch ausreichend performanter Hardware läuft, kann es öfter mal eng werden.

- Die Algorithmen sind zwar genormt, nicht aber die Hardware, auf denen sie ausgeführt werden und auch nicht die Programmierer, welche die Algorithmen auf den Zielumgebungen implementieren (die machen auch mal Fehler).

- Ein Fehler in einem komprimierten Datenstrom wirkt sich zwar schwerwiegender aus, tritt aber wegen der geringeren Datenmenge mit geringerer Wahrscheinlichkeit auf.

Gruß
Robert

morgen robert!

mit dir kann man zumindest fachlich diskutieren! :thumb:


d.h. (wenn ich das noch richtig im kopf habe) - es gleicht sich aus. fehler bei komprimierten daten treten weniger oft auf, dafür heftiger, weil mehr verloren geht.
unkomprimierte daten sind natürlich deutlich größer, geht was verloren, wirkt sich das aber deutlich weniger aus.
wird am ende wahrscheinlich ein nullsummenspiel sein schätze ich. ist die frage, ob man diesen verlust wirklich hören kann => ich sage nein, weil wenn ein teil fehlt, bekommt man das als hörer garnicht mit, weil der stream ja nicht abbricht, sondern irgendwo ein ganz kleines geräusch plötzlich fehlt und nach ein paar millisekunden wieder kommt.
dass solche unregelmäßigkeiten ein mensch raushhört - also naja - da kann sich jeder selber sein urteil bilden.:D


die hardware ist nicht genormt, die protokolle aber schon. d.h. jede hardware muss gleich vorgehen (es entpackt zb ein intel i7 nach dem selben muster wie ein phenom 2) - sonst müsste jeder hardwarehersteller alle protokolle auf seine hardware um-normen.
also das protokoll wird immer nach dem gleichen prinzipp abgearbeitet - in der - nennen wir sie cpu - drinnen kann es jedoch unterschiede geben je nach architektur - da stimme ich dir zu.
naja, cpu´s machen keine fehler - oder praktisch keine - vielleicht ist die 100000 milliardstel kommastelle falsch - aber das ist für uns menschen nicht ausschlaggebend bzw hör oder sehbar.


da hast du recht. nur stellt sich jetzt mir die frage: wozu verlustfrei komprimieren, wenn man dann am ende verlustbehaftet dekomprimiert? dafür hätte dolby oder dts ja eine extra komrpimierungsroutine schreiben müssen und eine fürs dekomprimieren - das kann ich mir selber nicht vorstellen bzw kenne ich kein einziges beispiel aus der pc welt, wo das so gemacht wird.

den teil mit syncronisation etc - da hast du recht - ist die frage, wie das von den einzelnen herstellern umgesetzt wird und v.a. wie gut.
ist am pc sektor ja gleich - nvidia´s 5d shader zb arbeiten anders als die von ati.

kennst du keinen dts oder dolby produktdesigner? :D

Es geht da zunächst mal um das zur Verfügung gestellte Potenzial. Wenn die eingestezte Hard- und Software dieses dann nicht optimal ausschöpft, z.B. aus Preisgründen, ist das halt so.

Man kann es aber auch abkürzen:
Auch bei HD-Ton und PCM gibt es zwischen Playern und Receivern unterschiedlicher Qulaitätsstufen hörbare Unterschiede. Das kann ich dir versprechen. :)

Gruß
Robert

Hi

wie Patrick schon sagte werden auch bei Video keine daten verloren. Und da ist die Datenrate wesentlich höher, und man könnte deutlich mitm Finger auf die Fehler zeigen

Und bei dem popeligen Audiostream soll auf einmal was verloren gehen, was dann auch noch gleich alle hören?

das hat aber eher was mit den d/a wandlern zu tun, als mit dem stream ansich mMn.

wiegesagt, die rechenpower zum decodieren von dem futzi-audio-stream ist echt marginal - das kann dir sogar ein arm prozessor aus dem handy live machen.
es gibt für jede routine spezifikationen, die jeder hersteller einhalten muss, um dts-hd und true-hd fähig zu sein + um den sticker zu bekommen, ganz egal wie der hersteller das intern im avr regelt - am ende muss/sollte das selbe rauskommen.


genau darum gehts mir. beim bild merkt keiner was (der aber eine ca 6x höhere datenrate macht und sich fehler deutlichst bemerkbar machen). und beim audiostream hört jeder jedes bit raus. :p

Die Datenrate ist noch viel, viel höher - denn natürlich wird das Bild unkomprimiert übertragen, während die vom Player angezeigte Bitrate die des komprimierten Streams ist.
1920x1080x24 (angenommene Farbtiefe)x24 (Hz) = 1194393600 Bit/s, also fast 1,2 GBit/s, wenn mich nicht alles täuscht.
Dagegen sind die 6,x MBit/s für unkomprimierten Ton (PCM, 48 kHz, 16 Bit) doch zu vernachlässigen.

^^ Von wegen mit dir kann man fachlich diskutieren, habe immer noch keine fachlich schlüssige Antwort gehört ^^

Habe ich doch schon gesagt:
Die mit den niedrigeren Bitraten sind meistens im 16 Bit-Format, die mit den höheren Bitraten im 24 Bit-Format (aber u.U. hochgesampelt, also nur ein Placebo).
Zudem habe ich den Eindruck, dass bei dts die Bitrate des Cores mitgezählt wird, während bei TrueHD der Core nicht reingerechnet wird, weil es sich dem Vernehmen nach tatsächlich um eine separate Spur handelt.

Beispiel hier: https://bluray-disc.de/blulife/blog/tsungam/581-im-a-cyborg-blurayuk
Die Datenrate der dts-Spur entspricht ziemlich genau der Summe der beiden Dolby-Spuren.

Zumindest dass klingt für mich schlüssiger wäre eine Erklärung