Das Video ist größer als geplant
Re: Das Video ist größer als geplant
vllt. weiss er das nicht und encodet mit ton. würde auch das größen problem erklären.
Re: Das Video ist größer als geplant
Also ich habe bis jetzt glaub ich immer mit Tonspur encodet,
weil ich ja keine Möglichkeit hatte den Ton zu komprimieren...
Jetzt hab ich'n Audio-Converter aber jetzt weiß ich nicht wie man die Audio-Datei dareinschneidet?
weil ich ja keine Möglichkeit hatte den Ton zu komprimieren...
Jetzt hab ich'n Audio-Converter aber jetzt weiß ich nicht wie man die Audio-Datei dareinschneidet?
- Kaoru_Battlemuffin
- Senpai
- Posts: 143
- Joined: 29.12.2007 21:35
- Gruppe: Gruppe Kampfkuchen
Re: Das Video ist größer als geplant
Also, Quellendatei (AVS Script mit Directshowsource("datei.avi") reicht schon) öffnen, der Ton wird automatisch vom FFDSHOW Decoded (falls es nichts extravagantes is
). Die AVS nach möglichkeit mit VirtualdubMod öffnen. Unter Streams -> Stream list dann die Tonspur auswählen und auf "Save WAV" klicken.
Dann ziehst du dir BeSweet (http://www.chip.de/downloads/BeSweet-1.4_13006247.html). Ist ein CLI Transcode Tool mit GUI (Grafischer Oberfläche). Da kannst du dann deine Tonspur die du als Unkomprimierte WAV gespeichert hast reinziehen und als MP3 encoden (Nach möglichkeit CBR ... Target auf "Bitrate" setzen und bei dem Bitrateregler einen Haken bei "Restrict Encoder to Constant Bitrate" machen).
Dann kannst du bei Virtualdubmod wo du noch deine Datei und das Streamlist Fenster offen hast deinen Stream disablen. Dann encoden.
Die fertig encodete Datei wieder mit Virtualdubmod öffnen, und nur die Datei selbst, ohne AVS Script bitte.
Dann kannst du da unter Stream List wieder deine Tonspur hinzufügen. F7 drücken und bei Video Mode "Direct Stream Copy" wählen. Und fertig is dein gemuxxtes Video. Hf
Btw: Auf Wunsch bin ich Bereit noch gleich Screenshots zu machen
![Wink ;)](./images/smilies/icon_e_wink.gif)
Dann ziehst du dir BeSweet (http://www.chip.de/downloads/BeSweet-1.4_13006247.html). Ist ein CLI Transcode Tool mit GUI (Grafischer Oberfläche). Da kannst du dann deine Tonspur die du als Unkomprimierte WAV gespeichert hast reinziehen und als MP3 encoden (Nach möglichkeit CBR ... Target auf "Bitrate" setzen und bei dem Bitrateregler einen Haken bei "Restrict Encoder to Constant Bitrate" machen).
Dann kannst du bei Virtualdubmod wo du noch deine Datei und das Streamlist Fenster offen hast deinen Stream disablen. Dann encoden.
Die fertig encodete Datei wieder mit Virtualdubmod öffnen, und nur die Datei selbst, ohne AVS Script bitte.
Dann kannst du da unter Stream List wieder deine Tonspur hinzufügen. F7 drücken und bei Video Mode "Direct Stream Copy" wählen. Und fertig is dein gemuxxtes Video. Hf
Btw: Auf Wunsch bin ich Bereit noch gleich Screenshots zu machen
![Image](http://www.cccp-project.net/wiki/images/0/05/Amz_cccp_bigbanner_07.gif)
![Image](http://www.cccp-project.net/wiki/images/4/45/Cccpuserbar.jpg)
Use CCCP9+9, Codename "NEIN NEIN NEIN"
- Devil Doll
- Kámi-sama
- Posts: 584
- Joined: 30.12.2007 00:18
- Gruppe: Devil Doll
- Contact:
Re: Das Video ist größer als geplant
Ich möchte beim Encoden im Prinzip genauso arbeiten wie KaNego, also in einem Arbeitsgang eine fertige Datei inklusive Audio-Stream zu erzeugen und nicht diesen Audio-Stream noch in einem nachgeschalteten (wenngleich nur ca. eine Minute dauernden) Arbeitsgang separat einfügen (bei größeren Dateimengen, etwa beim Umbasteln einer kompletten Serie von MKV nach AVI für meinen Standalone-Player, ist eine vollautomatische Lösung im Batch-Betrieb über Nacht nun mal die deutlich bequemste).
Unser Arbeitsstil unterscheidet sich darin, dass ich den Audio-Stream nur ein einziges Mal erzeuge (für das Timing-Raw nehme ich denselben Audio-Stream wie für spätere QC- oder Release-Encodings); ich brauche diesen Stream also als separate Datei (und nicht als Teil des Avisynth-Datenstroms) und mische ihn zu jeder der verschiedenen Encoding-Varianten jeweils nur noch dazu, statt ihn erst während des Video-Encoding-Laufes mit zu erzeugen, wie KaNego das bisher tun will.
Dies ist der Grund, weshalb ich das eigentlich stark veraltete VirtualDubMod gegenüber dem weitaus aktuelleren VirtualDub verwenden muss: VirtualDub besitzt keine Funktion für das "Hinzumischen" des Audio-Streams aus einer externen Datei. Dies ist auch der einzige Schritt, wo mein Verfahren von demjenigen abweicht, das Kaoru beschrieben hat (auch ich verwende BeSweet für die Audio-Stream-Vorverarbeitung): Ich sehe keinen Grund dafür, das Dazumischen in einem separaten Schritt durchzuführen, wenn ich mit VirtualDubMod beides in einem Durchgang erledigen kann.
Unser Arbeitsstil unterscheidet sich darin, dass ich den Audio-Stream nur ein einziges Mal erzeuge (für das Timing-Raw nehme ich denselben Audio-Stream wie für spätere QC- oder Release-Encodings); ich brauche diesen Stream also als separate Datei (und nicht als Teil des Avisynth-Datenstroms) und mische ihn zu jeder der verschiedenen Encoding-Varianten jeweils nur noch dazu, statt ihn erst während des Video-Encoding-Laufes mit zu erzeugen, wie KaNego das bisher tun will.
Dies ist der Grund, weshalb ich das eigentlich stark veraltete VirtualDubMod gegenüber dem weitaus aktuelleren VirtualDub verwenden muss: VirtualDub besitzt keine Funktion für das "Hinzumischen" des Audio-Streams aus einer externen Datei. Dies ist auch der einzige Schritt, wo mein Verfahren von demjenigen abweicht, das Kaoru beschrieben hat (auch ich verwende BeSweet für die Audio-Stream-Vorverarbeitung): Ich sehe keinen Grund dafür, das Dazumischen in einem separaten Schritt durchzuführen, wenn ich mit VirtualDubMod beides in einem Durchgang erledigen kann.
Re: Das Video ist größer als geplant
Devill Doll das mit dem dazumischen kannst aber auch ohne Probleme über Avisynth regeln. (aber ich benutze, für xvid und lossless exporte selber auch noch VirtualDubMod, weil mir in diesem der umgang mit avs scripten eher zusagt)
Aber bei uns wird wohl ein großer Unterschied sein das ich erstmal alles zu einem lossless encode filtere (lagarith+pcm),und von diesem alle weiteren encodes erstelle, spart mir das filtern zu jedem arbeitschrit und auch wen bei einem hardsub mal wieder wegen einen typo eine noch mal final encoded gemacht werden muss. Und vor allem geh ich bei VFR zu CFR encodes sicher das alle Frames und audio synch übereinstimmen.
Aber bei uns wird wohl ein großer Unterschied sein das ich erstmal alles zu einem lossless encode filtere (lagarith+pcm),und von diesem alle weiteren encodes erstelle, spart mir das filtern zu jedem arbeitschrit und auch wen bei einem hardsub mal wieder wegen einen typo eine noch mal final encoded gemacht werden muss. Und vor allem geh ich bei VFR zu CFR encodes sicher das alle Frames und audio synch übereinstimmen.
"While at present we have no plans for the franchise [on next-gen consoles]..."
![Image](http://forums.animesuki.com/images/as.icon/signaturepics/sigpic62762_1.gif)
![Image](http://forums.animesuki.com/images/as.icon/signaturepics/sigpic62762_1.gif)
- Devil Doll
- Kámi-sama
- Posts: 584
- Joined: 30.12.2007 00:18
- Gruppe: Devil Doll
- Contact:
Re: Das Video ist größer als geplant
Wir beide tun wirklich fast dasselbe, wie Du hier nachlesen kannst (allfällige Verbesserungsvorschläge werden dankend angenommen).max2k wrote:Aber bei uns wird wohl ein großer Unterschied sein das ich erstmal alles zu einem lossless encode filtere (lagarith+pcm),und von diesem alle weiteren encodes erstelle, spart mir das filtern zu jedem arbeitschrit und auch wen bei einem hardsub mal wieder wegen einen typo eine noch mal final encoded gemacht werden muss.
Ich gehe allerdings so schnell wie möglich von PCM-Audio (wofür ich keine Verwendung habe) zu MP3-CBR128 über und muxe dieses bei Soloprojekten sogar in die Lossless-Variante hinein, weil ich diese direkt als Timing-Raw verwenden kann.
Die Audio-Verarbeitungsvariante innerhalb von Avisynth hat GhostDog mir freundlicherweise mal erklärt, aber aufgrund der verschiedenen möglichen Audio-Formate müsste ich im Avisynth-Skript jedesmal den Aufruf der entsprechenden Zugriffsfunktion anpassen - und im oben verlinkten Artikel alle möglichen Varianten zu erklären, erschien mir nicht mehr übersichtlich genug (deshalb habe ich diesen Teil dort bisher nicht eingearbeitet, ich denke aber noch darüber nach).
Die Audio-Verarbeitung geht relativ zur Video-Verarbeitung so schnell und verwendet so viel kleinere Dateien, dass ich diesen Teil gerne (einmalig für das gesamte Projekt) manuell erledige.
Re: Das Video ist größer als geplant
Vielen Dank nochmal für all die netten Tipps!
Ich habe oben gelesen, das man auch per Avisynth den Ton reinmischen kann...
Wie sieht denn dazu der Befehl aus?
Ich habe oben gelesen, das man auch per Avisynth den Ton reinmischen kann...
Wie sieht denn dazu der Befehl aus?
- Devil Doll
- Kámi-sama
- Posts: 584
- Joined: 30.12.2007 00:18
- Gruppe: Devil Doll
- Contact:
Re: Das Video ist größer als geplant
Wenn es nur ein (immer gleicher) "Befehl" wäre, dann hätte ich die Methode im Fansub-Wiki beschrieben. Es kommt aber darauf an, welches Format der Audio-Stream Deiner Eingabe hat - Du musst dieses Format durch die Wahl der passenden Zugriffsfunktion und der passenden Parameterwerte exakt beschreiben, um auf deren Daten zugreifen zu können.
Installier Dir mal das NicAudio-Plugin für Avisynth 2.5 (die Webseite behauptet "Version 1.7", die Readme-Datei im Download-Archiv meint "Version 1.82", die zu installierende DLL selbst meldet eine Versionsnummer "2.0.0.5"...) und lies eventuell zugehörige Threads in Doom9, weil die Readme-Datei sehr knapp ausgefallen ist:
Installier Dir mal das NicAudio-Plugin für Avisynth 2.5 (die Webseite behauptet "Version 1.7", die Readme-Datei im Download-Archiv meint "Version 1.82", die zu installierende DLL selbst meldet eine Versionsnummer "2.0.0.5"...) und lies eventuell zugehörige Threads in Doom9, weil die Readme-Datei sehr knapp ausgefallen ist:
Für "reinmischen" reicht das natürlich noch nicht aus - beispielsweise weißt Du ja nicht, ob Video- und Audio-Stream synchron sind und welcher zeitliche Versatz (Delay) eventuell vorzunehmen wäre.Syntax:
AC3: NicAC3Source("FileName.ac3", int "Channels", int "DRC")
DTS: NicDTSSource("FileName.dts", int "Channels", int "DRC")
MPA: NicMPASource("FileName.mpa", int "Channels")
LPCM: NicLPCMSource("FileName.lpcm", int "SampleRate", int "SampleBits", int "Channels")
RAW: NicRawPCMSource("FileName.lpcm", int "SampleRate", int "SampleBits", int "Channels")
Note: "Channels" specifies the maximum number of channels to output. This is the only optional parameter.
Note: "DRC" specifies DRC algorytm. ) 0 means nothing (default), 1 means Normal the only optional parameter.
Example:
LoadPlugin("NicAudio.dll")
NicAC3Source("c:\File.AC3")
or
LoadPlugin("NicAudio.dll")
NicAC3Source("c:\File.AC3", DRC=1)
or
NicLPCMSource("c:\File.lpcm", 48000, 16, 2)
(NicLPCMSource expects raw LPCM files. Not LPCM wav files. At present it only supports 2-channel LPCM wav files)
Re: Das Video ist größer als geplant
Also der Guide ist super, ich hab mir den mal gleich in die Favoriten gemarkt, da in den kommenden Wochen meiner erster reencode mit einer "DVD-source" ansteht.
Verbesserungsvorschläge: Das mit dem 704*396px, ich würde eher auf 704*400px encoden, da man sicht so nicht den bitstream mit Scheininformationen vollsaut die aufgrund der nicht 100% 16bit kompatiblitet der auflösung enstehen (400 geht durch 16 zu teilen wie die meisten gängigen Auflösungen,nur eben 704*396 nicht.) Vor allem wen man schon kompimirungsschwreiten hat würde ich es vorziehen Mod16 zu bleiben. Da man eh schon cropt, könnte man es auch nutzen um der anarmophitet entgegen zu steuern, die ihn wirklichkeit so gering ist, das jemand der behauptet die wirklich wahrzunehmen, sich was einredet. Ich mein auch gelesen zu haben das man bei NTSC DVDS wenigstens 8 px an den seiten cropen soll da an den rändern, da auserhalb des Bildes Kopierschutz informationen versteckt sind die man sonst mit encoded...
Ich glaube man kann die AR auch mit YATTA genau nachrechnen, aber bevor ich mich mit YATTA beschäftige stehen erstaml noch Dringender Sachen an (mehr Filter testen etc.), kanntes du dich nicht mit YATTA aus DD, und werst du bereit jemanden einzuweissen, wen sich wer ihn einem halben Jahr oder so in diesen "Wahnsinn" begeben will, scheint ja keine vernünftigen tuts zugeben.
Verbesserungsvorschläge: Das mit dem 704*396px, ich würde eher auf 704*400px encoden, da man sicht so nicht den bitstream mit Scheininformationen vollsaut die aufgrund der nicht 100% 16bit kompatiblitet der auflösung enstehen (400 geht durch 16 zu teilen wie die meisten gängigen Auflösungen,nur eben 704*396 nicht.) Vor allem wen man schon kompimirungsschwreiten hat würde ich es vorziehen Mod16 zu bleiben. Da man eh schon cropt, könnte man es auch nutzen um der anarmophitet entgegen zu steuern, die ihn wirklichkeit so gering ist, das jemand der behauptet die wirklich wahrzunehmen, sich was einredet. Ich mein auch gelesen zu haben das man bei NTSC DVDS wenigstens 8 px an den seiten cropen soll da an den rändern, da auserhalb des Bildes Kopierschutz informationen versteckt sind die man sonst mit encoded...
Ich glaube man kann die AR auch mit YATTA genau nachrechnen, aber bevor ich mich mit YATTA beschäftige stehen erstaml noch Dringender Sachen an (mehr Filter testen etc.), kanntes du dich nicht mit YATTA aus DD, und werst du bereit jemanden einzuweissen, wen sich wer ihn einem halben Jahr oder so in diesen "Wahnsinn" begeben will, scheint ja keine vernünftigen tuts zugeben.
"While at present we have no plans for the franchise [on next-gen consoles]..."
![Image](http://forums.animesuki.com/images/as.icon/signaturepics/sigpic62762_1.gif)
![Image](http://forums.animesuki.com/images/as.icon/signaturepics/sigpic62762_1.gif)
- Devil Doll
- Kámi-sama
- Posts: 584
- Joined: 30.12.2007 00:18
- Gruppe: Devil Doll
- Contact:
Re: Das Video ist größer als geplant
Nein, YATTA ist nicht mein Ding (gerade weil TIVTC mit vernachlässigbarem Aufwand so ordentliche Ergebnisse liefert, habe ich diesen Wiki-Artikel überhaupt erst geschrieben, dessen Inhalt ich für alle meine Releases seit Seikai no Senki III nahezu exakt verwendet habe). Wäre Elberet noch hier, der könnte das sicherlich richtig gut erklären... oder jabba, wenn er die Zeit dafür übrig hätte...
Meine Kenntnisse über Videoformate und deren Behandlung reichen für einen wirklich guten Artikel gar nicht aus - deshalb nur dieser "Waschzettel", um mit geringem Aufwand zu brauchbaren Ergebnissen zu kommen (ein Artikel, der doppelt so gute Qualität ermöglichen würde, wäre sicherlich mindestens fünfmal so umfangreich). Da gibt es zahlreiche Encoder, die wesentlich mehr wüssten als ich, der ich halt im Wesentlichen Texte ordentlich formulieren kann.
Bezüglich der Mod16-Theorie für die Seitenlängen (welche im Artikel ja verlinkt ist) erinnere ich mich vage, beim Recherchieren zu diesem Artikel in Doom9 einen Thread über Testmessungen gelesen zu haben, welcher die Theorie aufstellt, dass Seitenlängen knapp unterhalb von Mod16 noch bessere Komprimierungsergebnisse liefern als bei exakter Teilbarkeit; mit dieser Information im Hintergrund sah ich dann keinen Grund, von exaktem 16:9 (also 704*396px) abzugehen... auch, weil ich nicht beurteilen kann, welche Effekte es auf allfälligen 16:9-Fernsehern haben könnte, wenn dort das Bild noch einmal (minimal) gezerrt werden muss, um exakt dargestellt werden zu können. Dann lieber gleich 16:9 und eine mögliche Fehlerquelle ausschließen (zumal die konkrete Dateigröße bei steigender Medien- und Leistungskapazität mit der Zeit an Bedeutung verlieren wird).
Was die Kopierschutzinformationen angeht: Kannst Du dafür eine vertrauenswürdige Quelle nennen? So "rein auf Verdacht" würde ich eine solche Empfehlung ungern in den Artikel einbauen (außerdem: Welchen Unterschied macht das schon, wenn man bei einem Fansub erkennen kann, woher die Raw stammt? Die Rechtslage ist doch unstrittig).
Meine Kenntnisse über Videoformate und deren Behandlung reichen für einen wirklich guten Artikel gar nicht aus - deshalb nur dieser "Waschzettel", um mit geringem Aufwand zu brauchbaren Ergebnissen zu kommen (ein Artikel, der doppelt so gute Qualität ermöglichen würde, wäre sicherlich mindestens fünfmal so umfangreich). Da gibt es zahlreiche Encoder, die wesentlich mehr wüssten als ich, der ich halt im Wesentlichen Texte ordentlich formulieren kann.
Bezüglich der Mod16-Theorie für die Seitenlängen (welche im Artikel ja verlinkt ist) erinnere ich mich vage, beim Recherchieren zu diesem Artikel in Doom9 einen Thread über Testmessungen gelesen zu haben, welcher die Theorie aufstellt, dass Seitenlängen knapp unterhalb von Mod16 noch bessere Komprimierungsergebnisse liefern als bei exakter Teilbarkeit; mit dieser Information im Hintergrund sah ich dann keinen Grund, von exaktem 16:9 (also 704*396px) abzugehen... auch, weil ich nicht beurteilen kann, welche Effekte es auf allfälligen 16:9-Fernsehern haben könnte, wenn dort das Bild noch einmal (minimal) gezerrt werden muss, um exakt dargestellt werden zu können. Dann lieber gleich 16:9 und eine mögliche Fehlerquelle ausschließen (zumal die konkrete Dateigröße bei steigender Medien- und Leistungskapazität mit der Zeit an Bedeutung verlieren wird).
Was die Kopierschutzinformationen angeht: Kannst Du dafür eine vertrauenswürdige Quelle nennen? So "rein auf Verdacht" würde ich eine solche Empfehlung ungern in den Artikel einbauen (außerdem: Welchen Unterschied macht das schon, wenn man bei einem Fansub erkennen kann, woher die Raw stammt? Die Rechtslage ist doch unstrittig).
Re: Das Video ist größer als geplant
Ich glaub ich lass den die Tage noch mal einige 1st pass Testencodes laufen, und vergleiche den einfach die maximalen Videosize und average Bitrate einiger Encodes, in den Auflösungen 704/396 und 704/400, um sicher zu gehen.Devil Doll wrote:
Bezüglich der Mod16-Theorie für die Seitenlängen (welche im Artikel ja verlinkt ist) erinnere ich mich vage, beim Recherchieren zu diesem Artikel in Doom9 einen Thread über Testmessungen gelesen zu haben, welcher die Theorie aufstellt, dass Seitenlängen knapp unterhalb von Mod16 noch bessere Komprimierungsergebnisse liefern als bei exakter Teilbarkeit; mit dieser Information im Hintergrund sah ich dann keinen Grund, von exaktem 16:9 (also 704*396px) abzugehen...
"While at present we have no plans for the franchise [on next-gen consoles]..."
![Image](http://forums.animesuki.com/images/as.icon/signaturepics/sigpic62762_1.gif)
![Image](http://forums.animesuki.com/images/as.icon/signaturepics/sigpic62762_1.gif)
- Devil Doll
- Kámi-sama
- Posts: 584
- Joined: 30.12.2007 00:18
- Gruppe: Devil Doll
- Contact:
Re: Das Video ist größer als geplant
Ich weiß nicht, ob die reine Dateigröße da aussagefähig ist.
Bitrate ist für sich genommen ja auch keine Qualität (800kb/s XviD ist nicht gleich 800kb/s H.264!). Bei diesem Thread hat der Tester deshalb eine Maßzahl herangezogen, mit der irgendwie Bewegung/Inhalt/etc. eines Videos gemessen wird, und diese dann in Relation zur Dateigröße gesetzt, um die Effizienz der Komprimierung zu messen (wobei diese Bewegungsmesszahl im Thread selbst auch wieder umstritten war... einen glaubhaften numerischen Ersatz für Encoderaugen scheint es noch nicht zu geben).
Bitrate ist für sich genommen ja auch keine Qualität (800kb/s XviD ist nicht gleich 800kb/s H.264!). Bei diesem Thread hat der Tester deshalb eine Maßzahl herangezogen, mit der irgendwie Bewegung/Inhalt/etc. eines Videos gemessen wird, und diese dann in Relation zur Dateigröße gesetzt, um die Effizienz der Komprimierung zu messen (wobei diese Bewegungsmesszahl im Thread selbst auch wieder umstritten war... einen glaubhaften numerischen Ersatz für Encoderaugen scheint es noch nicht zu geben).
Re: Das Video ist größer als geplant
Ich rede davon von den selben lossless encodes je einen 1stpass in den Auflösungen 704*400 und 704*396 zu machen, alles mit den gleichen setings, als Xvid! (worauf ich achten muss, einen resizes filter zu benutzen der nicht noch mal schärft
)
Die maximale grösse des Videostreams nehm ich aus dem statsfile und die durchnitliche Bitrate sieht man ja am ende des encodes. Beides hat rein gar nichts mit der Encode Quali zu tun, da es die Werte sind die der Encode maximal ereichen könnte (also maximale Qualitet, bei diesen setings und von dem ll) und hier raus wird ersichtlich sein bei welche Auflösung man wirklich weniger maximale Bitrate benötigt.
![Wink ;)](./images/smilies/icon_e_wink.gif)
Die maximale grösse des Videostreams nehm ich aus dem statsfile und die durchnitliche Bitrate sieht man ja am ende des encodes. Beides hat rein gar nichts mit der Encode Quali zu tun, da es die Werte sind die der Encode maximal ereichen könnte (also maximale Qualitet, bei diesen setings und von dem ll) und hier raus wird ersichtlich sein bei welche Auflösung man wirklich weniger maximale Bitrate benötigt.
"While at present we have no plans for the franchise [on next-gen consoles]..."
![Image](http://forums.animesuki.com/images/as.icon/signaturepics/sigpic62762_1.gif)
![Image](http://forums.animesuki.com/images/as.icon/signaturepics/sigpic62762_1.gif)
- Devil Doll
- Kámi-sama
- Posts: 584
- Joined: 30.12.2007 00:18
- Gruppe: Devil Doll
- Contact:
Re: Das Video ist größer als geplant
Wenn Du tatsächlich so eine Testreihe vorhast, dann mach doch gleich noch verschiedene Varianten für das Resizen mit (Bicubic, Lanczos, ...?).
Who is online
Users browsing this forum: No registered users and 82 guests