Help - Search - Members - Calendar
Full Version: Batch: mp3 wird nur noch als Dateiordner angezeigt
Mp3tag Forums > Mp3tag - Deutsch > Allgemein
vI3Tz
Hallo,

ich habe vor kurzem versucht meine komplette Musiksammlung (ca 10k mp3's) mit mp3tag 2.51 zu bearbeiten. Ich habe lediglich das POPM-Feld beschrieben.

Dann der Schock: Viele mp3's werden im Windows Explorer nur noch als leerer Dateiordner angezeigt. Scheinbar sind die Dateien unwiederbringbar zerstört. Ein Muster ist dabei nicht zu erkennen.

Nun bin ich mir nicht sicher ob es an mp3tag liegt oder ob meine externe HDD einen Schaden hat. Diese überprüfe ich bereits seit einigen Stunden mit HD Tune Pro auf Fehler.

Hat jemand schon einmal ähnliche Erfahrungen machen müssen?

Gruß,
Dennis
DetlevD
QUOTE (vI3Tz @ Jun 18 2012, 15:38) *
... ich habe vor kurzem versucht meine komplette Musiksammlung (ca 10k mp3's) mit mp3tag 2.51 zu bearbeiten. Ich habe lediglich das POPM-Feld beschrieben. ...

Zunächst mein Beileid, aber ... hättest du nicht zuerst mit ein paar wenigen Dateien experimentieren können?

Mir ist nichts darüber bekannt, wie man eine Datei derart zerstören kann, dass daraus ein leerer Ordner wird?!

Mir ist nichts darüber bekannt, dass das Schreiben des Tagfeldes POPULARIMETER (POPM in ID3v2.3 und ID3v2.4) zu einer Zerstörung der MP3 Dateien führen kann.

Es ist sehr ungewöhnlich, was du berichtest!

Welche Tag-Typen sind in den Dateien vorhanden (z. B. ID3v1, ID3v2.3, ID3v2.4, APE)?
Welcher Tag-Typ wird gegenwärtig von Mp3tag angezeigt?
Welchen Tag-Typ (einen oder mehrere) hatten die MP3 Dateien vor der Veränderung und welchen Tag-Typ (einen oder mehrere) haben sie jetzt nach der Veränderung?

Was zeigt die Fenster-Titelzeile an im Dialog "Erweiterte Tags..."?
Werden überhaupt Tag-Felder angezeigt im Dialog "Erweiterte Tags..."?

DD.20120618.1616.CEST
vI3Tz
Hallo Detlev,

erstmal vielen Dank für die schnelle Antwort! Natürlich habe ich ein Backup meiner Musiksammlung. Ich arbeite auch schon sehr lange mit mp3tag und mir ist sowas zuvor nie passiert.

Google spuckt auch nichts dergleichen aus. Ich bin momentan wirklich ratlos.

Was die Dateien vor der Bearbeitung hatten, kann ich nicht genau sagen. Vermutlich ein wildes durcheinander.

Ich habe mp3tag so eingestellt, dass es nur id3v2 schreibt und id3v1 löscht.

Natürlich ist es mir erst aufgefallen als ich mp3tag bereits geschlossen hatte. Daher kann ich auch nicht sagen was alles noch angezeigt wurde. Neu einlesen geht ja nun nicht mehr.

Die überprüfung der HDD ist mittlerweile bei ca 80% und hat noch keinen Fehler gefunden.

Könnte es Probleme mit Lese- und Schreibrechte gegeben haben?
ohrenkino
ZITAT(vI3Tz @ Jun 18 2012, 15:38) *
... nur noch als leerer Dateiordner angezeigt.... oder ob meine externe HDD einen Schaden hat. ..

dass aus dateien ordner werden kommt mir sehr seltsam vor.

wie voll ist denn die externe Festplatte? sind die magischen 10% schon unterschritten? Dann kann Windows (manchmal) die "Sicherheitsbeschreibung" nicht mehr aktualisieren. Und das verursacht seltsame Phänomene.

Wenn du die Festplatte verdächtigst: was sagt denn chrystaldiskinfo (freeware)? Ist die HDD ok oder schon im gelben Bereich?

Unter Windows 7 würde ich für die Festplatte eine Shell als Admin öffnen (cmd) und die Überprüfung der HDD per Kommandozeile ausführen - da bekommst du mehr infos:
chkdsk g: /v /r
Und wenn all diese Tests eine saubere HDD zeigen, dann muss man gucken, was mit den Audiodateien los ist.
vI3Tz
Also ich gehe jetzt mal davon aus, dass die HDD in Ordnung ist.

HD Tune Pro hat keine Fehler gefunden.
WD Data LifeGuard Diagnostics hat nichts schlechtes gefunden.
Bei chrystaldiskinfo ist alles im grünen Bereich.
Chkdsk hat meiner Auffassung nach auch nichts fehlerhaftes gefunden. Habe den log mal angehängt.

Was mir noch eingefallen ist:
Einige mp3's waren wohl schreibgeschützt und konnten daher von mp3tag nicht bearbeitet werden. Allerdings sind diese Dateien nicht beschädigt worden. Ich habe anschließend den Schreibschutz des übergeordneten Ordners inkl. aller Unterordner und Dateien aufgehoben. Daraufhin sind nun einige mp3's versteckt und das lässt sich komischerweise auch nicht rückgängig machen.

Schon mal vielen Dank für eurer Engagement!

CODE
Chkdsk wurde im Lesen-/Schreibenmodus ausgeführt.

Dateisystem auf W: wird überprüft.
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet WD White.

CHKDSK überprüft Dateien (Phase 1 von 5)...
137728 Datensätze verarbeitet. Dateiüberprüfung beendet.
1 große Datensätze verarbeitet. 0 ungültige Datensätze verarbeitet. 0 E/A-Datensätze verarbeitet. 0 Analysedatensätze verarbeitet. CHKDSK überprüft Indizes (Phase 2 von 5)...
Der Indexeintrag für die Objektkennung in der Datei 0x19 verweist auf Datei 0x19670,
aber diese Datei enthält keine Objektkennung.
Ein Indexeintrag wird aus dem Index $O der Datei 25 gelöscht.
Der Indexeintrag für die Objektkennung in der Datei 0x19 verweist auf Datei 0x1966d,
aber diese Datei enthält keine Objektkennung.
Ein Indexeintrag wird aus dem Index $O der Datei 25 gelöscht.
Der Indexeintrag für die Objektkennung in der Datei 0x19 verweist auf Datei 0x1966b,
aber diese Datei enthält keine Objektkennung.
Ein Indexeintrag wird aus dem Index $O der Datei 25 gelöscht.
Der Indexeintrag für die Objektkennung in der Datei 0x19 verweist auf Datei 0x4784,
aber diese Datei enthält keine Objektkennung.
Ein Indexeintrag wird aus dem Index $O der Datei 25 gelöscht.
Der Indexeintrag für die Objektkennung in der Datei 0x19 verweist auf Datei 0x4772,
aber diese Datei enthält keine Objektkennung.
Ein Indexeintrag wird aus dem Index $O der Datei 25 gelöscht.
Der Indexeintrag für die Objektkennung in der Datei 0x19 verweist auf Datei 0x4778,
aber diese Datei enthält keine Objektkennung.
Ein Indexeintrag wird aus dem Index $O der Datei 25 gelöscht.
Der Indexeintrag für die Objektkennung in der Datei 0x19 verweist auf Datei 0x4770,
aber diese Datei enthält keine Objektkennung.
Ein Indexeintrag wird aus dem Index $O der Datei 25 gelöscht.
Der Indexeintrag für die Objektkennung in der Datei 0x19 verweist auf Datei 0x4765,
aber diese Datei enthält keine Objektkennung.
Ein Indexeintrag wird aus dem Index $O der Datei 25 gelöscht.
Das Dateinamenattribut des Indexeintrags 0_temp_playlist.wpl von Index $I30,
der 0x1585 untergeordnet ist, kann in der Datei 0x1a27 nicht
gefunden werden.

Indexeintrag 0_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Der Indexeintrag 10_temp_playlist.wpl von Index $I30 in der Datei 0x1585 verweist auf die nicht verwendete Datei 0x20a6.
Indexeintrag 10_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Das Dateinamenattribut des Indexeintrags 1_temp_playlist.wpl von Index $I30,
der 0x1585 untergeordnet ist, kann in der Datei 0x1a28 nicht
gefunden werden.
Indexeintrag 1_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Das Dateinamenattribut des Indexeintrags 2_temp_playlist.wpl von Index $I30,
der 0x1585 untergeordnet ist, kann in der Datei 0x1a2c nicht
gefunden werden.
Indexeintrag 2_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Das Dateinamenattribut des Indexeintrags 3_temp_playlist.wpl von Index $I30,
der 0x1585 untergeordnet ist, kann in der Datei 0x1f61 nicht
gefunden werden.
Indexeintrag 3_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Das Dateinamenattribut des Indexeintrags 4_temp_playlist.wpl von Index $I30,
der 0x1585 untergeordnet ist, kann in der Datei 0x1f62 nicht
gefunden werden.
Indexeintrag 4_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Die Dateireferenz 0x1fce000000001f63 von Indexeintrag 5_temp_playlist.wpl von Index $I30 mit dem
übergeordneten Element 0x1585 ist nicht die gleiche wie 0x1fa6000000001f63.
Indexeintrag 5_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Die Dateireferenz 0x1fd0000000001f64 von Indexeintrag 6_temp_playlist.wpl von Index $I30 mit dem
übergeordneten Element 0x1585 ist nicht die gleiche wie 0x1fa7000000001f64.
Indexeintrag 6_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Der Indexeintrag 7_temp_playlist.wpl von Index $I30 in der Datei 0x1585 verweist auf die nicht verwendete Datei 0x1f65.
Indexeintrag 7_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Der Indexeintrag 8_temp_playlist.wpl von Index $I30 in der Datei 0x1585 verweist auf die nicht verwendete Datei 0x1f66.
Indexeintrag 8_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Der Indexeintrag 9_temp_playlist.wpl von Index $I30 in der Datei 0x1585 verweist auf die nicht verwendete Datei 0x1f67.
Indexeintrag 9_temp_playlist.wpl in Index $I30 der Datei 5509 wird gelöscht.
Die Dateireferenz 0x24a2000000001973 von Indexeintrag scan_file.dat von Index $I30 mit dem
übergeordneten Element 0x1585 ist nicht die gleiche wie 0x2570000000001973.
Indexeintrag scan_file.dat in Index $I30 der Datei 5509 wird gelöscht.
Das Dateinamenattribut des Indexeintrags tsbyebye von Index $I30,
der 0x1585 untergeordnet ist, kann in der Datei 0x195d nicht
gefunden werden.
Indexeintrag tsbyebye in Index $I30 der Datei 5509 wird gelöscht.
143550 Indexeinträge verarbeitet. Indexüberprüfung beendet.
0 nicht indizierte Dateien überprüft. 0 nicht indizierte Dateien wiederhergestellt. CHKDSK überprüft Sicherheitsbeschreibungen (Phase 3 von 5)...
137728 SDs/SIDs verarbeitet. 3 unbenutzte Indexeinträge werden aus dem Index $SII der Datei 9 gelöscht.
3 unbenutzte Indexeinträge werden aus dem Index $SDH der Datei 9 gelöscht.
3 nicht verwendete Sicherheitsbeschreibungen werden aufgeräumt.
Überprüfung der Sicherheitsbeschreibungen beendet.
2912 Datendateien verarbeitet. CHKDSK überprüft USN-Journal...
79700144 USN-Bytes verarbeitet. Die Überprüfung von USN-Journal ist abgeschlossen.
CHKDSK überprüft Dateidaten (Phase 4 von 5)...
137712 Dateien wurden verarbeitet. Dateidatenüberprüfung beendet.
CHKDSK überprüft freien Speicherplatz (Phase 5 von 5)...
81186434 freie Cluster verarbeitet. Verifizierung freien Speicherplatzes ist beendet.
Fehler in Volumebitmap werden berichtigt.
Windows hat Probleme im Dateisystem behoben.

488384000 KB Speicherplatz auf dem Datenträger insgesamt
163316192 KB in 51386 Dateien
25124 KB in 2913 Indizes
0 KB in fehlerhaften Sektoren
296948 KB vom System benutzt
65536 KB von der Protokolldatei belegt
324745736 KB auf dem Datenträger verfügbar

4096 Bytes in jeder Zuordnungseinheit
122096000 Zuordnungseinheiten auf dem Datenträger insgesamt
81186434 Zuordnungseinheiten auf dem Datenträger verfügbar
ohrenkino
ZITAT(vI3Tz @ Jun 19 2012, 08:24) *
Also ich gehe jetzt mal davon aus, dass die HDD in Ordnung ist.

....
Chkdsk hat meiner Auffassung nach auch nichts fehlerhaftes gefunden. Habe den log mal angehängt.

Das würde ich nicht so sehen: die ganzen ins Nirvana zeigenden Indexeinträge sind entweder Folge oder Ursache für das seltsame Verhalten: denn wenn die Zeiger in der Sprungtabelle nicht richtig sind, funktioniert auch das Wiederfinden nicht.
Im Gegenteil: wenn du an diesen Dateien rumschreibst, werden eben Daten sonstwo in diese Dateien gepackt ...
Oft treten diese Arten Fehler auf, wenn Speicher mit Puffer noch am Schreiben (Pufferleeren) sind, wenn etwas unvorhergesehenes wie ein Absturz oder ein gewaltsames Entfernen eines externen Geräts ohne Abdocken vorgenommen wird.
Es ist beruhigend, dass die HW anscheinend in Ordnung ist - die Logik war es auf jeden Fall nicht.
Wenn du sicher sein willst, dass jetzt Ruhe ist, dann führe den Überprüfungsvorgang mit CHKDSK bitte noch einmal aus. Wenn dann wieder Indexeinträge falsch sind, verabschiedet sich gerade dein Boot-Sektor bzw der Bereich, wo die Tabelle der Dateieinträge gespeichert wird.
Wenn aber im Moment nichts auftritt, sind die Fehler wohl behoben und du kannst die Sicherungskopie einspielen. ;-)
vI3Tz
Ok danke für deinen Tipp. Ich lasse Chkdsk jetzt noch einmal laufen und schaue dann mal was dabei raus kommt.

Würde es etwas bringen die Platte neu zu formatieren? Sie ist im Moment auf NTFS und ich habe überlegt auf FAT32 umzustellen. Ich möchte die Platte nämlich an meinen Linksys Router hängen damit ich im Netzwerk darauf zugreifen kann. Und da ist FAT32 wohl besser.

Aber jetzt probiere ich erstmal Chkdsk.
ohrenkino
ZITAT(vI3Tz @ Jun 19 2012, 12:15) *
... auf FAT32 umzustellen....

Nein, das ist nur dann sinnvoll, wenn das dahinterliegende Sytem kein NTFS versteht. Die Fehlerkorrektur ist bei NTFS deutlich besser (nie wieder verloren Cluster).

Es gibt bestimmte physische Bereiche auf einer Platte, die dürfen einfach nicht kaputt gehen, sonst ist die ganze Platte hin. Dazu gehört der Startbereich.
Wenn dieser Bereich Probleme bereiten sollte, ist es weiser, mal zu sehen, ob die Platte noch Garantie hat und sie dann wirklich zu tauschen. Manchmal erwischt man eben ein Montagsprodukt.
Die Neuformatierung würde am womöglich defekten Startbereich (der immer an der selben Stelle ist) nichts ändern.
vI3Tz
Also Chkdsk hat keine falschen Indexeinträge gefunden. Scheint alles wunderbar.

Kann ich den Startbereich auch überprüfen? Die Platte ist schon ziemlich alt, daher kommt Garantie nicht in Frage.
ohrenkino
ZITAT(vI3Tz @ Jun 19 2012, 13:17) *
Also Chkdsk hat keine falschen Indexeinträge gefunden. Scheint alles wunderbar.

Kann ich den Startbereich auch überprüfen? Die Platte ist schon ziemlich alt, daher kommt Garantie nicht in Frage.

Dann wäre ich jetzt erst mal optimistisch, dass die Platte noch ein Weilchen hält.
Dass ich da auf dem Startbereich rumreite, liegt doch nur daran, dass ich nicht beurteilen kann, was die Platte schon alles erlebt hat.
Und nach meiner Erfahrung wird jeder Hinweis auf ein spezielleres Benutzerverhalten wie "USB-Platte rausziehen ohne Abdocken" eher als Angriff gewertet - was so nicht gemeint ist.
Die Analyse des Startbereichts hast du eigentlich jetzt gerade mit chkdsk absolviert - denn wenn chkdsk versucht hätte, Korrekturen zu schreiben, die aber dann nicht angekommen wären, was der wiederholte chkdsk-lauf an den Tage gebracht hätte, wäre dies ein Hinweis gewesen.
Diese Fehler scheinen jetzt alle beseitigt zu sein, jetzt steht nur noch der Test aus, ob eine Wiederholung der Änderung des POPM-Feldes wieder zu so einer Katastrophe führt.
vI3Tz
Ok dann ist ja alles gut. Ich werde die Platte jetzt erstmal neu formatieren. Kann ja nicht schaden. Dann spiele ich das Backup drauf und teste noch einmal das POPM Feld aller Dateien zu schreiben.

Auf jeden Fall schon mal ein riesiges Danke für eure Hilfe. Hoffen wir mal, dass jetzt alles reibungslos klappt rolleyes.gif
vI3Tz
Noch ein kleines Update:

Habe formatiert und nochmal mit dem Paragon Partition Manager nach fehler gesucht. Er hat dann zwei kleine Fehler im Master File Table gefunden.

Ich werde jetzt versuchen diesen mittels TestDisk wiederherzustellen.

Edit:
MFT und MFT mirror sind defekt. Also kann ich es nicht reparieren.
Ist die Platte noch zu retten? Die Daten sind mir egal.
ohrenkino
ZITAT(vI3Tz @ Jun 19 2012, 17:31) *
...
MFT und MFT mirror sind defekt. Also kann ich es nicht reparieren.
Ist die Platte noch zu retten? Die Daten sind mir egal.

Das sind diese beiden Bereiche, die nicht kaputt gehen dürfen. Also sieht es eher so aus, als seien diese beiden Bereiche physisch kaputt und lassen deshalb keine verlässliche Speicherung mehr zu.
Seagate hat, glaube ich, 3 Jahre Garantie ... aber wenn diese zeit auch schon um ist, befürchte ich, lohnt es sich nur noch, aus den Festplattemagneten ordentlich starke Kühlschrankmagnete zu machen. (Ohne Gewähr).
DetlevD
QUOTE (vI3Tz @ Jun 19 2012, 17:31) *
... MFT und MFT mirror sind defekt. Also kann ich es nicht reparieren. Ist die Platte noch zu retten? Die Daten sind mir egal.

Es gibt noch ein paar Möglichkeiten.
Die Paragon Software benutzen und erst einmal die Platte mit einem anderen Dateisystem formatieren, z. B. Linux Ext4FS oder Apple HFS+, eine kleine Partition max. 1 GB reicht aus.
Vielleicht auch 'mal mit GPT experimentieren, wenn vorhanden.

Wenn Fehler auftreten, dann Low Level Format Tool vom Plattenhersteller besorgen und ausführen.
Wenn Fehler auftreten, dann ...
Wenn keine Fehler auftreten, dann noch einmal probieren, mit MBR und NTFS zu formatieren.
Und intensiven Plattentest durchführen.

DD.20120619.1850.CEST
vI3Tz
MFT und MFT mirror konnte ich dank eines intensiven Suchlaufes mit TestDisk wiederherstellen. Habe auch direkt den MBR neu geschrieben. Anschließend habe ich eine low level formatierung mit dem CCleaner durchgeführt und noch einmal chkdsk ausgeführt.

Letztendlich sind auch in Paragons Partition Manager keine Fehler im Dateisystem mehr auffindbar gewesen. Von daher bin ich nun soweit der Festplatte wieder zu vertrauen.

Euch ein riesiges Danke für die tolle Unterstützung!!
DetlevD
QUOTE (vI3Tz @ Jun 21 2012, 10:04) *
MFT und MFT mirror konnte ich dank eines intensiven Suchlaufes mit TestDisk wiederherstellen. Habe auch direkt den MBR neu geschrieben. Anschließend habe ich eine low level formatierung mit dem CCleaner durchgeführt und noch einmal chkdsk ausgeführt.
Letztendlich sind auch in Paragons Partition Manager keine Fehler im Dateisystem mehr auffindbar gewesen. Von daher bin ich nun soweit der Festplatte wieder zu vertrauen. Euch ein riesiges Danke für die tolle Unterstützung!!

Gut, dass du deiner Fesplatte wieder Vertrauen entgegen bringst.

Ich möchte nur anmerken, dass ich nicht glaube, dass CCleaner überhaupt in der Lage wäre, eine low-level Formatierung durchzuführen.
Im übrigen steht eine low-level Formatierung ganz am Anfang des Prozesses, der mehrere Stunden dauern kann, bei großen Festplatten vielleicht sogar Tage dauert.
Dafür findet man gelegentlich das passende Programm direkt beim Hersteller der Festplatte.
Vielleicht gibt es auch entsprechende Tools unter Linux, die diese Funktion liefern.
Nach der low-level Formatierung wird die Festplatte dann mit Master Boot Record oder GPT versehen, die Partitionen werden definiert, und diese dann jeweils mit einem gewünschten Dateisystem formatiert.

DD.20120621.1100.CEST
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2014 Invision Power Services, Inc.