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

[Torben]

Hallo,

gibt es irgendwo eine Beschreibung der Datenformate für die Dateien mit den Endungen .bm, .cp und .dat? Ich würde mir gerne einige Tools schreiben, die z.B. die Umwandlung der .ts-Dateien in .mpg-Dateien mittels VLC Streaming-Client automatisieren.

Zudem wäre ich am Datenformat der Kanalliste CHANLIST.BIN interessiert, um einen eigenen Kanallisteneditor zu schreiben, der Drag&Drop unterstützt.

Torben

PS: Ich habe das ganze Forum durchsucht, bevor ich diesen Beitrag geschrieben habe, ich hoffe ich habe keinen entsprechenden Beitrag übersehen.

[akniest]

Hi Torben,

du bist nicht der einzige, der nach den Dateibeschreibungen sucht, leider gibt es keine im Internet.

Die Meta.dat ist einigermaßen gut analysiert, da kann ich dir einen Aufbau (soweit ich ihn kenne) zuschicken.

Bei der CHANLIST.BIN wird es schwieriger, da die sehr komplex ist. Zudem gibt es hier einen CRC32-Check. Ich habe einige Teile dieser Datei entschlüsselt, aber die wichtigsten fehlen noch. Es wird wohl darauf hinauslaufen, dass wir die Dateien selber analysieren müssen. Wir können und da gerne zusammentuen, vielleicht haben wir die Dateien dann irgendwann komplett entschlüsselt.

Ich wollte auch einen besseren Kanaleditor basteln, mit modernen Features, die Analyse der CHANLIST.BIN läuft aber sehr zähflüssig.

Wofür die Dateien mit .bm und .cp gut sind, habe ich noch gar nicht herausgefunden.

Gruß
Andreas

[Geesz]

@akniest /
@Torben:
Habt ihr beiden schon mal bei der COMAG-Technik angefragt, ob die euch die Dateiformate zukommen lassen können?
(technik ät comag-ag dot de)

Die haben wohl nicht unbedingt Ressourcen/Geld frei um den Editor weiterzuentwickeln. Der Editor 1.1 war ja offensichtlich auch nur eine Notoperation, wegen der Database 1.1 Problematik.
Vielleicht sind sie für eure Unterstützung sogar dankbar.

[KOMA00]

Zitat von Torben

gibt es irgendwo eine Beschreibung der Datenformate für die Dateien mit den Endungen .bm, .cp und .dat? Ich würde mir gerne einige Tools schreiben, die z.B. die Umwandlung der .ts-Dateien in .mpg-Dateien mittels VLC Streaming-Client automatisieren.

Die Dateien rec.bm und rec.cp brauchst Du dafür nicht. Nach meinen Tests, sind diese Dateien bei allen Aufnahmen identisch, jedenfalls, wenn man noch keine Marken gesetzt hat.

In diesem Fall ist die rec.bm 416 Bytes groß (FW 3.6DE), beginnt mit 0xff 0xff 0xff 0xff 0x01 und der Rest sind NUL-Bytes.

Die rec.cp ist 372 Bytes groß (FW 3.6DE) und besteht nur aus NUL-Bytes.

Ich werde deshalb auf rec.bm und rec.cp vorerst keine weitere Energie verschwenden. Mein Fernziel liegt darin, irgendwann am Computer bearbeitete Filme wieder auf den Receiver zurück zu bekommen (wie das bei diversen Kathrein-Modellen mit mkrecord bereits möglich ist). Dafür brauche ich die Dateien offensichtlich nicht. Mittelfristig, will ich die Meta-Infos für einen Film unter Linux auslesen und bearbeiten können.

In der meta.dat, die immer 112 Bytes groß ist (FW 3.6DE), steht der Filmname anscheinend ab Byte 13 und endet mit einem NUL-Byte. Vor dem Filmname steht bei mir eine 0x08. Ob das immer so ist, werde ich in Kürze feststellen, wenn ich die vier Minimitschnitte, die ich gerade zu Testzwecken anfertige auf den Rechner geholt habe.

Über die TS-Datei habe ich noch nicht viel herausgefunden. Ich habe zwar ein Miniprogramm geschrieben, das mir die Analyse des Transport Streams erleichtert. Allerdings sind die Infos, die ich zum Transport Stream bisher gefunden habe, offenbar sehr ungenau. Nach den Infos, die ich habe, müsste beispielsweise ein PES-Block innerhalb eines Stream-Blocks mit 0x00 0x00 0x01 beginnen. Das ist aber offenbar nicht der Fall. Da werde ich noch ein paar Infos mehr suchen. Auffällig ist jedenfalls, dass im ersten Stream-Block ab Position 0x60 noch einmal der Titel steht und zwar ebenfalls mit einem führenden 0x08. Darüber hinaus, steht an Position 0x38 offenbar "reg". Außerdem finden sich Byte 0x58-0x5b aus meta.dat in rec.ts wieder an Position 0x10 bis 0x14 des ersten Blocks. Das ändert sich in den Fortsetzungen rec.01 etc. Dort ist der erste Block zwar in weiten Teilen aber nicht vollständig identisch. Der erste Block von rec.01 und rec.02 wiederum unterscheidet sich nur in 6 Bytes (eventuell sind das in Wirklichkeit 4 Word oder 2 Long, also 8 Bytes).

Zitat von akniest

du bist nicht der einzige, der nach den Dateibeschreibungen sucht, leider gibt es keine im Internet.

Die Meta.dat ist einigermaßen gut analysiert, da kann ich dir einen Aufbau (soweit ich ihn kenne) zuschicken.

Damit wir uns die Arbeit nicht alle mehrfach machen, könntest Du vielleicht Deine bisherigen Erkenntnisse mal hier veröffentlichen. Vielleicht können wir ein neues Thema "Technische Spezifikation von meta.dat, rec.ts, rec.bm und rec.cp" aufmachen? Oder hast Du die schon irgendwo verfügbar gemacht. Die meta.dat scheinst Du ja inzwischen sehr gut zu kennen. Leider nützt mir ein Windows-Programm nicht viel. Ich hätte gerne ein paar Kommandozeilenwerkzeuge für Linux und habe dafür auch schon etwas Zeit investiert.

[thomas998]

Hallo !
Zum Transport Stream: Suche mal im Internet nach is138181.pdf und is138182.pdf. Das sollte weiterhelfen.
Zur Analyse des TS: http://dvbsnoop.sourceforge.net

Gruß
Thomas

[KOMA00]

Zitat von thomas998

Zum Transport Stream: Suche mal im Internet nach is138181.pdf und is138182.pdf. Das sollte weiterhelfen.
Zur Analyse des TS: http://dvbsnoop.sourceforge.net

ISO-13818-1 habe ich bereits. Das ist auch durchaus hilfreich und korrigiert diverse Fehler aus der deutschen Doku, die ich im Netz gefunden hatte. Leider sind darin eher wenige Paket-IDs spezifiziert. Ich werde mich mal noch nach ISO-13818-2 umsehen. Vielleicht steht dort noch etwas nützliches drin.

dvdsnoop hatte ich mir auch schon besorgt. Das ist eigentlich für die tuxbox (dbox2 mit Linux) gedacht und lässt sich bei mir auf dem PC nicht compilieren. Ich werde Deine Anregung aber nochmal in dem Sinne aufgreifen, dass ich dort vielleicht noch ein paar Informationen aus den Paketen ziehen kann. Ich vermute aber, dass den spezifischen Pakete im Header der ts-Dateien nur durch mühsame Analyse und Ausprobieren beizukommen ist. Dafür taugt mein eigenes Analysewerkzeug genauso gut. Das kann ich wenigstens einfach um gewünschte Angaben verfeinern.

Die meta.dat habe ich inzwischen übrigens bis auf ein paar wenige Bytes verstanden:

meta.dat:

Example:

00:  05 00 72 6a 07 00 00 00   00 00 00 00 08 NN NN NN
10:  NN NN NN NN NN NN NN NN   NN NN NN NN NN NN NN NN
20:  NN NN NN NN NN NN NN NN   NN NN NN NN NN NN NN NN
30:  NN NN NN NN NN NN NN NN   NN NN NN NN NN NN NN NN
40:  NN NN NN NN NN NN NN NN   NN NN 00 14 10 01 00 00
50:  d8 07 06 0a 02 00 00 00   85 d4 00 00 02 27 2a 00
60:  00 00 00 00 01 00 00 00   5e 44 00 00 03 00 00 00

Description:

0x00:  5 Bytes: 0x05 0x00 0x72 0x6a 0x07      (magic ??)
0x05:  7 Bytes: 0x00 ... 0x00                 (reserved)
0x0c:  1 Byte:  0x08 = Title of transmission  (title type [2=station or manual input])
0x0d: 62 Bytes: NN ... NN 0x00                (film title)
0x4b:  1 Byte:  0x14 = 20                     (start time: hour [GMT!])
0x4c:  1 Byte:  0x10 = 16                     (start time: minute)
0x4d:  1 Byte:  0x01 = 01                     (start time: second)
0x4e:  1 Word (Lowbyte first): 0x0000 = 0     (start time: fraction ??)
0x50:  1 Word (Lowbyte first): 0x07d8 = 2008  (start date: year)
0x52:  1 Byte:  0x06 =  6 = Juni              (start date: month)
0x53:  1 Byte:  0x0a = 10                     (start date: day)
0x54:  1 Byte:  0x02 = Tuesday                (start date: day of week [0=Sun])
0x55   7 Bytes: 0x00 0x00 0x00 0x85 0xd4 0x00 0x00  (unknown ??)
0x5c:  1 Byte:  0x02 =  2 Stunden             (duration: hours)
0x5d:  1 Byte:  0x27 = 39 Minuten             (duration: minutes)
0x5e:  1 Byte:  0x2a = 42 Sekunden            (duration: seconds)
0x5f:  1 Byte:  0x00                          (reserved)
0x60:  1 Byte:  0x00 = TV                     (service 0=TV 1=Radio)
0x61:  3 Bytes: 0x00 0x00 0x00                (reserved)
0x64:  1 Byte:  0x01                          (unknown)
0x65:  3 Bytes: 0x00 0x00 0x00                (reserved)
0x68:  1 Word (Lowbyte first): 0x445e         (PID = programm-ID)
0x6a:  2 Bytes: 0x00 0x00                     (unknown)
0x6c:  1 Long (Lowbyte first): 0x00000003     (timer number)

Die im Beispiel rot gedruckten Bytes sind mir noch gänzlich unklar. Bei den grün gedruckten Bytes bin ich mir der Bedeutung noch nicht vollständig sicher. Das Byte vor dem Titel der Aufnahme verwirrt mich noch. Ich hatte da bisher 0x08 und 0x02. Außerdem ist dieses Byte zusammen mit dem Titel auch identisch im ersten Block der ts-Datei zu finden. Einen Zusammenhang zwischen dem Wert des Bytes und der Länge des Titels (was nahe liegen würde) konnte ich bisher nicht feststellen.

Bei Byte Nummer 0x60 gibt es die Theorie, dass es die Unterscheidung zwischen TV (=0x00) und Radio (=0x01) enthält. Wenn dem so ist, stimmen in der Erklärung oben auch die Bytes 0x61 bis 0x63 nicht, sondern sind reserviert.

Die Dateien rec.bm und rec.cp werden übrigens nach meinen Tests tatsächlich nicht benötigt. Wenn ich die aus rec_0000-Verzeichnissen lösche, dann legt der Receiver die einfach bei Bedarf wieder an.

Um meine Vermutungen mit den Millisekunden bei der Startzeit und dem »fraction« genannten Teil bei der Dauer, von der ich vermute, dass es Frames sind, zu untermauern, muss ich demnächst mal noch einen Test machen, bei dem ich am Anfang einer Aufnahme mal weniger als eine Sekunde abschneide - falls ich das hinbekomme.

Bei der maximal möglichen Länge des Titels bin ich mir noch nicht ganz sicher. Eingeben kann man am Receiver nur maximal 14 Zeichen. Das werde ich gelegentlich mit einer manipulierten meta.dat testen

[Geesz]

Zitat von KOMA00

(...)
Um meine Vermutungen mit den Millisekunden bei der Startzeit und dem »fraction« genannten Teil bei der Dauer, von der ich vermute, dass es Frames sind, zu untermauern, muss ich demnächst mal noch einen Test machen, bei dem ich am Anfang einer Aufnahme mal weniger als eine Sekunde abschneide - falls ich das hinbekomme.

So wirst du es nicht testen können, da Bug #45 wohl noch nicht gefixt wurde.

Wie sieht es denn aus, wenn du die Meta.dat manipulierst und dem Receiver wieder zufütterst?

[KOMA00]

Zitat von Geesz

So wirst du es nicht testen können, da Bug #45 wohl noch nicht gefixt wurde.

Wie sieht es denn aus, wenn du die Meta.dat manipulierst und dem Receiver wieder zufütterst?

Bei Start und Länge bin ich noch nicht dazu gekommen. Änderungen des Titels funktionieren, Änderungen von Byte 0x6c (Timer Nummer), und 0x68-0x69 (PID) kümmern den Receiver nicht weiter. Beim Titel muss ich auch noch testen, wie lange der tatsächlich sein darf. Wenn das nur die 14 Zeichen sind, die der Receiver bei der Eingabe erlaubt, dann sind die restlichen Bytes, die im Beispiel mit NN markiert wurden, vermutlich reservierte NUL-Bytes.

Die Tests sind etwas mühsam, weil ich die Testdaten immer per USB-Stick zwischen Receiver und PC hin und her tragen muss (da liegen auch noch zwei Stockwerke dazwischen). Außerdem habe ich nur wenig Zeit. Ich würde eigentlich gerne in die Analyse der rec.ts einsteigen. Gerade wenn Bug #45 noch längere Zeit überlebt, wäre die Möglichkeit, den Film am Rechner schneiden und dann wieder auf den Receiver zurück spielen zu können, wichtig. Wäre deshalb schön, wenn sich noch jemand an der Analyse der meta.dat beteiligen würde.

[thomas998]

Hallo !
Zur meta.dat :
http://forum.digitalfernsehen.de/for...at#post2716535

Thomas

[KOMA00]

Zitat von thomas998

Zur meta.dat :
http://forum.digitalfernsehen.de/for...at#post2716535

Danke für den Link!

Das stimmt für FW 3.6de aber nicht ganz. Ich habe jetzt verifiziert, dass der Titel tatsächlich bis zu 62 Bytes lang sein darf, nicht nur 30. Im Schnittfenster werden davon über 40 Bytes angezeigt. Der Titel muss dabei mit einem NUL-Byte enden und nicht darstellbare Zeichen werden bei der Anzeige ignoriert.

Das mit dem Wochentag dürfte stimmen.

Die Unterscheidung TV/Radio muss ich nochmal verifizieren. Es würde meiner Theorie entgegen stehen, dass man theoretisch auch Aufnahmen über mehr als 255 Stunden, 59 Minuten und 59 Sekunden machen kann. Übrigens sind die erst 13 Bytes auch nicht immer identisch. Das 13. Byte (also Byte Nummer 12) hatte ich schon als 0x08 aber auch als 0x02.

[akniest]

Zitat von KOMA00

Das stimmt für FW 3.6de aber nicht ganz. Ich habe jetzt verifiziert, dass der Titel tatsächlich bis zu 62 Bytes lang sein darf, nicht nur 30. Im Schnittfenster werden davon über 40 Bytes angezeigt. Der Titel muss dabei mit einem NUL-Byte enden und nicht darstellbare Zeichen werden bei der Anzeige ignoriert.

Hi, bei der 3.5b werden nur 30 Zeichen aus dem Timer / der EPG übernommen. Es werden auch nur 30 Zeichen im Display angezeigt. Vielleicht wurde diese Beschränkung bei neueren FW-Versionen aufgehoben bzw. erweitert.

Zitat von KOMA00

Das mit dem Wochentag dürfte stimmen.

Tut es, habe ich verifiziert.

Zitat von KOMA00

Die Unterscheidung TV/Radio muss ich nochmal verifizieren. Es würde meiner Theorie entgegen stehen, dass man theoretisch auch Aufnahmen über mehr als 255 Stunden, 59 Minuten und 59 Sekunden machen kann.

Das habe ich ebenfalls mehrfach verifiziert, das Feld ist definitiv der Service, aus dem aufgenommen wurde. Es ist durchaus möglich, dass die Tage in den Bytes vor der Aufnahmedauer abgelegt werden, da sind ja noch Bytes frei. Auch wenn es nur wenige gibt, die eine Aufnahme über 24 Stunden laufen lassen werden.

Zitat von KOMA00

Übrigens sind die erst 13 Bytes auch nicht immer identisch. Das 13. Byte (also Byte Nummer 12) hatte ich schon als 0x08 aber auch als 0x02.

Deswegen steht da ja auch unbekannt. Es wäre echt toll, wenn man hier mal herausbekommt, warum manchmal 08 und manchmal 02 da steht.

Zusammen werden wir es schon herausbekommen...

Gruß
Andreas

[KOMA00]

Zitat von akniest

Hi, bei der 3.5b werden nur 30 Zeichen aus dem Timer / der EPG übernommen.

Das ist noch immer so.

Zitat von akniest

Es werden auch nur 30 Zeichen im Display angezeigt. Vielleicht wurde diese Beschränkung bei neueren FW-Versionen aufgehoben bzw. erweitert.

In der Aufnahmenübersicht und in der Dateiverwaltung werden sogar noch weniger Zeichen angezeigt (etwas über zwanzig). Im Schnittdialog sind es aber 40, wenn man eine entsprechend modifizierte meta.dat hat. Wenn man außerdem in den Namen nicht darstellbare Sonderzeichen einbaut (ausprobiert mit CR LF), dann werden diese bei der Ausgabe einfach übersprungen und noch Zeichen angezeigt, die jenseits der 40er-Grenze stehen. Wenn man das NUL-Byte am Ende des Titels vergisst, zeigt der Receiver aber nur noch Müll an. Er hat dann bei mir in größerer Schriftart nur noch Minute und Sekunde der Aufnahmedauer angezeigt. Ein klein wenig vorsichtig muss man also bei der Manipulation des Titels durchaus sein.

Zitat von akniest

Tut es, habe ich verifiziert.

Das habe ich ebenfalls mehrfach verifiziert, das Feld ist definitiv der Service, aus dem aufgenommen wurde.

Stimmt absolut!

Zitat von akniest

Es ist durchaus möglich, dass die Tage in den Bytes vor der Aufnahmedauer abgelegt werden, da sind ja noch Bytes frei.

Du meinst das Bytes oder die beiden Bytes direkt vor der Stunde? Da hatte ich bisher tatsächlich immer NUL. Werde ich testen. Obwohl es eigentlich egal ist, ob die Bytes immer NUL sind oder die Tage enthalten.

Zitat von akniest

Deswegen steht da ja auch unbekannt. Es wäre echt toll, wenn man hier mal herausbekommt, warum manchmal 08 und manchmal 02 da steht.

Wenn ich genau nachdenke, dann habe ich zwei unterschiedliche Arten von meta.dat analysiert. Einmal habe ich Dateien echter Aufnahmen angeschaut. Dabei wurden Filme im EPG zur Aufnahme ausgewählt. Die haben alle 0x08 vor dem Titel. Die Mehrzahl der Tests habe ich aber gemacht, indem ich einfach einen neuen Timer angelegt und dort ein bis zehn Minuten aus dem aktuellen Programm von arte oder phoenix aufgenommen habe. Dabei steht zum einen vor dem Titel immer eine 0x02 und zum anderen ist der Titel der Programmname und nicht der Name der Sendung. Könnte eventuell genau diese Unterscheidung, Titel der Sendung vs. Name des Senders, die 0x08 oder 0x02 begründen?

Etwas später ergänzt: Ich habe jetzt noch ein paar Tests zu dem Byte vor dem Titel gemacht. Meine Vermutung scheint zu stimmen: 0x08 steht für den Titel der Sendung (bei Aufnahme via EPG) und 0x02 für den Namen des Senders oder eine manuelle Eingabe. Ich weiß nur noch nicht, was passiert, wenn man den Titel der Sendung, die man per EPG programmiert hat, nachträglich durch editieren des Timers ändert. Letztlich ist das für meine Zwecke aber auch egal.

[cis2000]

Hallo,

erst mal. Ich glaube nicht, dass nur die Datei meta.dat für das Abspielen verantwortlich ist. Ich werde mich auf alle Fälle mit an der Auflösung beteiligen.
Ich habe mir heute den Kopf der rec.ts einmal angeschaut. Der scheint auch mehr Info's zu haben als gewöhnlich. Mal sehen habe auch erst angefangen zu testen.
Ich werde auf alle Fälle meine Eingebungen mit einbringen, denn ich finde Euer Vorhaben toll.

Bis bald!

[thomas998]

Hallo !
Ich habe mir eine mehrteilige Aufnahme näher untersucht und möchte die Ergebnisse zur Diskussion stellen. Nach ermitteln von relevanten Paketen
(Padding,PMT,PAT,Video,Audio) habe ich versucht ein System zu erkennen:

Bei einer rec.ts sieht mein Schema wie folgt aus:

PAD 0 PAD 1 PMT 2 PAT 3 PMT 4 [508 Datenpakete] PAD 512 PAT 513 PMT 514 [510 Datenpakete] PAD 1024 PAT 1025 PMT 1026 [510 Datenpakete] PAD 1536...

Zu lesen ist das ganze als Paket-Typ(PAD,PMT,PAT) und TS-Paketnummer.
Auffallend ist die Sequenz: PAD,PAT,PMT gefolgt von 510 Datenpaketen.

Bei einer rec.01 sah es etwas anders aus:

PAD 0 PAT 1 PMT 2 [510 Datenpakete] PAD 512 PAT 513 PMT 514 [510 Datenpakete] PAD

Hier ist vom Anfang an die Sequenz.

Als zweites habe ich die Padding-Pakete untersucht, weil ihr Inhalt beliebig sein kann, da der Decoder TS-Pakete verwirft.
Padding-Paket für rec.ts:

  G   0x1F  0xFF  0x10  0x02  0x32  0x23  0x10  0x01  0x00  0x00  0x00  0x00  0x00  0x00  0x00
    0     1     2     3     4     5     6     7     8     9    10    11    12    13    14    15
 VVVV  VVVV  VVVV  0x00  VVVV  VVVV  VVVV  0x00  0x06  0x00  0x00  0x00    e   0x00    f   0x00
   16    17    18    19    20    21    22    23    24    25    26    27    28    29    30    31
   g   0x00    j   0x00  0x12  0x00    h   0x00  0x00  0x00  0x00  0x00  0x01  0x02  0x02  0x03
   32    33    34    35    36    37    38    39    40    41    42    43    44    45    46    47
 0x00  0x04  0x00  0x00  0x00  0x00  0x00  0x00    r     e     g   0x00    h     c   0x32  0x00
   48    49    50    51    52    53    54    55    56    57    58    59    60    61    62    63
 0x00    d     d   0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
   64    65    66    67    68    69    70    71    72    73    74    75    76    77    78    79
 0x00  0x00  0x00  0x00  VVVV  VVVV  VVVV  0x00  VVVV  VVVV  VVVV  VVVV  0x00  0x00  0x00  0x00
   80    81    82    83    84    85    86    87    88    89    90    91    92    93    94    95
 0x02    D     a     s   0x20    E     r     s     t     e   0x00  0x00  0x00  0x00  0x00  0x00
   96    97    98    99   100   101   102   103   104   105   106   107   108   109   110   111
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  112   113   114   115   116   117   118   119   120   121   122   123   124   125   126   127
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  128   129   130   131   132   133   134   135   136   137   138   139   140   141   142   143
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  144   145   146   147   148   149   150   151   152   153   154   155   156   157   158   159
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  VVVV  VVVV  0x00  0x00
  160   161   162   163   164   165   166   167   168   169   170   171   172   173   174   175
 VVVV  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  176   177   178   179   180   181   182   183   184   185   186   187

VVVV=veränderlich
Byte 0: TS-Sync Byte
Byte 1 u.2 : PID (Pad = 0x1fff)
Byte 56-58: reg
Byte 60-62: hc2 (firmware ? ich meine früher dort auch reg gelesen zu haben)
Byte 96: 0x02
Byte 97-105 : Titel
Byte 106: Null-Byte

Unbekannt:
Byte 16-23: 8 Byte (2*32Bit little Endian ?)
Byte 28,30,32,34,38=e,f,g,j,h
Byte 84-92: 8 Byte (2*32Bit little Endian ?)
Byte 172,173 ?
Byte 176

rec.01

   G   0x1F  0xFF  0x10  0x02  0x32  0x23  0x10  0x01  0x00  0x00  0x00  0x00  0x00  0x00  0x00
    0     1     2     3     4     5     6     7     8     9    10    11    12    13    14    15
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x06  0x00  0x00  0x00    e   0x00    f   0x00
   16    17    18    19    20    21    22    23    24    25    26    27    28    29    30    31
   g   0x00    j   0x00  0x12  0x00    h   0x00  0x00  0x00  0x00  0x00  0x01  0x02  0x02  0x03
   32    33    34    35    36    37    38    39    40    41    42    43    44    45    46    47
 0x00  0x04  0x00  0x00  0x00  0x00  0x00  0x00    r     e     g   0x00    h     c   0x32  0x00
   48    49    50    51    52    53    54    55    56    57    58    59    60    61    62    63
 0x00    d     d   0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
   64    65    66    67    68    69    70    71    72    73    74    75    76    77    78    79
 0x00  0x00  0x00  0x00  VVVV  VVVV  VVVV  0x00  VVVV  VVVV  VVVV  VVVV  0x00  0x00  0x00  0x00
   80    81    82    83    84    85    86    87    88    89    90    91    92    93    94    95
 0x02    D     a     s   0x20    E     r     s     t     e   0x00  0x00  0x00  0x00  0x00  0x00
   96    97    98    99   100   101   102   103   104   105   106   107   108   109   110   111
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  112   113   114   115   116   117   118   119   120   121   122   123   124   125   126   127
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  128   129   130   131   132   133   134   135   136   137   138   139   140   141   142   143
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  144   145   146   147   148   149   150   151   152   153   154   155   156   157   158   159
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  160   161   162   163   164   165   166   167   168   169   170   171   172   173   174   175
 0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00  0x00
  176   177   178   179   180   181   182   183   184   185   186   187

Byte 16-23 und Byte 172,173 sowie Byte 176 sind hierbei konstant.

gruß
Thomas

[akniest]

Hi,

könnte es sein, dass die gleichen Informationen wie in der META.DAT in dem Paket stecken? Der Titel scheint übrigens länger zu sein, die ganzen Nullbytes dahinter sollten ebenfalls noch dazu gehören. Vermutlich ist der Titel inkl. Nullbyte 62 Bytes lang (wie in der Meta.dat).

Gute Arbeit.

Gruß
Andreas