Beiträge von TomKeller

    Zitat von henderson;241287

    Bei unterschiedlichen Samplingraten verweigert VirtualDub konsequent die Arbeit, insofern ist der Lovecraft's Tip überaus brauchbar.


    Du meinst bestimmt Bitraten. Samplingraten sind die mit den Kilohertz-Angaben (sprich: 44,1kHz Samplingrate bei Audio-CDs... oder 48kHz Samplingrate beim Ton auf DVD... usw.).


    Bei unterschiedlichen CBR-Bitraten (und auch Samplingraten) mag das mit VirtualDub stimmen - ganz klar: dann wird das Zusammenfügen unmöglich. Nicht nur mit VirtualDub! Auch mit anderen Tools sollte man das (selbst wenn die's zulassen) nicht machen! Bestenfalls hat man dann nämlich ab dem Schnitt keinen Ton mehr... schlimmstenfalls wird er ab da asynchron (da evtl. die "neue" Bitrate falsch interpretiert wird).


    Bei VBR-Bitraten schwankt aber die Bitrate allgemein immer (mal mehr mal weniger) stark im Laufe einer Tonspur. Trotzdem hat VirtualDub (wie schon erwähnt) kein Problem damit, zwei Teile mit VBR-Ton zusammenzufügen, die irgendwann vorher auch mit VirtualDub(Mod) getrennt wurden. Probleme gibt's nur, wenn die beiden Teile separat mit VBR-Ton gedubbed wurden (sprich: Film auf US-DVD => Rip als 1400MB AVI => gesplittet in 2x700MB AVI => deutscher Line-Ton an erste AVI angepaßt in VBR-MP3 encodet und druntergelegt + deutscher Line-Ton an zweite AVI angepaßt in VBR-MP3 encodet und druntergelegt). Dann beschwert sich VirtualDub grundsätzlich über unterschiedliche Bitraten und verweigert das Zusammenfügen!


    Da aber, wie gesagt, die Bitrate bei VBR-Ton immer schwankt, kann man solche Problemfälle trotzdem fehlerfrei zusammenfügen - komplett ohne Reencoding (zumindest, solange nur die Durchschnittsbitrate unterschiedlich ist und nichts anderes)! Nur geht das eben nicht mit VirtualDub.

    Zur Anleitung fallen mir 3 Sachen ein, die sie (sorry... nicht bös gemeint) überflüssig machen:

    • Aktuelle VirtualDub-Versionen können auch mit VBR-Ton umgehen. Die VBR-Meldung und die "Kaputt-Korrektur" von VBR-Ton kann man in den Options => Preferences => AVI abstellen (Haken setzen bei Disable auto-correction of data rate... und Haken entfernen bei Warn when VBR audio is detected)!
    • Es gibt nicht immer Probleme in VirtualDub(Mod) beim Zusammenfügen von AVIs mit VBR Ton. Werden nämlich zwei VBR-AVI-Teile zusammengefügt, die ursprünglich auch mal zusammenhingen, gibt's grundsätzlich KEINE Fehlermeldung von VirtualDub(Mod) und auch keine Probleme beim Zusammenfügen!
    • Dateien mit der Cannot-append-segment-Fehlermeldung wurden meist nachträglich separat gedubbed, was zu eben diesem Problem beim Zusammenfügen führt. Man muss allerdings nicht den Ton gezwungenermaßen mit konstanter Bitrate reencoden. Man kann die Dateien auch einfach zusammenfügen - solange man nicht auf VirtualDub besteht. Ein Tool, was das hinkriegt, ist AVI-Mux GUI. Einfach dort beide Dateien nacheinander in das obere Feld ziehen, beide markieren, auf "Datenquelle aus Quelldateien generieren" klicken und per "Start" eine neue Datei erstellen.
      Empfehlenswerter ist hingegen Avidemux (der Installer mit GTK+ Interface liefert auch eine deutschsprachige Oberfläche mit). Bei AVI-Mux GUI kann es nämlich ab der Schnittstelle zu einem Zeitversatz zwischen Bild und Ton kommen, wenn die Tonspur der ersten Datei kürzer war als deren Videospur - mit Avidemux passiert das NICHT. Die Bedienung ist ähnlich wie bei VirtualDub: man öffnet die erste AVI, und "klebt" die zweite über Datei => Anhängen dran. Links Video und Audio auf Kopie stellen (das ist das Avidemux-Pendant zu DirectStream copy), Format auf AVI stellen und über Speichern eine neue Datei erstellen (dabei auch die Dateiendung *.avi im Dialogfeld angeben).
      Das erspart einem das Umwandeln der Tonspur und den damit verbundenen Zeit- und Qualitätsverlust!

    YAMB in der neuesten Version scheint tatsächlich beim Joinen die Dateien nicht aneinander zu "kleben", sondern alle Tracks (Video und Audio) parallel zu muxen. Mal die ältere(n) Version(en) ausprobieren (es ging nämlich früher definitiv damit)... oder MP4box per Kommandozeile benutzen und die Dateien über:


    Code
    1. "C:\Pfad_zur\mp4box.exe" "C:\Pfad_zur\Quelldatei_Nr1.mp4" -cat "C:\Pfad_zur\Quelldatei_Nr2.mp4" -out "C:\Pfad_zur\Zieldatei.mp4"


    ... zusammenfügen!

    Zitat von cathy888;240742

    Und es wäre gut zu wissen, wo der Grund für den Fehler liegt, damit ich in Zukunft nix brenne, was nachher nicht läuft.
    Wie gesagt, es wurden alle Files unter den selben Umständen und mit den gleichen Programmen bearbeitet. Entpacken klappte ja auch anstandslos. Größe stimmt.


    Wenn das Entpacken fehlerfrei klappt, gibt's eigentlich nur zwei mögliche Fehlerquellen:

    • Derjenige, der die Datei gepackt und angeboten hat, hat schon eine defekte Datei als Quelle genommen!
    • Der Datenträger, auf den du das entpackst (Festplatte?), hat Fehler.


    Zitat von cathy888;240742

    Müsste man alles am besten erstmal durch VDM laufen lassen??


    Wäre zu empfehlen.

    Ich hab die Demo gespielt und muss sagen: wirklich klasse! 'Ne super Mischung aus den besten Elementen aller Batman-Comics, -Filme und -Animationsserien. Die Grundstimmung ist düster und die Story ausgefeilt und erwachsen - beides keine Selbstverständlichkeit bei Game-Umsetzungen von Comics. Die Game-Engine ist (wenn auch nicht ganz so aktuell) leistungsfähig genug, um eine sehr schöne Optik auf den Bildschirm zu zaubern - aber gleichzeitig moderat genug bei den Hardwareanforderungen, um z.B. in der PC-Fassung auch auf nicht so schnellen Maschinen in hoher Qualität ruckelfrei zu laufen.


    Über die Lokalisation kann man jetzt streiten! Ich persönlich hätte Christian Bales dt. Stammsprecher David Nathan nicht auf diesen gealterten Schrank von Batman besetzt - er klingt dafür deutlich zu jung (auch wenn er sich Mühe gibt). Im Original hört man ja (wie schon in der wunderschönen 90er Jahre Batman-Animationsserie) wieder Kevin Conroy und Mark "don't-call-me-Luke-Skywalker" Hamill auf Batman und Joker. Mir hätten daher die dt. Synchronsprecher der Serie wesentlich besser gefallen - aber: naja, man kann nicht alles haben (wahrscheinlich sind die auch schon etwas zu alt und haben sich aus der Synchronbranche zurückgezogen). Trotzdem ist positiv anzumerken, dass durch die Bank weg professionelle dt. Sprecher besetzt wurden, die ihre Sache gut bis sehr gut machen. Auch das ist nicht alltäglich - viele erinnern sich bestimmt aus dem Stegreif an Game-Synchronisationen, wo die Sprecher klangen, als ob man schnell mal alle Schreibtischkräfte, Azubis und Praktikanten in's Tonstudio geschleift hätte :eek: ...


    Alles in allem bin ich hellauf begeistert. Das Game ist vorbestellt (was eine Seltenheit ist bei mir) und ich fiebere dem Release schon entgegen...

    Meinst du diese 5 Dateien (?):



    Das ist der Quellcode - denn benötigst du nur, wenn du Programmierer bist und dich über die Funktionsweise der soundtouch.dll informieren bzw. sie modifizieren willst ;) .


    Wenn du SoundTouch nur benutzen willst, benötigst du einzig und allein die soundtouch.dll (zusätzlich zu BeSweet, natürlich)! Nimm die letzte Beta von hier - da ist die DLL schon dabei.

    Die Meldung deutet auf eine defekte Datei hin. Warum, weshalb - keine Ahnung! Ich hab ebenfalls keine Ahnung, warum du keine Abspielprobleme damit hast. Je nach MediaSplitter bzw. Player wird teilweise die Reparatur temporär (praktisch on-the-fly) beim Wiedergabestart erledigt - könnte bei dir der Fall sein.


    VirtualDub(Mod) versucht die Datei (soweit wie möglich) zu rekonstruieren. Wenn die Tonspur dieser rekonstruierten Datei zu klein ausfällt, konnte die Datei wohl nicht vollständig rekonstruiert werden.


    Du könntest versuchen, die Datei vor dem Demuxen hiermit zu reparieren - ist so ziemlich das beste Tool, was ich dafür kenne: schnell, effizient und simpel. Aber erhoff dir nicht zu viel: wenn VirtualDubMod die Datei nicht komplett reparieren kann, wird es dieses Tool auch nicht können. Bestenfalls fehlt nach der Reparatur damit aber nicht ganz so viel vom Ton, wie mit VirtualDubMod...

    Wenn das ein MPEG2-Videostream ist, sollte das eigentlich gehen. Es gab früher schließlich auch diverse MPEG2-VfW-Codecs, mit denen man AVIs mit MPEG2-Video erzeugen konnte... und mit ffdshow-VfW existiert gewissermaßen immernoch so ein Codec!


    Das Muxen eines M2V-MPEG2-Videostreams in einen AVI-Container könnte mit Avidemux klappen - probier's mal aus.


    Die Frage ist aber: warum das ganze? MPEG2 in AVI macht am PC keinen Sinn (da kann man genausogut den MPG-Container nutzen) und dürfte auf kaum einem Hardware-Player laufen :confused: ...

    Ja und... äh... ja :p ! Ja... ein (der!) Haupt-Handlungsstrang wird abgeschlossen. Allerdings war die Serie ja auf 3 Staffeln ausgelegt - daher werden neue Fragen aufgeworfen, die durch das Fehlen von Staffel 3 leider nie aufgelöst wurden.


    Jedoch beantworteten die Produzenten und vor allem der Schöpfer der Serie, Daniel Knauf, der Fangemeinde die wichtigsten dieser Fragen. So wurden umfangreiche Informationen über die Naturgesetzte, auf denen die Serie beruht, zur Verfügung gestellt... ebenso wie das sogenannte "Pitch Document" (eine Zusammenfassung der ersten Staffel - gedacht für die Autoren der Serie und das Studio - welche Informationen zu allen Charakteren und deren Hintergründen liefert, sowie viele Geheimnisse der Serie erläutert).


    Ich kann die Serie empfehlen - sie hat allerdings teilweise ihre Längen. Aber Mystery-Fans kommen definitiv auf ihre Kosten. Mir sind nach dem Ansehen der beiden Staffeln allerdings einige Zusammenhänge auch erst durch das ergänzende Lesen der genannten Zusatzinformationsquellen klar geworden (z.B. - ohne jetzt allzu stark zu spoilern - die Bedeutung des Satzes auf dem Spiegel).

    Stimmt schon (siehe auch: viel nackte Haut in "Californication", "Six Feet Under" & "Carnivàle"... sowie ein klein wenig in "Dexter" & "Rescue Me" ;) ). Der finanzielle Rückhalt seitens des Senders ist natürlich auch viel größer (siehe: das 4 Mio. Dollar Budget pro Folge von "Carnivàle", das aufwändige Kostüme und Settings sowie unzählige hervorragende Darsteller und Statisten erlaubte).


    Trotzdem scheinen es vor allem diese Sender zu sein, die viel lieber auf eine Serie mit Anti-Helden setzen - und dass kann eigentlich nicht gezwungenermaßen an der erlaubten Freizügigkeit oder dem größeren möglichen Budget liegen. Siehe "Breaking Bad": der produzierende Sender AMC ist kein PayTV-Kanal und vergleichsweise klein - traut sich aber trotzdem, ein ungewöhnliches Anti-Helden-Szenario umzusetzen. Es geht also... wenn sich nur mal mehr das gleiche trauen würden! Denn damit ist viel mehr möglich, als mit den bekannten (oft schon ausgelutschten) Konzepten...

    Und?! Allein das dürfte nicht gezwungenermaßen bedeuten, dass seitens des Senders ein großes Interesse an ausgefallenen Ideen bestehen muss! So eine Risikobereitschaft ist nämlich (auch unter PayTV-Sendern) nicht gerade weit verbreitet (siehe Premiere/Sky :p )!

    Was vielleicht noch in eine ähnliche Kerbe schlägt, wäre "Rescue Me" - das bietet einen bitterbösen, teilweise extrem zynischen Humor (wie ja "Breaking Bad" ebenfalls). Und eventuell noch die Serie, durch die Dexter-Darsteller Michael C. Hall hierzulande fernsehbekannt wurde: "Six Feet Under"! Auch da: sehr viel schwarzer Humor, sowie unkonventionelle Charaktere und Handlungen - allerdings auch drama-lastiger als die bisher genannten Serien!


    Ach ja - auch sehr zynisch, witzig und extrem gut gespielt: "Californication"! 'Nem Kumpel von mir hab ich diese Serie mal als "das 'Sex And The City' für Männer" beschrieben - das trifft's eigentlich ziemlich gut :p .


    Überhaupt lohnt sich mal ein Blick auf die von Showtime und HBO produzierten Serien. Die setzen offenbar sehr gerne extrem unkonventionelle Konzepte um (wie halt "Dexter", "Californication", oder auch "Dead Like Me"... bzw. "Six Feet Under", "Carnivàle", und auch "True Blood").

    Zitat von Jack;234076

    Bei VHS lassen sich ca. 200 Luma-Zeilen eindeutig voneinander unterscheiden, und eine Zeile kann ca. 160 Helligkeitspegelwechsel haben, ergo maximal mit 320 Pixeln abgetastet werden.


    Gut...


    Zitat von Jack;234076

    Der verlinkte Artikel ist übrigens sehr vereinfachend und berücksichtigt einige Details nicht, die wichtig wären zum Verständnis der Leistungsfähigkeit von VHS.


    ... dann erkläre mir bitte, wie du von 200 Zeilen a 160 Pegelwechsel auf deine maximal 320 Pixel kommst (wo doch Zeilen und Helligkeitspegelwechsel nichts mit Pixeln zu tun haben)... oder mehr noch: wie du so zielsicher auf 288 Pixel vertikale Auflösung kommst (wobei deine Vorgabe mit 320x288 ja sogar die in den VCD-Specs vorgegebene PAL-Auflösung unterbietet). Würde mich halt interessieren - da ich mir (allerdings nur basierend auf praktischer Erfahrung und nicht unbedingt technischem Grundlagenwissen) nicht wirklich vorstellen kann, dass mit dieser Auflösung eine qualitativ ebenbürtige Digitalisierung einer VHS-Kassette erzielt wird, wie z.B. mit einer Zielauflösung von 704x576.


    Erklär's mir bitte (aber möglichst simpel - denn meine chronischen Nackenschmerzen und meine momentane Erkältung allein, führen schon zu höllischen Kopfschmerzen :p ) - denn ich bin ja auch nur Laie. Bislang hab ich keinen Grund gehabt, den Ausführungen im Gleitz-Forums zu misstrauen, da sich da ja viele Leute als Mods und Admins rumtreiben, die beruflich mit Fernsehtechnik bzw. dem Digitalisieren von analogen Medien zu tun haben...

    Zitat von Jack;234041

    Durch die vielen analogen Kompressionsverfahren die VHS einsetzt, liegt die reale Information irgendwo in der Gegend von 320x288.


    Dem muss ich klar widersprechen. Man kann bei analogem Video (wie eben bei VHS als Quelle) nicht von pixelbasierten Auflösungen sprechen, da es sowas in der analogen Welt nicht gibt - siehe hier:

    Zitat von Kika

    Und daher kommt auch das Gerücht, eine VCD hätte die gleiche oder gar eine höhere Auflösung wie VHS. Das ist aber falsch. Warum, das werde ich nun versuchen zu erklären.
    Wir reden, wenn VHS gemeint ist, von analogem Video. Dabei muss man sich zuerst von der Vorstellung von Pixeln trennen, die gibt's da nicht. Entscheidend ist nur das Signaltiming.


    Dementsprechend schwieriger gestaltet sich die Digitalisierung von analogem Quellmaterial (bei möglichst geringem Qualitätsverlust):

    Zitat von Kika

    Um das VHS-Signal also nahezu verlustfrei aufnehmen und wiedergeben zu können, müsste man eigentlich mindestens doppelt so viele Pixel aufnehmen wie das Grundsignal Linien hat. Bei VHS also 480x576. Da aber die Farbauflösung niedriger ist, kommt man mit 352x576 als Endformat sehr gut zurecht. Als Tipp sollte aber gelten, grundsätzlich mit 704x576 aufzunehmen.


    Siehe auch hier:

    Zitat von Gleitz

    Da wir ein analoges Signal haben und kein klar umrissenes digitale Signal, wurde der Begriff Linie eingeführt. Eine Linie beschreibt den zeitlichen Durchlauf, bis eine Sinuskurve einen vollständigen Phasenwechsel vollzogen hat.
    Die Frequenz mit der VHS oder auch Composite arbeiten liegt zwischen 220 und 250 Phasenwechsel oder Linien.


    Um von einer VHS verlustarm aufzunehmen, sollte man mit mindesten der doppelten Anzahl von Pixel wie Linien aufzeichnen, was einer Auflösung von 480x576 px entspricht. Da aber das Farbsignal eine niedrigeres Grundsignal hat, würde eigentlich 352x576 px ausreichen.


    Ist die Signalfrequenz höher wie bei einem S-VHS- (bis zu 440 Linien) oder RGB-Signal (bis zu 550 Linien), dann reicht das nicht mehr. Durch die höhere Signalfrequenz, oder mehr Linien pro Zeile, werden die Linien nicht nur schmäler, sondern das Bild wird auch detaillierter gezeichnet. In diesem Fall sollte mit 704x576 px aufgezeichnet werden.

    Man sollte vielleicht mal (auch von Seiten ATIs) auf Folgendes hinweisen:

    • Die Grafikkarten mit "HD" im Namen können zwar die Decodierung von H.264-Videos in HD-Auflösung übernehmen... allerdings nur, wenn die Videos mit bestimmten Einstellungen encodet wurden (= nicht höher als Level 4.1 / nicht mit mehr als 3 aufeinanderfolgenden B-Frames / nicht mit mehr als 4 Reference Frames). Trifft man auf ein Video, das diese Vorgaben nicht einhält, muss die CPU das Decodieren übernehmen - und ist die CPU recht langsam, kann das in "Ruckelorgien" ausarten.
    • Man benötigt einen speziellen Decoder, der diese Hardwarebeschleunigungs-Fähigkeiten der Grafikkarte nutzen kann. Meist wird dabei DXVA als Schnittstelle genutzt. Decoder mit DXVA-Unterstützung gibt's z.B. von CyberLink (unter anderem in PowerDVD enthalten), von Corel (in WinDVD enthalten) oder ArcSoft (in TotalMedia Theatre enthalten). Freeware-Decoder mit DXVA-Unterstützung gibt's hingegen kaum - der einzige mir bekannte wäre der im Media Player Classic - HomeCinema von "casimir666"!
    • Wer grundsätzlich so wenig Probleme wie möglich beim Playback haben möchte, der sollte daher eine Kombination aus sehr schnellem Software-Decoder (für die Fälle, wo die CPU die Decodierung übernimmt) und gutem DXVA-tauglichen Decoder installieren. Ein schneller Software-Decoder für H.264-Videos wäre z.B. CoreAVC... DivX7 soll aber auch recht flink sein! Beim Decoder mit DXVA-Unterstützung kann man den kostenlosen aus dem MPC-HC nehmen (den gibt's auch separat), oder halt einen der kostenpflichtigen - der kostenlose bietet sich aber an, da man ihn so einrichten kann, dass er wirklich nur dann genutzt wird, wenn das Video wirklich DXVA-kompatibel ist.

    Stimmt auch wieder. Aber... hmmm... "wesentlich schneller"? Kommt mir nicht unbedingt schneller vor als mit BeSweet :confused: ! Du benutzt aber schon Timestretch (ich wüßte jetzt zumindest keine andere AviSynth-Funktion, die Soundtouch nutzt) und verfütterst dann den Output von WAVI direkt an Aften, oder?


    Ich muss aber dazu sagen: ich bin mit dem Output von geschwindigkeitsangepaßten 5.1 AC3s ohne Tonlagenänderung nie so ganz zufrieden. Vor allem bei Musik hört man, dass die Kanäle immer mal wieder um 1 (vielleicht 2) Millisekunden auseinanderdriften und sich dann wieder fangen. Das ist aber algorithmenbedingt und im Heimbereich praktisch unvermeidbar. Ich meine: nicht umsonst wird selbst im professionellen Bereich (wie eben dem DVD-Mastering) bei der Wandlung Film=>PAL meist auf die Audioanpassung mit Tonlagenänderung zurückgegriffen...