Videos auf USB-Stick haben Artefakte - altert ein USB-Stick?

[Nicht die Mama]

Ich hole diesen ganz alten Beitrag mal hoch da ich eine ähnliche Frage habe.

Auf einem USB-Stick, welchen ich am TV betreibe (und daher regelmäßig mit Strom versorgt wird) , habe ich in mehreren Videos seit kurzem "bunte Bildartefakte", in manchen auch "Bild-Stottern" und manche Frames sind bunt-verschwommen. Soweit so gut (oder auch nicht). Erster Gedanke ist halt dass der USB-Stick (bzw. die Sticks) einen weg hat und an sein Ende kommt (auch wenn das (das Dateisystem auf den Stickst in Ordnung ist laut Windows, NTFS).

Was mich aber wundert:
Wenn ich die jeweiligen Dateien nun auf einen anderen Datenträger kopiere so sind die aufgezählten Dinge wohl in der Datei drinnen da diese nach dem Kopiervorgang der Datei auch vorhanden sind.
Wenn ich die Videodateien nun mit dem Original vergleiche (die Originale lassen sich ohne diese Probleme abspielen) so sind beide komplett identisch. Der Hash stimmt nach wie vor bei allen überein und auch bei einem direkten Binärvergleich gibt es keine Unterschiede zwischen den Dateien.

Es sind dieselben Videodaten/Musikdateien und dennoch sind die Dateien unterschiedlich. Das eine Video funktioniert ohne Probleme, das andere ist mit bunten Bildartefakten versehen, stottern und derlei. Gibt es ein Programm oder irgendeine Art wie man die ja vorhandenen Unterschiede bei solchen Dateien feststellen kann (ohne sich die Videos jetzt erst anzusehen bzw. wenn es sich um Daten-Dateien handelt)? Ich meine bei Media-Dateien kann man das ja optisch/akustisch feststellen ob da etwas fehlt/anders ist aber wie soll man das denn bei Daten-Dateien machen? Der Bit-für-Bit Vergleich scheitert da ja und ich war mir sonst immer sicher dass man damit ja einen Unterschied erkennen müßte.

 

[4BitDitherBayer]

Bei Video Dateien ist die Endung sehr wichtig.
Du kannst bspw. eine Video.mkv Datei auch in eine Video.mp4 Datei umbenennen. Das führt dazu das der Player das Video mit den Limitierungen für .mp4 "Bitraten, Keyrames, Audioformat" abspielen will.
Da das Video in Wirklichkeit aber ein .mkv ist kann dies außerhalb der Spezifikationen von .mp4 liegen u. zu den von dir beschriebenen Fehlern führen.

Bei einem Bit-für-Bit Vergleich würden beide Videos identisch aussehen da ja nur ihre Benennung geändert wurde. Vielleicht wurde da ja was durch eine Software verändert.

 

[Vindoriel]

Wobei die eigentlichen Spezifikationen im Header stehen, also am Anfang der Videodatei. Dem VLC oder MPC ist die Dateiendung völlig egal, kannst das Video auch in Video.exe (natürlich lasse ich die Endungen anzeigen, also nichts mit Video.exe.mp4) umbenennen und ins Fenster vom VLC / MPC ziehen, das Video wird einwandfrei abgespielt.

 

[Nicht die Mama]

Es handelt sich jeweils um .mp4 Dateien, die habe ich selbst komprimiert etc. und das Original funktioniert ja bestens. Und die ganzen Macken der Datei(en) die auf dem USB-Stick lagen sind fest in der Datei - es handelt sich nicht um einmalige Abspielfehler.

Und da frage ich mich wie das überhaupt möglich ist wenn doch alles sagt dass die Dateien identisch sind. Und da müßte es dann doch etwas geben um den bestehenden Unterschied irgendwie zu erkennen bzw. eine plausible Erklärung muß es dafür doch geben.

 

[Nicht die Mama]

Ich drücke den Beitrag nochmal hoch.

Hat dazu keiner eine Antwort? Ich finde es allein schon wegen dem Hintergrund interessant dass die Aussage fest im Raum steht (seit jeher) dass man die Integrität einer Datei anhand der zuvor vom Original erstellten Prüfsumme verifizieren kann. Und das mag ja auch absolut richtig sein - doch scheint gerade in Zeiten von Flash-Speicher auch der Datenträger eine Rolle zu spielen. Sehe ich das richtig? Das ist eine reine Vermutung aber anders kann ich mir das nicht erklären. Zwei Dateien, gleiche Prüfsumme, trotzdem unterschiedlich in Frames und Ton.

Ein Rätsel bleibt das für mich trotzdem und ich finde einfach keine richtige Antwort. Bisher ist dieses Verhalten, soweit ich es zumindest mitbekommen habe, auch nur bei USB-Sticks bei mir aufgetaucht (bei 2 Stück, verschiedene Marken). Ich hatte nun auch mal das Original mit der Kopie über einen SHA256 Hash verglichen (soll ja einen Unterschied geben zwischen den verschiedenen Verfahren - wobei ich auch das nicht verstehe da ich davon ausgegangen bin dass ein reiner Bit-für-Bit Vergleich immer gleich ist) und auch hier waren die Daten gleich.

 

[Fusionator]

Wenn ich die jeweiligen Dateien nun auf einen anderen Datenträger kopiere so sind die aufgezählten Dinge wohl in der Datei drinnen da diese nach dem Kopiervorgang der Datei auch vorhanden sind.

Dann ist es schlichtweg nicht möglich, dass die Dateien identisch sind.
Vorausgesetzt du spielst beide Dateien mit dem selben Player ab.

Es gibt die Möglichkeit in einem Hexeditor zwei Dateien miteinander zu vergleichen, bzw. Unterschiede anzeigen zu lassen. HxD sollte das z.B. können.
Und ich würde sagen, dass der Stick Schrott ist, oder der Fernseher irgendein Mist damit treibt.
Aber tendenziell ist ein USB-Stick eben ein USB-Stick. Don‘t trust him

 

[Nicht die Mama]

Wie gesagt ist das ja "in der Datei". Ich kann die kaputte Datei kopieren und die Defekte werden mit kopiert. Also ist das Medium auch egal, ob ich nun von dem USB-Stick oder einer SSD abspiele, auf dem Monitor oder dem Fernseher.

Verglichen habe ich die Dateien schon auf mehrere Arten, geht ja auch über den Total Commander. Dort kann man die Dateiinhalte auch nebeneinander ansehen und Unterschiede werden hervorgehoben in einer Extra-Zeile.

Dass der USB-Stick eine Macke hat ist höchst wahrscheinlich, da die Daten dort drauf ja auch erst "nach und nach Macken bekommen haben". Aber das ändert ja nichts am eigentlichen Problem. Ich war eigentlich auch der Meinung dass eine solche Prüfung eine Datei immer verifizieren kann weil es anders quasi nicht möglich wäre. Wobei "unmöglich" immer irgendwann gesagt wird bis dann das Gegenteil bewiesen wird - vor einer ganzen Weile hätte man auch noch gedacht dass unterschiedliche Dateien nicht dieselbe Prüfsumme haben können.

 

[wuselsurfer]

Dass der USB-Stick eine Macke hat ist höchst wahrscheinlich, da die Daten dort drauf ja auch erst "nach und nach Macken bekommen haben".

Genau so verhält sich ein USB-Stick wenn er sich verabschiedet.

Aber das ändert ja nichts am eigentlichen Problem. Ich war eigentlich auch der Meinung dass eine solche Prüfung eine Datei immer verifizieren kann weil es anders quasi nicht möglich wäre.

Eine Prüfsumme (CRC) addiert die Bits 2, 3, 4 und 7 eines Bytes zum Beispiel.
Das wird bei jedem oder augewählten Bytes gemacht.

Mit Hilfe des Reed-Solomon-Code werden die Prüfbits angesteuert, die einzelne Bitfehler erkennen können.
Längere Fehler sind allerdings schwer zu detektieren.

vor einer ganzen Weile hätte man auch noch gedacht dass unterschiedliche Dateien nicht dieselbe Prüfsumme haben können.

Seit wann das?
Das haben wir schon im Studium angeführt.

Wenn die bits 2 ,3 ,4 und 7 gleich sind oder die gleiche Summe ergeben, kann man da eine völlig unterschiedliche Datei "drumherum" haben.

 

[Banned]

Unterschiedliche Prüfverfahren haben unterschiedliche Limitierungen bei der Fehlerkennung.

Bei CRC32 wäre es jetzt nicht soo verwunderlich, bei SHA256 finde ich es schon erstaunlich. Das wäre dann schon ein extremer Zufall.

Ich hatte nun auch mal das Original mit der Kopie über einen SHA256 Hash verglichen (soll ja einen Unterschied geben zwischen den verschiedenen Verfahren - wobei ich auch das nicht verstehe da ich davon ausgegangen bin dass ein reiner Bit-für-Bit Vergleich immer gleich ist) und auch hier waren die Daten gleich.

SHA256 ist aber kein Bit-Vergleich, sondern basiert auf einer Prüfsumme. Bei einem Bitvergleich gäbe es Abweichungen.

 

[Nicht die Mama]

@wuselsurfer

Keine Ahnung seit wann das ist ... wie du schreibst hattet ihr das ja schon im Studium. Ist aber auch hvöllig egal da es ein allgemeiner Zeitraum gemeint war.

Das mit den Verfahren ist gut zu wissen, Danke. Dennoch habe ich jetzt alles durch und die Dateien bleiben identisch trotz Unterschied.

@Banned
Der Unterschied ist mir bekannt. Wie geschrieben habe ich ja beides gemacht - ist über den Total Commander möglich (Hash, Binärvergleich etc). Hatte ich früher über die fc.exe unter Windows gemacht. Inzwischen nutze ich zum vergleichen immer den Total Commander.

 

[Banned]

Es ist m.E. schon logisch völlig unmöglich:

Wenn Datei1 und Datei2 komplett Bit-identisch sind, dann kann es nicht sein, dass Datei1 beim Öffnen/Wiedergeben ein anderes Verhalten zeigt als Datei2 (und umgekehrt), oder es liegt zumindest nicht an der Datei. Es gibt keine kleinere Einheit als ein Bit in der Datenverarbeitung (ein Bit kann nur 1 oder 0 sein - da gibt es kein Vertun*), wenn beide Dateien Bit-identisch sind, dann sind sie auch identisch.

Die einzige Vermutung, die ich da noch hätte, wäre, dass es u.U. an den Metadaten liegt (evtl. berücksichtigt TC diese nicht) - ist aber nur eine Vermutung - weiß nicht, ob diese evtl. den Index enthalten.

Ansonsten bin ich da auch überfragt. Wenn mir jemand nachvollziehbar erklären kann, wie sich zwei Bit-identische Dateien unterscheiden sollen, dann gerne. Ist in meinen Augen nicht möglich.



*Bei einem Datenträger mit schwindender Magnetisierung der aufgezeichneten Daten könnte wohl eine 1 als 0 erkannt werden und umgekehrt, aber du hast die Datei schließlich umkopiert, somit fällt auch das raus.

PS: Dass du beide Dateien am selben System wiedergeben hast, nehme ich einfach mal an.

 

[Nicht die Mama]

Ansonsten bin ich da auch überfragt. Wenn mir jemand nachvollziehbar erklären kann, wie sich zwei Bit-identische Dateien unterscheiden sollen, dann gerne. Ist in meinen Augen nicht möglich.

Genau das ist ja auch meine Ursprungsfrage. Ich bin felsenfest der Meinung (oder war es) dass das nicht möglich ist. Und da bin ich ja voll und ganz der zitierten Meinung und will da auch gar nicht Recht haben oder so etwas ... nur bin ich da völlig überfragt und frage mich: Wenn so etwas tatsächlich passieren kann was könnte man denn dann tun um wirklich sicherzugehen dass extern gesicherte Daten 1:1 identisch bleeiben (wenn Verfahren zum Überprüfen zwar identische Ergebnisse erzeugen können aber die Dateien eben nicht identisch sind).

Die Dateien habe ich am selben System und an anderen abgespielt. Während der PC diese Dateien noch abspielt, mit Artefakten etc., stürzt der Fernseher dabei komplett ab (also das Bild hält an, dann kommen bunte Streifen und dann wird der USB-Stick getrennt). Die Dateien habe ich inzwischen auch mal auf die interne HDD vom Blu-ray Player kopiert gehabt - selbes Ergebnis - allerdings ohne Absturz. Dann habe ich die ganz frischen Original-Dateien von der Backup-HDD auf den USB-Stick kopiert und diese laufen ohne irgendwelche Probleme.

Wie gesagt ich will ja gar nicht Recht haben - es wäre mir sogar viel lieber wenn sich einfach herausstellt dass ich mal wieder irgendeinen dummen Fehler gemacht habe.

 

[Fusionator]

Es ist m.E. schon logisch völlig unmöglich:

Genau. Und damit ist eigentlich schon alles gesagt. Der Rest ist entweder Voodoo oder Layer 8 Problem.

@Nicht die Mama
Installiere dir mal eine oder beide der unten genannten Programme (nur als Beispiel)

https://www.heise.de/download/product/hashtab-30191
oder
https://github.com/namazso/OpenHashTab

Dann mach mal eine SHA256 Checksumme und du wirst sehen, dass diese Dateien nicht identisch sind, es sei denn sie sind es wirklich.

Als Gegenchek kannst du auch mal mittels eines Hexeditors ein einzelnes Bit in einer kopierten Datei umdrehen und du wirst sehen, dass die Checksummen nicht identisch sind

 

[Nicht die Mama]

Danke für die Links aber das kenne ich ja schon. Der "Total Commander" (Dateimanager) kann das alles - SHA256+, HEX, direkter Binärvergleich. Das habe ich schon durch. Ich hatte mir irgendwann mal eine Lizenz für das Programm gekauft weil ich das so toll fand/finde. Da könnte sich der Windows-Explorer eine wahnsinnig Dicke Scheibe von abschneiden.

 

[Vindoriel]

Vielleicht braucht die Fehlerkorrektur im Controller vom Stick für den Fernseher zu lange, weil der Fernseher einen kleineren Cache hat als Windows. So würde Windows als Beispiel 500 MB im Voraus lesen und während diese noch abgespielt werden, bricht die Datenrate vom Stick vorübergehend ein und kommt wieder auf das erforderliche Tempo, bevor der Cache "abgespielt" wurde. Wenn der Fernseher nur 50 MB cachen würde, dann hätte man das Problem mit den Artefakten, weil der Datenstrom abreißt.

 

[Nicht die Mama]

Dm kann ich zwar nicht ganz folgen (bin da nicht so versiert in der Thematik) aber das stimmt sicher. Es geht nur nicht rein um den USB-Stick, der ist mir relativ egal da eh wohl hinüber (wenn ich die dann mal auseinander nehme wundere ich mich oft wie die inzwischen aufgebaut sind - früher war noch im hinteren langen Plastik-Teil eine lange Platine und heute ist der längliche Plastik-Teil oft nur noch Fake und ist komplett leer und ganz vorne am Anschluss ist eine kleine Mini-Platine die ähnlich einer Mini-SD ausschaut).

Die Dateien selbst sind ja anschließend betroffen, egal auf welchem Datenträger. Ich hatte die Dateien zur Sicherheit auch vorhin nochmal durch ein anderes Programm geschickt mit SHA256, unter "HashMyFiles". War aber, wie erwartet, selbiges Ergebnis wie unter dem Total Commander.

 

[4BitDitherBayer]

Man nennt das Bit Flip das kann geschehen wenn die Ladung in einer Speicherzelle schneller instabil wird als erwartet wenn z.B. die Isolierung der Speicherzelle mit der Zeit nach lässt.
Dann kann es geschehen das der Gespeicherte Wert verfälscht wird u. Datensätze fragmentiert oder komplett unbrauchbar werden. Wenn Video Daten Fragmentiert werden kann es gut seine das der Player die Fragmentierten Stellen "dir er nicht versteht" mit bunten Kästchen ausgibt.
Ein Programm hingegen würde bei Fragmentierung direkt abstürzten oder eine Fehlermeldung ausgeben das etwas nicht gelesen werden kann.

Das ist einer der Nachteile von FAT32 es hat im Gegensatz zu NTFS keine Schutzmechanismen.

NTFS überwacht und korrigiert im Hintergrund kontinuierlich Probleme durch vorübergehende Beschädigungen, ohne das Volume offline zu schalten. Dieses Feature wird als NTFS-Selbstreparatur bezeichnet, das in Windows Server 2008 eingeführt wurde.

Ich denke mal dein USB-Stick ist in FAT32 Formatiert richtig?

 

[Nicht die Mama]

Die Erklärung klingt gut, Danke. Einige der betroffenen USB-Sticks haben in der Tat FAT32 als Dateisystem. Das klingt wirklich interessant. Ein anderer betroffener USB-Stick ist zwar im NTFS-Dateisystem aber auf diesen kann ich unter Win11 gar nicht mehr zugreifen und daher nichts zu den Dateien sagen (was halt auch komisch ist da dieser unter Win7 und am TV ohne Probleme lief und auf Win11 erst gar nicht als Laufwerk erkannt wird).

Das wäre also schon einmal eine gute Erklärung wie die Artefakte zustande gekommen sind bzw. wie die Fehler in die Datei gekommen sind.

 

[Banned]

Jetzt verstehe ich gar nichts mehr. Ich dachte, du hättest die Datei auf eine SSD kopiert und dann auf dem selben Weg wiedergegeben wie die Datei, die einwandfrei funktioniert?!?

 

[Nicht die Mama]

Kann sein dass ich mich da manchmal etwas falsch ausdrücke. Ich habe, hier im laufe der Zeit geschrieben, dass ich die Datei mehrfach kopiert habe vom USB-Stick: Auf meine SSD, auf die interne HDD im Blu-ray-Player, auf einen anderen Stick. Demnach habe ich die Datei am PC wiedergegeben (VLC, SMPlayer), am Fernseher direkt (USB-Port) und über den Blu-ray-Player. Jeweils das Original und Kopien.
Ändern tut das in diesem Fall aber eh nichts da die Fehler ja immer mit kopiert wurden.

Wie gesagt eine mögliche Erklärung könnte das ja sein was oben steht.
Warum die Dateien aber nun dennoch gleich sind - keinen Schimmer warum.