Fragen zu MeGUI und MeGUI-Wiki

  • Hi,

    ja zumindest bei HD-Aufnahmen kommt für mich nur die unkomprimierte Tonspur in Frage. Den Job hatte ich nur erzeugt, weil ich eben keine andere Möglichkeit in MeGUI sah, die Tonspur zu extrahieren. Aber dann kamst du mit Strg+F7 und ich sah den Wald wieder. ;) Überhaupt hatte ich die Tools wohl konsequent missachtet.

    Bisher arbeitete ich fast ausschliesslich mit den Frontend's StaxRip und Handbrake und bin da wohl etwas vorbelastet. Letztendlich versteckt sich dahinter bei allen die gleiche "Technik" nur eben anders angeordnet und Funktionen sind mal oder weniger leicht zu finden.

    Ich habe mal fix deine Vorgehensweise nachgeahmt mit dem Ergebnis das die Tonspur wie erwartet asynchron war. Beim Demuxen der Tonspur hat er leider das Delay nicht in den Dateinamen mit einfügt. In der Logdatei stand lediglich das er eine verbleibende Verzögerung von -9ms nicht beheben konnte. Natürlich habe ich dann versucht beim letzten Schritt diese und andere Werte händisch ins Delay-Feld einzutragen, ohne Erfolg. Und jedesmal mich an die Delay-Werte ranzutasten ist unnötig umständlich. Da es keine Vorschau gibt, müsste man jedesmal die Aufnahme muxen. Das geht jetzt bei einer Testdatei die nur ein paar MB ist noch aber bei kompletten Filme machen sieht das schon anders aus.

    Vielleicht hab ichs auch anders verstanden als du es beschrieben hast.

    Ich habe die bereinigte Datei geöffnet (mit TS-Doctor alles rausgeschmissen was ich nicht brauche, da er sich beim Indexieren mittels L-Smash an weiteren Tonspuren stört), L-Smash File Indexer gewählt, alle Tonspuren und indexiert. Gecroppt und danach im Input-Reiter nur den Videostream in die Queue geschickt - codiert. Ergebnis, eine .mkv ohne Ton - okay.
    HD Streams Extractor gestartet, File Mode und die original .ts ausgewählt. AC3 Audiostream als .ac3-Datei speichern lassen - okay.
    Zum Schluss MKV-Muxer geöffnet zuvor erstellte .mkv und .ac3 Streams ausgewählt und gemuxt. Ergebnis wie gesagt asynchron. Natürlich habe ich mit Delay-Werten rumgespielt die mir die originale .ts liefert aber diese brachte keinen Erfolg so musste wiedermal die Augen-Ohren Kombination herhalten und raus kam ein Delay von 650ms. Aber diese Frickelei muss ich echt nicht haben. Nachvollziehen oder gar errechnen konnte ich den Wert auch nicht.

    Mache ich es hingegen wie sonst auch gibts keine Probleme mit der Synchronität. Bereinigte Datei öffnen, als Indexer diesmal FFMS genommen und gecroppt. Im Input-Reiter auf "AutoEncode" gegangen "Adaptive Muxer" öffnet sich und codiert - alles okay. Komischerweise ist das Delay-Feld beim Adaptive Muxer ausgegraut und mit einer Null versehen, so dass ich leider nicht sehen kann was er da nun errechnet hat. Aber rauskommt eine synchrone Datei. Ob er den Audiostream aber jetzt wirklich nur gemuxt oder ihn irgendwie doch codiert hat ist nicht ersichtlich. Da sind wir wieder beim Fehlen einer passtrough Funktion.


    edit:

    Jetzt hab ichs nochmal mit einer anderen Methode probiert. Raus kam eine synchrone codierte .mkv mit unangetasteter Tonspur.
    Diesmal habe ich zuerst die bereinigte Aufnahme mit HD Streams Extractor geöffnet A/V-Streams als h264/ac3 demuxt. Danach über die Tools den Indexer geöffnet, weil sonst kann man ja nirgends ein Raw-Stream öffnen. Besagten Raw-Stream (h264) also geöffnet und mit DGAVC (alle anderen waren ausgegraut) indexiert. Wieder das Übliche: wahlweise gecroppt und codiert. Dann nochmal durch den MKV-Muxer gejagt und fertig.


    Gruß

    Einmal editiert, zuletzt von eronix (3. Januar 2015 um 23:26)

  • Dass Asynchronitäten ohne spezielle Vorarbeiten vielleicht nicht korrekt behoben werden, ist immer ein gewisses Risiko. Leider weiß ich nicht in jedem denkbaren Fall, wie die optimale Vorgehensweise wäre. Da müsste man schon die konkreten Beispiele genauer analysieren. Eine erweiterte MediaInfo-Analyse wäre immer der Anfang, und eine Überlegung zum Demultiplexen. 9 ms spielen sicher keine Rolle, das ist unter der Wahrnehmungsschwelle. Aber die Ursache für etwa 650 ms muss irgendwie herauszukriegen sein. Sei es z.B. eine am Anfang angeschnittene GOP, die vorbereinigt werden könnte.

  • Die Variante die ich per edit noch angefügt hatte, ist bisher recht zuverlässig - auch wenn sie von den Einstellungen dem One-Klick-Encoder recht ähnlich ist. Wirklich schade das beim One-Klick kein manuelles Croppen möglich ist.
    Ein weiterer Nachteil der Methode demux, indexieren, Video-Codierung und mux ist, das dadurch das Erstellen mehrerer Jobs die man dann in einem Rutsch abfahren kann nicht mehr möglich ist. Da die Jobs ja aufeinander aufbauen und ohne Datei XY die Job 1 erstellt Job 2 auch nicht erstellt geschweige dann gestartet werden kann. Damit kann ich mich allerdings arrangieren.

    Die exorbitante Verzögerung übrigens lag am RAW-Cutter vom TS-Doc, ich hatte zu Testzwecken etwas abgeknipst dabei ist irgendwas im Header flöten gegangen. Dennoch schade, das der Demuxer den Versatz nicht erkannt hat. Jedenfalls klappt so auch die Variante den du als "den ausführlichen, manuellen Weg" bezeichnet hast.

    Auch wenn mir der "AutoEncode"-Button immernoch suspekt ist. Ich meine, wozu soll der genau gut sein. Klickt man ihn gleich nach dem Starten des Tools an, will er verständlicherweise ein Video-Input haben. Geht man aber den Weg über File -> Open hat sich das doch erledigt, von da aus geht doch alles seinen normalen Weg über Index, Avisynth, A/V bearbeiten/ codieren bis hin zur fertigen Datei. Also wozu dieser olle Knopp? ^^

    Gruß

    3 Mal editiert, zuletzt von eronix (4. Januar 2015 um 22:01)

  • Soweit ich weiß, geht es beim "AutoEncode" wohl darum, immer wieder mal verschiedene Dateien in die gleichen Formate zu konvertieren, ohne irgendwas zu schneiden (weder in der Bildfläche noch in der Spieldauer), also davon ausgehend, dass die Vorlagen gut genug zum "blinden" Konvertieren sind.

    Leider weiß ich nicht viel über Automatisierungsmöglichkeiten bei MeGUI. Vielleicht gibt es eine etwas komfortablere Variante, die ich nicht kenne. Das muss dann eventuell mal im englischen doom9-Forum gefragt werden, falls Zathor hier nur noch selten reinschaut...

  • Noch eins zu deinem Edit:

    Die Tonspur demultiplexen ist bei verbreiteten Formaten (AC3, AAC, MP3) üblich und meist auch relativ problemlos. Aber die Videospur "raw" demultiplexen ist (je nach Format) eventuell nicht sinnvoll, weil sie im Rohformat mangels Header einige wichtige Eigenschaften (z.B. die Framerate) nicht speichert, oder vielleicht überhaupt nicht mehr erkannt wird (rohes H.264 geht noch, rohes VC-1 wäre dagegen wohl verloren). Als Videoquelle sollte man also oft besser eine Datei mit Container verwenden, je nach enthaltenem Videoformat. Dass für eine rohe H.264-Videospur nur noch der technisch veraltete DGAVCIndex angeboten wird, ist dann auch eine unangenehme Folge des Demultiplexens. Der empfohlene L-SMASH-Indexer sollte z.B. für Video-Quellen im MKV-Container zur Verfügung stehen.

    Es gibt auch Audioformate, die roh nicht verwertbar sind, allerdings eher Tonspuren in AVIs mit geringerer Qualität (z.B. ADPCM), die heute nicht mehr verbreitet genutzt werden.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!