Ich kenn zwar die Praxis, Binärdateien und andere wichtige Dateien mit
md5sum abzusichern und auf Echtheit zu prüfen, hatte aber jahrelang nie
mit einem Fehler zu tun.
Aber dann:
Ich hatte mehrere mp3-Dateien, ursprünglich mittels 'streamripper' von
Internet-Radiostationen aufgezeichnet.
Die hatte ich öfters auf verschiedene Memorysticks und auf Notebooks
kopiert, um sie abzuhören.
Das OS war immer Linux (aufzeichnen, kopieren, abhören mit 'mplayer').
Irgendwann stellte ich fest, dass ein 'diff' von ursprünglich gleichen
Datei Fehler ergibt.
Machte dann einen
1
od -t x1 dat1.mp3 >/tmp/11
2
od -t x1 dat2.mp3 >/tmp/12
3
diff /tmp/11 /tmp/12
4
1655660c1655660
5
< 145040000 14 b6 a9 a6 7c c3 fa d3 50 b1 f0 76 02 f3 b4 ce
6
---
7
> 145040000 fc e5 cc 94 e4 8b bb 92 9c 3b d7 e7 7f f8 af 12
8
1657132c1657132
9
< 145116000 f5 0a e5 27 f5 da 7c 5a 00 07 5a 7b c1 74 db 0c
und stellte fest, alle Abweichungen sind 16 Bytes lang und beginnen an
einer 512Byte - boundary.
Wie kann das entstehen? Bei Kopiervorgängen wurde nie ein Fehler
gemeldet?
Ich weiß nicht, welches Medium versagt hat, aber bei einigen
Unregelmäßigen war oft ein Intenso 64GB Stick im Spiel, mit exFat
formatiert.
Gibt es ein brauchbares Tool, um eine Mp3 Datei auf 'damaged' zu
untersuchen?
Ich würde gern herausfinden, welche Datei die orginale ist.
Manchmal meldet der mplayer einen Fehler oder man hört ein Knacksen.
Ich würd auf nen defekten usb-stick tippen, kannst du die beteiligten
usbsticks eingrenzen? dann prüf die doch mal, schreib sie mit Zufall
voll (den du vorher auf deine platte schreibst) und vergleiche
hinterher.
> RAM defekt
Ja?
Die Abweichungen beginnen immer an einer 512Byte-Boundary, bezogen auf
den Anfang der Datei.
Falls es so ist, dass beim Kopieren der Datei die Datei sektorenweise
(512) gelesen wird und immer an die gleiche RAM-Adresse schrieben wird,
und die ersten 16 Bytes dieses RAM-Bereichs defekt sind, wäre das
denkbar.
Ingenieur schrieb:> alle Abweichungen sind 16 Bytes lang
Woher weißt Du, daß der Player die Daten niiie verändert hat? Kopiere
die Daten MEHRFACH auf die Sticks und vergleiche sie dann nach dem
abspielen.
oszi40 schrieb:> Woher weißt Du, daß der Player die Daten niiie verändert hat?
Wenn es so ist, dann wären beim Lesezugriff ein paar Bytes gekippt.
Vielleicht ist das denkbar. Irgendwann passieren ja Datenfehler.
Aber absichtlich macht der mplayer das nicht.
Ingenieur schrieb:> Aber absichtlich macht der mplayer das nicht.
Alle Geheimnisse kenne ich nicht, aber manche mp3 werden mit einer DB
verglichen oder ergänzt. Daher kommt mein allgemeiner Verdacht.
Intenso 64GB - Stick....
Das ist das Problem!
Ich hab hier auch so ein Problem. Das liegt eindeutig am Intenso-Stick.
Bei manchen Sticks von Intenso führt das zu regelrechten Blockaden.
Besonders wenn USB2/3 gemischt benutzt wird. Ich hatte erst Die
exFAT-Formatierung in Verdacht, aber das wars nicht... Verwunderlich
ist, dass unter Windows7 keine Hardware-ID angezeigt wird. Das irgendwas
oberfaul.
Ich hab jetzt Kingston DTR3.0 G3.
da gibts auch viele Meldungen bei google.
Stichwort Bit-Rot, Silent Data corruption, ...
Platten sind in den letzten Jahr(zehnt)en gewaltig gewachsen, die
durchschnittliche Fehlerrate gleich geblieben.
Resultat: Beim kompletten Kopieren einer 2 TB-Festplatte ist schon
ziemlich sicher eine Datei kaputt.
Server-Platten sind um den Faktor 10-100 besser, aber auch nicht
"garantiert fehlerfrei".
Bei RAID hilft ein regelmäßiges "Background Scrubbing" solche Fehler zu
finden.
Ansonsten: Checksums, checksums, checksums
Am komfortablesten im Dateisystem integriert. BTRFS, ZFS, ReFS, ...
http://heise.de/-2314398
Speicherfehler sehen meistens anders aus. Sind meist Bitfehler, sonst
kommt das OS gleich gar nicht mehr hoch.
Das hat dann was mit Cachesize etc zu tun. Die Fehler sind zwar immer
noch an Grenzen, aber meist geht es da um 4k Blöcke und dann irgendwo in
der Datei.
Hatte ich schon, und zu der Zeit grade große Mengen Dateien umkopiert...
Ich hatte allerdings auch MD5s und konnte nach Analyse der
Fehlerbitmuster mir ein Programm schreiben, dass dann per Bruteforce die
Bits zurückgekippt und dann geschaut hat, ob die MD5 wieder passt. Ja,
das kostet enorme Rechenzeit, geht aber: 350 MB Datei hat 90000 4K
Blöcke - 31 TB testen. Wahrscheinlichkeiten reduzieren das auf ein
Viertel und Mathe halbiert das ganze noch ein mal, so dass man dann nur
rund 4 TB testen muss :) Macht man das von hinten nach vorne, dann ist
das ganze auch nicht mehr linear, d.h. 30% der Bytes brauchen nur 10%
der Rechenzeit, 50% nur 25% usw. Da ist man dann bei <=30 Minuten, wenn
man mit 2 GB/s rechnet (man könnte das auch noch irgendwie auf
Grafikkarten auslagern, aber egal).
