Beiträge von matbal

Meiner Meinung nach ist das Ergebnis vom Sample ganz passabel:

Samples.mkv.html

Besser ist es so (Pfade müssen angepasst werden) - es sind weniger Zeilen und es ist übersichtlicher...

LoadPlugin("c:\...\...\DGDecode.dll") 
MPEG2Source("Samples.d2v")


Import("c:\...\...\srestore.avs")
leakkernelbob()      # oder ein anderer Bobber
srestore()

Wie das Script genau arbeite, brauch man gar nicht zu wissen, nur wie man die enthaltene Script-Funktion anwenden muß. Und selbst da sind schon sinnvolle Voreinstellungen enthalten, die man erst einmal ausprobieren kann.

Damit alles übersichtlich bleibt, speicherst du das Script in eine separate Datei, z.B. srestore.avs.
Diese Datei importierst du dann einfach und rufst daraus die Script-Funktions srestore() auf.
Ohne Parameter werden die Voreinstellungen genommen. Die Parameter brauchst du nur anpassen, wenn du mit dem Ergebnis nicht zufrieden bis und weiter optimieren willst.

p.s. Der zweite Deinterlacer nach srestore() ist überflüssig.

Ich hatte heute auch das gleiche Problem. Ein ziemlich 'frisches' Betriebssystem Win7 x64. Es mußten also vorher einige Programme installiert werden, bevor StaxRip startet.

Dann, beim Versuch, die MPG-Datei zu öffnen, wurde der fehlenden YV12 Codec bemängelt. StaxRip wollte ffdshow oder xvid dafür einrichten. Nach der Einrichtung (xvid) hat StaxRip die MPG-Datei geöffnet und angefangen, die vorbereitenden Schritte durchzuführen. Bis dann die in den ersten Thread-Beiträgen beschrieben Fehler aufgetreten sind.

Im Temp-Ordner waren die demuxten Dateien, die d2v-Datei und eine avs-Datei. Also habe ich geprüft, ob ob die avs-Datei fehlerhaft ist. Die Hinweise hier im Thread haben mich auf die richtige Spur gebracht. Das heißt, die avs-Datei ließ sich zwar im Media Player abspielen, zeigte aber kein Bild in VirtualDub. Unter File Information in VDM wurde angezeigt: FourCC YV12 und Decompressor xvid.

Offenbar hat der YV12 Decoder doch nicht richtig funktioniert. Ich habe mir jetzt den Codec von http://www.lillevold.com/files/ installiert. Danach ließ sich das Video auch in VirtualDubMod richtig öffnen.

Und StaxRip läuft auch wieder.

(Ich habe noch nicht weiter untersucht, warum mit xvid oder ffdshow das Decodieren von YV12 nicht funktioniert hat, bzw. was ich falsch gemacht habe. In meinem XP-Rechner wird die YV12-Decodierung nämlich von ffdshow übernommen.)

Ich finde es interessant. Eigentlich bräuchte diese Stelle überhaupt nicht deinterlaced werden. Ich weiß schon, warum ich Programme mit Vorschau vorziehe.

Was mir auffällt, ist, daß das Originalbild offenbar schon digital bearbeitet wurde. Für mich sehen die Flugzeugszenen nach digitalem Zoom aus, vielleicht ist auch noch eine kleine Drehung um ein paar Grad dabei. Man sieht quasi schon die einzelnen "Zeilen". Das scheint auch den Deinterlacer verwirrt zu haben.

Gruß

Schau mal unter AddBorders in der AVISynth-Hilfe nach...

Gruß

Welchen Decoder verwendet der Player?

Beim mplayer2 zum Beispiel kannst du das unter "Eigenschaften" => "Erweitert" sehen. (Mit dem WMP kenne ich mich nicht aus.)
Mit ffdshow als Decoder habe ich hier keine Probleme.

Eigentlich kenne ich das Verhalten nur von VirtualDub, wegen dem VfW-Interface. Wenn man sich vor Augen hält, daß zum decodieren eines B-Frames immer zwei Referenzbilder schon decodiert sein müssen, ist das leicht nachvollziehbar.

Da AVI ja eigentlich linear arbeitet, mußte man mit Tricks arbeiten:

1. Man gibt den Film immer ein Bild später wieder (kein PB). Dann hat man die beiden für ein B-Frame benötigten Referenzen nämlich schon dekodiert.

2. Oder man packt erst einmal zwei Bilder in einen Frame zusammen (PB). Dann hat man beim nachfolgenden B-Frame die benötigten Referenzen parat. Damit die Frameanzahl trotzdem stimmt, muß für jedes "gepackte" Frame ein zusätzliches N-Frame (Bild ohne Inhalt) eingefügt werden. Mit dieser Methode hat VirtualDub bzw. das VfW-Interface keine Probleme bei der rechtzeitigen Darstellung der Bilder.

Gruß

sidewinder711

Wie hast du denn das "falsche" Frame festgestellt?

Wenn man die beiden Filme per Direct Show Decoder anschaut - das sind praktisch alle Player -, sind sie absolut gleich. Diesen Unterschied kann man nur sehen, wenn der Decoder die alte VfW-Schnittstelle verwendet (z.B. direkt in Virtual Dub). Das ist aber kein wirklicher Fehler, sondern prinzipbedingt

Mit diesem AVISynth-Script kannst du selber testen, daß alles OK ist:

a=directshowsource("test24-no-pb.avi")
b=directshowsource("test24pb.avi")


stackvertical(a,b)

Gruß

Zitat von stax0711

Teste bitte mal eine neue beta, hoffe dass jetzt alles 100% korrekt funktioniert.

Ja, super. Jetzt funktioniert es richtig. Das sind ja richtig fixe Bug Fixes

Gruß

Zitat von Brother John

Ist bei dir in den StaxRip-Projektoptionen "Use ITU-R" aktiviert? Das brauchst du, um auf 640×480 zu kommen. Aber auch wenn das nicht der Fall ist, rechnen sowohl StaxRip als auch MeGUI falsch.

Die Option ist aktiviert.

Ist nur ein bißchen dumm, wenn man sich nicht auf die Ergebnisse verlassen kann. Ich bin da auch nur durch Zufall drauf gestoßen, weil ich zufällig nicht gecropt hatte.

Zitat von Brother John

Ein bisschen weiterspekuliert dürfte der Fehler daher kommen, dass die modernen Encoding-Frontends versuchen, das Seitenverhältnis des Quellmaterials immer automatisch zu bestimmen und dafür gerne das DAR nehmen.

Vielleicht sollte das ürsprünglich bei den krummen DVB-Auflösungen, wie 352x576, 480x576, 528x576 und 544x576 helfen :hm:

Wobei bei der 544er Auflösung ja noch ein zusätzlicher Fehler entsteht:
544 * 4/3 = 725

Gruß

Hallo Leute,

ich habe eine Frage zur Berechnung der Zielauflösung.

Bei einer DVD-Recorder-Aufnahme in PAL 4:3 / 704x576 schlägt StaxRip eine in die Breite gezogene Zielauflösung von 640x464 Pixel vor. Laut Brother Johns Encodingwissen sollte aber ziemlich genau eine 4:3 Auflösung herauskommen.

Habe ich irgend eine Einstellung übersehen? Oder Fehler im System?

Gordian Knot kommt im etwa auf die gewünschte Zielauflösung von 640x480.

MeGui schlägt allerdings auch die krumme Auflösung von 640x464 vor. Wird hier vielleicht die nach der gleichen Formel gerechnet?

Gruß

Stimmt. Wenn der Panasonic-DVD-Recorder DVD-RAM beschreiben kann, kann er es auch einlesen. Nur müssen die Daten auch so draufgeschrieben sein, wie der Recorder es erwartet. Die DVD-RAM muß im DVD-VR Mode (Videorecorder-Mode) beschrieben sein.
(DVD-VR-Struktur enthält einen Ordner DVD_RTAV mit VR_MOVIE.VRO und einer passenden IFO).

Panasonic-DVD-Player sind da nicht so wählerisch. Die kommen auch mit DVD-RAMs zurecht, die im Videomode beschrieben wurden (VIDEO_TS und VOBS)

Obwohl Nero dieses DVD-VR Format theoretisch erzeugen kann (editierbare DVD), ist die entstandene DVD-RAM incompatibel. Panasonic erkennt sie nicht.

Ein Programm, welches wirklich 100-prozentig Panasonic-kompatible DVD-RAMs erstellen kann, ist TMpgEnc Mpegeditor 2.0.
Von hier können die DVD-RAM-Titel auch in Highspeed (verlustlos) auf die Recorder-Festplatte kopiert werden.

Gruß

DVD-RAM muß nicht finalisiert werden. (Am PC wird sie wie eine große Diskette verwendet. Einfach Datei per Drag&Drop draufkopieren und gut ist's.)

Das Problem wird sein, daß dein DVD-Videorecorder nicht mit DVD-RAM umgehen kann. Dir bleibt nichts weiter übrig, als DVD-R oder DVD-RW (oder die Plus-Varianten davon) zu verwenden. Damit kommen die meisten Player zurecht.

Gruß

Probiere mal das Script "MRestore.avs"

Dein Clip sieht damit zumindest ganz passabel aus:
http://www.file-upload.net/download-697454/test.avi.html

Gruß

Du könntest z.B. Foobar2000 oder Winamp mit MP3-Output-Plugin verwenden.

Foobar2000 ist einfach, es gibt aber nur eine Einstellung - den Qualitätregler, entspricht den neuen Presets von Lame "-V 0" bis "-V 9". In Foobar2000 gibt es im Kontextmenü der Titel den Menüpunkt "Convert". Der MP3-Encoder greift auf Lame.exe zurück. Encodet wird nur mit variabler Bitrate. (Grund: Foobar2000 ist auf Qualität ausgelegt)

In Winamp kannst du dir ein Output-Plugin für MP3 installieren. Die meisten dieser MP3-Output-Plugins verwenden ebenfalls Lame (lameenc.dll), bieten aber mehr Einstellmöglichkeiten.

Mit beiden Programmen kannst du mehrere WMAs in einem Rutsch konvertieren.

Gruß

qfactor

Bist du dir sicher, daß beide Videos identisch sind? Wenn die Videos unterschiedlich geschnitten sind, gibt es Probleme.

Deswegen würde ich eher versuchen die Videos zu synchronisieren. Sollte mit AVISynth funktionieren. (Abweichungen der Bilder sieht man sofort.) Wenn die Videos exakt übereinstimmen, paßt auch das Audio.

Warum willst du denn den Ton synchronisieren?

Ich würde die Filme (das Video) synchronisieren. In AVISynt beide Dateien laden und übereinander anzeigen. Dann kannst du einen Film in der Framerate solange anpassen, bis sie synchron sind.
Außerdem fällt bei Video auch eher auf, wenn einer der Filme geschnitten wurde.

Wenn die Filme synchron sind, sind die Töne auch synchron. Dann kannst du den Ton vom veränderten Film als WAV exportieren.

Das Delay, das beim Schneiden mit Cuttermaran entsteht, sieht man in der Schnittliste. Das Delay (Delta) liegt zwischen -16ms und +16ms pro Bereich und ist damit praktisch nicht hörbar. (Weniger als die halbe Dauer eines Bildes)

Wenn Cuttermaran fehlerhaft schneiden würde, würden die Fehler auch im von Cuttermaran gemuxten mpg enthalten sein. Muxen würde also das Problem nicht beseitigen.

BeSweet normalisiert nach der Azid-Kompression. Das kann man nicht beeinflussen.

Wie sich die Option "Dialog Normalization Reduction" auswirkt, weiß ich nicht. Die habe ich noch nie verwendet.

Zitat von HQ-LQ

bei der Azid-Dynamikkompression gibt es 4 möglichkeiten
welche ist denn nu die richtige?

Kann man pauschal nicht sagen. Es kommt auf die Dynamik vom Quellmaterial an. Die entscheidende Instanz ist dein Ohr...

Das Normalisieren hebt die Lautstärke so weit an, daß die lauteste Stelle gerade nicht übersteuert.

Ist die Dynamik der Quelle aber sehr hoch (Lautstärkeunterschied zwischen lauten und leisen Stellen), dann sind nach dem Normalisieren die leisen Stellen noch zu leise. Hier kommt jetzt die Dynamikkompression ins Spiel. Durch die Dynamikkompression werden die laute Pegelspitzen gedämpft. Dadurch daß dann "mehr Luft" nach oben ist, wird beim anschließenden Normalisieren die gesamte Datei lauter.

Ich habe leider keine optimalen AC3-Dateien gefunden, um den Einfluß der drei Kompressions-Einstellungen genau bestimmen zu können. Bei meinem Testschnipsel, der relativ wenig dynamisch war, kam ich auf folgende Unterschiede, fallst du damit etwas anfangen kannst.

• Light ca. 3 dB
• Normal ca. 6 dB
• Heavy ca. 8 dB

(Inverse ist ein Expander und damit zum Erhöhen der Lautstärke ungeeignet. Hier würde nur Lautes noch lauter werden)

Ich bin beim Experimentieren erst darauf gekommen, daß der Acid-Kompressor alleine die Lautstärke gar nicht erhöht, sondern nur die Pegelspitzen reduziert. (Ist dann eigentlich ein Limiter.)
Erst das anschließende Normalisieren erhöht die Lautstärke. Deswegen muß neben der Kompression immer noch die Normalisierung aktiviert sein.

Gruß

Zitat von HQ-LQ

was ist besser Dynamickompression oder Boost
ggf. denke ich auch daran zu der aac 5.1 auch eine aac 2.0 zu erstellen

Ich weiß nicht, ob es noch interessiert, aber ich habe jetzt mal ausführlich getestet. Mein Ergebnis des Tests: Ich würde nur zur Azid-Komprimierung greifen.

Die Azid-Dynamikkompression ist eine echte Dynamikkompression. Damit meine ich eine echte dynamische Verstärkung. Wenn man hier übertreibt, kann es zu auffälligen Lautstärkeschwankungen (Pumpen) kommen.
Die Azid-Dynamikkomprimierung arbeitet nur mit 5.1-Material.

Boost ist dagegen eine nichtlineare Verstärkung. Das bedeutet, daß das Eingangssignal mehr oder weniger verzerrt wird. Das K.O.-Kriterium für mich. Je Stärker der Faktor und je lauter das Eingangssignal ist, um so stärker die "Verformumg". Das kann man leicht an einer Dreiecksschwingung in einem WAV-Editor beobachten.
Die DSPguru-Einstellung arbeitet sogar fehlerhaft.
(Im Prinzip könnte man die Arbeitsweise von Boost mit der Bandsättigung bei Analog-Kassetten vergleichen)

Gruß