forum von fan-sub.de

So, während für unseren Fansub die Qualikontrolle läuft, spiele ich mit Virtualdub rum.
Zum Problem: Ausgangsdatei: Folge.avi, 270 MB, divx-video codec, audio PCM , 119,875 Bilder pro Sekunde, Format 1280x720

Wenn ich es mit xvieo auf 640x360(mit resize) verkleinere und Audio codiere habe ich das Problem, das mein Bild entweder stockt oder flimmert als würden sich 2 Bilder überlappen. Manuell auf 25fps zu reduzieren brachte nur schwarzes Video(wohl nur die leeren Bilder genommen^^)
Anleitung zum xvid-codec habe ich jetzt schon genug gelesen, wobei ich mich im allgemeinen an diese Anleitung halte: http://www.cs-erweiterungen.de/tutorials.php?site=48 (Spiele es nicht, die Anleitung ist aber 1000 mal besser als was sich sonst im Netz gefunden habe.)
gewünschte Größe: 230 bis 250 MB. (Hier ist es nicht so schlimm aber die RAWS werden bis zu 470 MB groß)
Falls Bedarf besteht lade ich auch meine Xvid-Einstellungen mal als Bilder hoch, jedoch nicht mehr heute, sondern morgen.
Ich hoffe ihr könnt mir weiterhelfen. Falls irgendjemand auch Anleitungen für h264 Hardsubs findet, immer her damit, sonst werden wohl VLC media Player Anhänger in die Röhre schauen.^^ (Softsub mit Nero 7 und mkvmerge)

25fps scheinen mir die falsche Idee zu sein: 119.875fps sind 5 * 23.975fps; mit "decimate by 5" in VirtualDub würdest Du also die übliche Framerate von 23.976fps ziemlich genau treffen (während 119.875fps zumindest für meinen Standalone-Player ungenießbar sind und wahrscheinlich auch noch Platzverschwendung).
Eine intelligentere Decimate-Funktion (tdecimate aus dem TIVTC-Paket?) würde wahrscheinlich bessere Qualität liefern (d. h. weniger Ruckeln), dafür müsstest Du Deine Raw aber durch ein AviSynth-Skript laufen lassen, bevor Du das eigentliche Encoding darauf anwendest.

Resizen um Faktor 4 in der Fläche dürfte dünne Linien stark beschädigen; um dies gegenzubalancieren würde ich LanczosResize verwenden (das sollte VirtualDub aus Bordmittel unterstützen, notfalls eben auch wieder via AviSynth).
Spricht etwas gegen eine Verkleinerung auf 704x400px? Standalone-Player können bis zu 720px pro Zeile abspielen, Du musst nicht ohne Not kleinere Bilder erzeugen.

PCM-Audio ist natürlich erst recht Platzverschwendung; MP3/CBR mit 128kb/s wird in den meisten Fällen für einen Anime-Fansub ausreichen, finde ich. Das wären dann ca. 22 MB für die Tonspur von 24 min einer Anime-Episode. Bei 230-250 MB erwünschter Dateigröße blieben 208-228 MB für den Videostream übrig, das wären laut XviD-Taschenrechner 1084-1196kb/sec, die Du mit XviD-2pass-Encoding dann auch ziemlich genau treffen könntest, falls Du wirklich genau gleich viel Dateigröße pro Episode haben willst (und nicht unterschiedlich große Episoden bei unterschiedlich viel Bewegung, was immerhin auch eine denkbare Strategie wäre).

Ich rate dazu, die Gesamtzahl der Episoden des Projekts zu berücksichtigen. Es wäre nämlich schon irgendwie ärgerlich, wenn die Serie beispielsweise 24 Episoden hätte und dann wegen der Dateigröße nur 19 davon auf eine DVD gebrannt werden könnten (4483 MB pro DVD bzw. 703 MB pro CD geteilt durch Episodenzahl oder bei einer kürzeren Serie eventuell die Hälfte davon, natürlich unter Berücksichtignug sämtlicher Specials, wäre eine Dateigröße, die ich zumindest mal als denkbaren Kandidat im Auge behalten würde - das tun leider zu wenige Encoder).
Bei einer kurzen Serie mit durch 3 teilbarer Episodenzahl wäre in Deinem Fall also exakt 244 MB eine Dateigröße, die manchem Fan sympathisch erscheinen könnte (3 Episoden pro CD - ich selbst brenne allerdings nur noch DVDs); bei durch 4 teilbarer Episodenzahl wären 175.5 MB eine interessante Dateigröße (Deine Raws sind gegenüber DVD-ISOs eh vergleichsweise schlecht, weil für diese enorme Fläche und Frames-Rate zu klein - da kannst Du ein Nicht-HD-Video durchaus auf deutlich unter 200 MB encoden, ohne damit etwas Wesentliches kaputt zu machen).

Eigentlich hättest Du diese ganzen Vorarbeiten schon vor Beginn des Projekts machen müssen. Timer und Typesetter können nämlich nicht sinnvoll auf ein 119.875fps-PseudoRaw timen, wenn Du anschließend beim Release-Encoding auf ein 23.976fps-Raw umstellst - mach Dich darauf gefasst, dass ihr das gesamte Timing nochmal überarbeiten müsst, weil die Szenenschnitte gelegentlich um 1 Frame daneben liegen werden, und das sieht einfach schrecklich aus.
Überhaupt hat ein 119.875fps-Raw eine Frame-Einblendungsdauer von weniger als 0.01sec, was jedoch die Zeitauflösungsgrenze von ASS-Skripten ist. Framesgenaues Timing ist deshalb mit solchen Raws nicht zuverlässig möglich! Eigentlich hätte sich der Timer über Dein Raw-Material beschweren müssen, mit dem man gar nicht sinnvoll arbeiten kann. (Ich habe exakt dasselbe Problem auch schon mal gehabt und der Timer durfte kurz vor dem Release eine Menge Überstunden schieben...)

OK versuche es nochmal, bin gespannt was nach der Uni raus gekommen ist.

Mal auf die mittlerweile typischen 120fps VFR zu kommen (Variable Frame Rate)...

Wie der AVI Hack genau funktioniert habe ich mich nicht mit beschäftigt. Das Prinzip ist aber recht einfach. Normalerweise werden bei Animes das Opening und das Ending bei 29,97fps und der Teil dazwischen bei 23,976fps gespeichert ...

Vorteil: Flüssiges Bild beim Opening und Ending (oft sehr gut zu erkennen wenn die Credits durchs Bild fahren)
Nachteil: SAP-Fähigkeit = 0 und sonst auch nicht wirklich empfehlenswert für den endverbrauch ...

Bei MKV wiederum ist es rech einfach, da gibt es entsprechende Tools für (mkv2vfr z.B.) mit dem man ne Textdatei erzeugen kann in der drinsteht welche Bereiche (in Frames angegeben) mit wieviel FPS abgespielt werden.

Bei AVIs sieht das ganze schon wieder bescheuerter aus... Ohne sich da tiefer in die Materie einzuarbeiten hilft nur ein Decimate oder convertfps=true bei Directshowsource im AviSynth (Aikousha meint letzteres erzeugt blends, ist mir persönlich noch nie wirklich aufgefallen :\).
Allerdings weiß ich gerade nicht ob man einfach den mpeg4-raw stream in eine MKV speichern kann um dann mkv2vfr anzuwenden ...

es handelt sich dabei ja nicht um VFR sondern ganz stupide wurde alles auf 120fps aufgebläht, da es der kleinste gemeinsame der beiden framerates von OP/ED und Episode ist. würde da also entweder OP/ED und Epi verschieden behandeln und dann per MKV einfachen zusammenfügen oder wenn man auf kosten von stockenden scrollings in OP/ED arbeiten will halt nen "decimate by 5, wie DD schon sagte.

So danke erstmal für die Antworten, das decimate 5 hat nicht nur die encodezeit von 1,5 Stunden auf 20 Minuten reduziert sondern liefert auch ein kleineres File und dies mit Singlepass. Also werde ich wohl auf evtl 175MB/Folge runtergehen können und die Auflösung anheben. Das mit dem einen Frame pro Sekunde wäre ehrlich gesagt noch verkraftbar(bei rund 24 frames pro Sekunde ist das im einstelligen Prozentbereich einer Sekunde. Es verschiebt jedoch teilweise um bis zu drei Sekunden??? Während anders herum die Episodentitel korrekt angezeigt werden. Auch die Länge de Videos ist gleichgeblieben.

Zum Thema timen:
Kurze Voranmerkung: RAW und Engsub sind bis auf die Milisekunde gleich, was die Zeiten angeht.
Wurde auf Mp4 und Engsub gemacht(weil wie gesagt, es bei der RAW im Ton ganz schrecklich gehangen hat). Das Video konnte aber korrekt mit Aegisub wiedergegeben werden. Meine Idee wäre jetzt einfach ohne UT zu codieren und den dann nochmal drauf zulegen. Geht dies als Hardsub ohne Qualiverluste? Oder zweite Idee: erstmal nur die FPS ändern und dann später beim Umstieg von divx auf xvid wieder Untertitel reinbrennen. (Zeitaufwand für das encoden relativ egal, nur sollte es nicht wieder zig Stunden Einarbeitung kosten). Außerdem habe ich nicht vor die ersten fünf Folgen nochmal zu timen(zumindest bis jetzt nicht).

ZUM Thema DVD: gibt es leider noch nicht, da die Serie erst im TV kam, selbst die Engsubber sind m.E. noch nicht fertig.(Fehlen noch 2 folgen)


...(und nicht unterschiedlich große Episoden bei unterschiedlich viel Bewegung, was immerhin auch eine denkbare Strategie wäre).... machen das xvid nicht zum Teil automatisch?

...Bei 230-250 MB erwünschter Dateigröße blieben 208-228 MB für den Videostream übrig, das wären laut XviD-Taschenrechner 1084-1196kb/sec,...
erstaunlicherweise sind es 1268kb/sec trotz 160kb/s Lame mp3 (und nur 193 MB gesamt jetzt)

...Animes das Opening und das Ending bei 29,97fps und der Teil dazwischen bei 23,976fps gespeichert ...
kann man das nicht als Zonen definieren und mittendrin die Framerate wechseln(bei 2 Schnitten im Vid wär dies verkraftbar)

...SAP-Fähigkeit = 0... Tut mir leid, kenne den Begriff nicht.

...P/ED und Epi verschieden behandeln und dann per MKV einfachen zusammenfügen ... Drei Files nacher zu einem zusammenpappen? Geht das?


Meine Gedanken jetzt dazu: - Avisynth-anleitungen suchen und framerate ändern.
- auf weitere nette Vorschläge von euch warten.
- komplett auf Softsub umzusteigen
-
Habe leider keine zeit mehr um es näher zu erläutern(da was ganz wichtiges passiert ist)
Aber ich habe meine
decimate 5 singlepass avi (640*360, 23,98 fps, 191 MB mit xvid und Lame) zusammen mit meiner Nero7 mp4(720*576, 25fps, nero digital avc, mit aac musik, ohne UT) gemuxt. (Wollte eigentlich nur testen ob ich mit mkvmerge zwei Dateien zu einer machen kann).
Ergebnis: mkv mit Untertitel und annehmbarer Quali nur ist sie jetzt wieder 207 MB groß. Für alle die sich jetzt fragen, wie blöd man sei kann so was zu tun, dem muss ich ehrlich gesagt recht geben.
Edit2: nur die singlepass zu Mkv zu machen bringt es nicht(sieht extrem schlimm aus aber die Timings stimmen dann wieder.

ZweiPi wrote:So danke erstmal für die Antworten, das decimate 5 hat nicht nur die encodezeit von 1,5 Stunden auf 20 Minuten reduziert sondern liefert auch ein kleineres File und dies mit Singlepass. Also werde ich wohl auf evtl 175MB/Folge runtergehen können und die Auflösung anheben. Das mit dem einen Frame pro Sekunde wäre ehrlich gesagt noch verkraftbar(bei rund 24 frames pro Sekunde ist das im einstelligen Prozentbereich einer Sekunde. Es verschiebt jedoch teilweise um bis zu drei Sekunden??? Während anders herum die Episodentitel korrekt angezeigt werden. Auch die Länge de Videos ist gleichgeblieben.

Was meinst Du mit "es", und was genau hast Du getan, um in diesen Zustand zu kommen? 23.976fps sind nicht 24 fps, sondern eben 0.1% weniger - und das sind bei 24*60 Sekunden einer Episode exakt 1.44 Sekunden Differenz, wenn Du die Anzahl der Frames nicht änderst. Damit würde sich das Timing spürbar verschieben.

ZweiPi wrote:Meine Idee wäre jetzt einfach ohne UT zu codieren und den dann nochmal drauf zulegen. Geht dies als Hardsub ohne Qualiverluste?

Jeder Encoding-Durchgang mit XviD ist verlustbehaftet. Du könntest das Video unkomprimiert encoden (dann wird es als Datei ca. 20 GB groß) und anschließend die Untertitel drüber legen und XviD-encoden, wenn Dir das irgendwas bringen sollte.

ZweiPi wrote:ZUM Thema DVD: gibt es leider noch nicht, da die Serie erst im TV kam, selbst die Engsubber sind m.E. noch nicht fertig.(Fehlen noch 2 folgen)

Denke Dir an dieser Stelle einen beliebig bösen Kommentar von mir über Leute, die eine Serie übersetzen, von der sie nicht mal das Ende kennen, und das auf der Basis eines EngSubs von Leuten, die das Ende ebenfalls nicht kannten.
Ich meinte aber keine kommerzielle DVD, sondern eine selbst gebrannte - ich kann ja nicht meine gesamte Anime-Sammlung auf meiner Festplatte halten, so groß ist die bei meinem alten PC eben nicht. Und aus logistischen Gründen (Beschriftung der Scheibe und ihrer Hülle im Regal) wäre mir 1 Serie == 1 DVD sympathisch. (Im Zweifelsfalle brenne ich noch den EngSub mit drauf, wenn Platz dafür übrig ist... meistens muss ich mir ja eh den ansehen, wenn ich die Handlung verstehen will.)

ZweiPi wrote:...(und nicht unterschiedlich große Episoden bei unterschiedlich viel Bewegung, was immerhin auch eine denkbare Strategie wäre).... machen das xvid nicht zum Teil automatisch?

Theoretisch ja - wenn Du XviD machen lässt (also beispielsweise eine Bitrate von 9999kb/sec angibst). Dann aber kannst Du nicht mehr auf eine konkrete Dateigröße zielen. (Die Größe beeinflussen kannst Du dann schon noch durch Änderungen bestimmter XviD-Parameter, aber eben nicht mehr sehr zielgenau.)

ZweiPi wrote:erstaunlicherweise sind es 1268kb/sec trotz 160kb/s Lame mp3 (und nur 193 MB gesamt jetzt)

Ich habe die Episodenlänge ja nur geschätzt - wenn sie kürzer ist, bekommst Du mehr Bandbreite pro Dateigröße hin.

ZweiPi wrote:...Animes das Opening und das Ending bei 29,97fps und der Teil dazwischen bei 23,976fps gespeichert ... kann man das nicht als Zonen definieren und mittendrin die Framerate wechseln(bei 2 Schnitten im Vid wär dies verkraftbar)

In AVI-Container nicht, in MKV-Containern schon.

ZweiPi wrote:...SAP-Fähigkeit = 0... Tut mir leid, kenne den Begriff nicht.

StandAlone-Player sind separate DVD-Abspielgeräte, die man an seinen Fernseher anschließt, wenn man keinen Computer im Wohnzimmer stehen haben will, aber trotzdem Videos ansehen können möchte. Diese Geräte unterstützen AVI-Container, inzwischen auch DivX und XviD als Codecs (manchmal nicht mit dem vollen Parametersatz, mein Gerät kann beispielsweise XviD/GMC3-Videos nur mit spürbaren Bildfehlern darstellen) und maximal 720px pro Zeile (für mehr müsste man spezielle HD-fähige Geräte kaufen, die derzeit noch ziemlich teuer sind).

ZweiPi wrote:...P/ED und Epi verschieden behandeln und dann per MKV einfachen zusammenfügen ... Drei Files nacher zu einem zusammenpappen? Geht das?

In MKV schon.

ZweiPi wrote:- komplett auf Softsub umzusteigen

Für ein HD-Bildformat wie 1280x720px durchaus eine denkbare Lösung. MKV würde Dir sowohl die verschiedenen Frameraten erlauben als auch H.264 als Codec, womit Du trotz Riesen-Auflösung eine gute Qualität bei angemessener Dateigröße hinkriegen würdest (also ohne Resize). Dieses Release wäre allerdings nur auf (leistungsfähigen) PCs abspielbar.

Das, was viele Gruppen in dieser Situation machen, ist: Zwei Releases, nämlich

• eines als MKV-Container mit H.264-encodetem Video-Stream und 1280*720px Auflösung sowie drei Video-Teilen mit unterschiedlichen Frame-Raten (optimale Qualität, hohe Encoding-Dauer, nur auf leistungsfähigen PC abspielbar) und
• das andere als AVI-Container mit XviD-encodetem Video-Stream und 704*400px Auflösung sowie nur einem Video-Teil mit fester Frame-Rate (schlechtere Qualität, OP & ED ruckeln, dafür abspielbar auf Standalone-Playern und alten PCs).

also ich mach sowas immer so in avs: das hier braucht man: http://neuron2.net/fdecimate/fdecimate.html
wenn ich das standard-"ChangeFPS(23.976)" benutzt hab, {\i1}dann{\i0} hat das wie blöd geruckelt. mit diesem filter passiert das nicht, imho.
da steht auch einiges interessantes dazu.
mit virtual dub kann ich dir aber nicht weiterhelfen, weil ich davon nur wenig ahnung habe.

mfg baboon

Edit(@Aikousha):\\ ich habe Avisource aufgegeben ^^. Mag an meinen wenigen Kenntnissen liegen, aber bis jetzt hatte ich nur Probleme damit. Bin zufrieden mit DSS

Devil Doll wrote:

ZweiPi wrote: Das, was viele Gruppen in dieser Situation machen, ist: Zwei Releases, nämlich

• eines als MKV-Container mit H.264-encodetem Video-Stream und 1280*720px Auflösung sowie drei Video-Teilen mit unterschiedlichen Frame-Raten (optimale Qualität, hohe Encoding-Dauer, nur auf leistungsfähigen PC abspielbar) und
• das andere als AVI-Container mit XviD-encodetem Video-Stream und 704*400px Auflösung sowie nur einem Video-Teil mit fester Frame-Rate (schlechtere Qualität, OP & ED ruckeln, dafür abspielbar auf Standalone-Playern und alten PCs).

Wir werden am Anfang drei bis vier Versionen releasen, so wie das aussieht. Aber wenn ihr euch mit "ruckelnden" Avi´s anfreunden könnt dann ist schon eins meiner Probleme gelöst.

Die 1280*720 wird wohl noch dauern. (Obwohl mein Rechner ohne Mühe große Auflösungen spielt und genug Speicherplatz hat bevorzuge ich die kleinen Dateien)

Und Sorry für den überhasteten Post von weiter oben aber habe echt nicht viel Zeit.

ZweiPi wrote:Die 1280*720 wird wohl noch dauern. (Obwohl mein Rechner ohne Mühe große Auflösungen spielt und genug Speicherplatz hat bevorzuge ich die kleinen Dateien)

Wenn Du H.264 zum Encoden verwenden würdest statt XviD, dann würdest Du auch die hohe Auflösung mit einer relativ kleinen Datei hinkriegen - nur kostet das Abspielen eines so codierten Videos dann deutlich mehr Leistung als das Abspielen eines XviD-Videos.

So nun mal zu meinen Erfolgen:
Avi mit xvid, ohne sichtbares Ruckeln im Multipass 720*405, 175MB bei 23,98 FPS leider nur 880 kbits
und mkv mit 1280*720 was aber 343 MB groß ist. Ist das zu groß? Nero zwingt mich hier leider eine bitrate von über 2000kb/s zu nehmen und andere h264, mp4 Decoder kenne oder habe ich nicht (Nero 7 war damals teuer genug). Virtual Dub bietet mir noch einen Microsoft mpeg 4 v2 Decoder an aber ich glaube, den brauche nicht anzufassen.
Ich habe noch eine 1024*576 Version mit 130-140 MB was ich am Anfang releasen wollte, aber ihr steht ja nicht auf Softsubs.
Wenn dies so geht, würde ich sagen, das ich auf die fertige ASS warten muss.

Für h.264 solltest du MeGui mit dem Opensource Codec x264 benutzen. Ich finde den Nerocodec nicht so gut - kannst du bei dem Neroencoder überhaupt eine avs als Input nehmen?

ZweiPi wrote:Ausgangsdatei: Folge.avi, 270 MB, divx-video codec, audio PCM , 119,875 Bilder pro Sekunde, Format 1280x720

AFAIK können diese Angaben nicht stimmen, da allein schon die PCM größer als 270MB wäre. Bitte posten den Log von MediaInfo oder Avinaptic oder GSpot, ...

ZweiPi wrote:trotz 160kb/s Lame mp3

Meiner Meinung nach zuviel. Du wirst selbst bei 96kbps den Unterschied nicht hören.

I.R.Baboon wrote:also ich mach sowas immer so in avs:

Code: Select all

directshowsource("pfad\video.bla", fps=119.88, convertfps=true)
Loadplugin("pfad\fdecimate.dll")
Fdecimate(23.976)

das hier braucht man: http://neuron2.net/fdecimate/fdecimate.html
wenn ich das standard-"ChangeFPS(23.976)" benutzt hab, {\i1}dann{\i0} hat das wie blöd geruckelt. mit diesem filter passiert das nicht, imho.
da steht auch einiges interessantes dazu.
mit virtual dub kann ich dir aber nicht weiterhelfen, weil ich davon nur wenig ahnung habe.

mfg baboon

DirectShowSource() ist die letzte aller Möglichkeiten. Da die Source eine AVI zu sein scheint, würde ich eher AVISource() vorziehen. Der einzige Einsatzfall, der mir für DirectShowSource() einfällt ist VRF (und auch das scheint hier nicht ggb. zu sein) oder falls jmd. FLV o.ä. unbedingt weiter verarbeiten zu muss.
(Um die Frage "Warum kein DirectShowSource()?" vorwegzunehmen: DSS arbeitet nicht framegenau. Worst Case für jedes Encoding imo.)

Das bei ChangeFPS() ein "ruckeln" wahrnehmbar ist, und bei ConvertFPS() nicht, liegt in der Arbeitsweise der Filter.

ChangeFPS wrote:ChangeFPS changes the frame rate by deleting or duplicating frames

ConvertFPS wrote:The filter attempts to convert the frame rate of clip to new_rate without dropping or inserting frames, providing a smooth conversion with results similar to those of standalone converter boxes. The output will have (almost) the same duration as clip, but the number of frames will change proportional to the ratio of target and source frame rates. [...] The filter has two operating modes. If the optional argument zone is not present, it will blend adjacent video frames, weighted by a blend factor proportional to the frames' relative timing ("Blend Mode"). If zone is present, it will switch from one video frame to the next ("Switch Mode") whenever a new source frame begins, that is, usually somewhere in the middle of a target frame. Switch Mode assumes that the output will be shown on a TV where each frame is scanned from top to bottom. The parameter zone specifies the height of the transition region in which the current frame will be blended into the next.

Um es etwas einfacher Auszudrücken: ChangeFPS() ist ein dumme, automatisierte Dezimierung (die allerdings nicht per se schlecht sein muss!).
Persönlich würde ich hier auch eher zu einem Dezimierung-Filter neigen, statt zu einer Blend-Konvertierung (da die Source "aufgebläht" wurde). Welcher Decimate-Filter am geeignetsten ist, ist abhängig von der Source, deinem Ziel das du erreichen willst und deinem persönlichem Geschmack.

@ZweiPi: Mit der Installation von AviSynth kommt auch eine deutsche Anleitung mit. In dieser wird die Nutzung von AviSynth Schritt-für-Schritt beschrieben.

Also um auf PCM zurückzukommen, es steht PCM da(Virtual Dub) , höchstwahrscheinlich mit Codec(man kann ja auch Wavedateien mit mp3 Codec codieren). Werde mal auf 128 runtergehen aber dies wird so um die 3-5 MB ausmachen.
Zum Thema Nero und avs: nein natürlich nicht, deshalb ja Softsub als mkv.

Zum Thema Megui: interessanterweise war ich vorhin schon auf der Seite und habe mir den codec runtergeladen und war aufgrund der Konsolensteuerung erst mal geschockt(LaTex-Geschädigter, falls jemand das was sagt)
Jetzt habe ich mal weiter runter gescrollt und anscheinend gibst auch eine Steuerung per Maus dafür. Schau es mir heute Abend mal an.(hoffentlich mit avs Unterstützung)

Zum Thema Dezimate: gut das ich alle falschen Optionen als erstes ausprobiert habe aber der Virtual Dub decimate 5 funktioniert im Multipass hinreichend gut. Werde über das Wochenende mal auf verschiedenen Rechner prüfen.

Noch etwas anderes: Habe den Softsub mittlerweile auf 5 Rechnern getestet und nur auf meinem wird die Karaoke nicht richtig angezeigt(wenn sie so schimpfen darf). Hat jemand dazu eine Idee? Wenn nicht, auch nicht schlimm.

Edit1: Avisynth anleitung habe ich weggeklickt, da ich dies scheinbar nur als Vorrausetzung für Virtual DUb brauchte.
Edit2: Megui auf die schnelle zu bedienen wird nichts, fatal Error beim Autoencode und ich habe den Haken für Multithreating noch nicht gefunden

Natürlich frisst MeGui AVS, MeGui funktioniert nur mit avs. Außerdem gibt's natürlich auch eine grafische Oberfläche und den auto-Mode zu nehmen ist auch dumm, so kompliziert ist MeGui auch nicht, ... es gibt sogar einen AVS Script Ersteller.

Und PCM ist unkomprimiert, .. und kann auch nicht komprimiert sein. Ist mir jedenfalls unbekannt.

VirtualDub benötigt nicht zwingend AviSynth, aber es ist sehr praktische, das es damit umgehen kann. Und bitte lies die Readme's / Hilfen! Diese wurden nicht umsonst geschrieben! Encoding bedeutet als erstes lesen und verstehen!

MeGUI hat eine Update-Funktion, die alles herunterlädt, was du benötigst. Wenn du es selbst mit der MeGUI Referenz nicht schaffen solltest, mit MeGUI umzugehen, solltest du dir vllt. besser einen Encoder suchen.
___

PCM ist unkomprimiert. 25min PCM im WAVE-Conainer hätten die Größe von ~1,3GB. Mit zusätzlichem Video in 720p@~120fps ist es also ein Ding der Unmöglichkeit, dass die Source "nur" 270MB groß sein kann. (Allein schon 270MB für eine 720p-HD-RAW ist das Grauen schlechthin). (Deswegen hatte ich ja auch um die Log von MediaInfo gebeten.)
___

Anmerkungen am Rande: Ja, es gibt auch ein VfW-Version von x264. Und nein, diese sollte man nicht benutzen. Warum? Ganz einfach. Weil mann AVC in AVI nicht macht. (Hat technische Gründe. Und VirtualDub versteht nunmal nur AVI.) Also am besten die CLI-Version nutzen und MeGUI, StaxRip o.ä. als GUI wählen und das ganze in MP4 oder MKV packen.

Ich empfehle dir, ZweiPi, dringend einige Grundlagen anzueignen, wenn du vorhast einen Anime zu encoden der 24 oder 26 Episoden hat. Als "Einstieg" währe bspw. Brother Johns Encodingwissen nicht schlecht.

ZweiPi wrote:Avi mit xvid, ohne sichtbares Ruckeln im Multipass 720*405, 175MB bei 23,98 FPS leider nur 880 kbits und mkv mit 1280*720 was aber 343 MB groß ist. Ist das zu groß?

Zunächst mal: 405px ist nicht durch 4 teilbar (und erst recht nicht durch 16). Es hatte schon einen Grund, weshalb ich 704x400 (beide Dimensionen durch 16 teilbar) empfohlen hatte; alternativ 704x396, was exaktes 16:9 bei Teilbarkeit durch 4 wäre. Beides ist nahe dran am Maximum dessen, was Standalone-Player bzw. nicht HD-fähige Fernseher darstellen können. Für den Vergleich dieser beiden Auflösung siehe u. a. diesen Thread hier.

880kb/sec sind für ein Nicht-HD-Anime in XviD durchaus üblich - vergleiche mal die Dateigrößen anderer Releases hier. Zielgrößen: 703 MB pro CD für 4 Episoden = 175.5 MB, 4483 MB pro DVD für 26 Episoden = 172MB, 4483 MB pro DVD für 24 Episoden = 186.5 MB... es hängt von Deiner Serie ab, was "passt".

Angenommen, Du hast etwa 27 MB Audio-Stream in Deinem Video (160kb/sec für normale Episodenlänge - MediaInfo-Report wäre in der Tat hilfreich), dann sind die Video-Streams 175-27=148 bzw. 343-27=316 MB groß, d. h. der 1280x720px-Videostream hätte 316/148=213.5% Bandbreite des 720x405px-Streams bei immerhin 1280/405=316% der Fläche, was ich für angemessen halten würde.
Mit H.264 müsstest Du allerdings einen qualitativ ausreichenden Videostream von ungefähr 200 MB hinkriegen, schätze ich mal.

OK, nachdem die Möglichkeiten hier jetzt doch sehr klar abgesteckt wurden, werde mich mich mal durch die readme's kämpfen, nachdem dies mehrere hier empfohlen haben: Deshalb würde ich mich irgendwann noch einmal melden, falls es noch immer nicht klappt.
Mein Hauptproblem wurde schon lange gelöst und dafür bin ich sehr dankbar(vernünftige Avi hinzubekommen(in meinen Augen)), aber ich sehe anhand des weiter oben genanten Buches beim Überfliegen, das noch viel Arbeit vor mir liegt.
An Devil Doll: es waren 720*404(vertippt(aber trotzdem nur durch 4 teilbar))).
Also bis die Tage.
ZweiPI