FPS von DTS-Tonspur erkennen?

  • Hab hier die 720p DL Version von Bones S7, wobei bei der 7x01 die englische Tonspur fehlt. Hab mir die DTS-Tonspur aus der 1080p rausgenommen und wollte die reinmuxen, passt aber trotz delay nicht. Gehe davon aus, dass die FPS nicht übereinstimmen, nur hab ich die 1080p MKV schon gelöscht und wollte die nicht unbedingt noch mal laden müssen. Also, kann man der DTS-Tonspur ansehen, auf welchen FPS sie läuft?

  • Kann man nicht! Wie soll das denn auch gehen? FPS bedeutet ja "frames per second" also "Bilder pro Sekunde" - und eine Tonspur besteht halt nicht aus Bildern ;) .


    Man könnte höchstens Rückschlüsse aus der Laufzeit ziehen. Das geht schon auf den ersten Blick:
    Die Tonspur ist deutlich kürzer als das Video(?) = dann ist die Tonspur dementsprechend für eine höhere Framerate als die vom Video ausgelegt! Die Tonspur ist merklich länger(?) = dann ist sie für eine niedrigere Framerate gedacht!


    Das lässt sich auch ausrechnen - z.B. so:
    Nimm die Gesamtframeanzahl des Videos und teile sie durch die Laufzeit der DTS-Tonspur (in Sekunden... mindestens bis auf eine halbe Sekunde genau) -> du erhältst die Framerate, bei der die Tonspur unter das Video passt (aber ACHTUNG: das Ausrechnen klappt NUR, wenn die 720p- und die 1080p-Variante absolut identisch geschnitten sind).

  • Schon klar, da aber Subtitle Workshop SRTs umrechnen kann, so dass sie auf Videos mit anderer FPS passen (obwohl der Wert auch nicht in der Datei steht), hatte ich irgendwie gehofft, es ging auch bei Audio bzw., dass beim Muxen des Videos der Wert auch noch in die Tonspur geschrieben würde, oder so. Aber danke für die Berechnung, die 1080p läuft auf 23,97 FPS und die 720P auf 25 FPS. Wenn ich die jetzt die Tonspur mit irgendner Software (welche, kann Magix Video DTS 5.1?) anpasse, wie sieht's dann mit dem Qualitätsverlust aus durchs Rekodieren aus?

  • Schon klar, da aber Subtitle Workshop SRTs umrechnen kann, so dass sie auf Videos mit anderer FPS passen (obwohl der Wert auch nicht in der Datei steht), hatte ich irgendwie gehofft, es ging auch bei Audio bzw., dass beim Muxen des Videos der Wert auch noch in die Tonspur geschrieben würde, oder so.


    Ähm... schlechtes Beispiel: SubtitleWorkshop kann das nämlich NUR DANN umrechnen, wenn du die Quell- und Ziel-Framerate für die SRT manuell(!) angibst! Automatisch erkennen kann es die Framerate NICHT... bzw. nur, wenn eine Videodatei mit dem selben Namen im selben Ordner wie die SRT liegt ( => dann orientiert sich SubtitleWorkshop nämlich an der Framerate eben dieser Videodatei). Liegt die SRT allerdings alleine vor, ist's Sense mit der Erkennung der Framerate...


    Ist bei 'ner Tonspur doch ganz genauso: kennst du die Quell- und Zielframerate, kannst du die Tonspur entsprechend strecken/stauchen. Kennst du eins davon bzw. beides nicht, dann ist das halt nicht möglich.



    Aber danke für die Berechnung, die 1080p läuft auf 23,97 FPS und die 720P auf 25 FPS. Wenn ich die jetzt die Tonspur mit irgendner Software (welche, kann Magix Video DTS 5.1?) anpasse, wie sieht's dann mit dem Qualitätsverlust aus durchs Rekodieren aus?


    'Nen Qualitätsverlust gibt's definitiv - ob du den hörst, ist allerdings fraglich. Ich würde mir da eher Sorgen um "Clipping" machen:


    http://de.wikipedia.org/wiki/%…_%28Signalverarbeitung%29


    Zur Frage nach der Software:
    Wenn am Ende wieder eine DTS-Tonspur raus kommen soll, wird es schwierig. DTS-Encoder sind meist in teurer, (semi)professioneller Software zu finden (Tools von Magix gehören da meines Wissens nicht dazu) oder als ebenso teure Standalone-Versionen zu haben.


    Eac3to könnte z.B. die Frameratenkonvertierung vornehmen und ist auch kostenlos... benötigt aber für die DTS-Ausgabe zusätzlich den kostenpflichtigen DTS-Encoder von SurCode.


    Es gibt nur einen einzigen kostenlosen DTS-Encoder - dcaenc:


    http://forum.videohelp.com/thr…caenc-2-%5BMinGW-build%5D


    Ich hab kürzlich eine Ausgabeerweiterung für BeHappy:


    http://behappy.codeplex.com/


    ... gebastelt, über die dcaenc in BeHappy verwendet werden kann. BeHappy kann dabei die Frameratenkonvertierung übernehmen. Vorteil gegenüber eac3to: bei BeHappy kann man auswählen, ob sich die Tonlage beim Beschleunigen/Verlangsamen einer Tonspur ändern darf, oder nicht.


    Allerdings ist die Inbetriebnahme von BeHappy nicht gerade ohne:

    • das .NET Framework 2.0 (oder höher) muss installiert sein (ab Windows Vista ist das bei Windows schon vorinstalliert... also in dem Fall kein Problem)
    • AviSynth muss installiert sein
    • dann entpackst du mein vorbereitetes BeHappy-RAR-Archiv in ein beliebiges Verzeichnis (das Passwort für's Entpacken ist das Standardpasswort von der Seite hier)
    • zuletzt holst du dir das Paket mit den Decoder-Plugins von hier (selbes Passwort) -> die kommen in den Plugins-Ordner von AviSynth (der ist üblicherweise im Installationsverzeichnis von AviSynth zu finden)


    Wenn du danach BeHappy startest, lädst du über das obere Feld (unter [1] Source) die Quell-DTS (als "Dateityp" => "NicDtsSource" wählen). Unter [3] Digital Signal Processing machst du einen Haken bei "TimeStretch ...":



    ... und klickst dann auf den Button "Configure". Im Konfigurationsfenster:



    ... kannst du nun oben die Quell- und Zielframerate angeben und ganz unten auswählen:

    • Rate, tempo and no pitch correction (= Geschwindigkeit anpassen MIT Tonlagenänderung)
    • Pitch changed preserving tempo (= Geschwindigkeit beibehalten MIT Tonlagenänderung => für Tonspuren die dank falscher Wandlung zu tief/hoch klingen und wo deshalb nur die Tonlage korrigiert werden soll)
    • Tempo changed, pitch correction (= Geschwindigkeit anpassen OHNE Tonlagenänderung)


    Zuletzt wählst du dann unter [4] Destination aus der Drop-Down-Liste ganz unten "DCAENC DTS @ 1536 kbps" aus (über die drei Punkte hinter diesem Feld gelangst du zu "Configure" und kannst dort auch alternativ 768 kbps als Bitrate einstellen) und gibst im Feld darüber deinen Zieldateinamen an.


    Nun klickst du unten rechts auf den Button "Enqueue" und der Encoding-Auftrag landet in der Warteschlange. Dort startest du die Konvertierung bzw. die Abarbeitung der Warteschlange (logischerweise ;) ) über den Button "Start".

  • lad dir eac3to und den DTS encoder von surcode... findet man per google...


    dann einfach in cmd "eac3to.exe quelldatei.dts zieldatei.dts -speedup"
    das wars schon... wenn du nicht dts haben willst, dann z.b. "eac3to.exe quelldatei.dts zieldatei.ac3 -640 -speedup" dann wird es in 640kbps AC3 encoded...


    mach keinen timestretch... ja, die tonhöhe bleibt da gleich, aber das hat sehr viel mehr artefakte, wenn du also qualität haben willst, würde ich davon abraten...


    kannst auch anstatt die englische tonspur zu re-enocden, nen slowdown auf die deutsche machen, dann bleibt die englische retail tonspur untouched... dafür einfach bei eac3to das tag "-slowdown" anstatt "-speedup" benutzen...


    und wegen der tonhöhe beim anschauen, kannste wenn du mit nem HTPC schaust immer noch reclock benutzen um die geschwindigkeit beim playback zu beeinflussen...

  • mach keinen timestretch... ja, die tonhöhe bleibt da gleich, aber das hat sehr viel mehr artefakte, wenn du also qualität haben willst, würde ich davon abraten...


    Die bleibt nur gleich, wenn man (in BeHappy) "Tempo changed, pitch correction" wählt. Bei "Rate, tempo and no pitch correction" wird hingegen einfach resampled - ähnlich wie es eac3to bei slowdown/speedup macht.


    Angeblich soll SoX 'ne extrem hochwertige Audio-Stretching-Funktion bieten:


    http://sox.sourceforge.net/


    ... was dann vermutlich auch in AviSynth über die soxfilter.dll möglich ist. Hab ich aber noch nicht ausprobiert...


    Ansonsten muss ich dir schon zustimmen: die Laufzeitkorrektur OHNE Tonlagenänderung ist die Königsdiziplin, an der auch High-End-Algorithmen teilweise hörbar scheitern (der DIRAC-Algo von WaveLab kriegt das halbwegs ordentlich hin... ist aber höllisch rechenaufwändig).


    Ich würde trotzdem vorschlagen: ausprobieren und testhören... idealerweise auch an einer Stelle mit Musik. Dann kann man immernoch entscheiden, ob es sinnvoll/notwendig ist, oder halt nicht...

  • Danke für die Tipps, aber für eine Folge ist mir der Aufwand zu hoch. Vor allem, da ja evtl. künftig mit nem Quality-Upgrade zu rechnen ist und dann ein vernünftiger DL-Rip inkl. Subs kommt. Bin von der Lovestory dieser Staffel eh nicht angetan :-(

  • Naja - das sind ein paar Klicks plus einige Zeit warten für die Umwandlung. Unter "aufwändig" verstehe ich da was GANZ anderes (z.B. das akribische manuelle Anpassen einer Tonspur ;) ).


    Aber du hast schon Recht. Vor allem ist ja nicht mal 100%ig sicher, dass die Tonspur danach wirklich perfekt passt...

  • naja, solang alle episoden das selbe format hat (gleich viele tonspuren und untertitelspuren) dann sind das 2 befehle, einen um alle tonspuren zu reencoden und einen um alle episoden mit der tonspur zu muxen.... so viel ist das auch wieder nicht ^^
    aber kanst ja warten..

  • Angeblich soll SoX 'ne extrem hochwertige Audio-Stretching-Funktion bieten:


    Nach vielen, vielen, wirklich sehr vielen Tests, blieb nur das Elastique-Timestretch Filterplugin aus Soundforge im Soloist-Mode. Das ist dann dafür aber auch "nahe an Perfektion".

    Postfächer laufen über. Lange Wartezeiten!

  • Ich hab mal einen Testdurchlauf durchgeführt. Quelle war eine FLAC mit Musik... genauer: mit dem "Blood Theme" aus der Serie "Dexter". Diese habe ich mit verschiedenen Algorithmen auf doppelte Laufzeit gestreckt, unter Beibehaltung der Tonhöhe. Die Ergebnisse:


    Ich hätte auch gerne mal den DIRAC3-Algorithmus getestet... hatte aber keine entsprechende Anwendung zur Hand.


    Testsieger meiner Meinung nach (und da schließe ich mich "smizz" an): élastique... mit etwas Abstand gefolgt von DIRAC (wobei DIRAC sogar an manchen Stellen besser zu klingen schien als élastique... dafür an vielen anderen jedoch deutlich schlechter). Allerdings arbeitet der DIRAC-Algorithmus arsch-lahm ;) . In der allerhöchsten Qualitätseinstellung hätte er an den paar Minuten Ton locker mehrere Stunden gerechnet... weshalb ich die mittlere Einstellung gewählt hatte (der DIRAC3 soll deutlich schneller arbeiten... aber den konnte ich wie gesagt nicht testen). Die élastique-Engine brauchte hingegen nur Sekunden für die Berechnung.


    Qualitativ dahinter liegt die SoundTouch-basierte TimeStretch-Umwandlung von AviSynth. Artefakte sind da schon recht deutlich hörbar, aber kein Vergleich zum Schlusslicht SoX. Keine Ahnung, ob ich da irgendwas bei der Bedienung falsch gemacht habe (oder vielleicht hätte ich noch etwas mit den zusätzlichen Parametern des tempo Kommandozeilenbefehls rumspielen sollen!?) - aber das Ergebnis ist akustisch einfach ziemlich enttäuschend. Hätte ich nicht gedacht - schließlich hatte ich einige Lobeshymnen auf die Qualität dieser SoX-Funktion im Hinterkopf.


    Bliebe nur die Frage, wie sich die Methoden bei Tonspuren mit mehr als 2 Kanälen schlagen. Da kommt nämlich als wichtiger Faktor hinzu, dass die Phasenbeziehungen der Kanäle zueinander nicht durch minimale Zeit-Abweichungen hörbar zerstört werden. Zumindest das élastique-Plugin weigert sich, mit mehr als zwei Kanälen gefüttert zu werden... laut AviSynth-Dokumentation geht das mit TimeStretch auch nicht richtig (bei mehr als zwei Kanälen werden sie als separate Mono-Kanäle behandelt... was halt die Phasenbeziehung zerstört)... und DIRAC beherrscht das wohl erst in der Pro-Version des DIRAC3-Algos. Bliebe nur SoX :whistling: ...

  • Da wir Timestretch ja lediglich verwenden um gestreckte Aufnahmen wieder auf PAL-Geschwindigkeit zu bringen, lag das Augenmerk nicht unbedingt auf der Vollerhaltung aller Beziehungen der Kanäle zueinander, da diese ohnehin schon vom Sender durchs OTF-Stretching zerstört sind.
    Wir wollten möglichst keine weiteren Artefakte auf die Stimmen draufrechnen und für den Rest eine zumindest brauchbare "Rettung" durchführen.
    Bisher gab es bei den betroffenen Serien auch später eine DVD-VÖ mit 5.1 Ton bzw. Ausstrahlungen auf anderen Sendern ohne Stretching, sodass der Kompromiss "fürs Erste" reicht.


    Allgemein ist aber Stretching eine Sache die mir ganz extrem übel aufstößt, aber es scheint sonst niemanden zu stören, wenn der Ton blechern und abgehackt klingt und vom tollen "FullHD" nur ein von Ghosting durchsetzter, matschiger Bildbrei übrig bleibt. ;)
    Sonst würden sich vielleicht mehr HD+ Abonnenten beschweren.
    (Es wirkt übrigens, meistens Stellen die Sender die Nachtwiederholung sofort wieder auf unstretched um. Aber sie verfallen immer wieder in Lethargie und senden dann auch Nachts wieder stretched. Und das mit fast bis zu 9% Verlangsamung!)

    Postfächer laufen über. Lange Wartezeiten!

  • Es gehen aber beim Stretchen von Mehr(-als-2-)kanal-Ton keine Beziehungen der Kanäle verloren, wenn der Ton über ein einfaches Erhöhen/Senken der Samplerate und anschließendes Resampling beschleunigt/gestreckt wird. Natürlich ist dabei die Tonlagenänderung unvermeidlich... aber das wird halt am häufigsten gemacht, weil das Ergebnis üblicherweise massiv besser klingt, bei gleichzeitig geringerem Rechenaufwand.


    Doch wozu sich drüber ärgern, wenn Sender sowas machen? Es gibt nämlich meines Wissens auch keinen Standard dafür, auf welche Framerate die Synchro angefertigt wird. Dass die Sender dann noch einen drauf setzen und zusätzlich mit den Geschwindigkeiten rum spielen, ist dann auch nicht weiter verwunderlich - fällt dem Otto-Normalzuschauer ja eh (meist) nicht auf ;) .

  • Klar, ich meinte kein "primitives" resample.


    Übrigens kann man abschätzen, dass ca. 99% aller Synchros von Serien die in progressiv vorliegendem Bildmaterial eingekauft wurden zur PAL Geschwindigkeit synchronisiert werden.
    Einzige mir bekannte Ausnahme einer aktuellen Serie bei der dies nicht gemacht wurde ist "Haven".
    Eine wage Vermutung ist, dass man zuerst nur eine BD-VÖ geplant hatte und die Serie erst nach der Bearbeitung in den Sendeplan übernommen wurde.
    Jedenfalls gab es dafür dann kein Timestretching, sondern eine recht passable Normwandlung.


    Richtig abstrus war es allerdings bei Law & Order Special Victims Unit S01 in der WS DVD VÖ.
    Hier wurde die PAL Synchro auf NTSC Niveau in der Tonlage abgesenkt und dann per Timestretch wieder auf PAL Geschwindigkeit gebracht.
    Das Ergebnis ist natürlich ein hässlicher Zwitter aus beiden Nachteilen der Techniken. Zu tiefe Stimmen und Stretchingartefakte. Jippie.


    Das Gefummel an der Geschwindigkeit wie du es nennst ist mir übrigens nach wie vor nur schlecht selbsterklärbar.
    Der einzige Grund der mir einfällt ist, dass durch den PAL-Speedup die Dauer der Episoden nicht mehr ins Sendeschema passt und man gezwungen wäre mehr Werbung zu zeigen als man rechtlich darf.
    Aber gibt es eine Begrenzung der Werbedauer? Man sollte doch eher froh sein, dass man einen kurzen Werbeblock mehr einbauen kann.
    Man könnte dann sogar die Werbeblöcke der Produktion übernehmen, anstatt einfach irgendwo mitten rein zu schneiden wie es oft passiert.


    Die Struktur der Episoden ist nämlich durchaus bewusst gewählt, und die Kapitelblenden, die in den USA für die Werbung benutzt werden, sind vom Spannungsbogen drauf abgezielt, dass der Zuschauer nicht umschaltet.


    Naja ich werde vermutlich nie ganz durchblicken, warum deutsche Free-TV-Sender so agieren wie sie agieren.
    Das reicht von der, in meinen Augen, sinnlosen und kontraproduktiven Ausstrahlung von Halbstaffeln und anschließenden wahlfreien Wiederholungen bei Serien mit rotem Faden (Dr. House), bis zu maßlosem Einsatz von DRC in AC3-Tonspuren die ihren eigenen DRC-Wert auf Framebasis mitbringen sollten, welche aber in Bezug zur Werbung gesetzt wird, sprich, nach der Werbepause ist die Dynamik zunächst vollwertig, da die extrem laute Werbung die DRC-Verstärkung auf null drückt, und entlang des nächsten Abschnitts steigt die DRC dann auf astromische Werte (bis zu 6 dB und mehr), aber natürlich immer per Hardlimiter auf -6 dB limitiert, damit man zum Auspegeln der Werbung noch schön viel Platz nach oben hat.


    Aber das sind Nickeligkeiten mit denen man irgendwie zu leben gelernt hat als TV-Dubber ;)

    Postfächer laufen über. Lange Wartezeiten!