Raw-Cutter: Fortschrittsanzeige

[parameter]

Ich muss öfters notgedrungen zum RAW-Cutter greifen, weil etliche Aufzeichnungen am Anfang bzw. Ende so vermurkst sind, dass ich mit der TS-Doctor-Schnittfunktion nicht klar komme, weil der Schnittpunkt nicht korrekt ansteuerbar ist.

Dabei ist mir folgender Bug aufgefallen:
Es passiert immer mal wieder, dass die Fortschrittsanzeige bei so bei 89 % stehen bleibt und ich irgendwann auf abbrechen klicken muss.
Die geschnittene Aufzeichnung ist jedoch komplett. Es ist wohl nur ein Problem der Fortschrittsanzeige und dass der Cutter nicht meldet, dass er fertig ist.

In dem Zusammenhang hätte ich noch einen Verbesserungsvorschlag:
Die LOG-Datei des TS-Doctor zeigt die Packets in Hex-Zahlen an. Anhand dieser im Log enthaltenen problematischen Packet-Grenze ermittle ich meine RAW-Cutter-Schnittpunkte, die wiederum in Dezimalzahlen angegeben werden müssen. So ist jedesmal ein zusätzlicher Bearbeitungsschritt der Umrechnung von Hex in Dezimal erforderlich.
Diese Umrechnung ist zwar kein wirkliches Problem, aber eigentlich unnötig, wenn man dem Raw-Cutter Hex-Zahlen übergeben könnte.

[Xa89]

Es wär schon besser, wenn die Umrechnung entfällt. Eine neue Funktion neben "Nur Überprüfen", die ein Ergebnis wie der Raw Cutter liefert und dabei die Schnittpunkte berücksichtigt, würde ich mir auch wünschen.

[Cypheros]

Wie wäre es denn wenn man zwei Offsets festlegen könnte mit denen man den TS-Doctor dazu bringt die ersten und die letzen paar Megabyte komplett zu ignorieren als wenn man die Dateien vorher mit dem RawCutter gestutzt hätte?

[Xa89]

Jede Funktion im TS-Doctor mit der ich schneller das gewünschte Ergebnis erhalte, ist gut.

[parameter]

Wie wäre es denn wenn man zwei Offsets festlegen könnte mit denen man den TS-Doctor dazu bringt die ersten und die letzen paar Megabyte komplett zu ignorieren als wenn man die Dateien vorher mit dem RawCutter gestutzt hätte?

Ich bin mir nicht sicher, ob das in allen Fällen was nützt, aber das müsstest Du besser beurteilen können.
Stellst Du Dir das so vor, dass parallel zum Setzen des Offsets ohne weiteren Korrekturlauf mit Speicherung auch ein weiteres auf optischer Basis beruhendes Schneiden im Wiedergebafenster möglich sein soll?

Bevor ich die Streams mit dem RAW-Cutter bearbeitet habe, sind sie manchmal so vermurkst, dass ich im Schnittfenster nur wenige Minuten am Anfang überhaupt ansteuern kann. Manchmal spielt der Stream dann am Ende des Time-Balkens einfach weiter, manchmal stockt er auch wirklich am Ende und der Stream erscheint nur wenige Minuten lang.
Das Setzen des Offset müsste also komplett wirklich so wirken, als wenn der Stream schon von allem Murks befreit wurde.

Das wäre, wenn es funktioniert, für mich schon eine schöne Vereinfachung. Allerdings sollten die Offsets wirklich wie beim RAW-Cutter präzise setzbar sein und im Zahlenformat wie im Log-File.

[Cypheros]

Also der TS-Doctor macht das schon bei einigen speziellen *.DVR Aufnahmen von Comag oder Xoro. Der TS-Doctor beachtet den Startoffset auch bei der Wiedergabe und es ist als wenn die ersten KByte an "nicht TS-Daten" gar nicht vorhanden wären.

Ich stell mir das so vor, dass Du in den Einstellungen vorgibts immer die ersten 10 MB weg zu lassen und die letzten 5 MB. Oder ist das von Aufnahme zu Aufnahme unterschiedlich?

[parameter]

Ich stell mir das so vor, dass Du in den Einstellungen vorgibts immer die ersten 10 MB weg zu lassen und die letzten 5 MB. Oder ist das von Aufnahme zu Aufnahme unterschiedlich?

Das ist im Effekt bei jeder Aufnahme unterschiedlich. Ich setze je nach Sender keinen oder einigen Vor- und Nachlauf. Manche Sender sind fast exakt, so dass ich ohne Vor- bzw. Nachlauf auskomme, manche benötigen zur Sicherheit mehr Toleranz.
In fast jedem Fall erhalte ich jedoch meistens durch die zu Beginn noch laufenden Trailer Murks, der ein Schneiden mit dem TS-Doctor verhindert bzw. sogar die Wiedergabe vermurkst, ob er nun nur sekunden- oder minutenlag ist.. Der Murks entsteht fast ausschließlich bei Pay-TV-Sendern, die einerseits lobenswerterweise einen Film komplett ohne Kastrierung und Werbeunterbrechung zeigen, andererseits vor und nach dem Film durch Trailer, Format-, Tonwechsel usw. den aufgezeichneten Brutto-Stream vermurksen.

Zunächst prüfe ich, ob der Stream mit TS-Doctor zu schneiden oder im Vorschaufenster überhaupt wiederzugeben ist. Ist das nicht der Fall, lasse ich zunächst eine neue Datei erzeugen und schaue anschliessend ins Log-File, ob ich dort den tatsächlichen Beginn und das Ende des Films anhand der TS-Warning-Meldungen identifizieren kann. Die identifizierten Packet-Nr. rechne ich dann ins dezimale Format um und trage sie in den RAW-Cutter ein. Zu 90 % ist danach der Stream normal ansehbar und über TS-Doctor eventuell falls erforderlich weiter schneidbar. Ansonsten ist halt nochmals ein Blick ins Log-File erforderlich, um festzustellen, ob man die Offsets falsch interpretiert hat und das Ganze gegebenenfalls zu wiederholen.

Ich bin schon daran interessiert, bei Aufnahmen, die ich behalten will, einen kompletten Film von Anfang bis Ende einschließlich den Credits zu erhalten.
Daher wäre eine solche Funktion des Offset im Vorschaufenster für mich nur interessant und eine Verbesserung, wenn ich dort individuell im Log-File ermittelste Packet-Nr. als Offset eintragen könnte.

[Cypheros]

Also ich denke fast, dass da ein grundsätzliches Problem vorliegt, dass ich mir mal genauer anschauen sollte.
Kannst Du mir, wenn Du möchtest auch "disket" per PM, mitteilen welche Aufnahmen Du genau von welchem Sender machst und mit welchem Receiver?

Ich könnte dann mal versuchen das zu reproduzieren und eine Lösung dafür zu finden.

[parameter]

Also ich denke fast, dass da ein grundsätzliches Problem vorliegt, dass ich mir mal genauer anschauen sollte.

Ich habe mal ein Logfile einer typischen Problemaufnahme beigefügt.

[Cypheros]

Hi,

der Anfang mit den Errors ist nicht schlimm, das passiert häufig mit bestimmten CamModulen für PayTV. Die Module brauchen manchmal einen Moment bis sie mit der Entschlüsselung anfangen.

Was aber unschön ist, sind die falschen PCR-Werte:

Code Auswählen Erweitern

TS Warning: PCR timing for PID 0215 last PCR:00:01:58.745 current PCR:00:01:58.782 at paket 00013F14 TimeBase:10690375 PCRExtension:221
TS Warning: PCR timing for PID 0215 last PCR:00:01:58.782 current PCR:00:01:58.819 at paket 00013F15 TimeBase:10693709 PCRExtension:240
...

TS Warning: PCR timing for PID 0215 last PCR:00:01:59.559 current PCR:02:30:42.339 at paket 00013F2A TimeBase:8589810509 PCRExtension:251
TS Warning: PCR timing for PID 0215 last PCR:02:30:42.339 current PCR:02:30:42.376 at paket 00013F2B TimeBase:8589813849 PCRExtension:66
TS Warning: PCR timing for PID 0215 last PCR:02:30:42.376 current PCR:02:30:42.413 at paket 00013F2C TimeBase:8589817183 PCRExtension:86
TS Warning: PCR timing for PID 0215 last PCR:02:30:42.413 current PCR:02:30:42.450 at paket 00013F2D TimeBase:8589820514 PCRExtension:208
....

Erst ab Paket 00013F2A scheint der Timer zu stimmen. Man sieht das an dem Sprung von über 2 Stunden. Das bedeutet, dass die ersten 16MB Schrott sind und damit jeden Mediaplayer aus dem Konzept bringen.

Das sieht mir so aus als ob da noch irgenwas von einer anderen Aufnahme im Puffer stand was da an den Anfang gehängt wird. Da der Receiver diese Timer bestimmt nicht selbstso verbogen hat, kann das eigendlich nur so eine Vermischung zweier Aufnahmen sein.

Kann es sein, dass da am Anfang auch ein paar Bilder auftauchen, die nicht zur eigendlichen Aufnahme gehören?

[Cypheros]

So, die neue Beta 1.1.38 sollte diese Art von Fehlern nun erkennen und ein Lösung anbieten 

[parameter]

So, die neue Beta 1.1.38 sollte diese Art von Fehlern nun erkennen und ein Lösung anbieten 

Vielen Dank für Deinen Einsatz. Ich kann bestätigen, dass die Funktion bei dem speziellen Problem der PCR-Fehler im Vor- und Nachlauf von Filmen grundsätzlich meistens hilfreich ist.
So wurde das ärgerliche Problem der PCR-Fehler bei diesen Aufnahmen in eine praktische Hilfe beim Finden der Schnittpunkte umgemünzt, mit der ohne manuelles Herantasten auf praktische Weise ein Schnitt möglich ist.