Zurück   Startseite > Foren > Set-Top-Boxen für Digital TV > Comag, Silvercrest & Clones > PVR2/PVR2 HD

Antwort
 
LinkBack Themen-Optionen Thema durchsuchen
Alt 21.05.2008, 21:49   #1 (permalink)
Neuling
 
Registriert seit: 05.2008
Beiträge: 1
Frage Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

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.
Torben ist offline   Mit Zitat antworten
 
Anzeige
 
News
Alt 22.05.2008, 11:21   #2 (permalink)
Senior Member
 
Registriert seit: 03.2008
Ort: Hornbek
Beiträge: 185
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
__________________
VU+ Duo mit VTi-Image
Comag PVR 2/100CI (80GB) - FW 3.8final - Defekt
Kopiertool:
www.familiekniest.de/pvrcopy
akniest ist offline   Mit Zitat antworten
Alt 25.05.2008, 10:20   #3 (permalink)
Senior Member
 
Registriert seit: 12.2007
Beiträge: 478
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.
Geesz ist offline   Mit Zitat antworten
Alt 14.06.2008, 10:10   #4 (permalink)
Junior Member
 
Registriert seit: 06.2008
Beiträge: 25
AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Zitat:
Zitat von Torben Beitrag anzeigen
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:
Zitat von akniest Beitrag anzeigen
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.
KOMA00 ist offline   Mit Zitat antworten
Alt 14.06.2008, 11:58   #5 (permalink)
Junior Member
 
Registriert seit: 03.2008
Beiträge: 88
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://dvbsnoop.sourceforge.net

Gruß
Thomas
thomas998 ist offline   Mit Zitat antworten
Alt 16.06.2008, 08:44   #6 (permalink)
Junior Member
 
Registriert seit: 06.2008
Beiträge: 25
AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Zitat:
Zitat von thomas998 Beitrag anzeigen
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:

Code:
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

Geändert von KOMA00 (18.06.2008 um 12:43 Uhr) Grund: Beschreibung von meta.dat korrigiert
KOMA00 ist offline   Mit Zitat antworten
Alt 16.06.2008, 21:06   #7 (permalink)
Senior Member
 
Registriert seit: 12.2007
Beiträge: 478
AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Zitat:
Zitat von KOMA00 Beitrag anzeigen
(...)
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?
Geesz ist offline   Mit Zitat antworten
Alt 17.06.2008, 09:12   #8 (permalink)
Junior Member
 
Registriert seit: 06.2008
Beiträge: 25
AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Zitat:
Zitat von Geesz Beitrag anzeigen
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.
KOMA00 ist offline   Mit Zitat antworten
Alt 17.06.2008, 09:26   #9 (permalink)
Junior Member
 
Registriert seit: 03.2008
Beiträge: 88
AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

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

Thomas
thomas998 ist offline   Mit Zitat antworten
Alt 17.06.2008, 16:28   #10 (permalink)
Junior Member
 
Registriert seit: 06.2008
Beiträge: 25
AW: Suche Format-Beschreibung für .bm, .cp, .dat-Dateien und CHANLIST.BIN

Zitat:
Zitat von thomas998 Beitrag anzeigen
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.
KOMA00 ist offline   Mit Zitat antworten
Antwort

Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche

Forumregeln
Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are an


Ähnliche Themen
Thema Autor Forum Antworten Letzter Beitrag
Suche Festplattenrecorder (Format MPEG) tvjack DVD-Player, Recorder und Multifunktionsgeräte 1 19.04.2008 11:44
Konvertieren von Dateien in DVD-Format motvoc Digital TV über Satellit (DVB-S) 1 28.01.2007 17:17
Suche Anleitung für Bearbeitung von MPEG2 Dateien gabbiano Digitale Audio- und Videobearbeitung 8 21.05.2005 18:09
Suche zu GP31 Datenblatt Technische Beschreibung Handbuch berniP Digital TV über Satellit (DVB-S) 4 18.10.2004 22:51
HUMAX PVR 8000, *.aud-Format,, Festplatte Receivers, MP3 Dateien Zaxareas Humax 0 07.04.2004 14:04


Alle Zeitangaben in WEZ +2. Es ist jetzt 11:05 Uhr.


Powered by vBulletin® Version 3.8.7 (Deutsch)
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO 3.6.0 PL2
© Auerbach Verlag, Leipzig
Twitter