Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Anzeige

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Hallo !
Danke für den dvbsnoop-patch.
Zu Deiner Anfrage: Ersteinmal unseren Thread
und dann noch dieses:
http://forum.digitalfernsehen.de/forum/showpost.php?p=3076999&postcount=9

gruß
Thomas

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Danke für Deinen Link. In dem Beitrag steht aber so weiter ich sehe nichts, was mein dvbsnoop-Patch nicht bereits enthält. jukson hat ja leider den Source seines Programmes nicht veröffentlich, so dass ich dort nicht nachschauen kann, ob er noch etwas weiß, was noch nicht allgemein verfügbare Info ist.

Den Patch werde ich übrigens demnächst wieder vom Server nehmen. Wer den also will, sollte ihn sich bald besorgen.

Ach eine Neuigkeit ist im Thread doch noch zu finden, nämlich, dass in meta.dat eine CRC enthalten sein soll. Wo die steht und über welche Bytes der meta.dat die gehen soll, ist mir aber nicht klar. Wäre schön, wenn die Formatbeschreibung aufgreifen und entsprechend ergänzen würde.

BTW: Die korrekte CRC-Berechnung für die PAT- und PMT-Blöcke ist in den Sourcen von dvbsnoop zu finden.

Ich selbst werde mich als nächstes daran machen, in mein Programm eine Analyse von PAT und PMT einzubauen, was beides kein Problem sein dürfte. Bevor ich mich dann daran machen, nicht nur heuristisch (nämlich über die Stellung im Comag-Block), sondern tatsächlich Video- und Audio-PID zu ermitteln und den ts darauf einzudampfen, werde ich wohl auf BerliOS oder sourceforge ein OpenSource-Projekt daraus machen. Als dritter Schritt kommt dann, wieder Comag-, PAT- und PMT- einzufügen. Danach kann dann jeder, der will, die zusammengeschusterten Sourcen nehmen und beispielweise mit Hilfe der mpeglibs ein richtig schönes Programm aus dem Wissen machen oder entsprechendes in ProjectX einfügen (das ist noch etwas, was mich selbst reizen würde, da ich bei der Gelegenheit mein oberflächliches Java-Wissen aufpolieren könnte). Ich selbst habe schlicht nicht die Zeit, so ein Projekt längere Zeit intensiv durchzuziehen und werde mich deshalb mit einem Hack zufrieden geben. Mir geht es ohnehin eigentlich nur darum, die unnötigen EPG- und VTX-Blöcke los zu werden. Für Filme, die mich wirklich interessieren, mache ich mit dvdwizard DVDs. Das geht sehr schnell.

Edit: Ich habe gerade gesehen, dass Du Dich mit ProjectX beschäftigst. Heißt das, dass Du gewillt bist, daran zu programmieren, es also so zu erweitern, dass es Comag-compatible TS-Files erzeugt? Dann könnte ich mir die Arbeit schon einmal sparen. Unter Linux arbeitest Du auch. Vielleicht sollte ich das Erstellen eines Projekts für meinen Analysehack auf sf oder BerliOS vorziehen. Im Prinzip bevorzuge ich BerliOS, weil ich dort schon länger ein größeres Projekt administriere, während ich auf sf bisher nur Mitentwickler war. Was wäre Dir lieber?

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Hallo !

Ich kann mich nicht erinern, daß davon einmal die Rede war.Da wir ja alle mal den Titel geändert haben und es trotzdem angzeigt wurde ist das widerlegt.

http://tstool.sourceforge.net/

http://tstools.berlios.de/

Ich habe mit den Programmen aber noch nicht gearbeitet.

Project-X entfernt in der Einstellung "zu TS" EPG,VTX und anderes
Einstellungen Ausgabe :_> Verarbeitung von Elemtarströmen
Mpeg-Video und Mpeg-Audio gewählt.

Bei einem Test mit einem Sonntags-Film vom ZDF wurde die Datei von 2047MB auf 14007 MB verkleinert.PAT und PMT werden auch angepaßt.

Einstellungen Erweitert: TS: generiere PMT inhaltsbezogen.

Das Comag-compabtible Format könnte über Projects-Nachbearbeitung erfolgen.Dadurch wäre man von den Sourcen von Project-X und auch von Java
befreit.(minimalinvasiv ).
Das ist nicht der schnellste Weg, aber der allgemeinste. Damit ließen sich auch MPeg-Videos (PS) umwandeln.

Ich habe ja schon einen Weg aufgezeigt, ohne die Quellen von Project-X zu verändern.Ich werde dort im Moment keine Hand anlegen. Wenn es extern gelöst würde, wären auch die Quellen einfacher zugänglich und müßten nicht umständlich aus project-X extrahiert werden.

Ich habe jetzt mal mit dem Tool von juson (Comag_ts) gearbeitet und da sind Kopierzeiten von 12 Min für einen 90 Min Film drin. Zusätzlich kommen dann noch die Zeiten für Projectx.

Diese Situation hatte ich schon einmal mit einem VDR. Ich habe mich damals damit beholfen nur Sprungmarken in Projectx zu sicher und diese in ein vdr-kompatibles Format umzurechnen und mit dem Jump-and Play Patch lief das gut.Und villeicht geht in diese Richtung ja in Zukunft etwas.

http://forum.digitalfernsehen.de/forum/showpost.php?p=3152474&postcount=1

Ein anderer Punkt ist die interne Schnittfunktion des Comag. Der Comag schneidet sehr schnell, also kein Vergleich zu unserem Vorgehen.

http://forum.digitalfernsehen.de/forum/showpost.php?p=2870402&postcount=30

Vielleicht lohnt es sich, dort noch einmal genauer hinzusehen.

Jukson hat ein neues Tool angekündigt:

Punkt 1 und Punkt 3 hören sich ja ganz interessant an.

Mir ist das egal.

gruß
Thomas

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Das bedeutet nur, dass das Gerät keine CRC prüft. Letztlich reicht das und ich habe gestern auch erstmal erfolgreich eine neue meta.dat aus einer rec.ts generiert. Bei der Gelegenheit habe ich auch gleich dummy rec.cp und rec.dat erzeugt, obwohl der Comag nicht darauf besteht, sondern diese beiden ggf. selbst neu anlegt.

Das erste Tool ist mal wieder etwas für Windows. Das zweite wäre zwar für meine Analysen interessant gewesen, ich denke aber nicht, dass ich es noch brauche.

Ja, das habe ich schon gemacht. Allerdings werden dabei auch die Null Packets (PID 0x1fff) entfernt. Bisher verwende ich die mir bisher noch unbekannten Bytes aus den Null Packets noch (siehe unten).

Ich nehme an, dass Du bei der zweiten Größe eine 0 zuviel eingetippt hast. Mein eigenes Programm habe ich bisher nur auf kleine Dateien losgelassen. Dabei wurden 267MB in 211MB eingedampft (siehe unten).

Du meinst ein Programm, das man nach Project-X aufruft oder kann man Project-X mitteilen, dass es die Ausgabe durch ein anderes Programm pipen soll? Eine Pipe wäre jedenfalls mit Sicherheit schneller als über eine temporäre Datei zu gehen. Die Nachbearbeitung kann allerdings nicht per Pipe erfolgen. Man muss nämlich am Ende nochmal in das erste Null-Packet (erstes Packet im Comag-Header) schreiben, um dort die Anzahl der Null-Packets im kompletten Stream einzutragen.

Ein Programm, das einfach eine ts-Datei für den Comag aufbereitet, ist auch das, was mir derzeit vorschwebt. Da Project-X bereits Einstellungen für Header etc. für andere Recorder bietet, wäre es aber letztlich auch nicht schlecht, wenn Project-X irgendwann eine solche für den Comag bieten würde.

Ein Standalone-Programm für ts-Dateien ist trotzdem praktisch. Das ist dann unabhängig von Project-X.

Wenn ich die Diskussion zu dem Tool richtig verstehe, schreibt das direkt per USB auf die Platte des Comag. Dabei ist das Hauptproblem, die langsame USB-Schnittstelle des Teils. Ich habe gestern sämtliche Filme von der internen Platte auf eine externe USB-Platte kopieren lassen. Je Film hat der Comag dabei ebenfalls 10 bis 20 Minuten gebraucht.

Soweit auch ich sehe, schneidet der Comag immer nur an Null Packets. Das ist recht schnell zu machen, setzt aber eigentlich auch voraus, dass die Null Packets an stellen im MPEG-Datenstrom stehen, an denen das passt. Ich muss mal sehen, was passiert, wenn ich meinen eingedampften Film am Comag schneide.

Das "nur an Null Packets" ist übrigens keine wahnsinnig große Einschränkung. In meinem Testfilm kommen die Null Packets nach 478ms, 488ms, 498ms, 508ms, 519ms, 529ms, 702ms usw.

Bis auf Beschreibung aus dem EPG kann ich das schon. Das ist nicht schwer. Wobei ich derzeit absichtlich alle Audio-Spuren drin lasse.

Es wäre aber schön, wenn er das diesmal openSource machen würde.

Mein eigenes Programm kann zum einen die rec.ts-Datei analysieren. Wenn im Kopf der rec.ts eingetragen ist, dass der komplette Stream aus weiteren Dateien besteht, werden auch die entsprechenden rec.01, rec.02 etc. mit gelesen (das kann man aber optional verhindern). Dabei kann man die Analyse auch auf bestimmte Paketarten oder Paketnummern einschränken. Bei der Analyse können die analysierten Pakete optional in eine neue Datei geschrieben werden (das war für mich bei der Analyse einfach praktisch). Analysiert werden die Null Packetes (ich nenne die Comag info packets), die PAT, die PMT, sowie PCR- und PTS-Infos. Die übrigen Pakete werden in der Analyse nur gedumpt.

Desweiteren kann mein Programm rec.ts-Dateien auf Header, Audio- und Video-Pakete eindampfen und dabei alle 512 Pakete ein Comag info packet und ein PAT-Packet einfügen, wie der Comag das haben will. Für das PAT-Packet wird dabei einfach eine Kopie des Original-PAT-Packets aus dem Comag-Header genommen. Für die Comag info packets wird das letzte gefundene Comag info packet verwendet. Derzeit wird als Anzahl der Teildateien noch die Originalanzahl eingetragen. Hier müsste noch eine Nachbearbeitung erfolgen, um am Ende die tatsächliche Anzahl einzutragen. Als Magic für das Filmformat (bisher habe ich 4:3, 16:9 anamorphic und 16:9 LB to 4:3 erkannt) wird das eingetragen, was im Kopf stand. Für die bisherige Spieldauer wird die Differenz aus letztem PCR und der Start-Uhrzeit eingetragen, falls beide bekannt sind. Ist PCR nicht bekannt, wird PTS verwendet. Ist diese auch nicht bekannt, wird die Spieldauer aus dem letzten gelesenen Comag info packet verwendet. Ganz am Ende wird dann die korrekte Anzahl an Comag info packets in den Header eingetragen. Besteht ein Film laut rec.ts aus mehreren Teildateien, so werden automatisch alle Teildateien nacheinander gelesen. Es wird derzeit aber nur eine einzige Datei geschrieben. Das Aufteilen war für meine Tests erst einmal nicht so wichtig. Zum Abschluss der Arbeiten kann optional noch eine neue meta.dat eine rec.cp und eine rec.dat erzeugt werden.

Beim Abspielen kam der Comag mit meinen eingedampften Dateien problemlos klar. Auch das Spulen und Springen hat wunderbar funktioniert.

Es gibt ein paar Bytes in den Comag info packets, die ich noch nicht verstanden habe. Davon ändern sich 4 in jedem Block. Falls es sich dabei um irgend eine Art von LONG Zahlenwert handelt, dann wird der Wert sehr schnell immer größer, springt aber alle paar Dutzend Pakete wieder auf einen kleineren Wert zurück. Ein CRC ist das wohl nicht, sonst müssten die Werte eigentlich zufälliger erscheinen. Ich werde mal noch testen, was passiert, wenn ich an der Stelle immer nur Nullen eintrage. Wenn das klappt, muss ich mich daran machen, das erste Comag info packet komplett neu zu erzeugen. Ich bin mal gespannt, wie das wird. Jurkson macht das ja offenbar schon.

Die Sourcen sind dadurch, dass sie durch diverse Experimente gewachsen sind, ein einziges Chaos und bestehen letztlich nur aus einer Reihe von Hacks. Trotzdem will ich die so bald wie möglich öffentlich machen. Anfangen werde ich vermutlich mit der Beschreibung der Dateien, soweit ich sie habe. Da weiß ich inzwischen nämlich wieder ein bisschen mehr als ich in dem dvbsnoop-Patch drin habe.

Für ein Programm, das lediglich aus TS Comag-TS macht, braucht man vermutlich deutlich weniger Auswertung, als ich derzeit mache. Dafür könnte es dann deutlich übersichtlicher werden. Im Augenblick bin ich aber noch am Experimentieren.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Hallo !

Ja man kann es in Project einstellen, daß ein Programm nach einer Verarbeitung aufgerufen wird.Z.B. mit dem TS.

Für einen Anfänger vielleicht. Ob es schneller wird vielleicht. Bei einer Integration in PjX würde die Ursprungsdatei einmal gelesen und das Ergebnis
einmal geschrieben. Bei der externen Lösung zweimal.

Nein, das Programm arbeitet auch mit externen USB-Platten oder USB-Sticks. Gestern dann der Krimi im Ersten. Pjx 4 Minuten. Comag_TS 12
Minuten.Das macht zusammen schon mal 16 Minuten...
Es läuft auch unter wine.

Vier Aufnahmen habe ich gestern geschafft. Mit mehreren Abstürzen.
Heute habe ich die Platte ausgebaut und in ein USB-Gehäuse gepackt.
Die restlichen 63 GB habe ich dann in ~1 Stunde kopiert. Bei Datenraten zwischen 15 und 20 MB/s.Ich gehe mal davon aus, das die Programmierung der USB-Schnittstelle suboptimal ist, ob als Host oder Slave.

Da der Comag wohl nicht an den GOP-Grenzen, wie PjX, schneidet muß man wohl mit Artefakte rechnen. Quick and Dirty...

http://forum.digitalfernsehen.de/forum/showpost.php?p=3173259&postcount=100

Wo soll den eingetragen sein, daß der Stream aus mehreren Dateien besteht ?

Der Comag kommt also mit Deinem gefilterten Stream klar.

http://forum.digitalfernsehen.de/forum/showpost.php?p=2891456&postcount=34

gruß
Thomas

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Ich finde nicht den Source seines Programms. Kostenlos ist ja schön, aber openSource wäre schöner.

In der ts-Datei. Ich bin mit der Doku noch nicht ganz fertig und will jetzt ehrlich gesagt nicht stückweise Doku kopieren. Sobald ich mit der Doku so weit bin, kannst Du Dir das im Projekt anschauen.

Schön. Die Bytes ändern sich also und wenn man stattdessen eine Konstante einträgt, dann stoppt der Player. Aber was er bei der Konvertierung nun einträgt, damit der Player nicht stoppt, hat er nicht verraten.

http://developer.berlios.de/projects/tscomagcv
Da ich keine Lust hatte nur Doku zu schreiben und außerdem Bedarf hatte, möglichst schnell und unkompliziert direkt im Dateimanager an die Infos aus der meta.dat zu kommen, habe ich mal zwischendurch zwei Progrämmchen geschrieben.

Das eine gibt es derzeit nur im SVN als source, heißt meta, funktioniert als Filter und gibt eine meta.dat aus dem input wahlweise als Text aus.

Das andere ist ein File Plugin für KDE3. Installiert man das, bekommt man beispielsweise in Konquerer bei den Dateieigenschaften einer Datei vom Typ application/x-comag einen zusätzlichen Reiter "Meta-Information", auf dem dann ebenfalls Titel, Aufnahmezeit etc. angezeigt wird. Damit das funktioniert muss man bei der Dateizuordnung zunächst den Mime-Type application/x-comag definieren, und ihm das Dateimuster meta.dat zuweisen.

Sobald ich Zeit habe, mache ich mit der Doku weiter. Ich will auch noch einen Prozess installieren, der automatisch HTML-Dateien aus der Doku erzeugt und die dann auf der Homepage des Projekts installiert. Meine Zeit ist aber leider beschränkt.

Edit: Ich habe jetzt mal eine minimale Projekthomepage aufgesetzt über die auch die HTML-Version der Formatbeschreibung - soweit ich bisher eben gekommen bin - verfügbar ist. Heute bin ich leider kaum zum Weiterschreiben gekommen.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Hallo !

Ich widerspreche da nicht, ist aber seine Sache.

Ich wollte nur damt sagen, daß ich an dieser Stelle auch schon war.

Doch hat er.Auf meine Frage nach der "Kommandospur" (Padding-Pakete PID=1FFF):

Auf meine Nachfrage:

Bekam ich noch folgenden Hinweis:

Er geht aber sehr kreativ mit PMT-Paketen um:

Habe ich ausgecheckt. Da ist aber der Wurm in Deinem Buildsystem:

Code:

Fortress:/srv/VIDEO/film/KOMA00/trunk # ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for md5sum... md5sum
checking for grep... grep
checking for pdflatex... no
configure: error: Unable to find the pdflatex application

Ich habe dann mal kfile_metadat heruntergeladen.
Jede Menge Fehler.

In der comag_meta.cpp fehlte ein include <ostream>.
und in dem src/Makefile habe ich bei den CXXFLAGS -fno-execptions gelöscht. Danach ließ sich das formal compilieren und installieren.

Das CLI-Tool habe ich mit kdevelop zum Laufen gebracht.

Erstmal Danke für Deine Arbeit !

Leider versagen die Tools bei ca 2/3 meiner Aufnahmen.

Code:

Fortress:~ # /home/thomas/meta/meta -a < /media/HDDRIVE2GO/rec_0000/meta.dat
terminate called after throwing an instance of 'comag::meta::failure'
  what():  Header or reserved bytes not valid
Aborted
Fortress:~ # /home/thomas/meta/meta -a < /media/HDDRIVE2GO/rec_0001/meta.dat
terminate called after throwing an instance of 'comag::meta::failure'
  what():  Header or reserved bytes not valid
Aborted
Fortress:~ # /home/thomas/meta/meta -a < /media/HDDRIVE2GO/rec_0002/meta.dat
terminate called after throwing an instance of 'comag::meta::failure'
  what():  Header or reserved bytes not valid
Aborted
Fortress:~ # /home/thomas/meta/meta -a < /media/HDDRIVE2GO/rec_0003/meta.dat
terminate called after throwing an instance of 'comag::meta::failure'
  what():  Header or reserved bytes not valid
Aborted
Fortress:~ # /home/thomas/meta/meta -a < /media/HDDRIVE2GO/rec_0004/meta.dat
terminate called after throwing an instance of 'comag::meta::failure'
  what():  Start date not valid
Aborted
Fortress:~ # /home/thomas/meta/meta -a < /media/HDDRIVE2GO/rec_0005/meta.dat
terminate called after throwing an instance of 'comag::meta::failure'
  what():  Header or reserved bytes not valid
Aborted
Fortress:~ # /home/thomas/meta/meta -a < /media/HDDRIVE2GO/rec_0006/meta.dat
meta.dat informations:
title_type:         transmission (0x08)
title:              Alter vor Sch�nheit
start_time:         19:12:33
start_date:         Mon 2008-12-15
duration:           01:35:25
comag packets:      52656
service:            TV (0x00)
Program-ID:         28006 (0x6d66)
timer:              0

Das kann nicht sein.
Fehlertests sind ja schön und gut, aber wenn man nicht weiß, welche Funktion ein Byte hat sollte man von gültig oder nicht gültig sprechen.
Wenn die meta.dat vom Comag gelesen und angzeigt werden sind sie gültig !

Dann nochmal zu Startzeit. Das ist wohl UTC für unsere Zeitzone muß noch eine Stunde addiert werden.

Ich selber programmiere z.Zt. an einem Programm um die EPG-Informationen zu scannen und die erweiterten Informationen zu einem Titel und einer Startzeit zu finden.Da kommt mir Dein CLI-Tool gerade recht.

gruß
Thomas

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Die Zeit ist nicht das Problem. Die steht in den Comag spezifischen Private-Packets in ms (also kHz) und kann außerdem aus PTS (90 kHz) oder PCR (27 MHz) gelesen werden. Das Problem sind die 4 Bytes danach. Die ändern sich extrem stark, ohne dass ich die geringste Ahnung habe, nach welchen Regeln.

Du hast schlicht kein pdflatex installiert. Die Doku-Sourcen sind aber in LaTeX geschrieben. Daraus wird dann automatisch pdf und html erzeugt. Die HTML-Doku, die leider noch ein paar Macken hat, ist auch über die Homepage verfügbar. Meine "Erkenntnisse" über die Null-Packets fehlen aber noch. Dazu bin ich bisher nicht gekommen.

Für den Make-Prozess lege ich noch nicht meine Hand ins Feuer. Dass kfile_metadat comag_meta.o derzeit statisch linkt ist nur ein Provisorium. Eigentlich soll der tools/source-Zweig eine shared library erzeugen und die dann von kfile_metadat.la bzw. kfile_metadat.so verwendet werden. kfile_metadat ist derzeit aber nicht mehr als ein Experiment. Ich habe vorher noch nie mit kdevelop gearbeitet geschweige denn ein Plugin für KDE erstellt. Dass das noch Exceptions wirft, statt diese abzufangen, ist mir durchaus klar. Wie gesagt, ist meine Zeit beschränkt. Mein eigentlicher Fokus liegt auf der Doku. An der ich demnächst weiter machen will. Statt selber compilieren dürfte in dem Fall die Verwendung des fertigen rpms oder auch die Verwendung der Sourcen aus dem source-rpm einfacher sein. Wie das i586er rpm aus dem source-rpm erzeugt wird, ist der spec-Datei im source-rpm zu entnehmen.

Du meinst das Testprogramm meta? Das ist kein kdevelop-Projekt. Das ist eine ganz normale automake/autoconf-Geschichte.

Was heißt hier: Kann nicht sein. Irgendwelche Plausibilitätstests müssen sein. Ich kann auch nur auf dem Wissen programmieren, das mir zur Verfügung steht. Bei allen meinen Tests, waren die ersten 5 Bytes der meta.dat immer gleich. Ich habe das auch in http://forum.digitalfernsehen.de/forum/showpost.php?p=2837879&postcount=6 dokumentiert und bisher hat da niemand widersprochen.

Das die Zeit GMT ist, hatte ich dort ebenfalls angegeben. Ich halte es auch nicht für sinnvoll, in der Lib diese Zeit jeweils auf aktuelle Ortzeit umzurechnen und dabei auch noch Sommer- und Winterzeit zu berücksichtigen. Schließlich ist die Zeit im TS AFAIK üblicherweise auch in GMT angegeben. Es wird schlicht das in Text übersetzt, was in der Datei steht. Da Du aber die Sourcen hast, kannst Du das gerne ändern. Du kannst das auch in Sternzeit umgerechnet ausgeben, wenn Dir das lieber ist. Man kann auch einen Modifier für die Ausgabe definieren, der das umschaltet. Kann man alles machen. Aber ich habe nicht die Zeit dafür.

Konstruktiv wäre jetzt, wenn Du mir einen Hexdump der meta.dats, die von comag_meta.cpp nicht akzeptiert werden, zur Verfügung stellen würdest - möglichst mit ein paar Angaben über die Aufnahmeumstände. Wenn Du einen BerliOS-Account hast, kann ich Dich auch als Entwickler eintragen und Du kannst selbst die Probleme bereinigen. Wir können auch einen branch mit Beispieldateien anlegen. Bei den meta.dat sollte das unproblematisch ein. Bei den ts wird das natürlich ein rechtliches Problem.

Ich selbst will heute noch zwei neue rpms hochladen, in denen dann auch die mimelnk-Datei enthalten ist, damit man den mime-type nicht manuell anlegen muss. Alles andere ist darin wie gehabt. Außerdem will ich mich endlich an die Doku der Null Packets machen.

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Muß ich mir noch einmal anschauen

Ja, habe ich verstanden. Pdflatex ist aber keine zwingende Build-oder Laufzeitbedingung für das kfile_plugin oder das CLI-Tool.

Ich empfand es als unglücklich,weil die Dateien am Comag ja angzeigt werden.

Laut Deinem Tool wird die Zeit in UTC gespeichert.Und auch im TS werden Zeitinformation (zb.:SI-EIT) in UTC gesendet und über TOT in die lokale Zeit übersetzt (s. EN300468)

Du hast Post auf Deinem Berlios-Account.

gruß
Thomas

 

AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Richtig. Aber da Doku der erklärte Hauptzweck des Projekts ist, ist nunmal die Doku kein Unterprojekt. libcomag_meta und meta sind jedoch ein Unterprojekt, genauer Bestandteil des Unterpojekts tools. Aus dem tools-Verzeichnis sollte es möglich sein, nur dieses zu erzeugen. kfile_metadat wiederum ist ein Unterprojekt von tools. Das ist bisher ein maschinell erzeugtes Projekt, das überarbeitet werden sollte.

Das Tool entspricht der Formatbeschreibung. Wenn der Comag auch Dateien liefert, die nicht der Formatbeschreibung entsprechen, dann ist die Formatbeschreibung ungenau, falsch oder unvollständig. Ich habe extra für Dich jetzt in meta noch eine Fehlerbehandlung eingebaut. Eigentlich ist meta aber nur ein Programm, um die Lib zu testen.

Ja, schön, heißt das heutzutage eben UTC statt GMT.

Du auch.