Beiträge von EthanoliX

Ich nehme stark an, daß der Encoder auf eben diese Qualitätsmodi optimiert wurde, und der Einfachheit halber zusätzliche Optionen weggelassen wurden. Es war wohl nicht geplant einen Encoder zu schreiben, der sich durch vielerlei Optionen besonders gut zum Basteln eignet. Immerhin kann man selbst entscheiden, ob man HE(v2) oder LC wünscht.

Zu der Frage: "Wie schaut's mit mehr als 250 aus?" kann ich sagen, daß ich standardmäßig als max. KFI immer 300 nehme, und noch keine beeinträchtigung , was das Spulen und Springen angeht, feststellen konnte. (XP 2400+ bei cropped PAL, 720*432) Auch bei einem Test mit einer 60sekündigen Nachrichtensprecherszene in Endlosschleife und einem Wert von 500 konnte ich noch keinen nennenswerten Unterschied feststellen.

LigH: Ich nehme an, er hat die Dateien als LC-AAC kodiert, zumindest sofern es nicht per Einstellung erzwungen wird, nutzt der Neroencoder ab -q031 aufwärts LC, darunter HE und ab 0,15 abwärts HE mit PS, so stand es mal irgendwo im engl. Doom9.

Ich glaube, myspam meint eher, daß Programme, die das Frequenzspektum visualisieren, bei seinen mit Nero erstellten Dateien, keine Frequenzen oberhalb 18 kHz anzeigen, und somit auch die Vermutung naheliegt, daß sie abgeschnitten wurden.

Bei HE-Material sollte trotz der Tatsache, daß oberhalb10kommaebbes kHz alles synthetisch generiert ist, per Visualisierung das volle im Endeffekt wiedergegebene Spektrum angezeigt werden, also auch alles über 10kommaebbes.

Allerdings ist es kaum tragisch, daß die Frequenzen oberhalb 18 kHz fehlen, denn auch das Gehör eines nicht discolärmgeschädigten Jugendlichen wird diese nicht mehr wahrnehmen können. (Absolut ggf. in Ausnahmefällen, aber nicht mehr in einem komplexen Spektrum.) Es dürfte vom subjektiven Eindruck eher auffallen, wenn bei gleicher Bitrate das volle Spektrum gespeichert wäre, aber dann in schlechterer Qualität, weil zuviel Daten verbraten werden, um die hohen Frequenzen mitzuspeichern.

Zitat

mit DIVX 3,8GB sehr gute qualität auf meinem lcd ist kein unterschied zu erkennen zur DVD

Verstehe mich bitte nicht falsch, ich möchte niemandem zu nahe treten, aber aus persönlicher Erfahrung weiß ich, daß solche Kommentare i.d.R. eines bedeuten: Die sujektiv wahrgenommene Qualität des Ergebnisses wird zum überwiegenden Anteil durch das Wissen um die Herstellung desselben bedingt.

Zumindest kann ich mir nicht anders erklären, warum du eine DivX-Version als de facto nicht zu unterscheiden betrachtest, die Ergebnisse, die DVD-Shrink und Co liefern, aber als "zu matschig" und als "Pixelbrei" verwirfst.

10 %, ja sogar (je nach Film) 20-25 % Einsparung bei der Videodatenrate sollten mit Programmen wie Shrink und dergleichen durchaus machbar sein, ohne zwangsläufig eine deutlich sichtbare Qualitätseinbuße hinnehmen zu müssen, die größer ist als bei der Umwandlung nach mpeg4 oder bei einem kompletten Neukodieren nach mpeg2

Sollte es dennoch nötig sein (z.B. weil der Film wirklich die 9 GB der DVD beansprucht) neu zu kodieren, würde ich empfehlen den Ton unveränmdert zu lassen, und das Bild (nur Ränder wegschnippeln) unter Ausnutzung des kompletten Platzes einer DVD5 als XviD im 2pass zu kodieren. (min. Quantizer 1, das bringt optisch eigentlich nix, aber warum die Psyche belasten, wenn der Platz ansonsten leer bliebe *g*, Quantizer > 2, wie Brother John empfiehlt, kann durchaus schon zu sichtbaren Beeinträchtigungen führen.) oder als x264 ohne oder mit minimalem Inloop-Deblocking.

Ein oder 2 Pixel Schwarz an den Rändern lassen sich auch recht gut mit FillMargins(a,b,c,d) maskieren. So handhabe ich es immer, wenn mod16 sonst an nur wenigen Pixeln scheiterte.

Danke für die Erläuterung, jetzt schließen sich so langsam die Verständnislücken.

Kleine Frage am Rande: Warum hat man Cropped D1 um 16 Pixel in der Breite erweitert? Ob ich jetzt nach Abzug des Overscans (je 16 Pixel, oder?) 672 oder 688 Pixel Breite habe, das macht den Kohl doch auch nicht fett.

We are getting closer... Danke schonmal.
Nur frage ich mich gerade, warum beide Formate, D1 und cropped D1, um den gleichen Faktor gestreckt werden, wenn es sich um die gleiche DAR handelt (Eigentlich müßte es doch sein: Gleiche DAR, andere Breite ==> andere PAR):

cropped D1: 704*1,092 = 768 ==> 768/576 = 4:3, paßt, aber:
D1 720 * 1,092 = 786 ==> 786/576 = irgendwas, nur nicht 4/3

Ich dachte immer das schöne an der DAR ist, egal welche Auflösung vorliegt, man könne sich darauf verlassen, daß das Bild eben das Seitenverhältnis hat, welches in der DAR festgelegt ist, aber dem ist scheinbar nicht so.

Ich lese nun schon seit Wochen die verschiedenen Threads (hier und in andere Foren) rund um das Thema AR durch, aber irgendwie steige ich nicht dahinter, wie letztendlich die Begriffe PAR und DAR zu deuten sind, wenn es um das Thema DVD geht.

An sich ging ich immer davon aus, daß die Formatangaben 4/3 und 16/9 eben genau (und das meine ich wörtlich: genau, eben nicht pi mal Daumen) das Seitenverhältnis des Bildes angeben, welches ich als Betrachter letztendlich zu sehen bekomme. Welche PAR dann zu wählen ist, hinge dann nur noch vom Wiedergabemedium ab, am PC mit quadratischen Pixeln (PAR 1) ging ich davon aus, eine 4/3-DVD müsse (unter beibehaltung der Zeilen) auf 768, und eine 16/9-DVD auf 1024 Pixel/Zeile gestreckt werden, denn 768/576 = 4/3 und 1024/576 = 16/9. Nur scheint dies ja gerade nicht der fall zu sein, vielmehr lauten die Korrekten Angaben 788 und 1050. Gut, kann ich prinzipiell mit leben, aber wo zur Hölle ist dann mein Denkfehler?

Denn wenn ich die Begriffe PAR und DAR so verwende, wie sie immer und immer wieder beschrieben werden, und dann o.g. Werte einsetze, kommt trotz korrekten Rechnens etwas anderes bei heraus, als wohl laut Spezifikation richtig ist.

So, danke für den Tip, Telecide löst das Problem. Aber ein paar kleine Fragen hätte ich da noch:

0. (Rhetorisch!) Warum bezahlt der BR Leute dafür, Fehler zu machen, für die Videoamateure ratz fatz eine Lösung haben?

1. Wie genau behandelt Telecide dieses Problem hinsichtlich der Synchronizität?

2. Was zum Geier kann man (Von der Audiobearbeitung mit Tonhöhe und Synchronizität mal abgesehen) beim Speedup 24 ==> 25 bitteschön falsch machen? Jedes Frame vom Film Scannen und dann einfach die Framerate auf 25 fps setzen. Dann ist der Film halt ein paar minuten kürzer, aber es heißt doch nicht umsonst Speed>up<. oder sehe ich das zu vereinfacht?

Zitat von scharfis_brain

Das einfachste ist: einfach decomb.dll runterladen und den telecide filter benutzen.

Okay, danke schonmal soweit. Hab die Anleitung kurz überfloge (muß gleich weg) und das dürfte in der Tat die Lösung für mein Problem sein. Danke schonmal.

So es denn dann Funktioniert (Ich zweifle nicht daran.) bliebe nur noch eins und ich bin glücklich: Die Antwort auf die Frage nach dem Warum.

Danke.

Moin, meiner einer hat ein kleines Problem, was ihn stutzig gemacht hat.

Ich habe hier die Rohdaten einer TV-Aufnahme (DVB-T), und da es sich um einen alten Kinofilm handelt, ging ich davon aus, daß es sich um Vollbilder handelt, diesen Anschein hatte es auch, bis zu diesem Szenenwechsel, ab dem das Material scheinbar interlaced ist.

Szenenwechsel (3 MB)

Skript:

Zitat

mpeg2source("g:\_temp\mpeg2schnitt\scharfschuetze_cut.d2v",cpu=2)

Trim(34210,34480)

Codec: XviD, konst. Quant. 3, interlaced

Wenn man nun via Skript folgendes macht:

Zitat

mpeg2source("g:\_temp\mpeg2schnitt\scharfschuetze_cut.d2v",cpu=2)

Trim(34210,34480)

SeparateFields()

DeleteFrame(216)

Weave()

kommt das dabei heraus. (2,6 MB)

Von analogen TV-Mitschnitten kannte ich diese Phänomen, daß scheinbar die falschen Felder in ein Frame gepackt sind, und es daher den Anschein hat, der Film sei interlaced, bei DVB aufnahmen ist mir dies hier das erste mal begegnet. Und v.a. wundert mich, daß es mitten im Film geschieht, und das nicht nur einmal. Das komplette Skript sah dann so aus:

Zitat

mpeg2source("g:\_temp\mpeg2schnitt\scharfschuetze_cut.d2v",cpu=2)

SeparateFields()

DeleteFrame(0)

DuplicateFrame(4257)

DeleteFrame(4334)

DuplicateFrame(4360)

DeleteFrame(68636)

DuplicateFrame(121364)

DeleteFrame(142244)

Weave()

FadeIn(10)

Crop(8,8,-8,-8)

FillMargins(2,0,2,0)

UnDot()

UnFilter(10,10)

Alles anzeigen

So, und nun zu meinem eigentlichen Anliegen:

1. Falls wer verbesserungsvorschläge hat, um dieses Problem zu umgehen: Immer her damit.

2. Weiß jemand wudurch dieses Problem bedingt ist? Kann es z.B. durch Aussetzer beim DVB-T-Empfang bedingt sein?

Danke schonmal.

Zitat von sade

Wie liest Premiere die Dateien?
per VFW: -mit mp4box den Videostream extrahieren und mit avc2avi in ein avi muxen
- im FFDShow Vfw Interface H264 ativieren
per Directshow: -keine Ahnung warum es nicht funktioniert

Hm, komisch, daß AviSynth so lahmarschig ist, denn ansonsten ist das im Zweifelsfall immer der Notanker, wenn alles andere versagt, zumindest sofern das Programm AVIs frißt.

Und AVC in AVI is so ne Sache... aber am besten: testen. Wenn es klappt, dann is gut, falls nicht denken wir darüber nach, wenn es soweit ist.

Hm, ohne meckern zu wollen, aber ist es nicht seine (JoeCools) Sache, warum er was macht?

Vielleicht sind es ja haufenweise unkomprimierte Aufnahmen, die er mit minimalem visuellem Verlust (Kompromiß!) als MP4s gespeichert hat, da er diesem Verlust eben der höheren Praktikabilität eines Scheibenbackups und den Kosten eines Plattenbackups, den Vorzug gibt.

Wichtig ist doch allein die Frage, ob es geht, und wenn ja, wie.

Hm, ich wage mal die Behauptung, daß es einfacher als mit MeGUI (die auf x264 zugeschnittene version), BeLight zum Audiokodieren und YAMB zum Muxen nicht geht. Und in Selurs Guide sind eigentlich alle bei x264 über MeGUI einstellbaren Optionen wunderbar, sogar mit empfohlenen Werten für diverse Szenarien beschrieben.

Klar ist es das, aber Du weißt doch, wie die Menschen sind. Da grassiert doch immer wieder die Versionitis, und nichts ist da so tödlich wie zu wissen, daß man ein Produkt benutz, welches nicht weiterentwickelt wird, bzw. welches weiterentwickelt wurde, einem selbst aber der Fortschritt vorenthalten wird.

Zitat von Kopernikus

Ateme verkauft den Encoder auch anderweitig. Nur eher nicht an Privatleute und Einzelanwender. Da ist auch nicht so das große Geld zu machen.
...

Das stimmt wohl.
Aber meine Aussage, daß x264 Ateme den Rang ablaufen könnte, war auch eher auf Nero bezogen, denn da war ja der Ateme Codec ein sehr wichtiges Kaufargument für ihre Produkte. So galt doch bei Erscheinen das Nero Paket mit dem Ateme Codec als erstes, kommerziell erhältliches Produkt, welches recht einfach und v.a. auch sehr schnell AVC Videos erstellen konnte.

Hm, dann würde mich mal interessieren, warum Nero nicht schon längst die neue Version eingebaut hat, wo sie doch mit der alten schon so großen Erfolg hatte.

Klar schlägt sich die alte Version noch immer gut, aber ich befürchte über kurz oder lang wird ihr x264, allein schon der Möglichkeit halber, in Ein-Klick-Programmsammlungen integriert werden zu können, den Rang ablaufen.

Und für all diejenigen, die gerne viele Schrauben zum daran drehen haben, ist ja jetzt schon x264 wesentlich interessanter.

Hm, mal ne ganz andere Frage: Vertreiben die Jungs ihren Codec eigentlich auch selbst, oder spielen sie nur Zulieferer? DEnn wer entwickelt schon was, nur damit es anschließend monatelang "ready for useage" verbringt, ohne wirklich eingesetzt zu werden.

Is' denn der neue Ateme schon fertig? Hab' dahingehend noch nix gehört.

Nochmal zu den Nero DLLs. Ich hatte bis vor kurzem auch das Problem, daß BeLight mit den DLLs von Nero 6.6 zwar klaglos seinen Dienst verrichtete, bei denen von Nero 7 aber streikte. Wie gesagt, bei mir reichte es aus, die mfc71.dll aus der 7er Nero installation mit ins BeSweet-Verzeichnis zu packen, und schon ging es.

Zitat von nexustheoriginal

Die NeroIPP.dll wird benötigt.

Außer den drei standardmäßig aufgezählten (neroipp.dll, aac.dll und aacenc32.dll) braucht man manchmal noch die mfc71.dll, die auch irgendwo (bei den nero shared files) rumfliegt. Die 6.6er liefen z.B. bei mir ohne, die 7er nur mit dieser Datei. Stand irgendwann mal im englischen Doom9-Forum