Laden...

Einzigartigkeit von gewissen byte-Bereichen für ID Generierung

Erstellt von Ballom vor einem Jahr Letzter Beitrag vor einem Jahr 561 Views
Ballom Themenstarter:in
31 Beiträge seit 2015
vor einem Jahr
Einzigartigkeit von gewissen byte-Bereichen für ID Generierung

Hi

Ich möchte grössere Mengen Medien Dateien (.mp4) die auch gross sein können (bis 50GB) schnell identifizieren können. Auch wenn der Benutzer die Datei verschiebt oder umbenennt.
Das ganze soll auch Plattformunabhängig sein. Also wenn die Datei vom Windows PC auf das Android Smartphone kopiert wird, dann soll die Android App die selbe ID generieren und die Datei erkennen.

Ich bin zum Schluss gekommen, dass ich am besten eine bestimmte Anzahl bytes[] kopiere und daraus ein MD5 Hash generiere.
Aktuell nehme ich 200 Bytes von position 500-700 und Dateien die kleiner sind als 1024 Bytes, ignoriere ich.

Leider habe ich festgestellt, dass einige Dateien am Anfang gleiche Bytes besitzen. Ich habe auch gehört, dass gewisse Dateien grössere Bereiche "reserviert" haben um Metadaten zu speichern. Andere Dateien wie z.B. gleichfarbige Bilder/Videos könnten auch grössere Identische Reihenfolgen haben.

Zudem hatte ich Probleme, bei grösseren Dateien aus anderen Bereichen als dem Anfang Bytes zu lesen, weil da riesige Variablen benötigt werden und int32 übergeben werden musste.

Jetzt meine Fragen:

  • Welcher Bereich in Dateien wäre am besten geeignet bzw sind am einzigartigsten?
  • Wie viele Bytes würde ich idealerweise lesen?
  • Wäre ein MP4 Video, das in der Hälfte geschnitten wurde am Anfang identisch zum Original oder ändert sich da Bytemässig alles?
  • Sind Dateien auf allen Plattformen total identisch?

Hoffe jemand kann mir da etwas dazu sagen. Möchte nicht direkt eine ganze Studie in Auftrag geben. 😉
Aber wenn es mal selten und ausnahmsweise eine Verwechslung geben würde, wäre das nicht sehr schlimm.

Danke schon mal im Voraus.

God save the screen.

T
2.219 Beiträge seit 2008
vor einem Jahr

Klingt nach einem Münzwurf was die Eindeutigkeit der Dateien angeht, wenn du nur 200 Bytes mitten in der Datei lesen willst.
Du kannst zwar eine gewisse Eindeutigkeit durch Hashing bei Dateien ermitteln, dazu müsstest du aber die ganze Datei einlesen und hashen.
Dateien haben an und für sich auch keine eindeutigen IDs.

Mir ist aber nicht klar, wie du darauf kommst, dass eine mp4 Datei auf Platform A anders sein könnte als auf Platform B.
Auf beiden hast du im Endeffekt die gleichen Bytes.
MP4 und co. sind spezifierte Formate mit einem fixen Aufbau.

Ein für alle Platformen eindeutige ID erzeugen klappt m.W. nur durch Hashing.
Eine original und eine geänderte Datei, z.B. durch Schnitt oder andere Änderungen in Bild/Ton, haben dann aber auch unterschiedliche Hashes/Bytes.
Wenn du solche Dinge vergleichen willst, wird es schon etwas komplexer und dürfte den Rahmen deines Vorhabens ggf. sprengen.
Dann müsstest du nicht nur stumpf die Bytes auswerten sondern müsstest direkt Bild/Ton z.B. mit Tools auswerten.

T-Virus

Developer, Developer, Developer, Developer....

99 little bugs in the code, 99 little bugs. Take one down, patch it around, 117 little bugs in the code.

16.806 Beiträge seit 2008
vor einem Jahr

Es gibt keine andere Möglichkeit eine verlässliche Eindeutigkeit zu ermitteln, als die gesamte Datei zu verarbeiten.
Deswegen gibt es Verfahren wie CRC32 bzw. CRC64, die entsprechend leistungsstark auf Hardware-Ebene umgesetzt werden können.
CRCxx basiert auf Zyklische Redundanzprüfung

MD5 ist dafür völlig ungeeignet, und auch gar nicht gedacht; dank der PHP Welt dafür trotzdem verwendet worden.

Du kannst Dich in das Thema "data loss prevention" einlesen, weil im Endeffekt Dein Vorhaben in dieser Technik umgesetzt wird: dabei werden Dateien "getaggt" (auf Basis der Checksumme) und so zB. eine Übertragung durch Policies verhindert. Dabei werden auch minimale Unterschiede erkannt, um Varianzen ebenfalls abzudecken (also nicht unbedingt nur CRC im Einsatz).
Sehr weit verbreitetes Verfahren im Enterprise Umfeld, um digitale Inhalte zu schützen.

Ballom Themenstarter:in
31 Beiträge seit 2015
vor einem Jahr

Danke für die Antworten.

God save the screen.

A
764 Beiträge seit 2007
vor einem Jahr

Zudem hatte ich Probleme, bei grösseren Dateien aus anderen Bereichen als dem Anfang Bytes zu lesen, weil da riesige Variablen benötigt werden und int32 übergeben werden musste.

Das verstehe ich nicht. Du kannst doch mit FileStream.Position direkt nach hinten springen.

@Abt:
Ist QuickIO.NET noch aktuell? Das bietet ja wohl auch sowas an:
"File chunk support for reading, comparisons and hashing."

16.806 Beiträge seit 2008
vor einem Jahr

Ist
>
noch aktuell?

No, GitHub - SchwabenCode/QuickIO: Not in active development anymore hab ich eingestellt, weil durch die Investments von Microsoft in den IO Namespace viel passiert ist und ich das leider auch gar nicht Multi Plattform fähig in der modernen .NET Welt implementieren kann (weil ich mich dann mit jedem IO Namespace von Unix und Co beschäftigen muss).

Ballom Themenstarter:in
31 Beiträge seit 2015
vor einem Jahr

Das verstehe ich nicht. Du kannst doch mit FileStream.Position direkt nach hinten springen.

Ja, du hast recht. FileStream.Position ist eine long Variable und somit bei weitem gross genug. Habe das bereits angepasst 🙂

God save the screen.

3.170 Beiträge seit 2006
vor einem Jahr

Hallo,

Trotzdem verlässt Du Dich hier auf den Zufall. Du wirst niemals zu 100% sagen können, dass 2 Dateien, bei denen ein bestimmter Byte-Bereich gleich ist, auch insgesamt gelich sind.
Alle Tools, die hier mit Checksummen arbeiten, tun dies i.d.R. nur für eine Erstprüfung, und bei einem Match wird ein kompletter Binärverglech durchgeführt. Erst der stellt sicher, dass das, was zunächst mal gleich aussieht, auch wirklich identisch ist. Bei einer Auswahl eines bestimmten Byte-Bereichs innerhalb von Dateien hast Du genau das gleiche Problem - wobei mir hier die Checksummen noch effektiver erscheinen.

Gruß, MarsStein

Non quia difficilia sunt, non audemus, sed quia non audemus, difficilia sunt! - Seneca

Ballom Themenstarter:in
31 Beiträge seit 2015
vor einem Jahr

Hi

Ich nehme jetzt 200 bytes aus dem Anfang, der Mitte und dem Ende. Setzte die Arrays zusammen und generiere daraus einen MD5 Hash. Das ganze funktioniert sehr gut und auch sehr schnell. Habe einige Tests gemacht. Zum Beispiel Video 2x genau gleich gerendert, aber das zweite einige Sekunden kürzer: Auch die bytes am Anfang haben sich komplett geändert.

Ihr habt recht, dass es keine 100% Sicherheit gibt, dass es nicht eine Verwechslung geben könnte. Ich entwickle keine Software um Dateien zu Synchronisieren, wobei es sehr problematisch wäre, wenn da etwas überschreiben würde. Bei mir geht es darum Videos zu verwalten. Von meiner Software wird keine einzige Datei umbenannt, bewegt oder irgendwie verändert. Es geht nur darum, Informationen über Videos zu verarbeiten, die der User lokal auf seinem Device hat (Thumbnails, Tags, Kategorien, ...) und diese natürlich dem Video zuzuordnen.

Das schlimmste was passierten könnte: Bei einem Video wird das falsche Thumbnail angezeigt und wenn der User es anklickt, startet es ein anderes, als er erwartet.

Selbst das ist meiner Einschätzung nach extrem unwahrscheinlich, wenn ich die Bytes wie oben beschreiben auslese und daraus ein MD5 Hash berechne.

God save the screen.

D
261 Beiträge seit 2015
vor einem Jahr

Ist es eine Anforderung, dass die Dateien nicht verändert werden? Wenn nicht, könntest du auch Meta-Informationen mit z.B. exif in die Dateien schreiben.
Wenn du dann einfach eine GUID in die Meta-Informationen der Datei schreibst, kannst du die GUID verwenden um Sie mit deinen Informationen zu verknüpfen.

Ballom Themenstarter:in
31 Beiträge seit 2015
vor einem Jahr

Ist es eine Anforderung, dass die Dateien nicht verändert werden? Wenn nicht, könntest du auch Meta-Informationen mit z.B. exif in die Dateien schreiben.
Wenn du dann einfach eine GUID in die Meta-Informationen der Datei schreibst, kannst du die GUID verwenden um Sie mit deinen Informationen zu verknüpfen.

Es war eigentlich keine Anforderung. Am Anfang habe ich eine ID an den Dateinamen angehängt. Aber unter Android hatte ich trotz Berechtigungen einige Probleme. Android mag es einfach nicht, wenn man Dateien umbenennt, verschiebt und löscht. Vor allem nicht, wenn es in anderen Laufwerken (SD-Card) geschieht. Deshalb bin ich auf die Idee mit den bytes gekommen.

Bis jetzt funktioniert es sehr gut. Auf jeder Plattform.

Deine Idee ist aber gut. Werde sie sicher im Hinterkopf behalten.

God save the screen.

16.806 Beiträge seit 2008
vor einem Jahr

Unterm Strich muss man halt sagen: Dein "System" basiert auf reinem Glück.
Nicht mehr, nicht weniger. Und das ist nie gut 🙂