Lucike
20.08.2003, 00:48
[equote:867b226259="Verfasst am: Mo März 03.03.2003 12:25 von TheHorse"]Hi matt,
ich weiß, dass du diesbezüglich etwas geändert hast. Leider fehlt bei den ts meines koreanischen Datensammlers aber immer noch nach der ersten Aufnahme die zweite Audiospur.
Beispiel:
0x200 immer da
0x201 nicht da (nicht mal scrambled)
0x203 wieder da
Habs auch schon mit Überspringen von 10 bis mehreren 100 MB versucht. Wahrscheinlich habe ich Laie keine Chance, mit dem Hexviewer nachzuforschen, ob die nun da ist oder wie die versteckt ist?
Ich kann das Problem natürlich lösen, indem ich den Film bei gewählter zweiter Audiospur nochmal am Receiver kopiere (du kennst das Verfahren). Nur ist das etwas umständlich. (Dass der Receiver da etwas möglicherweise nicht ganz Astreines mit der PMT macht, ist mir schon klar. Warum er sie dann beim Kopieren repariert, verstehe ich aber auch nicht.)[/equote:867b226259]
[equote:867b226259="Verfasst am: Mo März 03.03.2003 15:18 von dvb.matt"]es wird nur die PMT gelesen, die physisch als erstes ihr Startpaket im File hat.
Das ist bei deiner "Miss UC" wohl irgendein Musikkanal vom Tpx auf 11797.
was wiederum egal ist, weil die PIDs eh nach Auftreten gemeldet/genutzt werden, nicht nach PMT (sollten jetzt thereot. mehr sein)
0x201 findest du im .ts als "47 42 01 xx 00 00 01 Cx", falls es ein Startpaket ist (unscrambled und ohne besondere Zusatzdaten),
ansonsten "47 42 01 xx ..." bzw. "47 02 01 xx ..."
mail doch mal 200kB mitten aus dem "ersten" .ts
(wo 0x201 also mit Sicherheit drin sein sollte, und du auch gefunden hast )[/equote:867b226259]
[equote:867b226259="Verfasst am: Mo März 03.03.2003 16:33 von TheHorse"]Nach genauer nochmaliger "Analyse" können wir uns das wieder mal schenken. Ich muss mich damit abfinden, dass der koreanische Datensammler die zweite Tonspur immer scrambled aufzeichnet Ich weiß nur nicht, nach welcher Logik er immer gerade diese Spur erwischt.
Ich finde massenweise 47 42 01 D3 FB 5B 97 8E und ähnliches Zeugs im Original. Nach der Kopie am Receiver liest sich das schön 47 42 01 14 00 00 01 C0 usw.
ds.jar meldet die PID-Daten ja auch scrambled, wenn man den Haken weg macht. Hatte ich irgendwie übersehen. Kein Wunder bei den tausend Streams, die der Topfield da mit aufzeichnet!
Ich versuche mal ganz vorsichtig, im Topfield-Forum einen Bugreport abzusetzen. Wahrscheinlich bin ich wieder einer von zweien, die diesen Effekt haben.
Übrigens, toller Hex-Viewer! Da kann ich ja sogar andere Binärdateien reinladen[/equote:867b226259]
[equote:867b226259="Verfasst am: Mo März 03.03.2003 20:12 von dvb.matt"]also lassen wir wie's ist..
sogar andere Binärdateien reinladen
dat iss ja auch gedacht um zu gucken, wenn irgendn File nicht erkannt wird o.s.ä.[/equote:867b226259]
ich weiß, dass du diesbezüglich etwas geändert hast. Leider fehlt bei den ts meines koreanischen Datensammlers aber immer noch nach der ersten Aufnahme die zweite Audiospur.
Beispiel:
0x200 immer da
0x201 nicht da (nicht mal scrambled)
0x203 wieder da
Habs auch schon mit Überspringen von 10 bis mehreren 100 MB versucht. Wahrscheinlich habe ich Laie keine Chance, mit dem Hexviewer nachzuforschen, ob die nun da ist oder wie die versteckt ist?
Ich kann das Problem natürlich lösen, indem ich den Film bei gewählter zweiter Audiospur nochmal am Receiver kopiere (du kennst das Verfahren). Nur ist das etwas umständlich. (Dass der Receiver da etwas möglicherweise nicht ganz Astreines mit der PMT macht, ist mir schon klar. Warum er sie dann beim Kopieren repariert, verstehe ich aber auch nicht.)[/equote:867b226259]
[equote:867b226259="Verfasst am: Mo März 03.03.2003 15:18 von dvb.matt"]es wird nur die PMT gelesen, die physisch als erstes ihr Startpaket im File hat.
Das ist bei deiner "Miss UC" wohl irgendein Musikkanal vom Tpx auf 11797.
was wiederum egal ist, weil die PIDs eh nach Auftreten gemeldet/genutzt werden, nicht nach PMT (sollten jetzt thereot. mehr sein)
0x201 findest du im .ts als "47 42 01 xx 00 00 01 Cx", falls es ein Startpaket ist (unscrambled und ohne besondere Zusatzdaten),
ansonsten "47 42 01 xx ..." bzw. "47 02 01 xx ..."
mail doch mal 200kB mitten aus dem "ersten" .ts
(wo 0x201 also mit Sicherheit drin sein sollte, und du auch gefunden hast )[/equote:867b226259]
[equote:867b226259="Verfasst am: Mo März 03.03.2003 16:33 von TheHorse"]Nach genauer nochmaliger "Analyse" können wir uns das wieder mal schenken. Ich muss mich damit abfinden, dass der koreanische Datensammler die zweite Tonspur immer scrambled aufzeichnet Ich weiß nur nicht, nach welcher Logik er immer gerade diese Spur erwischt.
Ich finde massenweise 47 42 01 D3 FB 5B 97 8E und ähnliches Zeugs im Original. Nach der Kopie am Receiver liest sich das schön 47 42 01 14 00 00 01 C0 usw.
ds.jar meldet die PID-Daten ja auch scrambled, wenn man den Haken weg macht. Hatte ich irgendwie übersehen. Kein Wunder bei den tausend Streams, die der Topfield da mit aufzeichnet!
Ich versuche mal ganz vorsichtig, im Topfield-Forum einen Bugreport abzusetzen. Wahrscheinlich bin ich wieder einer von zweien, die diesen Effekt haben.
Übrigens, toller Hex-Viewer! Da kann ich ja sogar andere Binärdateien reinladen[/equote:867b226259]
[equote:867b226259="Verfasst am: Mo März 03.03.2003 20:12 von dvb.matt"]also lassen wir wie's ist..
sogar andere Binärdateien reinladen
dat iss ja auch gedacht um zu gucken, wenn irgendn File nicht erkannt wird o.s.ä.[/equote:867b226259]