Automatisches -80ms audio delay beim muxen mit tsMuxeR

Ich habe nämlich ein Problem, und zwar seit lange.

Ich wollte eigentlich alle Episoden einer Serie auf einer BD brennen.

Wie im Bild zu erkennen ist, ich setze dort ein Delay von 0ms, da im Original auch 0ms.
[Blockierte Grafik: http://desmond.imageshack.us/Himg440/scaled.php?server=440&filename=tsmuxer1.png&res=landing]
nach dem muxen hat die M2TS Datei ein Delay von -80ms. Man spürt es (es sind 2 Videoframes) zB beim Abspielen in einem BDplayer.
tsMuxerGUI sagt aber etwas anderes
[Blockierte Grafik: http://desmond.imageshack.us/Himg819/scaled.php?server=819&filename=tsmuxer2.png&res=landing]
Das ist falsch, und MediaInfo bestätigt es.
[Blockierte Grafik: http://desmond.imageshack.us/Himg17/scaled.php?server=17&filename=mediainfo1.png&res=landing]

Auch wenn nicht 0ms sondern irgendwelche positive Werten zB 460ms, diese -80ms werden addiert, also in dem Fall ein falsches Delay von 380ms wird erstellt (das Audio ist mit 80ms versetzt).

Das Problem ist bisher von mir noch nicht lösbar, auch multiAVCHD erstellt falsche Delays. Vielleicht gibt's einen anderen Muxer (ich weiss von tsRemux, der will aber keine einzelnen Streams).

Etwa Ideen?

Zitat von bigotti5

Das ist wohl eher ein Fehler von Mediainfo.
Erkennt auch im Jahr 2012 noch keine Streams korrekt die mit backward prediction B-Frames kodiert wurden (viele HW_Encoder machen es so).

Vielen dank für die Erklärung.
Warum hat die fertige BD trotzdem dieses Delay?

Zitat von Ghitulescu

nach dem muxen hat die M2TS Datei ein Delay von -80ms. Man spürt es (es sind 2 Videoframes) zB beim Abspielen in einem BDplayer.

Das Audio läuft in synch mit dem Video nur am PC (wobei denke ich, das Delay nicht betrachtet sei).

Gibts irgendwelche SW die das korrekte Delay auslesen kann?
Ja, ich habe auch Delay erraten bei HDTV Transport Stream gesehen

PS: es ist nicht klar von Bilder, es handelt sich um eine DVD, keine BD.

Zitat von bigotti5

Dann hat entweder ein Demuxer ein nicht vorhandenes Delay fälschlicherweise korrigiert oder Ton und Bild werden getrennt verarbeitet (Bild am TV, Audio am Receiver) oder man spürt es, weil man es spüren will oder ....

Ich bin ganz sicher dass ein Delay von 422 ms vorhanden ist. Ich habe noch mal die einzelne Dateien mit tsMuxrGUI gemuxt. Diesmal mit eine ältere Version (1.9.9). Ein Wunder ist geschehen. Das Delay ist bei 422 geblieben, nicht 362 wie früher, und gar nicht 280 oder so (multiavchd). MediaInfo zeigt aber immernoch 342ms, aber ich verstehe dass MI nicht immer korrekt sei.
Es handelt sich um einen anderen Film, wo das Delay grösser ist.
Ich kann bis zu eine PAL-Frame eine Asynch spüren ... und die AV-Kette ist kalibriert.

Zitat von bigotti5

Ohne Sample kann vieles und muss gar nichts sein.

Die Dateien sind insgesamt etwa 4GB gross ... die Studiologos dauern ein paar Minuten, es dauert also ziehmlich lang bis man eine Szene findet, wo kleinere Delays bemerkbar sind (bei 422 schon, aber bei 80 nicht). Ich muss mindestens ein paar Hundert MB uploaden, mit dem Schneiden bin ich nicht konfident ...

Bilder davon
[Blockierte Grafik: http://desmond.imageshack.us/Himg641/scaled.php?server=641&filename=pgcdemux1.png&res=landing]
PGCdemux hat mir immer gute Werte gezeigt

[Blockierte Grafik: http://desmond.imageshack.us/Himg694/scaled.php?server=694&filename=tsmuxer3h.png&res=landing]
also vor dem Muxen (422ms bei Hand eingegeben)

[Blockierte Grafik: http://desmond.imageshack.us/Himg43/scaled.php?server=43&filename=tsmuxer4.png&res=landing]
Hurra, das delay ist geblieben - die tatsächliche Überprüfung werde ich zu Hause noch mal durchführen (am BDplayer)

[Blockierte Grafik: http://desmond.imageshack.us/Himg802/scaled.php?server=802&filename=mediainfo2.png&res=landing]
Leider zeigt MI immernoch das falsche Delay

Zitat von Propaganda

Naja habe ich gerade vor kuzem gemacht aber egal und die Dynamik macht es nicht kaputt.Höchstens die Qualität könnte darunter leiden aber das hört kein Mensch raus.
192kB AC3.....in PCM 48kHz 16bit......und wieder in 256kB AC3

Zitat von LigH

Also das hilft mit Sicherheit nicht. Das macht nur die Dynamik kaputt.

Nicht unbedingt, es sind viele faktoren die dies beeinflussen, zB die Qalität der Decoder/Encoders, DRC/dialnorm, eventuelle Effekte usw.

Zitat von LigH

Eine einzelne AC3-Datei hat keine Verzögerungs-Informationen. Eine Verzögerung existiert ausschließlich in einem Kontainer, der Video und Audio gleichzeitig beinhaltet.

Das weiss ich.

Zitat von LigH

Außerdem kann bei DVD-Quellen ein falscher Delay-Wert berechnet werden, wenn man VOB-Dateien hat, die mehrere PGCs beinhalten, z.B. Navigations-Trick-Schwarzbilder vor dem Hauptfilm (aber wie oft soll ich noch vorbeten, bei DVDs immer die Hauptfilm-PGC zu extrahieren, wenn man mit Programmen arbeitet, die selber nicht die IFOs auswerten...).

So ist es, nur der Hauptfilm.

Zitat von LigH

Bei Transport-Streams ist das wieder eine andere Sache.

Das weiss ich auch.

Leider habe ich eine lange Pause gemacht, und mir nicht alle Tips&Tricks errinert habe, insbesondere die die für HDTV gelten.

Gestern abend war die Finale, hatte also keine Zeit das neue Mux zu brennen.
Zwei mal 15MB jeweil von VOB und M2TS wie von AVCHD erstellt wurde befinden sich hier.
Danke im Voraus.

Vielen dank für deine Mühe und Zeit.

Ich habe das falsche Delay eingeben?
Das ist was pgcdemux mir gesagt hat
[Blockierte Grafik: http://desmond.imageshack.us/Himg641/scaled.php?server=641&filename=pgcdemux1.png&res=landing]
Dieselben 422ms habe ich in multiAVCHD eingegeben, später, bei zweitem Versuch, auch in tsMuxerGUI. Die M2TS Datei gehört dem ersten Versuch (multiAVCHD, mit tsmuxer 1.10.6).
Soll ich 0ms eingeben? Ist die Anzeige des PGCdemux falsch? Bin jetzt wirklich verwirrt.

Vielleicht habe ich aus Versehen ein falsches Mux geschnitten. Ich habe mehrere Muxen ausgeübt ...
Ich habe 7 Episoden/Filmen.
Vor einem jahr habe ich so etwas ganz einfach mit multiAVCHD als BD erstellt. Nix Probleme, alles klappte wunderbar. Alles von EU-Herkunft.
Ich habe das noch mal versuch. MultiAVCHD verwieg sowohl die U/T noch die Delays richtig zu bearbeiten (die Timeshifts wurden immer 0, obwohl PGCdemux andere Werte gezeigt hat, die U/T wurden nur teilweise upskaliert).
Ich finde nicht mehr das Papier, aber nur der erste Film hat 0ms Delay und das als 0ms übertrug wurde. Korrektes Abspiel auf BDplayer. Der Zweite hat auch 0, MediaInfo und tsMuxeRGUI zeigten aber -80ms, Asynch am Fernseher. Der Dritte hat etwa 422ms, schon wieder MI un tMGUI zeigten 362ms (also immer eine -80ms Differenz), usw.
Jetzt verstehe ich das diese 2 Frames das -80ms Delay verursacht haben. Wustte damals nicht. Es ist auch wahr dass der Erste aus Europa kam, während die anderen aus USA (da erkennt man schon dass der Film nur machinell verarbeitet wurde).

So habe ich mich entschieden, alle Filme zur Hand zu demuxen, die U/T selber umwandeln, und die einzelnen Teile wieder zusammenzufügen. Schon wieder die Delays eingegeben, wie pgcdemux mir die zeigte.
Mit 1.10.6 dasselbe Ergebniss. Mit 1.9.9 sind die Werten geblieben, zumindest in tmgui.

Wie soll ich weitermachen? Soll ich die Delays von PGCdemux einfach ignorieren (0ms)? Soll ich die -80ms selber korrigieren (also direkt 362ms anstatt 422ms eingeben)? Soll ich immer -80ms eingeben?

UPDATE:
Ich habe mir die DVD2BD Lite Software heruntergeladen (Freeware) und damit wieder dasselbe Verfahren versucht. Es klappte wunderbar für alle Episoden, die die positiven Delays haben, scheiterte aber and die, die negative Delays haben. Diese habe ich noch mal mit tsmuxer gemuxt, und zwar mit Delay+80ms (zB 80 anstatt 0 usw).