Möglichkeit von Fehlern beim Verschieben/Kopieren? (Seite 1 von 3)

Ich bin nun nicht unbedingt der Linuxexperte. Darum habe ich meine Test's auf einem Win-Rechner gemacht.
Zuerst habe ich mal einen Titel in Flac umgewandelt und "Orig-Test.flac" genannt.
Dann habe ich mit einem Hexeditor diese Datei geöffnet, irgendwo mitten im File ein einziges Bit (!) verändert und als "Test.flac" zurückschreiben lassen.

Den Test habe ich 5 Mal wiederholt. Jeweils immer nur ein Bit an verschiedenen Stellen in der Datei.

Sei beruhigt... Du bekommst sofort eine CRC-Fehlermeldung!

Du kannst also getrost die -t verwenden.

Offtopic: Es erstaunt mich ehrlich gesagt, daß Linux keine Überprüfung beim kopieren/schreiben vornimmt. Denn genau das konnte sogar schon der gute alte Amiga 500 aus den 80er Jahren. Und dessen Filesystem hat seinen Ursprung aus dem UNIX-Bereich.

@Meiner Einer

Moin, Moin,

hast Du mal probiert, ob man mit den von Dir zielgerichtet verwundeten Flacs noch etwas anfangen kann (insbesondere decodieren, aber auch abspielen mit Foobar oder Winamp)? Würde mich sehr interessieren!

Zum Problem der Robustheit wurde hier und an anderen Orten schon diskutiert:

https://www.audiohq.de/viewtopic.php?id=947
http://www.hydrogenaudio.org/forums/index....showtopic=33226
https://www.audiohq.de/viewtopic.php?id=2430

Gruß
rhinozeros

@ rhinozeros

Natürlich kann man es noch abspielen! Das ist ja auch eine der Grundideen bei Flac. Es wird im Grunde nur ein Frame beschädigt, alles übrige bleibt lesbar/abspielbar.
Es gibt allerdings an der betreffenden Stelle ein heftiges Dropout von 92 Millisekunden Länge (Komprimierung bei 8)

Anbei wieder ein Screenshot.

@ m07u

Decoden funktioniert auch. Zumindest, wenn ich es in Audition öffne. Und dort kann ich es ja wieder in alle möglichen anderen Formate speichern.

PS - gibt es eine Möglichkeit, die Bilder hier direkt anzuhängen? Ich weiß nämlich nicht, wie lange sie bei dem Bildhoster abrufbar bleiben.

War vielleicht nicht so gut formuliert - sorry. Ich wollte damit sagen, daß ich es nur mit Auditon getestet habe. Für Audition bzw. CoolEdit steht ja ein separates "flac.flt" zur Verfügung.

Aber ich habe jetzt noch einen Test durchgeführt: Ich habe in die beschädigte Datei an anderer Stelle (weiter am Ende) noch einen weiteren (zweiten) Bitfehler eingefügt.
Anschließend den "Flac-Tester" drüberlaufen lassen. Erfolg: Er zeigt nur den ersten Fehler an (den auf dem Screenshot). Danach bricht er das weitere testen dieser Datei ab. Gleiches gilt für die "Flac.exe" bzw. das "Flac-Frontend": Sie brechen bei auftreten des ersten Fehlers ab. Somit wird die Datei nicht decodiert.

Anders verhält es sich beim Abspielen bzw. öffnen in Audition. Dort wird also trotzdem weitergelesen und das jeweils "kaputte" Frame mit "Stille" aufgefüllt.

PS - Ich verwende Audition auch aus beruflichen Gründen. Allerdings noch in der Version 1.5, weil es für meine Zwecke absolut ausreichend ist.

Das kann immer passieren.
http://de.wikipedia.org/wiki/Bitfehler
http://de.wikipedia.org/wiki/Fehlerkorrektur

Streng genommen hast Du ja nicht nur 0 und 1 auf den Leitungen, sondern noch jede Menge Störimpulse, Rauschen, Brummen usw. Dazu kommt noch die natürliche radioaktive und kosmische Strahlung. Das heißt, es kann immer mal ein Bit auf der Leitung "kippen" - deshalb ja auch mein Test auf Einzelbit-Ebene. Auch Speicherzellen halten ihre Information in Form einer Kondensatorladung. Und die lag meines Wissens sogar in den 80er Jahren schon in Größenordnungen um 100 Elektronen - mehr nicht.
Und auch bei magnetische Medien wie HD kommt es vor, das mal ein Bit nicht gleich beim ersten schreiben so will, wie es soll.

Das Problem ist aber dabei weniger die Tatsache, das ein Bit kippen kann, sondern vielmehr, das gerade unter Linux eine Prüfung nach dem Schreiben nicht stattfindet.
Window, Mac und auch Amiga dagegen lesen sofort nach dem Schreiben die Daten zurück und vergleichen sie. Im Fehlerfall werden dann bis zu 10 Schreibversuche unternommen, bis es eine Fehlermeldung gibt.

m07u hat in seinem ersten Post hier einen Link zu "ubuntuusers.de" angegeben, wo er diese Frage ebenfalls gestellt hat.
http://forum.ubuntuusers.de/topic/ist-kopi...autilus-sicher/

Speziell in Post 8 dort wird das erwähnt.

Ich war beim Lesen ebenfalls sehr überrascht! Ob diese Info seriös ist, kann ich Dir nicht beantworten. Ebensowenig, ob es nur "Nautilus" betrifft oder Linux komplett.

Außerdem bezieht sich das ja nicht auf die komplette Vielfalt der Datenübertragung und deren Protokolle, sondern konkret "nur" auf das schreiben von Daten auf ein Speichermedium.

Betrachten wir mal die Samples: 8712984 - 8685336 = 27684 Samples.
Ein Sample hat ja eigentlich 16 Bit (2 Bytes), zumindest dann, wenn es urprünglich von CD kommt.

Es fehlen Dir also 55296 Bytes.

Und jetzt kommt das eigentlich "interessante" daran: 55296 / 512 = 108. Es ist glatt teilbar ohne Rest!
Die Blockgröße einer HD beträgt auch heute immer noch 512 Bytes!!! Und diese werden seit ewigen Zeiten immer zu sogenannten "Clustern" zusammengefaßt wie z.B. 2 KByte, 4 Kbyte ... (= 4; 8; ... Blöcke) usw.

Das spricht mit großer Wahrscheinlichkeit für einen Dateisystemfehler. Vielleicht mal mit Chkdsk kontrollieren.

Ich will und kann an dieser Stelle keine Theorien bzw. Erklärungen zum Verhalten von Foobar bzw. Audacity anstellen. Das wären alles nur Vermutungen.

Das deckt sich mit meinen Erfahrungen (Dropout), da bei Dir mindestens ein Frame, vermutlich sogar 2 Frames defekt sind.
Zu Audacity kann ich gar nichts sagen, da ich es noch nie verwendet habe. Hast Du an der Stelle mal reingehört, ob es dort einen "Bruch" in der Musik gibt?