MP3 Aufnahmen von SD Karte retten?

[Sabbelbacke]

Alloha,

habe gestern mit einem ZOOM H2 eine Live-Aufnahme gemacht, leider hat der letzte, der die Bühne verlies, den Strom gezogen, zack aus weg. Jetzt hat das Ding die Aufnahme nicht abgeschlossen. Ein Kolege wollte nachsehen, ob es geklappt hat, angeschaltet.. Mehr passierte noch nicht. Ich vermute, dass beim Einschalten das Gerät die FAT formatierte, 2GB SD Karte einmal kurz duchprüft und dann ein paar Infos reinschreibt (es finden sich nach dem ersten Einlegen auf einer frisch formatierten Karte danach Verzeichnise, eine Index Datei des H2, usw..)...

Vermutlich wars jetzt also so: Datei nicht abgeschlossen, weil Strom spontan weg. Dann evtl. Platz auf der SD, wo die Datei mal war, durch kleinkram überschrieben..

Die üblichen, bei heise zu findenden, Data-Recovery tools finden nix... ALle möglichen alten JPGs, die da mal drauf waren..


gibt es ein tool, dass gezielt nach MP3 frames sucht? Photrec hab ich schon durch....

[Little Dwarf]

Hmm, ich weiß auch nicht so recht. Ich hab mal einige Gigabyte MP3s mit Recuva (http://www.piriform.com/recuva) wiederhergestellt. Aber ob das in deinem speziellen Fall hilft, weiß ich auch nicht.

[Sabbelbacke]

Danke, den kannte ich noch nicht, mal testen....
Gerade versuche ich mit VLC MP3 aus einem dd Image der SD zu ziehen.... mal schauen..

[Sabbelbacke]

Hat alles nix geholfen.... Kennt jemand den Aufbau eines MP3frames genauer? FF FB im Anfang? Könnte ich nicht ffmpeg oder MPlayer sagen: Nimm Dir mal das File, zieh alles, was MP3 da drin ist, raus und schreibs in ein neues File.. Damit wäre mir schon geholfen (wenn schon das File an sich nicht mehr auffindbar ist)..

[Zwilling999]

Jeder Frame hat einen Header der mit 11 Bit aus Einsen anfängt. Also FF. Danach kommt schon 1 Bit das aussagt welche Mpeg-Version (MP1, MP2, MP2.5 oder Mp3). Der FrameHeader ist 32 Bit (4 Byte) lang. Siehe WikiPedia.

Ob das mit ffmepg oder MPlayer funktioniert weiss ich nicht. Wenn Du aber schon eine Datei hast dann kannst Du die mal einfach in *.mp3 umbenennen und gucken was MPlayer oder ein anderes Programm ausgibt. Wahrscheinlich nur Krach. Also vorher Lautstärke runter. :)

[Sabbelbacke]

Einfach umbenennen geht nicht, wäre auch zu einfach, dann würde ich nicht hier fragen :) MP3-Tools, die auf Frame-Eben was machen, helfen auch nicht, da sie sich allein schon weigern ein 2GB File zu öffnen :) Wer ist ffmpeg Crack und wüsste aus dem Stehgreif, welche Syntax ich brauche um ffmpeg zu sagen, er soll alle MP3 Packete aus dAtei X fischen? -acopy mp3 ?

[Zwilling999]

da sie sich allein schon weigern ein 2GB File zu öffnen :)

Und was ist mit teilen der Datei in 'verdauliche' Häppchen?

[suedpaelzer]

Vielleicht so in etwa

ffmpeg -i Ausgangsdatei.mp3 -acodec copy Ergebnis.mp3

entnommen aus http://wiki.ubuntuusers.de/mp3wrap

Das soll kaputte Dateiheader reparieren können.

[fireball]

Evtl. kann was professionelles wie GetDataBack was reißen... gibts ja zum Test auch erstmal als Demo...

[Sabbelbacke]

Vielleicht so in etwa

ffmpeg -i Ausgangsdatei.mp3 -acodec copy Ergebnis.mp3

entnommen aus http://wiki.ubuntuusers.de/mp3wrap

Das soll kaputte Dateiheader reparieren können.
KLappt leider nicht. Der Punkt ist ja der, dass ich da keine "defekte mp3" habe, sondern ein Image einer SD-Karte, wo irgendwo auf der "Oberfläche" ein paar Mp3s liegen müssten. Die regulären Rettungstools für FAT Dateisysteme finden leider nix, hab jetzt Ontrack, Stellar, testdisk/Photorec, Disk Doctors, Recover Files Platinum und Recuva durch, keines hat was gefunden. Zumindest bei Photorec bilde ich mir ein, dass es auch simple MP3-frames ohne Header finden sollte, es kommt aber nix bei rum...

Daher die Idee, ffmpeg drauf los zu lassen, ich muss ffmpeg aber sagen, dass es quasi "brute force" anwenden soll - mit dem Standard-Stream-Copy sucht er nach intakten Mp3headern, die er am Anfang eines Diskimages natürlich nicht findet und bricht dann ab, weil ihm der Datenstrom nicht passt. VLC fummelt eine Weile dran rum, extrahiert auchirgendwas, aber nichts brauchbares (drei intakte MP3s sind auf der SD, die sollten Minimum ja dann da auftauchen)...

Das letzte Mal, dass ich mit ffmpeg was gemacht habe, war zu der Zeit, als ich verlustfrei MS-MPEG in ISO-MPEG4 verwandelt habe mit ein paar ffmpeg Tweaks, aber seit dem hat man da alles umgebaut.

Weiß jemand, ob man ffmpeg (oder mplayer) auch brute force mässig auf so was loslassen kann?

@fireball
das kenn ich noch nich, das probier ich mal

[suedpaelzer]

Ah... da fällt mir noch testdisk ein

http://www.cgsecurity.org/wiki/TestDisk

Wenn nur die FAT-Tabelle kaputt ist, müßte Testdisk dann hinbekommen.

[Sabbelbacke]

DAnke, hatte ich ja schon probiert. GetDataBack konnte auch nix reissen... I am out of luck..

[suedpaelzer]

Daher die Idee, ffmpeg drauf los zu lassen, ich muss ffmpeg aber sagen, dass es quasi "brute force" anwenden soll

Ich weiß nicht, ob im Grabber-Modus das helfen würde, d.h. das Image als Input-Device wählen und schauen, ob am Ende was brauchbares herauskommt.

[Sabbelbacke]

klingt interessant, hast Du das schon mal gemacht? Wie geht?

[suedpaelzer]

Nein, das habe ich noch nicht ausprobiert. Es war eine spontane Idee während ich gestern durch die Beschreibung gegangen bin.

[suedpaelzer]

Isobuster?

[suedpaelzer]

Audacity wäre auch ein Kandidat. Ich habe mal ein Image von meinem Zoom H4 gemacht, jedoch habe ich derzeit nur WAV-Dateien drauf. Dann mit audacity per Import->Rohdateien importieren. Meine Dateien hat er gefunden, wenn auch als einen Audiostream. Leider kann ich nicht sagen, ob es auch MP3 klappt.

[Sabbelbacke]

audacity probier ich mal aus... ah, interessant, es schluckt das Image und versucht es als mp3 zu öffnen, mal sehen, was passiert...

[Sabbelbacke]

Hm, als Mp3 geöffnet präsentiert er mir leider nur die Sachen, die auch als Files auf der SSD da sind (also die zwei Testeaufnahmen, die ich vor der jetzt gesuchten gemacht habe, so Sekundenschnipsel). Als "Raw" geht da natürlich so erst mal nix, er kann da nur PCM und Derivate, MP3 erkennt er da nicht...
Hm.... Murks das alles...

[suedpaelzer]

Schade...

Versuche doch mal folgendes:

ffmpeg -i sdimage -f mp3 output.mp3

Ich habe mein vorhandenes Image unter Linux als loop device gemountet und eine vorhandene MP3-Datei noch in das Image zu den vorhandenen WAV-Dateien reinkopiert. Das ganze wieder abgehängt und dann diese Imagedatei, wie oben, dem ffmpeg gefüttert. Daraus habe ich genau diese eine Datei wieder bekommen, jedoch erstmal mit 64 kB/s Bitrate. Das kann ja später immer noch optimieren. Gut, das Image hat noch einen funktionierenden FAT-Tabelle, die kann ich aber ggf. noch kaputt machen, um zu sehen, ob es weiterhin funktioniert.

Edit:

ffmpeg -f mp3 -vn -re -i sdimage -acodec copy output.mp3

sollte nach mp3 suchen, keine Video suchen und das ganze 1:1 rausschreiben

ffmpeg -f mp3 -i sdimage

sollte zumindest die gefundenen Streams anzeigen.

Ansonsten müßte ich schon vermuten, dass der Rekorder beim Formatieren wohl schon einiges kaputt gemacht und nicht nur die FAT-Tabelle neu erstellt hat.

Wie hast Du dd aufgerufen? Mit dd if=/dev/xxx of=sdimage ?

[fireball]

Das kann aber auch nur funktionieren, wenn alle Blöcke der Datei(en) ordentlich nacheinander ins Filesystem geschrieben wurden. Da muss man schon sehr optimistisch sein...

[suedpaelzer]

Das kann aber auch nur funktionieren, wenn alle Blöcke der Datei(en) ordentlich nacheinander ins Filesystem geschrieben wurden. Da muss man schon sehr optimistisch sein...
Das ist schon klar, aber ich glaube, hier würde schon ausreichen, wenn überhaupt ein Großteil gerettet werden kann.

[Sabbelbacke]

Merci für die Vorschläge!!


ffmpeg -f mp3 -vn -re -i sdimage -acodec copy output.mp3
Hab ich mal getestet, ich kriege:


built on Nov 11 2011 01:46:59 with gcc 4.6.2
configuration: --enable-gpl --enable-version3 --disable-w32threads --enable-
ntime-cpudetect --enable-avisynth --enable-bzlib --enable-frei0r --enable-libo
ncore-amrnb --enable-libopencore-amrwb --enable-libfreetype --enable-libgsm --
able-libmp3lame --enable-libopenjpeg --enable-librtmp --enable-libschroedinger
-enable-libspeex --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwb
c --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libxavs --enabl
libxvid --enable-zlib
libavutil 51. 24. 1 / 51. 24. 1
libavcodec 53. 31. 0 / 53. 31. 0
libavformat 53. 20. 0 / 53. 20. 0
libavdevice 53. 4. 0 / 53. 4. 0
libavfilter 2. 47. 2 / 2. 47. 2
libswscale 2. 1. 0 / 2. 1. 0
libpostproc 51. 2. 0 / 51. 2. 0
[mp3 @ 020B9EA0] Header missing
Last message repeated 9 times
[mp3 @ 020B9620] Estimating duration from bitrate, this may be inaccurate
Input #0, mp3, from 'g:\image.mp3':
Duration: N/A, start: 0.000000, bitrate: N/A
Stream #0:0: Audio: mp1, 0 channels, s16
Output #0, mp3, to 'output.mp3':
Output file #0 does not contain any stream

Photorec findet, auf dieses Image losgelassen, wenigstens die Sachen, die intakt noch drauf sind. ffmpeg findet so gar nix (ist witzigerweise aber auch nach rund 3 sekunden fertig, das Image ist 2GB, selbst bei einer SSD unwahrscheinlich).

[suedpaelzer]

Mhhmm.. das sieht nicht gut aus. Da kann nur noch ein Programm helfen, der auf low level die Teile sucht. Vermutlich klappt das auch nicht, weil evtl. schon überschrieben.

Edit:

Leider habe ich momentan nicht so die Zeit, sonst hätte ich da mal an einem C-Programm das ganze versucht. Den Aufbau des Header / Frames findet man ja beim Wikipedia.

[Sabbelbacke]

Danke Dir. Ich denke mal, dass Photorec genau das macht, dass es den Datenstrom simpel nach den Signaturen für Frames und Header durchsucht. Insofern glaube ich langsam, dass die Sache einfach glücklos ausgegangen ist :(