(Datei) Kopierfehler analysieren

[Ingenieur (Gast)]

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

 od -t x1 dat1.mp3 >/tmp/11
 od -t x1 dat2.mp3 >/tmp/12
 diff /tmp/11 /tmp/12
1655660c1655660
< 145040000 14 b6 a9 a6 7c c3 fa d3 50 b1 f0 76 02 f3 b4 ce
---
> 145040000 fc e5 cc 94 e4 8b bb 92 9c 3b d7 e7 7f f8 af 12
1657132c1657132
< 145116000 f5 0a e5 27 f5 da 7c 5a 00 07 5a 7b c1 74 db 0c
---
> 145116000 06 16 dd 87 60 82 6f 21 16 80 aa 74 7d 87 b2 c7

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.

[Peter II (Gast)]

Ingenieur schrieb:
> Wie kann das entstehen?

RAM defekt

[Dirk D. (dicky_d)]

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.

[Ingenieur (Gast)]

> 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.

[oszi40 (Gast)]

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.

[Ingenieur (Gast)]

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.

[oszi40 (Gast)]

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.

[Ingenieur (Gast)]

Habe dieses Tool mal ausprobiert.
Das stellt ein paar der Unregelmäßigkeiten fest.
Was ist eigentlich ein Frankenstein stream ?

mpg123-id3dump sr_program_2015_03_14_21_05_02.mp3

Note: Illegal Audio-MPEG-Header 0x7769ed56 at offset 30859265.
Note: Trying to resync...
Note: Skipped 99 bytes in input.

Warning: Big change from first (MPEG version, layer, rate). Frankenstein stream?
Note: Illegal Audio-MPEG-Header 0x2cddbbe2 at offset 30859504.
Note: Trying to resync...
Note: Skipped 179 bytes in input.

Warning: Real sample count 148482816 differs from given gapless sample count -1152. Frankenstein stream?

Nothing found for sr_program_2015_03_14_21_05_02.mp3.

[Stampede (Gast)]

Ist das vllt ein Teil des ID3 Tags o.Ä?

[??? (Gast)]

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.

[Ingenieur (Gast)]

das war dieser:
http://www.amazon.de/Intenso-Rainbow-Line-USB-Stick-orange/dp/B0081TNDYW/

allerdings habe ich diese Baureihe schon mit 4GB, 8GB (grün), 32GB 
(weiß), und nie Probleme gehabt.

[Planlos (Gast)]

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

[bastel_ (Gast)]

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).