ID3 2.4 Frame Flags --> Was ist Unsynchronisation?

[Hyperspacer]

Hallo,
Ich versuche gherade verzweifelt Coverbilder aus MP3 Tags auszulesen
Es handelt sich immer um den Tag in der Version 2.4. Die APIC Frames haben leider jedes Mal die Flags für "Unsynchronisation" und für "Data length indicator" gesetzt. Ich habe versucht mich darüber schlau zu machen, bin aber irgendwie nicht weiter gekommen. Könnte vielleicht jemand von den vielen hier die sich schon eingehend mit ID3 beschäftigt haben mir das mal erklären?
Der "Data length indicator" gibt an welche länge die Daten hätten, wenn sie nicht verschlüsselt, komprimiert oder sonst was wären, oder?
Aber was zur Hölle ist "Unsynchronisation"?

[Muetze1]

Data Length Indicator hast du schon richtig verstanden. Vor den Daten folgt nach der Frame noch ein 32 Bit Wert mit der Länge der Originaldaten.
Unsynchronisation bedeutet die Daten wurden so verändert, dass das 7. Bit in jedem Byte nicht benutzt wird und somit die Daten für ASCII Übertragung aufbereitet wurden. Die Daten müssen damit für das wieder auslesen entsprechend rückgerechnet werden. Meiner ID3Lib habe ich dies noch nicht beigebracht, da ich bisher noch nie eine solche Datei hatte. Ich weiss nicht in wie fern gausi dieses Feature schon unterstützt.

[Gausi]

(Argh. Langen Beitrag geschrieben, und dann ist der Browser abgestürzt. )

Nochmal die Kurzfassung. Mit dem 7.Bit oder ASCII-Übertragung hat das nichts zu tun. Vielmehr damit, dass das mp3-Format (so ziemlich) streaming-fähig ist. D.h. eine mp3-Datei kommt ohne einen Dateiheader aus. Stattdessen besitzt jeder MPEG-Frame (davon gibt es ein paar hundert oder tausend pro Datei) einen eigenen 4 Byte großen Header. Dieser Header beginnt mit 11 gesetzten Bits, also FF und >E0. Ein Decoder sucht nun diese Markierungen und versucht die Daten dahinter als MPEG-Frame zu behandeln. Wenn in anderen Binärdaten so eine Bytefolge auftritt (z.B. im Picture-Frame eine ID3-Tags) und der Decoder den ID3v2Tag nicht kennt (dürfte heutzutage eigentlich nicht der Fall sein) und ihn zum Dekodieren nicht überspringen kann, kann es in solchen Fällen zu einem Knackser in der Wiedergabe kommen.

Abhilfe ist dabei ganz einfach, falsche MPEG-Header zu zerstören, also alle FF >E0 (und FF 00) in dem Tag/Frame durch FF 00 >E0 bzw. FF 00 00 zu ersetzen. Zum Un-unsynchronisieren ersetzt man alle FF 00 durch FF. Meine Mp3FileUtils erledigt das automatisch - der Benutzer der Unit muss sich da nicht weiter drum kümmern. (Dafür kann die aber keine Verschlüsselung und Kompression.)

Was man damit für Unsinn treiben kann, zeigen diese beiden mp3-Dateien:

http://www.gausi.de/downloads/gewitt...t_unsynced.mp3
http://www.gausi.de/downloads/gewitter_unsynced.mp3

Hier wurde jeweils in das Donnergrollen-mp3 ein ID3-Tag eingefügt, in den eine andere mp3-Datei eingebettet wurde (in einen Gausi-Spezial-Experimentier-Frame). Einmal wurde Unsynch verwendet, einmal nicht. Wenn man nun den VLC zum Abspielen nutzt (andere Player sind da nicht so flexibel), dann startet der Positions-Schieberegler recht weit hinten - der ID3-Tag ist hier größer als die eigentliche Datei. Bei der einen Version kann man durch Vorspulen vor den Anfang in den ID3-Tag scrollen, wo dann das eingebettete mp3 gefunden und abgespielt wird. Mit Unsynch wird da nichts zum abspielen gefunden, da die MPEG-Header der eingebetteten mp3-Datei zerstört wurden.
Wenn man dann den Header des ID3Tags in den beiden Dateien zerstört (mit nem Hexeditor öffnen und das erste Byte ändern), dann wird dieser nicht mehr erkannt, und bei der ersten Variante spielen dann alle Player vor dem Donnergrollen die "Gewitter-Oma" ab, bei der anderen Version nur das Donnergrollen oder verweigern die Wiedergabe ganz, weil der erste MPEG-Frame zu weit hinten in der Datei steckt.

[Hyperspacer]

Das nenn ich eine gute Antwort!
Vielen vielen Dank!