Nicht reparierbare Aufnahme

[Woodman]

Ich habe am Wochenende eine Aufnahme gemacht, bei der bei der Sendung schon eine kurze Störung sichtbar war. Diese Störung ist aber offensichtlich so groß, das TS-Doctor nicht in der Lage ist, diese zu beheben. Nach dem Öffnen und Einlesen der .REC-Datei kommt kommentarlos ein Fenster für den Dateinamen zum wegschreiben. Nach dem Wegschreiben sieht das Ergebnis so aus:
[attachimg=1]
Nach Klick auf OK erscheint dieses Bild:
[attachimg=2]
Mit Klick auf "Play" wird offenbar der Fehlerhafte Teil der Aufnahme angezeigt.
Nach "Schließen" wird gefragt: "Reparierte Datei öffnen?"
Mit Bestätigung auf "Ja" geht das ganze Spiel wieder von vorne los.
Nach der Datei *_fixed_fixed_fixed_fixed.ts habe ich das Ganze abgebrochen. Nur leider ist jetzt kein Schnitt möglich:
[attachimg=4]

Kennt jemand noch eine Methode der Reparatur. An meinem Topfield ist die Aufnahme übrigens ohne Probleme (bis auf der besagten kurzen Störung) anzusehen. Im Anhang ([attachmini=3]) ist die Logdatei des ersten und des 4. Einlesens zu finden.

[ErichV]

Du könntest versuchen, mit dem Raw Cutter, der unter den Werkzeugen zu finden ist, jeweils einen kleinen Teil vor und nach der Aufnahme wegzuschneiden. Wie sieht es danach mit der Bearbeitung der Datei aus?
Wenn das Problem weiterhin besteht, wäre es wohl ratsam, Cypheros die Aufnahme zukommen zu lassen.

[Woodman]

Du könntest versuchen, mit dem Raw Cutter, der unter den Werkzeugen zu finden ist, jeweils einen kleinen Teil vor und nach der Aufnahme wegzuschneiden. Wie sieht es danach mit der Bearbeitung der Datei aus?
Wenn das Problem weiterhin besteht, wäre es wohl ratsam, Cypheros die Aufnahme zukommen zu lassen.

Mhm, Wozu ist der Raw Cutter gut? da steh' ich ja im Dunkeln. Einfach so irgendwas wegschneiden bringt's ja auch nicht.

Noch eine interessante Info:
Mit SmartCutter kann ich die Datei öffnen und durch die Aufnahme "scrollen". Dabei wird der Timecode für jeden Frame angezeigt. Bis zum Timecode  00:35:46.386 läuft alles normal. Wenn ich jetzt zum nächsten Frame wechsele, springt der Timecode auf 21:05:34.024 und vice versa.

[ErichV]

Mhm, Wozu ist der Raw Cutter gut? da steh' ich ja im Dunkeln. Einfach so irgendwas wegschneiden bringt's ja auch nicht.

Wie der Name schon sagt, kann mit diesem Tool grob geschnitten werden.
Der nach dem Schnitt übrig bleibende Stream ist im Vergleich zum Original komplett unverändert, mit anderen Worten: Ein 1:1 Auschnitt vom Original.
Manche Receiver neigen dazu, am Anfang einer Aufnahme einen "Datensalat" zu produzieren, der keine sinnvolle Weiterverarbeitung der Datei ermöglicht.
Deshalb könntest du vom Vorlauf deiner Aufnahme einen kleinen Teil testweise entfernen und schauen, ob dein Problem damit behoben ist.
Sicherheitshalber wird auch vom Nachlauf ein kleiner Teil weggeschnitten.

[Djfe]

Hi Woodman,

es wäre hilfreich, wenn du in den Einstellungen -> Dialoge
alles auf abfragen stellst und uns danach sagst, welche Dialoge während der Analyse aufpoppen

Der Speicherndialog kommt nämlich nur direkt, wenn man vorher einen der Dialoge beantwortet hat, oder wenn für einen von denen eine Voreinstellung (Ja) getroffen wurde
es gibt Fälle wo der TSD erst die Aufnahme reparieren will/muss, um sie korrekt bearbeiten zu können
in diesem Fall wird es vermutlich sein, dass er einen PCR jump fixen möchte

was im Log dazu steht:

Code Auswählen Erweitern

Strange PCR Jump: 03:46:13.312 [00:35:06.909] -> 24:17:01.773 [21:05:55.370]
                  20687946  -> 20940232

vermutlich versucht der TSD diesen Sprung von 35 Sekunden auf 21h zu reparieren

was komisch ist, ist dass beim 4. Versuch immernoch ein PCR jump gefunden wird
aber von 34 Sekunden an

als wenn er immer nur den Timecode einzelner PCRs/Teile des TS Streams nach hinten verschiebt statt alle auf einmal

@Cypheros ist das so gewünscht?

vermutlich müsstest du den Fixvorgang nur häufig genug ausführen, um alle Timecodes zu reparieren, aber das dauert ja viel zu lange

was ansonsten übrig bleibt ist, dass Cypheros oder jemand anderes eine Erklärung/Lösung nennt
das scheint mir nämlich ein Fehler im Programm zu sein

oder du könntest versuchen, den entsprechenden Dialog mal mit Nein zu beantworten
dann wäre der Sprung aber weiterhin in der Datei, was auch nicht so gut ist

am hilfreichsten erscheint mir ErichVs Kommentar
du trennst mit Raw Cuter die ersten 35 Sekunden vom Rest der Aufnahme
ich glaube folgende Werte aus dem Log sind die Nummern der entsprechenden Pakete im TS Stream

Code Auswählen Erweitern

20687946  -> 20940232
wenn du dem Raw Cutter also sagst: schneide von Paket 20940232 bis Ende, dann hast du den Teil der Datei, welcher die Timecodes ab ~24h hat

wenn dir der Teil reicht und davor nichts wichtiges kam, kannst du die Datei jetzt wieder mit dem TSD öffnen und es sollte keine weiteren Probleme geben

ansonsten könntest du für alle Pakete vom Anfang bis 20687946 machen (das ist dann der Teil mit den Timecodes um ~3h herum -> die ersten 35 Sekunden)

wenn die Timecodeanpassung des Filemergers (im Gegensatz zur PCR jump Korrektur) korrekt funktioniert, müsstest du dann beide Teile korrekt zusammenfügen können und die Timecodes sollten dann entsprechend automatisch angepasst werden

danach solltest du nochmal die TS Datei durch den Doc laufen lassen (und ggf. schneiden) und das Log hier posten
dann können wir dir sagen, ob alles ok ist

[Woodman]

Hallo Djfe,
Vielen Dank für Deine ausführliche Antwort.

Hi Woodman,

es wäre hilfreich, wenn du in den Einstellungen -> Dialoge
alles auf abfragen stellst und uns danach sagst, welche Dialoge während der Analyse aufpoppen

Danke für den Hinweis, mich hat nämlich gewundert, das er kommentarlos nach einem Dateinamen fragt.
Hier sind die Dialog-Anzeigen (die ich alle mit "Ja" beantwortet habe):
Nach der Original .rec-Datei:

Code Auswählen Erweitern

Unzulässigen Timer-Sprung entdeckt [00:00:03.043]
Schnitt nicht möglich. Die Aufnahme muss zuerst durch den TS-Doctor korrigiert werden!

Jetzt eine neue korrigierte Datei erzeugen?

Nach der ersten _fixed.ts:

Code Auswählen Erweitern

Unzulässigen Timer-Sprung entdeckt [-00:00:02.982]

nach der _fixed_fixed.ts:

Code Auswählen Erweitern

Unzulässigen Timer-Sprung entdeckt [00:00:02.975]

...und nach der _fixed_fixed_fixed.ts:

Code Auswählen Erweitern

Unzulässigen Timer-Sprung entdeckt [-00:00:02.982]

usw....
Da steht zwar immer etwas von 3 sek., aber tatsächlich tritt der Fehler nach ca 35min. auf, wie ich in meiner 2 Antwort beschrieben hatte.

....
was im Log dazu steht:

Code Auswählen Erweitern

Strange PCR Jump: 03:46:13.312 [00:35:06.909] -> 24:17:01.773 [21:05:55.370]
                  20687946  -> 20940232

Und dieser Fehler taucht im Log auch nur einmal auf. Obige Anzeige trifft auf die originale .rec-Datei zu.
Bei allen folgenden *_fixed.ts steht dann im Log dieses:

Code Auswählen Erweitern

Strange PCR Jump: 03:45:53.902 [00:34:47.499] -> 24:16:43.563 [21:05:37.159]
                  15678024  -> 15879149


...
vermutlich müsstest du den Fixvorgang nur häufig genug ausführen, um alle Timecodes zu reparieren, aber das dauert ja viel zu lange

Also die Log-Ausgaben lassen nicht darauf schließen.

...
oder du könntest versuchen, den entsprechenden Dialog mal mit Nein zu beantworten
dann wäre der Sprung aber weiterhin in der Datei, was auch nicht so gut ist

Korrekt, dann kann ich zwar den Schneide-Dialog aufrufen aber das Bild bleibt beim erst Frame eingefroren und somit ist auch kein Schnitt möglich.

am hilfreichsten erscheint mir ErichVs Kommentar
du trennst mit Raw Cuter die ersten 35 Sekunden vom Rest der Aufnahme

Wie gesagt ist der Fehler nicht bei 35sec. sondern bei ca. 35min., also bei ca. 2/3 der Aufnahme.

[ErichV]

Wie gesagt ist der Fehler nicht bei 35sec. sondern bei ca. 35min., also bei ca. 2/3 der Aufnahme.

Versuchen kannst du es ja trotzdem, hat schon bei dem einen oder anderen in der Vergangenheit so manche Wunder bewirkt. 

Vor langer Zeit besaß ich eine ähnliche Datei, wo der PCR-Wrap trotz zahlreichen Wiederholungen nicht gefixt werden konnte. Irgendwann hat es dann doch mit ein oder zwei Durchläufen geklappt. Der Fehler der Nicht-Beseitigung des PCR-Wraps war bei dieser einen Aufnahme nicht immer reproduzierbar. Nachdem die gefixte Datei geschnitten und archiviert wurde, hatte ich die Originalaufnahme gelöscht.

Es wäre sicherlich nicht schlecht, deine Aufnahme auf den FTP-Server von Cypheros zu laden.

[Woodman]

....
Es wäre sicherlich nicht schlecht, deine Aufnahme auf den FTP-Server von Cypheros zu laden.

Das habe ich getan, schaun'mer mal

Davon unabhängig habe ich für mich eine Lösung gefunden , die folgendermaßen aussieht:

Mit TS-Doctor->Werkzeuge->TS Formatwandler die Fehlerhafte .rec-Datei in .m2ts umgewandelt. Diese Datei ließ sich problemlos wieder in TS-Doctor öffnen.
Allerdings war jetzt ab der Fehlerstelle der Ton um ca 5sec zu spät!

Jetzt habe ich mit tsMuxeR GUI die .m2ts-Date demuxed und die resultierende AC3-Datei mit meinem alten MPEG-Video Wizard an passender Stelle 5sec herausgeschnitten und das Ergebnis wieder als AC3-Datei exportiert.
Die so erzeugte AC3 habe ich dann wieder mit tsMuxeR GUI und der .264-Datei zu einer .ts-Datei gemuxed.
Die so erzeugte .TS-Datei ließ sich wieder mit VCR und dem KMPlayer wiedergeben.
Das wichtigste aber: Die Datei ließ sich in DVR-Studio HD importieren.

[Derrick]

Ich habe mal den Nasenbeutler geleecht

Zunächst eine Kritik zum File. Da steht ..fixed_split_001_cutted.ts Die Aufnahme ist also vielleicht schon mal durch den Doc gelaufen. Viel besser ist es, das Original zu senden. Und dann auch nur so viel wie nötig. Da der Fehler am Anfang auftritt, reicht ein viel kürzerer Happen.

Die Datei scheint zunächst einmal fehlerfrei, da es keine offensichtlichen Übertragungsfehler gibt. Dass der Stream nicht ok ist, sieht man beim Abspielen natürlich sofort. Der Doc probiert damit eine Endlosreparatur..... 

Wo die Fehler liegen, kann ich nicht sagen. Der TSDoctor prüft auch nur die Syntax und stellt Timing Errors fest. Die Ursache dürfte hier aber tiefer liegen. Entweder beim Playout vom Sender oder beim Transfer auf deine HD. Verschlüsselt ist hier ja nichts.

Ich würde die Aufnahme löschen und auf eine Wiederholung warten. Sonst müsstest du wohl ein Stück rausschneiden. Der DOC scheint jedenfalls in diesem Fall überfordert.

Noch ein Kritikpunkt zum Handling im TSD. Folgt man der 1. Fehlermeldung, sind EIT und SDT futsch. Überhaupt sollte man die Tabellen in den Optionen permanent beibehalten können. Ausserdem ist die Dialoganzeige winzig und fast unlesbar.

[Woodman]

Ich habe mal den Nasenbeutler geleecht

Zunächst eine Kritik zum File. Da steht ..fixed_split_001_cutted.ts Die Aufnahme ist also vielleicht schon mal durch den Doc gelaufen. Viel besser ist es, das Original zu senden. Und dann auch nur so viel wie nötig. Da der Fehler am Anfang auftritt, reicht ein viel kürzerer Happen.

Sorry, das war mein Fehler. Ich hab' noch mal den Raw-Cutter drüber laufen lassen und ein 32MB großen Happen auf der FTP-Seite hochgeladen. Hier tritt der Fehler innerhalb der ersten Sekunde auf (mit SmartCutter kann man das wunderschön sehen: Nach dem Timestamp 00:00:00.640 springt die Zeit auf 20:29:48.280 )

Die Datei scheint zunächst einmal fehlerfrei, da es keine offensichtlichen Übertragungsfehler gibt. Dass der Stream nicht ok ist, sieht man beim Abspielen natürlich sofort. Der Doc probiert damit eine Endlosreparatur..... 

Interessant ist, das TSD dieses kurze Häppchen reparieren konnte.

Wo die Fehler liegen, kann ich nicht sagen....

Sind da nicht Timestamps in der Aufnahme? Wie kann der SmartCutter sonst diesen Zeitsprung anzeigen?
Interessant ist ja auch (wie ich vorher schon schrieb) das die Umwandlung in *.m2ts die Aufnahme quasi repariert hat. Sind hier vielleicht keine Timestamps drin?

[Cypheros]

Interessant ist ja auch (wie ich vorher schon schrieb) das die Umwandlung in *.m2ts die Aufnahme quasi repariert hat.

Nein, da wird nix repariert sondern einfach doof eingelesen und dann mit neuen Timern versehen. Dadurch werden Bild und Ton asynchron.

[Cypheros]

Hab mir das Problem genauer angeschaut. Das ist ein PCR-Sprung drin. Wenn man unter Einstellungen/Optionen/Korrekturverhalten den erweiterten PCR-Check aktiviert, wir der PCR-Fehler erkannt und man kann den Anfang wegschneiden.

Warum sowas passiert und dann mit diesen Werten, ist mir ein Rätsel. Sollte eigentlich nicht passieren.

Code Auswählen Erweitern

PCR 32 : (372922)  03:46:36.669
PCR 33 : (392882)  03:46:45.580
PCR 34 : (396240)  03:46:47.575
PCR 35 : (407976)  03:46:49.806
PCR 36 : (419551)  24:16:39.530
PCR 37 : (431289)  24:16:41.772
PCR 38 : (442895)  24:16:43.980
PCR 39 : (454547)  24:16:46.160

[Woodman]

Interessant ist ja auch (wie ich vorher schon schrieb) das die Umwandlung in *.m2ts die Aufnahme quasi repariert hat.

Nein, da wird nix repariert sondern einfach doof eingelesen und dann mit neuen Timern versehen. Dadurch werden Bild und Ton asynchron.

Die Asynchronität tritt tatsächlich erst ab der Fehlerstelle auf, das konnte ich reparieren.

Hab mir das Problem genauer angeschaut. Das ist ein PCR-Sprung drin. Wenn man unter Einstellungen/Optionen/Korrekturverhalten den erweiterten PCR-Check aktiviert, wir der PCR-Fehler erkannt und man kann den Anfang wegschneiden.

Interessant, werd' ich mir mal ansehen.

Warum sowas passiert und dann mit diesen Werten, ist mir ein Rätsel. Sollte eigentlich nicht passieren.
....

Wie ich im ersten Beitrag schon schrieb, passierte es bei der Aufnahme (die ich life geschaut habe). Kam wohl irgend eine Störung über den Sat.

[Djfe]

gut, dass das Problem nun gelöst ist
das Demuxen/das mit der m2ts konnte hier recht gut funktionieren, weil nur an einer Stelle ein Problem war
wenn die Aufnahme tatsächliche Übertragungsfehler und nicht nur fehlende Timecodes hätte, dann würdest du durch das Wegwerfen der korrekten Timecodes plötzlich an viel mehr Stellen Asynchronität haben, weil die Timecodes normalerweise sicherstellen, dass trotz fehlender Pakete Ton und Video durchgängig eine gleiche Zeitbasis haben


@Derrick warum sollte man eit und sdt nicht aus der Aufnahme rausnehmen?
VLC und co. können damit doch gar nichts anfangen, oder sehe ich das falsch?

[Derrick]

@Derrick warum sollte man eit und sdt nicht aus der Aufnahme rausnehmen?
VLC und co. können damit doch gar nichts anfangen, oder sehe ich das falsch?

Du kannst rausnehmen, was du willst. Ich will sie drin lassen, das aber nicht jedesmal bestätigen müssen und dabei eine Lupe gebrauchen zu müssen. Die Ahnungslosen, die gleich auf den Knopf drücken, weil der TSDoctor die Alarmglocken läutet, wenn da z.b. Längenangaben in den headern vom Videostream sind, sind von diesen (nützlichen ) Zusatzinfos für immer befreit, ohne gefragt zu werden