Beiträge von maju

Zitat von maju

Üblicherweise nehme ich von deutschem Himmel-TV auf das auf den HD Kanälen mit 1080i25 sendet. Nach der Reduktion der horizontalen Auflösung auf 1280 und einem Durchlauf durch Staxrip habe ich dann ein wunderbares progressives MKV das selbst auf dem Beamer beste Bilder liefert und meist ca. 1.5GB gross ist.

Das Ösi-TV sendet aber nun in 720p50 und wenn ich den TS mit gleichen Einstellung durch StaxRip laufen lassen ist das MKV 3-4 GB gross!
Primäre Ursache dafür dürfte sein, dass das Ergebnis beim Ösi-TV ein MKV mit einer Framerate von 50p ist und beim deutschen Himmels-TV ein MKV mit 25p.

Frage: Wo kann ich in Staxrip die Framerate einstellen, die im finalen MKV sein sollte? In den Profile Einstellungen habe ich dazu nichts gefunden ... und wenn das nicht der einzige Grund ist wieso progressive Quellen zu deutlich umfangreicheren Ergebnissen führt, so bitte ich um eure Hilfe mit welchen Einstellungen man das verhindern kann.

Ich kann leider die Option SelectEven oder SelectOdd in den Filter Einstellungen von Staxrip nicht finden bzw. nicht hinzufügen. Wie füge ich diese Optionen dem AVS Script hinzu?
Ich habe nur die AssumeFPS Option gefunden ... aber die führt zu keiner Verkleinerung.
Hier wäre wohl die ChangeFPS Option die richtige Option.
Aber auch ChangeFPS kann ich in den Filter Settings von StaxRip nicht finden ...

Üblicherweise nehme ich von deutschem Himmel-TV auf das auf den HD Kanälen mit 1080i25 sendet. Nach der Reduktion der horizontalen Auflösung auf 1280 und einem Durchlauf durch Staxrip habe ich dann ein wunderbares progressives MKV das selbst auf dem Beamer beste Bilder liefert und meist ca. 1.5GB gross ist.

Das Ösi-TV sendet aber nun in 720p50 und wenn ich den TS mit gleichen Einstellung durch StaxRip laufen lassen ist das MKV 3-4 GB gross!
Primäre Ursache dafür dürfte sein, dass das Ergebnis beim Ösi-TV ein MKV mit einer Framerate von 50p ist und beim deutschen Himmels-TV ein MKV mit 25p.

Frage: Wo kann ich in Staxrip die Framerate einstellen, die im finalen MKV sein sollte? In den Profile Einstellungen habe ich dazu nichts gefunden ... und wenn das nicht der einzige Grund ist wieso progressive Quellen zu deutlich umfangreicheren Ergebnissen führt, so bitte ich um eure Hilfe mit welchen Einstellungen man das verhindern kann.

Die Gründe für die unterschiedlichen Resultate beim Recoden mit Staxrip und MeGUI liegen tatsächlich bei der Vorbereitung des .TS Files und nicht an x264 bzw. dessen Parameter bei der Codierung. Wenn ich nämlich MeGUI ein AVS Script das von StaxRip erzeugt wurde als Video Input angebe (ja, das geht!) dann gibt es keine sichtbaren Unterschiede im resultierenden H264 Stream.

D.h. der FileIndexer von MeGUI - der das TS File analysiert und das AVS Script erzeugt - ist für meine HD Aufnahmen unbrauchbar. Da liefert doch StaxRip die perfekten Ergebnisse.

Wenn es nur auch so beim Erzeugen von 5.1 AAC Sound wäre ...

Ergänzung:

Wie bereits erwähnt schmiert BeSweet meist ab bei der Rekodierung von AC3 5.1 nach AAC 5.1 aus HD Aufnahmen.
Neuere Versionen der bsn.dll als die in der aktuellen StaxRip Version integrierte gibt es anscheind nicht.
Das Umstellen von Automatic nach ffmpeg führt ebenfalls - wie bei besweet - zu einem Crash der Audiokodierung.
Ich vermute dabei ein Problem mit der Filegrösse. Die WAV Dateien sind meist über 2GB gross.

Die einzige Option bei AAC5.1 Codierung die nicht zum Absturz führt ist eac3to.
Nachteil: Meist sind die Audiospuren viel zu leise.

Ich bin jetzt dazu übergegangen die Tonspuren nochmals mit MeGUI nach AAC 5.1 zu kodieren was keinerlei Abstürze zur Folge hat. Anschließend muxe ich neu nach MP4 oder MKV.

Wäre schön, wenn in Zukunft StaxRip die gleichen AAC 5.1 Tools wie MeGUI verwenden könnte damit ich auch meine HD Aufnahmen ausschließlich mit StaxRip konvertieren kann, denn die H264 Streams die StaxRip erzeugt sind absolut top. Bei MeGUI (obwohl das auch x264 verwendet) sind ein Haufen Artefakte vorhanden ... auch bei absolut identen x264 Parameter!

Also Staxrip kommt in der aktuellen Version mit einer bsn.dll vom 14.05.2007.
Diese bsn.dll crasht aber bei Codierung von AC3 5.1 nach AAC 5.1.
Hat Irgendjemand eine bsn.dll nach dem 14.05.2007?

Zitat von LigH

Vermutlich nicht, ohne dass der Quellcode von StaxRip so geändert wird, dass es ähnlich wie BeHappy oder MeGUI in diesem Bereich arbeitet.

Was muss ich tun um an deine gepatchte bsn.dll zu kommen?
Würde doch recht ungern auf die angenehme Automatik von Staxrip verzichten ...

Zitat von Werniman

Sofern du eine Heimkinoanlage hast, über die du das Ergebnis anhören willst, solltest du vor einer Konvertierung unbedingt sicherstellen, daß diese mit AAC 5.1 zurechtkommt. Das ist nämlich längst nicht bei jeder Anlage der Fall. Selbst wenn die Hersteller versprechen,daß AAC abspielbar ist, heißt das nicht in jedem Fall,daß es sich dabei auch um AAC 5.1 handelt, manche können auch "nur" AAC 2.0 (also Stereo).

Bei mir macht das ein Audiodecoder ...

Vielen Dank für die Info.
Wie lassen sich aber die Tools in Staxrip integrieren?

Hallo,

StaxRip funktioniert bei mir seit Jahren sehr gut.
In habe es aber nie geschafft eine DVB Aufnahme mit AC3 5.1 in einen AAC 5.1 Sound zu wandeln.
Dabei stürzt BeSweet stets ab.
Die Codierung in AAC 2.0 funktioniert hingegen einwandfrei.

Im Web findet man Infos, dass die bsn.dll durch eine gepatchte Version ersetzt werden soll.
Die Downloadlinks funktionieren aber leider nicht mehr.

Anbei noch eine Command Line bei mir zum Absturz führt:
"C:\StaxRip\Applications\BeSweet\BeSweet.exe" -core( -input "D:\Daten\Videos\test\test.wav" -output "D:\Daten\Videos\test\test.m4a" ) -ota( -norm 0.97 ) -bsn( -vbr 0.3 -6chnew )

Wo finde ich also die genannte bsn.dll die das Problem behebt?

2 Fragen:

1) Ich zeichne per DVB-S Filme mit AC3 Sound auf und schneide innerhalb von StaxRip die Werbung weg. Ich konvertiere nach AVI mit XVid und hätte gerne AC3 Sound drinnen. Dazu hat man die Möglichkeit das existierende AC3 Sound File zu muxen. Leider wird aber hier das bestehende, ungeschnittene File verwendet! Wie erreicht man, dass hier der AC3 Sound auch geschnitten wird?

2) Bei Sendern die das Bildverhältnis wechseln, erkennt StaxRip oft nicht das korrekte Bildverhältnis weil oft jenes Bildverhältnis verwendet wird, dass bei Werbung, Vorspann oder Nachspann existiert. Diese werden aber weggeschnitten. Wie erreicht man, das StaxRip die Analyse des Bildverhältnis anhand des geschnittenen Materials vornimmt (also die weggeschnittenen Bereiche gar nicht berücksichtigt). Das gleiche gilt fürs Croppen. Auch hier wäre es sehr praktisch, wenn die Analyse anhand der Schnittpunkte vorgenommen würde da im jetzigen Fall oft die Cropränder anhand des wegfallenden Materials gesetzt werden (und der Film dann die Letterboxränder hat).

mfg
Martin

1. Du kannst in StaxRip schneiden! Das ist einer der Kodierschritte im Assistenten.

2. Verwende statt 2-Pass Konvertierung die 1-Pass Konvertierung von Xvid (Constant Quality Profile). 1-Pass Konvertierung liefert KEINE schlechteren Ergebniss wie 2-Pass. 2-Pass wird nur benötigt um möglichst exakte Filegrössen zu erhalten. Mit 1-Pass gibt es keine Compressibility Check.

Martin

Wie kann ich ohne Warnung HD Material mit StaxRip codieren?

Wenn ich MPEG-2 HD's aufzeichne, codiere ich diese anschließend immer mit Xvid, 1280x720 und 4 Mbit/s. Das Ergebnis ist ein Film mit "vernünftiger" Grösse ohne an Qualität zu verlieren (auf meinem RückPro erkenne ich keinen Unterschied zum Original-MPEG2-HD in voller Auflösung!).

StaxRip hat aber was gegen das Codieren von Xvid HD ;D
Der Schiebebalken für die Auflösung lässt nur Auflösungen bis max. 720 Punkte horizontal zu. Wenn die Auflösung und Video Bitrate dann manuell eingetragen werden, überschlägt sich StaxRip fast mit Warnungen ... obwohl das Ergebnis einwandfrei und dessen Qualität Spitze ist.

Wäre es nicht Zeit, StaxRip HD tauglich zu machen?

Mein Vorschlag: "Width" und "Height" bzw. den Schieberegler für die Auflösung nicht mit fix vorgegebenen Werten zu definieren, sondern abhängig vom geöffneten File. Hat das geöffnete File eine horizontale Auflösung von 1920 so sollte auch der Maximalwert des Schiebereglers bis 1920 gehen. Bei einer DVD sind es dann halt 720 ... Das gleiche gilt natürlich auch für die vertikale Auflösung.

Ich weiss jetzt auch nicht genau wie StaxRip die vorgeschlagenen Resize Werte ermittelt. Kommen die von DGIndex oder sind diese hardcoded? Ich habe für mich jedenfalls eine Faustregel bei der Umwandlung von MPEG-2 nach MPEG-4 gefunden, die eigentlich immer zu einem guten Ergebnis führt: Ursprungsauflösung / 2,25. Diese ergibt bei PAL (720*576) ein Ergebnis von ca. 185.000 Punkten für den Videostream. Bei HD Inhalten (1920*1080) ergibt das dann entsprechend 1280*720. Wie gesagt weiss ich nicht wie StaxRip die Resize-Werte ermittelt aber eventuell könnte dies so angepasst werden damit auch HD Inhalte eine entsprechend höhere Auflösung bekommen ...

Martin

Ich habe das ganze jetzt nochmals ausführlicher getestet. D.h. alle Kodierungen haben die selbe Zielauflösung und keinen Sound.
Ausserdem ist anzumerken dass bei Xvid und Exact File Size mindestens eine Qualität von 60% gewählt werden muss, damit die Warnungen verschwinden (bei H.264 50%). Ob 60% bei Xvid oder 50% bei H.264 ist egal. Die Ergebnisse sehen subjektiv gleich aus.

Ausgangsmaterial: MPEG-2 DVB Mitschnitt, 480*576 (4/3 Letterbox), 44.296 KB

Beim Encodieren habe ich die Standardeinstellungen von StaxRip genommen und so wenig wie möglich manuell geändert. Alle Files haben als Ergebnis 608*336 bei 16/9.

1. Xvid Constant Quality Standardeinstellungen -> 19.454 KB

2. Xvid Exact File Size, nach dem Compressibility Test Qualität auf 60% gesetzt (damit sind alle Warnungen bezüglich Auflösung/Bitrate verschwunden) -> 18.246 KB

3. H.264 Constant Quality Standardeinstellungen -> 18.617 KB

4. H.264 Exact File Size, nach dem Compressibility Test Qualität auf 50% gesetzt (damit sind alle Warnungen bezüglich Auflösung/Bitrate verschwunden) -> 12.237 KB

5. H.264 1P-Goodquality, nach dem Compressibility Test Qualität auf 50% gesetzt (damit sind alle Warnungen bezüglich Auflösung/Bitrate verschwunden) -> 11.870 KB

Bei Xvid Konvertierung gibt es praktisch kaum Unterschiede zwischen 1-pass (Constant Quality) und 2-pass (Exact File Size) Encodierung.
Bei der H.264 Encodierung sieht das anders aus: Constant Quality zeigt ein Ergebnis, dessen Filesize grösser als mit Xvid 2-pass wird! Bei H.264 sollte man deshalb für 1-Pass Encodierung unbedingt 1P-Goodquality verwenden. Das Ergebnis ist sogar noch einen Hauch kompakter als die H.264 Two-Pass-Konvertierung mit Exact File Size!

Fazit: Das momentane H.264 Constant Quality Profil in StaxRip sollte angepasst werden. Eventuell sollte das 1P-Goodquality Profil 1:1 übernommen werden.

BTW: Ich weiss das es mit StaxRip problemlos möglich ist, sich die Profile selbst anzupassen. Damit aber andere Benutzer auch was davon haben, sollte über die Abänderung des H.264 Constant Quality Profils für zukünftige Versionen nachgedacht werden.

Martin

Bezüglich Unterschiede zwischen "Constant Quality" (1-pass) und "Exact File Size" (2-pass):

Ich codiere nun mit Xvid Encoder eigentlich immer mit Constant Quality und bin mit dem Ergebnis sehr zufrieden. Es kommt mir nie mehr der Gedanke, eine 2-Pass-Konvertierung mit Xvid durchzuführen, da die Unterschiede kaum spürbar sind (aber mit 1-pass deutlich schneller encodiert wird).

Das sieht aber bei H.264 anders aus. Wenn ich hier "Constant Quality" mit z.B. "1P-Goodquality" vergleiche, gibt es erhebliche Unterschiede. Laut Voreinstellungen verwendet StaxRip eine Qualität von "50" für Constant Quality. Wenn ich als Encoder-Einstellungen für H.264 aber "1P-Goodquality" auswähle, den Compressibility Test mache und dann die Qualität auf "50" setze, sieht das Ergebnis gleich aus, aber das File ist deutlich kleiner! Ich habe zu Testzwecken mal eine Aufnahme in 3 Files umgewandelt:

1. AVI (Xvid constant quality + MP3, 592x336): 42.856 KB
2. MP4 (H.264 constant quality + AAC LC, 2ch, 592x336): 31.395 KB
3. MP4 (H.264 1P-Goodquality 50% + AAC LC, 2ch, 592x336): 23.717 KB

Rein subjektiv sehen alle 3 Ergebnisse gleich aus.

Warum ist aber bei H.264 constant quality das Ergebnis so viel grösser als bei 1P-Goodquality? Bei Xvid gibt es solche Unterschiede zwischen 1-pass und 2-pass Encodierung nicht ...

Martin

Zitat von stax0711

Kommt dass bei dir häufig vor? Wenn ja beschreib mir doch bitte ein etwas genaueren Anwendungsfall.

Es ist nicht soooo wichtig. Es ist reine Bequemlichkeit wenn man mit verschiedenen Containern rumspielt. Wenn man den gesamten Filenamen der Zieldatei (d.h. inklusive Dateiendung) als Bezeichnung für die .rip Datei benutzen würde, könnte man Jobs erzeugen ohne den Zieldateinamen manuell ändern zu müssen.

In der Praxis wird aber das Encodieren einer Aufnahme/DVD in verschiedene Containerformate eher selten sein. Somit nicht so wichtig ...

Martin

Zitat von stax0711

Einfach Projekt laden, Zieldatei umbenennen und Job hinzufügen. Wenn man ein Job hinzufügt wird im Verzeichnis der Quelldatei ein Projekt mit dem Name der Zieldatei erzeugt, dass schien die bequemste Methode zu sein.

Ok. Fehler gefunden. Wenn ich den Container ändere, ändert sich auch die Dateiendung und somit der Dateinamen. Das ist aber zu wenig "Änderung", damit StaxRip eine neue Jobbenennung anlegen kann, da nur der Bereich vor der Dateiendung für das Erzeugen des .rip Files verwendet wird.

Eine Anregung: Eventuell könnte das .rip File inklusive Dateiendung angelegt werden? Ich meine wenn man ein Lost.mp4 erzeugen will, könnte dann das .rip File nicht als Lost.mp4.rip angelegt werden? Wenn man dann auf die schnelle auch ein AVI oder MKV erzeugen will, müsste man dann keine andere Dateibenennung finden, da die .rip Files dann Lost.mkv.rip und Lost.avi.rip heissen würden ... ohne das händisch ändern zu müssen.

Martin

Danke für das Update.

Habe die 0.9.9.2 installiert und dabei einen Unterschied festgestellt. Wenn ich bisher einen Film in AVI als auch MP4 umwandeln wollte ging ich folgendermaßen vor: Files geladen und einen Job in die Jobliste eingestellt. Dann das .rip File kopiert und umbenannt auf z.b. .mp4.rip. Dieses .rip File geladen, die Einstellungen für Audio/Videodecoder und den Container abgeändert und dieses .rip File der Jobliste hinzugefügt.

Wenn ich nun das zusätzliche .rip File lade und abändere, lässt es sich nicht mehr der Jobliste hinzufügen.

Wie gehe ich vor, wenn ich für einen Film mehrere Jobs mit unterschiedlichen Einstellungen erstellen will?

Martin

Zitat von Naito

Schau mal im "AAC encoding und MP4 muxing HowTo" S. 16 (aktuelle Version im Post 33).

Das ist genau das, was ich gesucht habe!
Danke!!

Martin

Ich hab' mal ein paar Aufzeichnungen vom "HD FORUM" auf Hotbird gemacht, die ja MPEG-4 über DVB-S ausstrahlen und nicht DVB-S2 benutzen und wollte mal sehen, ob ich diese Broadcasts in ein "PC-verträgliches" Format konvertieren kann.

Das erste Problem trat schon beim Demuxen des TS auf. Wenn ich versuche diesen H.264 TS zu demuxen, dann streiken die üblichen Mittel wie ProjectX (GOP > 6MB). Ich habe aber dann einen Weg gefunden, diesen H.264 TS mit mplayer zu demuxen:
video: mplayer.exe -dumpvideo -dumpfile video.264 record.ts
audio: mplayer.exe -dumpaudio -dumpfile audio.mp2 record.ts

Jetzt stehe ich aber an.
Der Videostream muss jetzt noch umgewandelt werden, damit er in ein MP4 gemuxt werden kann das VLC, etc abspielen kann.
Wer weiss wie das geht? Ausserdem wäre es natürlich überaus interessant, wenn man diesen H.264 Stream noch irgendwie resizen könnte. um Bandbreite und Platz zu sparen.

Hat da Jemand Erfahrung?

Martin

Hab's jetzt mit dimzon Plugin und BeLight nochmals getestet:

1. Nero: Egal ob mit StaxRip, Nero Recode oder BeLight; der encodierte Sound ist nur auf PC's mit 5.1 zu gebrauchen. Auf PC's mit Stereolautsprechern ist der Sound verkehrt codiert (es werden nur die Effektlautsprecher ausgegeben).

2. Wenn ich mit WinAMP oder FAAC einen AAC 5.1 erzeuge, dann kann man die Filme auch auf PC's mit Stereolautsprechern nutzen ... aber leider nur in VLC
Wenn ich die neueste Version von ffdshow installiere um einen Filter für alle Player zu haben, die den Content via DirectShow rendern, geht's auch wieder nicht!
Umso seltsamer da FAAC und ffdshow ja auf die gleichen Bibliotheken aufbauen ...

Martin