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 ...

Mal ein kleines Lebenszeichen von mir. Meine "Spielphase" ist jetzt erstmal vorbei: Ich habe in beiden Horizon-Teilen 100% auf "ultra-schwer" geschafft - damit bin ich fürs erste also durch. Wer Open-World-Spiele mag: Klare Empfehlung von mir. Die PC-Portierung ist dabei wirklich gut und fast fehlerfrei. Wenn man mal davon absieht, dass in Forbidden West einige (sehr selten gebrauchte) Attacken nur dann korrekt funktionieren, wenn man die Framerate auf 30fps beschränkt. Klingt komisch, ist aber so (und klar reproduzierbar).

In den letzten Tagen habe ich weitere Vorbereitungen für die Behandlung von OPUS-Dateien getroffen, hauptsächlich Refactoring der ganzen TAudioFile-Klassen. So hatte ich z.B. den Getter GetFileSize in der Basisklasse nur als abstract; deklariert, nur um den dann in jeder abgeleiteten Klasse exakt gleich zu implementieren. Das ist natürlich Unsinn.
Oder der Parameter "PictureType", der bei mp3 vom Type Byte war, und bei Flac Cardinal, aber in beiden Fällen nur klar definiert einen Wert von 0-20 haben konnte (vgl. z.B. die Flac-Doku) ... dafür gibt es jetzt einen Enum-Typen. Das ist dann zwar ein Breaking Change, aber der dürfte verschmerzbar sein - und macht die Anwendung transparenter, wenn man weiß, dass da nicht beliebige ganze Zahlen übergeben werden sollten.

Für die (aktuell 2, bald 3) Klassen, die die Vorbis-Comments nutzen, wird es dann auch einen gemeinsamen Vorfahren geben, damit die ganzen Vorbis-Getter/Setter und ein paar weitere Routinen nicht dreimal implementiert werden müssen.

Also: es geht weiter.

Und "Horizon: Lego Adventures" kommt ja erste gegen Ende des Jahres. Dann ist wieder Programmier-Pause.