mp3 Restaurierung / Konsistenzcheck

mr44er

moderater Moderator
Teammitglied
Ich habe noch ein paar mp3-Dateien verteilt auf diversen alten Datenträgern rumgammeln. Da sind tlw. Aufnahmen von mir und Kumpels vor 1999 dabei und es sind Unikate, einfach neu rippen ist nicht. Manchmal Sprachaufnahmen, manchmal Musik, manchmal beides gemischt.

Damals hatte ich noch keinen blassen Dunst von Konsistenz und encodern, geschweige denn vom Phänomen, dass Rohlingsbeschichtungen auseinanderblättern.:rolleyes:

Unlängst haben wir aus Nostalgie während einer Autofahrt die alten Schinken zur Belustigung gehört und festgestellt, dass es an manchen Stellen kracht und quietscht - ein klares Zeichen dafür, dass die Dateien defekt sind.

Spiele ich die Dateien am PC mit VLC ab, passiert das mal, mal aber auch nicht. Das verwirrt mich jetzt: bügelt vlc sowas aus (geht das überhaupt?) und das Autoradio nicht?
Fall ersteres, auf was basiert das 'Ausbügeln'?

Ich weiß ja, dass sich defekte mp3s quietschig anhören z.B. nach Festplattencrash und dann mit Rettungstools 90% der Datei zu bekommen. Als mir das mal passierte, habe ich die 'Schätze' einfach neu eingelesen und mich danach mit winsfv bzw. quicksfv auseinandergesetzt. Damals nutzte ich noch Windows/ntfs und bitrot war noch nicht so das Thema, weil Festplatten teuer und die Kapazität gering waren.
Mit ZFS ist das ja alles nicht mehr so das Problem.

Ich bin mir jetzt unsicher, wie ich mit den Dateien verfahre:

1. Ich weiß nicht mehr, mit welchen encoder sie geschrieben wurden. Wahrscheinlich gemischt, mal dieses Tool, mal ein anderes im Laufe der Zeit, zumal die Dateien nicht alle von mir sind. Weiß ich nicht, ob der encoder hierbei zum Problem überhaupt eine Rolle spielt.

2. Ich vermute, dass es mehrere Möglichkeiten an 'Defekten' (je nachdem wo was in der Datei fehlt oder was die recoversoftware anstellt, wie leere Stellen füllen oder sowas) gibt und somit unterschiedliche Auswirkungen. Zeitanzeige spielt verrückt, Vorspulen geht nicht/hängt, falsche Klänge etc.

3. audio/mp3val habe ich mal ausprobiert. Es macht auch irgendwas und 'korrigiert' bzw. schreibt das in eine neue Datei, aber ich würde gerne wissen was da passiert, sodenn es diverse Defekte gibt, mehrere Korrigierarten whatever. '-vv' ist nicht so verbose, dass es mich aufklären würde. :( Gibt es bessere/geeignetere Tools?

4. Beim Stöbern bin ich dann noch auf id3v2 gestoßen, mit dem man beim Erstellen von mp3s gleich einen CRC(-Wert) reinschreiben kann. Auch da blicke ich nicht durch. id3 sind doch Tags innerhalb einer mp3, also Metadaten? Hieße das, dass wenn ich heutzutage beim Erstellen einer mp3 diesen Wert reinschreiben lassen würde, mir diese Datei nicht mehr kaputtgehen kann oder doch und ein Abspieler kann es onthefly ohne Defekt abspielen?
Jetzt gibt es von id3v2 noch mehrere Versionen und tools dazu, wie eyed3 oder so ähnlich. Es verwirrt mich völligst.

5. Wie überprüfe ich die Konsistenz überhaupt? 1x Probehören, also auf die Ohren verlassen (schlechte Idee wenn ein Player Defekte einfach onthefly repariert) oder gibt es dazu Tools?

6. Angenommen ich habe die 'healthy' Dateien in einen Ordner sortiert und möchte sie 'ordentlich' archivieren. Auf ZFS und ECC verlassen oder doch eine .sfv dazu generieren oder macht man das in der BSD-Welt mit md5 oder sha256?

7. Etwas andere Baustelle, aber doch auch irgendwie dazugehörend: der Lautstärkepegel. Die Aufnahmen sind mit grottigsten Mikrofonen damals erstellt worden, somit ist die Qualität insgesamt schlecht. Was ein Kompressor bewirkt, weiß ich, soll hier aber nicht eingesetzt werden. Normalisieren und in die Datei festschreiben wäre eine Option, wenn das keine erneute Qualitätsminderung bewirkt.
Übrig bliebe noch mp3gain, aber auch das habe ich nicht gänzlich verstanden. Das soll ohne Qualitätseinbuße funktionieren und nur einen tag (Pegel rauf oder runter, der Player wendet es an) schreiben.
Verstehe ich das richtig, dass mp3gain sich eine Datei anguckt, den Maximalpegel als 99% (kurz vor Übersteuern) definiert und der Rest somit im Verhältnis vom Player gespielt wird?

Mir fehlt da echt Basiswissen und hoffe, dass ihr mich erhellen könnt. :)
 
1999 war die Frühzeit von mp3. In dem Jahr ist zwar Lame 3.0 erschienen, was einen sehr gravierenden Qualitätssprung brachte, aber sehr wahrscheinlich habt ihr noch einen der anderen, damals verbreiteten Encoder genutzt. Die basierten (nahezu) alle auf dem geleakten Fraunenhofer-Code, waren recht ineffizient und hatten ein schlechtes psychoakustisches Modell. Das ging so weit, dass man mit guten Kopfhörern den Encoder raushören konnte. Sie erzeugten eindeutige Artefakte.

Tools wie mp3val sind dann eine Hilfe, wenn man nicht neu encoden will. Weil jedes encoden immer einen Qualitätsverlust bedeutet und gerade bei schon "minderqualitativen" mp3 kann das bedeutend sein... Bessere Ergebnisse erzielt man aber meist, indem man die Datei mit einem guten mp3-Decoder in eine Wave-Datei decodiert. Ich nehme dafür mpg123, aber ich bin nicht das Zentrum der Welt. Die Wave-Datei wird dann für das Archiv in eine FLAC encodet und kann für's Autoradio und so weiter wieder in mp3 encodet werden. Damit hat man von der originalen mp3 bis zum FLAC im Archiv keinen Qualitätsverlust.

mp3 ist nun algorithmisch gesehen ziemlich genial, oder war es zumindest für seine Zeit. Allerdings hat es auch gravierende Nachteile.
mp3 unterstützt erstmal keine Meta-Tags, die verschiedenen id3-Tag Versionen codieren ihre Daten daher in Audio-Frames am Ende der Datei. Das funktioniert, da im Header der Datei eine Dateilänge angegeben ist, diese id3-Frames dahinter liegen und daher von gängigen Playern nicht abgespielt werden. Wenn doch hört man es recht deutlich durch Knacken und Qietschen am Ende der Tracks. Und id3-Tags unterstützen nur eine Nummer als Genre, es gibt daher nur 255 definierte Genres. Dumm, wenn man "Porngrind" als Genre schreiben will und dann bei "Heavy Metal" landet.
mp3 unterstützt auch kein Gapless Playback. Viele Player können es emulieren, meistens aber zu dem Preis, dass gewollte Pausen verschwinden oder verkürzt werden. Und mp3 hat keinerlei Konsistenzmechanismus, aber das haben viele neuere Formate auch nicht.

2. Ich vermute, dass es mehrere Möglichkeiten an 'Defekten' (je nachdem wo was in der Datei fehlt oder was die recoversoftware anstellt, wie leere Stellen füllen oder sowas) gibt und somit unterschiedliche Auswirkungen. Zeitanzeige spielt verrückt, Vorspulen geht nicht/hängt, falsche Klänge etc.
Sobald Frames eingefügt oder verändert werden, spinnt die Zeitanzeige. Ein Klassiker bei alten mp3 ist auch VBR-Encoding. mp3 sieht eigentlich keine variable Bitrate vor, sie wurde später mal reingefrickelt. Alte mp3 auf der Frühzeit haben daher für VBR falsche Headerinformationen, wodurch Player verwirrt sind.

5. Wie überprüfe ich die Konsistenz überhaupt? 1x Probehören, also auf die Ohren verlassen (schlechte Idee wenn ein Player Defekte einfach onthefly repariert) oder gibt es dazu Tools?
Dekodiere die Datei einmal mit einem guten Softwaredecoder wie mpg123. Der schreit recht deutlich, wenn er Frames nicht decodieren kann.

4. Beim Stöbern bin ich dann noch auf id3v2 gestoßen, mit dem man beim Erstellen von mp3s gleich einen CRC(-Wert) reinschreiben kann. Auch da blicke ich nicht durch. id3 sind doch Tags innerhalb einer mp3, also Metadaten? Hieße das, dass wenn ich heutzutage beim Erstellen einer mp3 diesen Wert reinschreiben lassen würde, mir diese Datei nicht mehr kaputtgehen kann oder doch und ein Abspieler kann es onthefly ohne Defekt abspielen?
Jetzt gibt es von id3v2 noch mehrere Versionen und tools dazu, wie eyed3 oder so ähnlich. Es verwirrt mich völligst.
Durch die CRC-Summe kann der Player theoretisch erkennen, dass die Datei verändert wurde. Aber er kann nichts korrigieren. Wenn er den Tag überhaupt beachtet...

Normalisieren und in die Datei festschreiben wäre eine Option, wenn das keine erneute Qualitätsminderung bewirkt.
Da du den Datenstrom verändern würdest, müsstest du neu encoden. Damit sind wir wieder bei FLAC für's Archiv. Aber die meisten besseren Player können Replay Gain, also höre auf @KobRheTilla.
 
Vielen Dank, sehr ausführlich. Damit komme ich weiter. Hier fehlt ein Kuss-Emoji. :D

In dem Jahr ist zwar Lame 3.0 erschienen, was einen sehr gravierenden Qualitätssprung brachte, aber sehr wahrscheinlich habt ihr noch einen der anderen, damals verbreiteten Encoder genutzt.

Ja, das mit lame hatte ich mitbekommen und 'wollte'...aber ich wusste nicht, wie ich den Quellcode verwurste. Binaries für Windows waren nur veraltete aufzutreiben, wenn überhaupt. Ich war damals vielleicht 15 und hatte keine Ahnung. ;)

Also als flac schiebe ich die Dinger erstmal so ins Archiv, je nachdem wie weit ich komme.

Eine Frage jetzt noch zu 'mp3val'. Was macht das Dingen maximal bei einer Reparatur? Anfang und Ende schieben/anpassen, aber fasst so wenig Ton an wie möglich oder gar nicht?
Die Info fehlt mir jetzt noch irgendwie...in flac neu kodieren und das vergleichen mit dem jeweiligen Ergebnis von mp3val ist arg mühselig. Evtl. kann ich mir den Schritt ja einfach sparen?
 
vielleicht lehne ich mich nun zu weit aus dem Fenster. Ich vergesse nämlich schneller, als ich lerne und bin zu faul, extra nochmal nachzulesen.

Seit es mp3 gibt, bin ich davon quasi ein Fan. Also, ich bin kein Fan von niemandem und gar nichts, aber mp3 hatte mich sofort begeistert. Natürlich auch deshalb, weil damals ja Audio-CDs das non-plus-Ultra waren, oder zumindest so galten.

Auf Audio-CDs liegt wav. Ziemlich einfach, plakativ und deshalb auch ein wenig falsch gesagt und genau in dem Stil möchte ich fortfahren, was dann dazu führen mag, dass ich hier lauter Halbwahrheiten von mir gebe.
Damit grätsche ich schon voll hinein: Das wav-Format der Audio-CD ist quasi kein digitales Format und schon muss ich mich ducken! Was ich meine ist natürlich, dass hier das Audio-Signal als analoger Stream rein kam und als digitaler Stream raus kam. Die analogen Spannungswerte der Tonkurve wurden mit (wenn ich recht erinnere) 44kHz abgescannt und dann jedem Messpunkt ein digitaler Wert zugeordnet. Der landete auf CD und war dann als Datei ein wav.

Die Leute vom Fraunhofer-Institut analysierten das nun und betrachteten vor allem Das Datenpaket auf einer CD. Es war sicher nicht besonders schwierig, Potenzial für Komprimierung zu erkennen. Die Frage war halt, wie komprimiert man und zwar möglichst ohne Verlust und so, dass es auch wieder dekomprimiert werden kann und als Musik am Ausgang erscheint.
Ich habe den Namen bladeenc im Kopf, mag aber irren. Ich meine, dass das der erste "Freie" Encoder gewesen ist, mit dem man die Algorythmen des Fraunhofer-Institutes anwenden konnte, um von einer Audio-CD Dateien zu erhalten, die etwa um den Faktor 10 verkleinert waren, sich aber gar nicht schlechter anhörten.
Es gab eine große Debatte um die Rechtmäßigkeit der Verwendung dieses Codes, der ja dem Fraunhofer-Institut entkommen war und schließlich dürfte er nicht binär ausgeliefert werden, sondern wurde dann jeweils selbst kompiliert.
Damit konnte dann der bladeenc verwendet werden und ich war damit sehr glücklich, rippte alle greifbaren CDs und wandelte nach mp3.

Erst im Laufe der Zeit kamen dann Diskussionen auf, dass die Ergebnisse gar nicht so toll seien, dass nicht ganz die Erwartungen erfüllt werden, die man mit hochtrabenden Versprechungen geweckt hatte.
Ich selbst bin damit niemals unzufrieden gewesen und nutze auch heute noch die alten Dateien.
Mit Lame wurde dann alles besser und auch ein wenig einfacher.

Heute gibt es nun flac und da ist nicht in erster Linie das Bestreben, Daten zu komprimieren und damit kleine Dateien zu erzeugen, sondern, ich sage das mal so, klein genug, aber ohne Verlust. Ich habe wenig Erfahrung damit, aber das Ziel scheint tatsächlich so verwirklicht zu sein und flac deshalb womöglich die Lösung unserer Zeit, besonders auch zum Archivieren von Material, aus dem dann evtl mal platzsparende mp3 oder ogg gemacht werden sollen.

Eine Frage jetzt noch zu 'mp3val'.
ich kenne das gar nicht und interpretiere nun den Beitrag von @Yamagi
Das brauchst du eigentlich auch gar nicht, denn du kannst/solltest dein Ausgangsmaterial zunächst in ein wav verwandeln und dazu einen mp3-Decoder verwenden.
Das bedeutet für mich: du liest den digitalen Stream über einen Decoder ein und gibst den "halb-Analog" wieder aus. Das Ergenis ist wie eine alte Audio-CD und ohne all das schöne Beiwerk, wie Header-Daten und so. Du bekommst zwar eine Datei, aber die enthält nur Audio und zwar möglichst korrekt, was einst zu mp3 gemacht worden war.

Erst diese Datei nimmst du dann und "digitalisierst" sie, wandelst sie in ein flac zum archivieren.
Alle weitere Bearbeitung erfolgt dann auf Grundlage dieses Archivs und dann auch möglichst Fehlerfrei.

Nun scheinst du ein Problem direkt auf deinem Ursprungsmedium zu haben und erhoffst dir, dass intelligente Algorithmen fehlende Daten wieder herstellen. Ich kenne mich damit nicht aus, aber es hört sich für mich zunächst mal nach einem typischen Datenrettungsproblem an und nicht nach einem Audio-Konvertierungsproblem.
Deshalb fällt mir dann auch spontan ddrescue ein. ddrescue nutze ich immer häufiger an Stelle eines einfachen dd, auch dann, wenn mir gar keine Fehler auf dem Datenträger bekannt sind. Ich habe dazu keine Erfahrung und lige vielleicht vollkommen falsch, aber, was du ja zunächst möchtest, ist ein Image der alten Datenträger erstellen, mit dem du arbeiten kannst und das auch möglichst bald, um nicht durch unvorsichtige andere Aktionen, womöglich etwas zu zerstören.
Keine Ahnung, wie ddrescue mit Audio-CDs umgeht.
Es versucht, einen Datenträger auszulesen und bleibt dabei sehr HW-nah. Es liest mehrach hin und hier und versucht, die Information vom Datenträger zu lesen, um sie dann in ein Image zu schreiben, dass endlich weiter bearbeitet werden kann.
Deshalb kam mir das nun spontan in den Sinn.

Anstatt Fehler durch Audio-Programme laufen zu lassen, erst mal versuchen, intakte Images der alten Daten zu erhalten!
Ich glaube auch nicht (weiß das aber nicht), dass Audio-SW besser beschädigte Rohdaten wieder herstellen kann. Deshalb würde ich die Prioritäten etwas anders setzen.
 
<offtopic>Es gibt auch "komplett" digitale Audio-CD (siehe DDD vs AAD/ADD auf der CD) - welches Format da beim Recording (Inputseite) verwendet wurde.. keine Ahnung.</>

Dass "gebrannte" schnell kaputt gehen, war doch schon sehr frueh bekannt!? Ich kann mich da aus mp3.de Zeiten (also 1999/2000) noch erinnern, dass die "Paranoiker" alle 6-12 Monate frisch gebrannt haben; oder Unsummen fuer angeblich sehr langlebige (10 Jahre?) Rohlinge ausgegeben haben. Aber nun ist das Kind im Brunnen und Yamagi hat das allermeiste schon beschrieben.

Bei den Tags wuerde ich noch Titelinformationen ("Freitext") sehen; aber das bringt Dir hinsichtlich reparieren so oder so nichts.
 
Eine Frage jetzt noch zu 'mp3val'. Was macht das Dingen maximal bei einer Reparatur? Anfang und Ende schieben/anpassen, aber fasst so wenig Ton an wie möglich oder gar nicht?
Ich habe mal kurz(!) durch den Code gescrollt: https://sourceforge.net/p/mp3val/subversion/HEAD/tree/trunk/sources/ so wie ich es sehe, schaut es für jeden Frame, ob es ein valider mp3-Frame ist. Defekte Frames werden verworfen (dann quietscht und kratzt es nicht mehr, sondern springt nur noch) und die kompletten Timing-Daten neu geschrieben. Außerdem werden der Dateiheader und id3-Tags korrigiert.
 
Seit es mp3 gibt, bin ich davon quasi ein Fan.
Ich auch. 300 böse zusammengesparte (daher im Hirn auf ewig eingebrannt) D-Mark für eine größere Festplatte. Es war eine 17GB-IDE-Platte. Windows ME damals und FAT32 eben, später dann Win2000 mit NTFS waren ein Segen!

Die analogen Spannungswerte der Tonkurve wurden mit (wenn ich recht erinnere) 44kHz abgescannt und dann jedem Messpunkt ein digitaler Wert zugeordnet. Der landete auf CD und war dann als Datei ein wav.
44,1kHz, FullAck!

Ich habe den Namen bladeenc im Kopf, mag aber irren.
Der allererste, den ich einsetzte...mhm. Namen vergessen, aber der konnte nur bis 56kbps codieren. Ich erinnere mich noch an was mit xing...xingrab....xinggrabber, wo ich die wavs zu mp3 wandelte. Da war eine Hand in der GUI, ähnlich wie im Klassiker 'Catacomb 3D'.

Ich selbst bin damit niemals unzufrieden gewesen und nutze auch heute noch die alten Dateien.
Ich war auch nie unzufrieden, denn Speicherplatz war um die Zeit begrenzt. Bei armen Schülern sowieso. :)

Heute gibt es nun flac und da ist nicht in erster Linie das Bestreben, Daten zu komprimieren und damit kleine Dateien zu erzeugen, sondern, ich sage das mal so, klein genug, aber ohne Verlust. Ich habe wenig Erfahrung damit, aber das Ziel scheint tatsächlich so verwirklicht zu sein und flac deshalb womöglich die Lösung unserer Zeit, besonders auch zum Archivieren von Material, aus dem dann evtl mal platzsparende mp3 oder ogg gemacht werden sollen.
Jep, flac komprimiert ohne was zu schnippeln. wavs gezippt, in stumpf ausgedrückt.

Nun scheinst du ein Problem direkt auf deinem Ursprungsmedium zu haben und erhoffst dir, dass intelligente Algorithmen fehlende Daten wieder herstellen.
Jein. Also die Fehler sind wohl damals entstanden...dauerndes Umkopieren, mal ne fehlerhafte gebrannte CD neu gebrannt etc., FAT32. Kumpel ist nicht IT-affin und hat mir drei nur halbkopierte Dateien gegeben. Solche Geschichten.
Und die 'defekten' Dateien sind dann unbemerkt, weil ich keine Ahnung von Konsistenz hatte, auf meinen damals 'primitiven' Archivdatenträgern verteilt gelandet. Das Lesen von diesen Datenträgern vor kurzem hatte keine Probleme gemacht, ich habe die defekten Dateien 'sauber' eingelesen.... :p und somit nützt dd-rescue nichts. Dass da ein Algorithmus mir die Audiobruchstücke nicht wiederbringt, ist mir klar, aber ich wollte wenigstens die Dateistruktur an sich so korrekt wie möglich bekommen. So wenig lossy wie möglich am Audio, so perfekt wies geht an der Dateistruktur. Ich hoffe, ihr versteht was ich meine....bin noch beim ersten Kaffee. ;)

Dass "gebrannte" schnell kaputt gehen, war doch schon sehr frueh bekannt!?
Ja, aber wenn du ein armer Schüler bist und noch die Zeiten von 10 DM/Rohling kennst, dann ist dir dein Gequassel vom Suff mit den Kumpels doch nicht soooo wichtig und erst recht gehst du nicht davon aus, dass es in 20 Jahren für dich kostbar sein wird.
+die doofen Gesichter, bei buffer underrun, weil du beim Brennvorgang was im Explorer geklickt hast und der Rohling sowie 10 DM 'verbrannt' waren. ;)
Die Generation der Aldi-Rohlinge, ab der die Stiftbeschriftungsseite kein weißes Plastik mehr hatte, die hält ewig. Das sind die einzigen übriggebliebenen (ich habe viele Sorten/Marken ausprobiert) und auf die brannte ich zuletzt bzw. auch heute noch, wenn ich was im Autoradio haben mag.
Ich hatte damals (eigentlich viel zu spät, weil ein Rohling da schon im Verhältnis günstiger 650 MB bot) ein 100er ZIP-Laufwerk von iomega vermacht bekommen. Vllt. wäre dies die bessere Alternative als ein Rohling gewesen. Hätte, hätte Fahrradkette. ;)

Ich habe mal kurz(!) durch den Code gescrollt
Danke dir. Ich habe ergänzend noch was gefunden:

http://mp3val.sourceforge.net/docs/manual.html#messages
 
Zurück
Oben