1. Cookies optimieren die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklärst Du dich damit einverstanden, dass wir Cookies verwenden. Weitere Informationen
    Information ausblenden
  2. Willkommen im Forum von DIGITAL FERNSEHEN - dem führenden Portal für digitales Fernsehen, Medien und Entertainment. Wenn du hier neu bist, schau dich ruhig etwas um und melde dich an, um am Forengeschehen teilnehmen zu können.
    Information ausblenden

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

Dieses Thema im Forum "PVR2/PVR2 HD" wurde erstellt von Torben, 21. Mai 2008.

  1. Torben

    Torben Neuling

    Registriert seit:
    21. Mai 2008
    Beiträge:
    1
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    Anzeige
    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.

    :confused: Torben

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

    akniest Senior Member

    Registriert seit:
    26. März 2008
    Beiträge:
    185
    Zustimmungen:
    0
    Punkte für Erfolge:
    26
    Technisches Equipment:
    Comag PVR 2/100 CI
    AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

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

    Geesz Senior Member

    Registriert seit:
    27. Dezember 2007
    Beiträge:
    478
    Zustimmungen:
    0
    Punkte für Erfolge:
    26
    AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

    @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.
     
  4. KOMA00

    KOMA00 Junior Member

    Registriert seit:
    2. Juni 2008
    Beiträge:
    25
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

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

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

    thomas998 Junior Member

    Registriert seit:
    31. März 2008
    Beiträge:
    88
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Technisches Equipment:
    Comag PVR 2/100CI,Sandberg-Konverter,640 GB Seagate ST3640323AS
    AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

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

    Gruß
    Thomas
     
  6. KOMA00

    KOMA00 Junior Member

    Registriert seit:
    2. Juni 2008
    Beiträge:
    25
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

    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:

    Code:
    [B][U]meta.dat:[/U][/B]
    
    [U]Example:[/U]
    
    00:  05 00 72 6a 07 00 00 00   00 00 00 00 [COLOR="Green"]08[/Color] 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 [COLOR="Green"]00 00[/COLOR]
    50:  d8 07 06 0a 02 [COLOR="Red"]00 00 00   85 d4 00 00[/COLOR] 02 27 2a [COLOR="Green"]00[/COLOR]
    60:  00 [COLOR="Red"]00 00 00 01 00 00 00[/COLOR]   5e 44 [COLOR="Red"]00 00[/COLOR] 03 [COLOR="Green"]00 00 00[/COLOR]
    
    [U]Description:[/U]
    
    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
     
    Zuletzt bearbeitet: 18. Juni 2008
  7. Geesz

    Geesz Senior Member

    Registriert seit:
    27. Dezember 2007
    Beiträge:
    478
    Zustimmungen:
    0
    Punkte für Erfolge:
    26
    AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

    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?
     
  8. KOMA00

    KOMA00 Junior Member

    Registriert seit:
    2. Juni 2008
    Beiträge:
    25
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

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

    thomas998 Junior Member

    Registriert seit:
    31. März 2008
    Beiträge:
    88
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Technisches Equipment:
    Comag PVR 2/100CI,Sandberg-Konverter,640 GB Seagate ST3640323AS
  10. KOMA00

    KOMA00 Junior Member

    Registriert seit:
    2. Juni 2008
    Beiträge:
    25
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

    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.