Tonshift nach Konvertierung in mkv/mp4 mit DVDFab

[gunpie]

Der Titel fordert die Antwort DVFab ist schuld heraus, leider ist es nicht so einfach, denn es besteht ein Abhängigkeit von der Bearbeitungsmethode mit dem aktuellen TS-Doctor. Mein Work-Flow:

Technisat HD-S2 von 2004 -> TS-Doctor-3.0.22 -> mkv via DVDFab

Als Whovian nehme ich mir bei One die Folgen mit englischem Originalton auf, von denen immer zwei unmittelbar hintereinander kommen, Ich scheide da i.d.R einen I-I-Übergang raus.

Das geht natürlich ziemlich schick mit der Dateiaufteilung vom TS-Doctor. Als kleines Schmankerl wird mir oft schon der korrekte Name für die Filme angeboten und häufig gibt's noch eine Inhaltsangabe dazu. Nur mit schöner Regelmässigkeit ergibt sich dann nach der Konvertierung mit DVDFab ein Ton-Versatz (-0.2-0.3s brauche ich dann als Korrekturwert)  für alle, ausser der ersten Datei.

Wenn ich die Teile einzeln mit dem TS-Doctor extrahiere tritt der Tonversatz nicht auf, dafür kriege ich aber nur die Inhaltsangabe für den ersten Film - lästig und es dauert natürlich länger. Das passiert auch bei anderen Sendern und mit längeren "Unterbrechungen" zwischen den Filmen.

Wenn ich mir aufgeteilten TS-Dateien anschaue (TS-Doctor, VLC) kann ich kein Problem erkennen.

Besteht eine Hoffnung auf Besserung?

[AX98]

Vielleicht werden die beiden Probleme umgangen mit der Batch-Verarbeitung ?
Dafür muss man die Aufnahme selbst nur einmal öffnen und für den Schnitt vorbereiten.

[Cypheros]

Wir haben DVDFab hier leider nicht im Einsatz und wissen nicht, warum das passiert. Bild und Ton haben bei TS-Aufnahmen einen separaten Timer, der dafür sorgt, dass Bild und Ton immer Synchron bleiben.
Möglicherweise berücksichtigt DVDFab diese Timer nicht korrekt, oder läßt an den Schnittpunkten Bilder oder Tonpakete weg. Das ist schwer zu sagen.

[gunpie]

Danke für den Hinweis auf die beiden Timer - ich hatte so etwas als Ursache in Verdacht.

Es muss aber auch irgendwas im internen Ablauf vom TS-Doctor anders sein, wenn ich den Aufteilungsmode wähle, den ich eigentlich sehr schätze. Irgendeine Idee was das sein könnte?

[Cypheros]

Leider nein.

[gunpie]

Vielleicht habe ich einen Hinweis oder eventuell ein falsches Verständnis der Aufteilungsfunktion.
Ich habe mir mal die gute und die schlechte Version der generierten ts-Dateien mit dem Packet-Viewer angeschaut:

- Bei der "guten" ist das erste PES-Paket mit einem "Start"-Flag versehen
- Bei der "schlechten" Variante ist das nicht der Fall.

Ich glaube das könnte der Grund für das Problem sein. Für die "gute" Variante habe ich den 1. Schnittbereich einfach gelöscht.

[Cypheros]

Kannst du mal die Logs zu den beiden Versionen posten?

[gunpie]

Aber gerne doch

[Cypheros]

Ich sehe keine Auffälligkeiten bei den Aufnahmen. Sieht alles sauber aus, keine Fehler.

[gunpie]

Ich will ja nicht rumquengeln, aber auch mit 3.0.23 sehen die Anfänge der Folgedateien nach der Aufteilung immer noch so aus, wie in dem Bild wiedergegeben.
Für diesen Unterschied muss es doch einen Grund geben.

[Cypheros]

OK, Du hast da offenbar einen besseren Durchblick als ich. Würde aber eher den TS Packet Viewer nehmen im TS-Doctor (Werkzeuge/Experten-Werkzeuge), der liefert mehr Details als die kostenlose Version des Packet-Viewers.

Der TS-Doctor schneidet an einem bestimmten Zeitpunkt, zu dem ein I-Frame auftaucht. Da Ton und Bild aber versetzt sind (Multiplexing) und das Dekodieren des Bildes länger dauert als das Dekodieren des Tons, beginnt der Datenstrom in den meisten Fällen natürlich schon etwas eher. Ansonsten für würde zum Begin des Bildes der Ton fehlen.

[gunpie]

Das war ja mal ein cooler Tipp :-) mit dem internen Viewer.

Schon das erste Paket sieht anders aus/wird anders angezeigt - in der "schlechten" Version (oben) fehlt der Zeitstempel, mag was mit continuity=4 zu  haben - noch kann ich das Transportstream-Format nicht beeten ;-), am Start einer Datei ist das doch eher fehl am Platz.

Es war aber exakt derselbe Schnittpunkt/Frame, wie sich ja auch aus den Logs ergibt. Ich denke, das weist erneut auf eine Beule bei der Aufteilung hin, die ich wirklich gerne nutzen würde.

[Cypheros]

Schau dir mal die unbearbeiteten Aufnahmen an, da wirst du feststellen, dass die meisten Aufnahmen ohne Zeitstempel anfangen. Das ist bei Transportstreams normal.

Du kannst ja mal versuchen mit dem TS Raw Cutter am Anfang Pakete abzuschneiden, damit die Datei mit einem Zeitstempel anfängt und zu schauen ob DVBFab dann besser damit klar kommt.

[gunpie]

Es ist mir durchaus bewusst, das Transportstreams "irgendwo" anfangen können, schliesslich sind sie dafür gebaut. Die Dateianalyse der unbearbeiteten Dateien durch Windows-Explorer dauert bisweilen schon recht lange und immer öfter verweigert sogar der VLC die Arbeit - ist vergleichsweise neu diese Erscheinung. Sollte ich mir mal die Codecs auf meinem Windows 10 anschauen oder einfach den Doctor zur Default-Anwendung machen?

Bislang war ich davon ausgegangen, dass es ein Feature vom TS-Doctor ist, für einen "sauberen" Anfang zu sorgen, zumindest, wenn ich mit einem I-Frame beginne. Schade, dass das nur für die erste erzeugte Datei gilt, aber dafür gibt es ja einen offensichtlichen Workaround.

Für mich war es primär wichtig den Zusammenhang zu erkennen und daraus einen Workaround/-flow abzuleiten.

Danke für die Unterstützung