Tja, das wüsste ich auch mal gerne.
Zum einen sollte das Format wohl streamingfähig oder so sein. d.h. ein player sollte in der Lage sein, an jeder beliebigen Stelle in das Stück einzusteigen, auch ohne den Anfang der Datei zu kennen. Daher muss jeder Audio-Frame einen Header haben, in dem Informationen über die Art der AudioDaten drin stehen. Daher muss der erste Header dieser Art auch nicht notwendig am Anfang der Datei stehen, wie es bei einfachen Formaten wie z.b. BMP der Fall ist.
Und dann das Gedöns mit den ZusatzInfos. Angefangen hat das wohl mit dem id3v1-Tag, der sehr einfach ist (die letzten 128 bytes eines mp3-files). Problem dabei ist, dass in 128 Bytes nur sehr wenig reinpasst, und daher hat man sich an Version2 rangemacht, und das würde dann EXTREM GRÜNDLICH gemacht. In den id3v2 Tag kann man theoretisch alles reinschreiben. Zum Beispiel Bilder. Oder das Video zu dem Lied. Oder vielleicht ein anderes mp3-File, indem der Ersteller seine Lebensgeschichte erzählt. Das würde dann eine rekursive Dateistruktur mit sich ziehen

Oder sogar ein bissel ausführbaren Code, der einem die Platte formatiert, wer weiss..?
Leider ist die Größe eines id3v2 Tags auf 256 MB (=2^28 Byte) beschränkt, daher gibt es die Möglichkeit, im id3v2Tag anzugeben, ob (und wenn ja wo) ein WEITERER id3v2Tag in der Datei zu finden ist. Man ist eben auf alles vorbereitet...
Ein weiterer Punkt ist der, dass man die AudioFrames mit einem gültigen MPEG-Header missbrauchen kann, um weitere Informationen zu speichern. Warum das beim abspielen keine Probleme macht, weiss ich nicht genau. Liegt wohl an der Art der mp3-Komprimierung.
Das machen zum Beispiel XING und LAME, die in den ersten MPEGFrame bei mp3s mit vbr u.A. die Anzahl der Frames reinschreiben, um die Dauer des Stücks berechnen zu können, OHNE die ganze Datei untersuchen zu müssen.
Und da es eine Vielzahl von Encodern gibt, und theoreitsch jeder seinen Senf dazugeben kann, wird das ganze eben etwas kompliziert.
We are, we were and will not be.