Mein SVCD-BIN 2 VIDEO_TS batch converter

  • Den VCDImager würde ich auch gern selbst übersetzen, denn die aktuellsten Win32-Binarys haben die Versionsnummer 0.7.14 während die aktuelle Version 0.7.21 ist.

    Gruß Frank

  • Kontakte mich im ICQ, falls Du Unterstützung zum Kompilieren brauchst.
    Oder nimm die Binaries aus meinem Archiv, je nachdem was Dir lieber ist, die sind auf jeden Fall aus der 0.7.21 übersetzt worden.

  • Zitat von Sonic77

    Kontakte mich im ICQ, falls Du Unterstützung zum Kompilieren brauchst.


    Ich werde darauf zurückkommen. Im Moment habe ich dafür leider nur nicht die Zeit dafür.

    Gruß Frank

  • @ Sonic77:

    Zu den Fehlern, die katjarella für sich korrigiert hatte:

    Was da in der FOR-Schleife überhaupt passieren soll, ist mir schon schwer verständlich; mal auf deutsch übersetzt:

    Für jede Datei in dieser Gruppe entscheide: Wenn mal irgendwann vorher ein Programm mit Fehlermeldung beendet wurde, dann springe für jede Datei zur Fehlerbehandlung, ansonsten ...

    Warum soll er bei (sagen wir mal) 20 Dateien denn 20 mal zur Fehlerbehandlung springen? Reicht nicht einmal? (Okay - nach dem ersten GOTO wird er sicher nicht wieder zurück kommen.)

    Logischer wäre doch:

    - zuerst einmal den ERRORLEVEL abfragen und evtl. mit GOTO wegspringen
    - danach die FOR-Schleife laufen lassen, wenn er nicht weggesprungen ist

    (Grundlagen der Informatik - Logik, Algorithmen, Programm-Ablaufpläne...)

  • Die Abfrage des Errorlevel IN der FOR Schleife diente dazu, die Schleife ggfs. vorzeitig abzubrechen. Er soll keine weiteren Dateien mehr bearbeiten, sobald ein Fehler aufgetreten ist.

    Solche Konstruktionen

    Code
    FOR (...) DO IF ERRORLEVEL 1 (....) else (
    
    
    )


    erlaubt CMD.EXE aber offensichtlich nicht generell (bei mir aber lief es so, warum auch immer, genau so, wie ich es wollte).

    Das liegt aber nicht daran, das diese Konstruktion generell unsauber ist. Ich kann die FOR Schleife nun mal nur mit einem GOTO vorzeitig abbrechen. Es gibt kein "break", bzw. tut es in einer Batch Datei nicht das, was man von C oder Java gewohnt ist (Schleifenabbruch).

    CMD files sind halt eher vorsintflutliches IF-THEN-GOTO-Basic als eine gescheite Programmiersprache. Mir sind höhere Programmierkonzepte durchaus bekannt, jedoch lassen die sich in einer solchen Sprache ganz einfach nicht so sauber umsetzen, wie man es gewohnt ist. Und überhaupt muss man sich, wenn man saubere do...while... Schleifen usw usw gewöhnt ist, auf dem niedrigen Niveau dieser Skriptsprache erst mal zurecht finden.

    Die FOR Schleifen funktionieren auch gar nicht so, wie ich dachte. Die Befehle in einer FOR Schleife werden eher gleichzeitig als nacheinander ausgeführt, da hilfts auch nichts wenn man sie untereinander schreibt, wie ich.
    Das habe ich aber jetzt in der 0.3b umgangen, indem ich in den FOR Schleifen nur noch ein CMD file mit CALL aufrufe, das dann sauber sequentiell abgearbeitet wird.

  • so ich habe den Fehler gefunden...

    Bei Deinem Aufruf: del "%OUTPUT_DIR%\filelist.txt" >NUL 2>&1 gibt es einen ERROR, weil die Datei ja nicht existiert.

    Besser: IF EXIST "%OUTPUT_DIR%\filelist.txt" DEL "%OUTPUT_DIR%\filelist.txt" >NUL 2>&1

    Hier auch das Richtig verschachtelte:

    Und das dies alles "vorsintflutliches" ist, kann ich nicht sagen. Denn wenn Du Dir mal meine Scripte anschaußt, nutze ich den CALL um IM Script zu springen. Sehr selten verwende ich extra cmd Files und baue alles in ein Script ein.

    Sag mal, ein Danke oder sowas kommt bei Dir wohl eher selten über die Lippen? Oder hälst Du das alles hier für unsere ( meine ) Pflicht? Dies soll von mir aus nicht Arrogant wirken, jedoch habe ich diesen Eindruck von Dir.

    wann kommt die Unterstützung von VCD oder xSVCD Images? Denn es ist ja egal ob Du nur m2v oder auch m1v weiterverarbeitest...

  • Zitat von katjarella

    Und das dies alles "vorsintflutliches" ist, kann ich nicht sagen. Denn wenn Du Dir mal meine Scripte anschaußt, nutze ich den CALL um IM Script zu springen. Sehr selten verwende ich extra cmd Files und baue alles in ein Script ein.


    Vorsintflutlich ist evtl. etwas übertrieben, aber wenn man das mal mit den Möglichkeiten einer bash vergleicht... Und allzugroße einzelne Dateien mag ich nicht so sehr, aber das ist ja alles Geschmackssache im Endeffekt.

    Zitat von katjarella

    Sag mal, ein Danke oder sowas kommt bei Dir wohl eher selten über die Lippen? Oder hälst Du das alles hier für unsere ( meine ) Pflicht? Dies soll von mir aus nicht Arrogant wirken, jedoch habe ich diesen Eindruck von Dir.


    Ich bedanke mich zwar nicht immer, aber immer öfter:

    Zitat von Sonic77

    Dafür bin ich ja auch dankbar, das sollte um Gottes Willen keine Aufforderung sein, kein Feedback mehr zu geben!


    Und für das Raussuchen des Fehlers auf meine Anforderung hin gibt's auch ein Dankeschön von mir, das hätte es aber auch ohne die Aufforderung gegeben ;)
    In den sonstigen Foren, die ich kenne, ist es halt aber eher unüblich, sich für jeden Errorlog einzeln zu bedanken. Hört sich jetzt blöd an, aber ich meine das absolut un-sarkastisch.

    Und betrachte die Medaille doch auch mal von der anderen Seite:
    Wer Interesse an meinem Script hat, kann es benutzen, und hier Fehler posten. Und ich bemühe mich dann, sie auszubauen. Ich erwarte von niemandem, der das Skript eigentlich gar nicht benutzen möchte, daß er es testet und Fehlerlogs postet. Solange es bei mir funktioniert, bin ich zufrieden. Wenn andere es auch benutzen wollen, bin ich gerne behilflich und verbessere es, wenn Fehler auftauchen.

    Da ich jetzt irgendwie arrogant rübergekommen bin, möchte ich noch loswerden, das folgende Textpassage auch irgendwie arrogant rüberkam:

    Zitat von LigH

    (Grundlagen der Informatik - Logik, Algorithmen, Programm-Ablaufpläne...)


    Wenn es in CMDs eine "tollere" Möglichkeit gibt, eine laufende FOR Schleife mittendrin abzubrechen, als mit einem "goto" oder "exit", wäre die Erwähnung dieser Möglichkeit ein wesentlich besserer Kommentar als der Text in den Klammern gewesen.

  • Sollte sie eigentlich nicht - tut mir leid. Ich wollte damit lediglich ausdrücken, dass eine kopfgesteuerte Schleife in dem Fall einfach verwirrend ist.

    Wer bash gewohnt ist, der ist natürlich im Vergleich zu Batch richtig verwöhnt; ich würde mir kaum getrauen, in einer Batch-Datei Befehlsgruppen mit Klammern zu bilden, weil ich mir nicht sicher wäre (und vielleicht auch noch an Win9x-Kompatibilität denke).

    Übrigens, ein Hinweis zur "Gleichzeitigkeit": Zwischen Windows 2000 und XP soll sich das Verhalten von synchronem zu asynchronem Starten geändert haben. Die einzige Möglichkeit, ein Programm mit Sicherheit unter beiden Systemen so zu starten, dass auf das Ende gewartet wird, wäre wohl "START /WAIT ...". Ich hoffe, das nützt beim Basteln.

  • Zitat von LigH

    Sollte sie eigentlich nicht - tut mir leid. Ich wollte damit lediglich ausdrücken, dass eine kopfgesteuerte Schleife in dem Fall einfach verwirrend ist.


    OK, nix für ungut, aber irgendwie kam ich mir langsam etwas in die Ecke gedrängt vor, ohne wirklich zu kapieren warum.

    Zitat von LigH

    Wer bash gewohnt ist, der ist natürlich im Vergleich zu Batch richtig verwöhnt; ich würde mir kaum getrauen, in einer Batch-Datei Befehlsgruppen mit Klammern zu bilden, weil ich mir nicht sicher wäre (und vielleicht auch noch an Win9x-Kompatibilität denke).


    Ich war mir ja auch nicht sicher mit diesen Klammern. Ich hatte es irgendwo beim endlosen Googeln der letzten Tage mal gesehen, und einfach übernommen, und es funktionierte. Es kam allgemein sehr viel "try & error" zum Einsatz.
    Die offizielle Microsoft Doku zeigt nur FOR-Schleifen, die über eine Zeile gehen, daher habe ich mich in der V0.3b jetzt auf solche beschränkt. IF und ELSE hingegen dürfen nicht in der gleichen Zeile stehen, die muss man (vorzugsweise mit Klammern) auf mehrere Zeilen verteilen.

    P.S.: Eventuell konnte ich die FOR-Schleife nur deshalb über mehrere Zeilen verteilen, weil sie mit einem IF anfängt - und somit eigentlich das IF über mehrere Zeilen verteilt ist, und das FOR nur "indirekt".
    Ich hätte das IF ERRORLEVEL auch lieber hinter dem CALL gehabt, aber das funktionierte bei mir nicht. Wenn meine Vermutung, daß alle Befehle in Klammern nicht sequentiell, sondern gleichzeitig verarbeitet werden, korrekt ist, würde das auch Sinn machen!
    Mit der neuen Struktur in der V0.3b gehe ich dem Problem aber jetzt einfach komplett aus dem Weg, sicher ist sicher.

    Zitat von LigH

    Übrigens, ein Hinweis zur "Gleichzeitigkeit": Zwischen Windows 2000 und XP soll sich das Verhalten von synchronem zu asynchronem Starten geändert haben. Die einzige Möglichkeit, ein Programm mit Sicherheit unter beiden Systemen so zu starten, dass auf das Ende gewartet wird, wäre wohl "START /WAIT ...". Ich hoffe, das nützt beim Basteln.


    Ich hatte mal eine Zeit lang "START /WAIT /B /LOW" Parameter drin, damit das ganze auch brav als Hintergrundprozeß läuft und nicht stört. Dabei fiel mir auf, das der START befehl sehr empfindlich auf die Reihenfolge dieser 3 Parameter reagiert, mit zum teil sehr seltsamen Ergebnissen (jedenfalls nicht den gewünschten). Da es sich bei allen zum Einsatz kommenden Programmen, mit Ausnahme von QuEnc, um "reinrassige" Kommandozeilen-Tools handelt, wäre QuEnc der einzige Punkt, wo man evtl. auf Windows2000 ein "START" benötigen könnte. Das werd ich mal im Hinterkopf speichern für den Fall das ein 2000 User das Skript mal ausprobiert.

    P.P.S: Katjarella's Code-Korrektur korrigiert im Endeffekt nicht die Klammerstruktur an sich, sondern verteilt sie nur über mehrere Zeilen, soweit ich das sehe. Diese Änderung ist aber trotzdem vollkommen korrekt, da IF und ELSE nicht in der selben Zeile stehen dürfen.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!