OK, danke für den Fehlerbericht.
Beiträge von stax76
-
-
Neues Build ist gleich online (Upload dauert ca. 2 min).
-
Sind leider mehrere Dialoge betroffen.
-
Neues Build folgt in ca. 15 Min.
-
steht in der Systemsteuerung oder der Logdatei
https://postimg.org/image/psv6255il/
100% bedeutet 96 DPI
150% sind 144 DPI usw., ich entwickle mit 288 DPI 4K unter W10 und teste regelmäßig 96 DPI unter W7 mithilfe der Lupe in vmware -
Also 100% oder 96 DPI? Steht auch in der Logdatei sobald du eine Quelldatei öffnest, zu finden über Tools > Log Datei.
Ist eigenartig weil ich 1920x1080 mit 96 DPI unter W7 getestet hab, werd es nochmal mit W10 überprüfen.
-
Hi,
müsste dazu folgendes wissen:Windows Version
DPI/Zoom Wert
Auflösung -
Das Icon hat keine besondere Bedeutung, das ich ein paar Wochen oder Monate keine große Lust hab viel am Rechner zu sitzen kann immer passieren, sonst geht alles weiter wie bisher.
-
Wirf mal ein Blick auf meine Signatur bezüglich Logdatei.
Vielleicht kannst du noch ein kurzes Video dazu hochladen.
-
Hi RoadrunnerRR,
wenn ich die Sache richtig verstanden hab dann ist das Problem die Höhe des Dialogs. Ich hab ein neues Build hochgeladen wo die einzelnen Text Felder auf ca. 10 Zeilen beschränkt sind.
Eventuell ist es geschickter den Code auszulagern und in StaxRip zu importieren, siehe Import:
http://avisynth.nl/index.php/Import
edit:
15 Zeilen dann im nächsten Build
-
Es hat leider eine StaxRip.exe.config Datei gefehlt und die Funktion zum Erinnern der Fensterpositionen wurde versehentlich entfernt.
-
Hier nochmal ein Test Build bevor am Sonntag nach 7 Monaten wieder ein stabiles Release kommt:
-
Hi, ist OK weil:
Jeder einzelne Job wird in einer neuen und eigenen Instanz ausgeführt, eine Instanz führt niemals mehr als einen Job aus.
Du kannst mit der Hauptfenster Instanz weiter arbeiten oder sie komplett schließen.
Die Standby/Shutdown Funktion geht nur wenn ausschließlich Job Instanzen ausgeführt werden.
Nach wie vor kann man beliebig viele Instanzen parallel die Jobliste abarbeiten lassen.
-
Hab gerade ein neues Build hoch geladen, die demuxing GUI unterstützt neben mkvextract und mp4box jetzt auch ffmpeg (bis jetzt nur Audio), da ich die Einstellungen nicht zurückgesetzt hab muss man sie manuell zurücksetzten:
Tools > Settings > Demuxing > Restore
oder nur den ffmpeg Demuxer hinzufügen:
Tools > Settings > Demuxing > Add
Standardmäßig sind avi, ts und flv als Eingabe Dateityp für den ffmpeg Demuxer eingestellt, lässt sich beliebig editieren.
Außerdem sollten ffmpeg und mkvmerge jetzt auch für TS korrekte Stream IDs verwenden.
Mit dem Brexit Sample war der Ton async wenn Audio demuxt wurde (delay stammt von MediaInfo), wenn man nicht demuxt und konvertiert sondern mkvmerge direkt die Audiospur aus der TS Datei einlesen lässt dann ist alles synchron.
-
Zur Erkennung der Stream IDs und allen anderen Stream Eigenschaften benutzt StaxRip grundsätzlich MediaInfo, für jeden Dateityp, Programme wie mkvinfo werden nicht benutzt. Mit TS funktioniert das leider nicht, irgendwelche Änderungen daran wären eher schwer und wenig aussichtsreich.
DGDecNV würde mit deinem Sample zurechtkommen, gilt auch sonst als zuverlässig, in StaxRip ist DGDecNV so integriert dass es alle Audiospuren extrahiert (demux) werden.
Ansonsten kannst du Settings > Demuxing > dsmux versuchen, damit wird die TS Datei in eine MKV Datei umgewandelt, dafür muss der Haali Splitter installiert sein, mit manchen Dateien gibt es leider Probleme, dsmux wird nicht mehr aktiv entwickelt. TS-Doctor hat ebenfalls eine Option um mit Haali MKV zu erzeugen, ich kann dir nicht sagen ob dass stabiler wie dsmux ist.
Ansonsten kann man auch mit mkvtoolnix nach MKV konvertieren, in der Vergangenheit war es so dass mkvtoolnix scheinbar mit Zeitstempeln gearbeitet hat was in StaxRip zu async Problemen geführt hat, wenn man TS-Doctor verwendet kann es sein dass es dieses Problem nicht gibt, müsste man probieren, die von Haali erzeugten MKV Dateien haben keine Async Probleme verursacht.
Kann TS-Doctor nicht demuxen?
-
Danke schon mal für das Sample, hab auch wieder eine DVB Karte.
Hab da geschlafen, ist im letzten Build wieder OK.
-
Danke für die Infos und das Sample, ich bin ein paar Tage Offline, dann schau ich es mir an.
-
Ich werd meine Samples in Bezug auf Stream IDs überprüfen, ansonsten könntest du noch l-smash und dgdecnv versuchen, besonders dgdecnv galt in Bezug auf TS immer als zuverlässig mit sehr gutem Support (technisch meine ich jetzt...), hab mit beiden schon gute Erfahrung mit TS gemacht. Wär's für dich möglich ein Sample hochzuladen? Logdatei wäre auch noch interessant. ffmpeg kann TS in etwa gut wie die meisten anderen Tools, soll heißen eher ungenügend. Es gibt für TS mit AVC kaum zuverlässige kostenfreie Tools, zumindest nicht zu dem Zeitpunkt als ich noch eine DVB Karte hatte, meine Karte war PCI was mein Motherboard nicht mehr unterstützt hatte, eventuell kauf ich mir bald wieder eine Karte, vielleicht kann jemand eine DVB-C Karte für PCI-E empfehlen.
-
Zitat
Ich hab z.B. Probleme L-SMASH Work und FFMS2 zu finden die für AviSynth+ 64b geeignet sind. Tante Google spuckt mir da nix aus.
StaxRip enthält ca. 30 AviSynth+ x64 plugins und ca. 15 VapourSynth x64 plugins, L-SMASH-Works und FFMS2000 sind für AviSynth+ x64 und VapourSynth x64 enthalten, es gibt ein Apps Dialog mit URL zur Webseite wo man meistens Download URLs findet.
-
Soviel ich weiß sind ts-doctor und DGDecNV ziemlich gut was die Vermeidung von async Problemen betrifft.
ZitatDie Frage ist natürlich trotzdem, warum dieses Problem bei AviDemux nicht passiert. Habe Stax76 aber schon das log-File bereitgestellt.
Vielleicht kann AviDemux gut mit TS umgehen, die meisten Tools haben mit TS eher große Problem.