Och, wenn die Dokumentation halbwegs klar ist, ist das Parsen und die Manipulation von Binärdateien auf dem Level eigentlich kein Problem. Die Fehlerbehandlung und "never trust an input" ist fast komplizierter als der Rest. Geht ja bei mir nicht um den Audiocodec, sondern nur um die Metadaten. Da hält sich die Komplexität noch in Grenzen.

Die "Kleinigkeit", die ich vergessen hatte, war übrigens relativ peinlich. Im Ogg-Seiten-Header gibt es ein Byte für die Anzahl der Daten-Segmente, die in dieser Seite zu finden sind, und dann ein passend großes Byte-Array, in dem die Größen der einzelnen Segmente zu finden sind (pro Seite also maximal 255 Segmente zu je 255 Byte). Beim Schreiben habe ich zwar die Anzahl der Segmente korrekt berechnet, aber deren Größen nicht in den Header geschrieben. Das ist natürlich Murks.

Interessanterweise ist es jetzt so, dass mein Code unter Umständen die benötigte Seiteanzahl für die drei Ogg-Header reduziert, auch wenn sich der Comment-Header vergrößert. Liegt daran, dass anscheinend einige Tagger den dritten Header (der auf die VorbisComments folgt), immer auf eine eigene OggPage schreiben. Das ist aber nicht erforderlich, und mache ich auch nicht so. Könnte ich höchstens als Option für die OggVorbisFile-Klasse einbauen, falls das ein Anwender der Klassen so haben möchte ...

Ansonsten passt das jetzt soweit. Seiten werden auch wieder durchnummeriert, und der Wert für "AbsolutePosition" sollte auch korrekt gesetzt werden. Muss nur noch ein paar Spezialfälle testen (d.h. Comment-Size ist ein exaktes Vielfaches von 255, oder sogar genau gleich 255*255). Und etwas Fehlerbehandlung für den Fall, dass das Seitenflag für "letzte Seite" nicht gesetzt ist, oder zu früh gesetzt wird.

Einbau in Nemp wird aber noch ne Weile dauern.

Keine Eile. Ich bin zu Hause eh' nicht mehr auf Windows unterwegs und im Büro komme ich nicht ganz so oft zum Musikhören, wie ich gern würde.

Na dann, schöne Grüße an Aloy

Gausi hat folgendes geschrieben :

Liegt daran, dass anscheinend einige Tagger den dritten Header (der auf die VorbisComments folgt), immer auf eine eigene OggPage schreiben. Das ist aber nicht erforderlich, und mache ich auch nicht so. Könnte ich höchstens als Option für die OggVorbisFile-Klasse einbauen, falls das ein Anwender der Klassen so haben möchte ...

Da hatte ich auch überlegt, warum sie das tun. Eventuell könnte das als Padding aber praktisch sein, wenn man das erste mal zum Einfügen von Metadaten sowieso renummerieren muss: mit etwas Glück ist für jede folgende Änderung wirklich genug Platz (128kB Cover ist ja doch ne Menge) und man kann den Rest in Ruhe lassen. Ob das jetzt als Optimierung auch sinnig ist, ist eine andere Frage

Nuja, Padding geht ja generell bei den VorbisComments - das ist trivial. Man kann den Vorbis-Block so groß machen (also die Größenangabe für das Packet im OggContainer), wie man möchte (in sinnvollen Grenzen natürlich), und den ungenutzten Bereich einfach mit Nullen füllen. Dafür habe ich ja neu im Code auf Ebene der TOggVorbisFile-Klasse etwas wie

Aber wenn der Tagger so implementiert ist, dass nach den Comments immer eine neue Seite angefangen wird, und der dritte Header eine eigene bekommt (danach MUSS die Seite abgeschlossen werden), ist nichts gewonnen, weil der mögliche Platz auf der Seite mit dem kleinen dritten Header so oder so nicht genutzt wird.

Ich könnte höchstens probieren, beim Schreiben die vorhandene Seitenzahl zu erhalten - aber dadurch wird der Code nicht übersichtlicher. Hab auch einen Code gefunden (mit einer "selbstgebastelten" Lizenz, also unbrauchbar für mich), der auf jede Seite immer nur 17 Segmente zu schreiben scheint (statt 255 möglichen). Kann man auch machen ...