Das Gewitter-Rätsel: Die Auflösung.

Hier wird die Lösung zur Frage im Ankündigungstopic fürs Adventsgewinnspiel 2006 erläutert.

Das Gewitter war über Bochum.

Wenn man den "richtigen" Player hat, ist das Rätsel gar kein Rätsel. Winamp 5.08d spielt die Lösung direkt ab, und auch den VLC kann man leicht dazu überreden, indem man etwas zurückspult.
Eine andere Möglichkeit ist es, das Gewitter auf eine mp3-CD zu brennen und in einem CD/DVD-Player, Discman oder Autoradio abzuspielen, der schon etwas älter ist, aber schon das Feature "mp3-fähig" hat. Auch hier hört man evtl. direkt die Gewitter-Oma.

Lösungsanleitung, ohne einen neuen Player zu installieren

So gibt praktisch jeder Player die Lösung preis: Die Datei in einem Hex-Editor öffnen, das erste Byte ($49, bzw. der Buchstabe "I") durch 0 ersetzen, abspeichern, abspielen, zuhören. Die Information, wo das Gewitter war, kommt relativ am Anfang des Gesprächs zwischen einer schwerhörigen alten Dame und einem Polizeibeamten in der Notrufzentrale.
Alternativ kann man das Patchprogramm im Anhang benutzen, was genau das auf Knopfdruck durchführt.


Wie geht das? Warum spielen einige Player Donnergrollen ab, und andere einen Notruf, der angeblich sogar echt ist? Warum macht ein Byte so einen Unterschied?
Zunächst: Die Datei ist nicht fehlerhaft(1). Es werden auch keine Sicherheitslücken oder merkwürdige Eigenheiten in mp3-Dateien ausgenutzt, sondern nur die Möglichkeiten, die der ID3v2-Tag so bietet.
Und der Klarheit halber: Ein Player, der nur Donnergrollen abspielt und als Länge 16 Sekunden angibt, arbeitet 100%ig korrekt. Es sind die Oma-Player, die (zumindest von einem gewissen Standpunkt aus) fehlerhaft arbeiten! Dazu mehr im weiteren Verlauf.



Erklärung für dieses absonderliche Verhalten


Wenn man sich den Anfang der Datei mal in einem Hex-Editor anschaut, erkennt man als allererstes die Zeichen "ID3". Das ist der Beginn eines ID3v2-Tags. Wenn man das Gewitter mit einem mp3-Player abspielt, dann wird ja auch in der ID3v2-Tag-Anzeige das angezeigt (vgl. auch Fußnote (1)):

Zitat:

Artist: Das Wetter Titel: Gewitter über Deutschland Album: Blitz und Donner

Wenn man schon den Hexeditor offen hat, stellt man sich vielleicht die Frage, wo in dem Tag was von "Gewitter" steht. Viele Hexeditoren bieten die Möglichkeit, nach Zeichenketten zu suchen. Eine Suche nach "Gewitter" springt irgendwo ca. 2/3 in die Datei hinein. Ein ID3-Tag mitten in einer mp3-Datei? Nein. Der Id3-Tag ist hier einfach so groß - er nimmt 2/3 der Datei in Anspruch, und nur das letzte Drittel ist für das Donnergrollen zuständig!
Ein Hinweis darauf liefert auch die Information "Header found at 594651", den einige mp3-Player in den Dateidetails anzeigen. Die Musik fängt (eigentlich) erst nach ca. 580kb an!

Einige haben ja auch die Zeichenkette "XMP" am Anfang entdeckt, und tatsächlich spielt diese (besser gesagt das "XMP1") eine zentrale Rolle. Diese Zeichenkette ist die ID eines "Frames"(2) innerhalb des ID3-Tags. Frame-IDs, die mit X, Y, oder Z beginnen, sind laut ID3-Standard "für experimentelle Zwecke" und können einfach so benutzt werden. Natürlich in dem Bewusstsein, dass es keine Garantie gibt, dass andere nicht dieselbe ID für was anderes benutzen, oder dass irgendein Programm damit was anfangen kann.(3)
In diesem speziellen experimentellen Frame, den ich mit "XMP1" bezeichnet habe, steckt eine weitere mp3-Datei. Ich hätte auch "XMP3" nehmen können, aber das wäre zu einfach gewesen . (4)
Und hiermit ist hoffentlich auch klar, warum ich der Meinung bin, dass die "Oma-Player" fehlerhaft arbeiten: Das Oma-Mp3 steckt im ID3-Tag, in dem Meta-Informationen über das eigentliche Lied gespeichert werden. Es ist genauso einzuordnen wie die Textinformationen in dem Tag, oder auch manchmal anzutreffende Bildinformationen (z.B. Cover) im Tag.

Etwas über den Aufbau von mp3-Dateien.

Eine mp3-Datei hat keinen "Header" im üblichen Sinn. Es gibt hier keinen Teil am Anfang der Datei, wo drin steht, "Hallo, ich bin eine mp3-Datei. Meine Bitrate ist 128, meine Samplerate 44.100, ich bin Stereo und 2 Minuten 30 lang."
Eine mp3-Datei besteht aus vielen vielen MPEG-Frames. Jeder dieser Frames beginnt mit einem Header, und in jedem dieser 4 Byte großen Header stecken die Informationen über Bitrate etc. drin. Bekommt ein Player eine mp3-Datei, muss er in dieser Datei den ersten solchen MPEG-Header suchen. Ab da ist dann meistens alles geregelt.
In der Regel fängt eine MP3-Datei mit einem MPEG-Frame an (also direkt mit "Musik"), oder mit dem ID3v2-Tag. Es kann auch Unsinn am Anfang stehen, oder "Nichts", was meistens durch einen schnell gelöschten ID3v2-Tag resultiert(5).
In diesem speziellen Fall beginnt die Datei mit einem recht großen ID3-Tag, der als Zusatzinformation eine weitere mp3-Datei enthält. Eine sinnvolle Anwendung hierzu wäre evtl. eine Art Audiokommentar des Interpreten zu dem Titel. Oder für Bastler könnte man die unterschiedlichen Spuren für Remixe auf diese Art in die Datei einbinden.
Ob man bei der Suche nach einem MPEG-Header den ID3-Tag mit einbeziehen sollte - darüber kann man diskutieren. Wirklich Sinn macht das imho nicht.

Fazit

Ein mp3-Player, der bei der Header-Suche den ID3-Tag mit einbezieht, findet in dem experimentellen XMP1-Frame was zum Abspielen. Player, die erst nach dem ID3Tag danach suchen, fangen bei dem Donnergrollen an. Ebenso verhalten sich Player, die den ID3v2Tag nicht kennen, was bei vielen etwas älteren Hardware-Playern der Fall ist.
Wenn wir nun den ID3-Tag zerstören, indem wir den Header ungültig machen, fängt jeder Player mit dem Abspielen bei der Oma an.


Es folgen nun ein paar Kommentare meinerseits zu diversen Playern. Ehrlich gesagt, kann ich einige Sachen kaum glauben.

Winamp

In ID3v2Tags ist es ausdrücklich erlaubt und vorgesehen, beliebige Binärdaten (z.B. Bilder) unterzubringen. Solche Daten können unter Umständen falsche MPEG-Header enthalten, was die Wiedergabe durcheinanderbringen kann (z.B. durch ein Knacksen am Anfang). Daher gibt es die Möglichkeit, Binärdaten vor der Verwendung in ID3-Tags so aufzubereiten, dass sie keine Daten enthalten, die als MPEG-Frame fehlinterpretiert werden können. Dieses Verfahren nennt man "Unsynchronisation". Ich verweise einfach mal hierhin und behaupte, dass der neue Winamp (und andere Player, die die Oma direkt abspielen) in der Hinsicht nicht optimal arbeitet. Man könnte wahrscheinlich Bilder in Picture-Frames so modifizieren, dass sie furchtbare Geräusche beim abspielen erzeugen.

VLC

Dieser imho äußerst geniale Player hat die Fähigkeit, fast alles abzuspielen. Dabei ist es ganz egal, ob die Datei komplett ist, oder Lücken aufweist. Meine Version des VLC reagiert bei der Datei so, dass die Wiedergabe mit Donnergrollen anfängt, der Schieberregler aber in der Mitte startet. Zieht man ihn zurück, landet man in dem Bereich der Datei, in der die Oma quasselt. Der VLC findet da MPEG-Header (obwohl er sie dort nicht vermutet hätte), und spielt sie ab. Imho konsequent und vernünftig, wenn man das generelle Verhalten dieses Players berücksichtigt.

Windows-Media-Player

Der WMP spielt die Oma nicht ab, sondern nur das 16sekündige Donnergrollen. Trotzdem wird als Spieldauer 53 Sekunden angezeigt. Dies resultiert wahrscheinlich daraus, dass der WMP bei der Berechnung der Spieldauer die Größe des ID3v2-Tags, der hier gut 2/3 der Datei einnimmt, ignoriert. Imho ein einfach nur peinlicher Fehler, denn auch bei normalen Dateien, die ein Cover o.Ä. im Tag haben, kann die Länge dadurch um einige Sekunden verfälscht werden.
Weitere Tests haben ergeben, dass der Windows Media Player 11 die aktuelle Version 2.4 des ID3Tags scheinbar nicht wirklich unterstützt, obwohl diese auch schon 6 Jahre alt ist. Zwar wird der Tag erkannt (sonst würde man die Oma hören), aber er kann nicht ausgewertet werden. Das ist nicht nur bei so exotischen Sachen wie hier der Fall, sondern scheinbar auch bei normalen Dateien, die mit 2.4 getaggt wurden.
Schlimmer noch: Ändert man den Tag, dann wird vor den vorhandenen ID3v2.4Tag ein weiterer Tag in der Version 2.3 geschrieben. Mit anderen Worten: Für MP3-Dateien ist der WMP nicht nur unbrauchbar, sondern durch dessen Verwendung können Informationen zu der Datei verloren gehen!(6)

bass und fmod

Player, die auf der bass.dll oder fmod aufsetzen, spielen nur Donnergrollen ab. Nach einem Patch der Datei wird bei bass nur die Oma abgespielt, obwohl danach eigentlich das Donnergrollen kommen sollte (wie es bei Winamp wohl auch der Fall ist, und auch in meinem Autoradio). Bei Fmod kommt nach der Oma das Donnergrollen, aber verzerrt. Ich vermute, dass da diese Engines durcheinanderkommen, weil Donnergrollen und Oma unterschiedliche Sampleraten haben (44 bzw. 22 kHz). Inwiefern "variable Samplerate" in mp3-Dateien erlaubt ist, weiß ich nicht.

ATL (AudioToolsLibrary)

Eine recht weit verbreitete OpenSource-Unit für die Anzeige von ID3-Tags ist die ATL. Die Entwicklung wurde schon vor einiger Zeit eingestellt, daher ist es nicht so verwunderlich, dass sie einige Macken hat. Trotzdem: Die ATL parst Id3v2.4-Tags nur dann richtig, wenn die einzelnen Frames (=Informationsfelder) jeweils nicht größer als 127 Bytes sind. Für Titel und Interpret mag das ausreichen, allgemein jedoch nicht. Bei längeren Daten greift ein Fehler in der Implementierung der ATL, der darauf beruht, dass die Längeninformationen in Version 2.4 etwas anderes gespeichert werden.


Ich hoffe, es ist jetzt einiges klar geworden. Alles kann ich nicht erklären, bei einigen Dingen kann ich nur begründete Vermutungen anstellen. Wer alternative Lösungen für das Rätsel hat, kann sie hier posten.

________________________
(1): Zumindest denke ich das. Warum weder der WMP11 noch mein etwas älteres Winamp die Standard-Informationen, die im ID3-Tag stecken, anzeigt, ist mir schleierhaft. Der VLC (der ja praktisch alles schluckt) zeigt es an, und mein eigener Player (Nemp) auch, ebenso "MP3TagStudio".
Ob VLC und MP3tagStudio das schlucken, weil sie eine bessere Fehlerkorrektur haben und Nemp, weil es eine zur verwendeten (fehlerhaften?) Schreibroutine die passende (ebenso fehlerhafte?) Leseroutine benutzt, oder ob Winamp und der WMP da irgendwelche Probleme haben, weiß ich nicht.
(2): Ein ID3v2-Tag ist unterteilt in mehrere Frames (= Informationseinheit). Jeder Frame beginnt mit einer Frame-ID (4 Bytes), und einer Größenangabe. Jeder Frame speichert eine bestimmte Information. Z.B. hat die Information "Titel" die Frame-ID "TIT2".
(3): Aufgrund der Größenangabe im Frame-Header können Id3-Tagger und mp3-Player unbekannte Frames einfach überspringen, daher macht das keine Probleme.
(4): Bevor die Frage kommt: Ja, theoretisch könnte diese mp3-Datei wieder einen ID3v2Tag haben, der wieder eine Mp3-Datei enthält. Rekursiv gebaute MP3s sind möglich!
(5): Wenn man den ID3v2Tag einfach mit Nullen überschreibt, erspart man sich das Neuschreiben der kompletten Datei!
(6): Aber Hauptsache ist ja, dass DRM und die Onlineshops funktionieren...

Ich bin auch durch den VCL-Player draufgekommen (Winamp startet nur noch manchmal - MS hat ein Problem festgestellt - deshalb hab ich die Datei mit dem VCL-Player geöffnet). War auch verwundert, dass der Schieberegler in der Mitte etwa beginnt, also hab ich ihn mal nach ganz vorne gezogen und siehe da: Die Oma war zu hören.

Also ich bin sofort durch Audacity drausgekommen. Ich musste die Datei nur öffnen und schon kam das Gespräch. Ich dachte erst, na so blöd wird das EE-Team nich sein, dass es die Lösung gleich am Anfang der Datei lässt. Als ich dann aber die Datei in Nemp abgespielt habe, da war auf einmal nur Grollen. Da wusste ich dann, wie schwer es die anderen haben mussten.

Naja, Adobe Audition hat auch kein Problem damit. Gehört habe ich es zuerst in JetAudio. Wie ich darauf gekommen bin, dass da noch was zusätzlich ist (und dass eben zwei Audio-Infos drin standen):
Der WMP zeigt 128 kbit/s an, In Adobe steht aber drin 32 kbit/s... Und in der Tat hörte sich das Donnern nicht nach 32 kbit an.
Adobe kennt XMP und zeigt die zusätzliche Audiospur auch unter Audiodaten 2 unter XMP an (in Audiodaten 1 stehen die Infos, also 32 kbit und so)...

Verwunderlich nur, dass diese beiden Spuren dann hintereinander ohne erkennbare Trennung angezeigt (und abgespielt natürlich) werden. Und dass als Audioformat der gesamten Datei 32 kbit angegeben werden, obwohl das ja wohl nur das Format der Sprache (nicht aber des Donnergrollens) ist. Oder?

Ich habs gestern meinem Infolehrer mal zum Knobeln gegeben. Mit dem entsprechenden Hinweis, dass ein Hex-Editor oder miestens ein anderer Mediaplayer reicht, hats er sehr schnell rausbekommen. (1 Minute vlt., aber er hatte ja den Vorteil, dass er bei mir nur Fragen musste, ob der Lösungsansatz richtig oder falsch ist *g*).
Nun er hats mit

IrfanView
gemacht. Der spielt dann gleich bei der Oma los und geht zum Schluss zum Gewitter über, wobei er die verschiedenen Bitraten gleich merkt.

Hmm...Wenn ich so höre, mit wie vielen Playern man direkt die Oma hört, dann glaube ich, dass ich noch etwas an meinem Tool arbeiten muss, was die aktuellen Charts in Dateien versteckt, in denen man sonst nur das Rauschen meiner Klospülung hört .

Obwohl: So ein großer Unterschied lässt sich da eh nicht raushören.

Gausi hat folgendes geschrieben:

Obwohl: So ein großer Unterschied lässt sich da eh nicht raushören.

*nick* Ich sag nur Hotel auf der Insel Honshū

feines ding das mp3. zu meiner verwunderung hat der in irfan-view integrierte player alles problemlos abgespiel. jaja ich weis, wie um alles in der welt kommt man bitte darauf ausgerechnet einen bildbetrachter mit einem mp3 player auszustatten? wohl weil es geht!

Mir ist heute noch was aufgefallen:
Wenn man die Dateiendung auf z.B. wav ändert spielt auch WindoofsMP die Oma ab, aber nur die Oma.