Beiträge von Archimedes1

Zitat von markanini

I don't get preview in windows 7. Any ideas?

Is it only the preview? All other things are working? Are you able to do some conversions (resizing, for example)? On "Load Images" there are also a (very little) preview window. Same behaviour?

Mattaufgaben lösen, zählt, prinzipbedingt (Stichwort: selektive Suche), nicht unbedingt zu den Stärken heutiger Schachprogramme. Aber auch hierfür gibt es eine Speziallösung: Chest. Mit Hilfe von ChestUCI ist die Engine auch in Arena einsetzbar. Mit der Engine kann man allerdings nicht spielen, sondern nur Probleme lösen. Matt in 126 Zügen? Kein Problem für Chest. Oder doch?

Zitat

Dieses Programm löst Schachprobleme bis zu 126 Zügen (bzw. 63 bei
Hilfs-Matt/Patt), und zwar sowohl klassische Matt- und Patt-Aufgaben,
als auch diese beiden Problemarten in den jeweiligen Sonderformen
Selbst- bzw. Hilfs-Matt/Patt, d.h. also insgesamt 6 verschiedene
Typen von Schachproblemen.

Besonders bemerkenswert an Chest ist seine extreme Geschwindigkeit,
die ihn meiner Meinung nach an die Spitze aller Mattlöse-Programme
stellt. Außerdem berechnet Chest auf Wunsch auch den vollständigen
Lösungsbaum und liefert (je nach Einstellung) zusätzlich noch eine
weitere Fülle von interessanten Informationen zum Schach-Problem
bzw. seiner Lösung.

Alles anzeigen

Zitat von istvan78

mit dem Windows Media Encoder ist es natürlich möglich innerhalb der Datei das Audio auszutauchen... Es ist bloß nervig es 500mal zu wiederholen. (Es dauert jeweils ca. 30 Sek.)

Nicht ganz uninteressant in diesem Zusammenhang: AutoIt. Damit lassen sich Abläufe unter Windows automatisieren. Einfach Script erstellen (lassen) und anschließend ausführen.

Run("notepad.exe")
WinWaitActive("Unbenannt - Editor")
Send("Der Gascht hots Spätzlebschteck zschpät bschtellt.")

Ich werd' schön langsam alt. Das neue Kontrollkästchen für die Vorschau unter "Bilder laden" wanderte bei Größenänderungen nicht mit.

Zitat von Archimedes1

Einziger Nachteil: Das Öffnen mehr als einer Datei mit "Öffnen" über das Kontextmenü funktioniert nicht zuverlässig, wenn Fritz Photo noch nicht geladen ist.

Auch das sollte jetzt funktionieren. Ich habe mich nun doch durchgerungen und lasse die von Windows gestarteten Prozesse solange warten (max. 60 Sekunden), bis die Hauptanwendung fertig geladen wurde. Das sollte ausreichen.

Nach reiflicher Überlegung habe ich die Nachrichtengeschichte nun doch eingebaut. Wenn das Programm bereits gestartet ist, dann kann man auch außerhalb des Programms mit dem Explorer Bilder hinzufügen (z. B. per Drag and Drop auf die ausführbare Datei, "Öffnen mit" und "Senden an" im Kontextmenü).

Einziger Nachteil: Das Öffnen mehr als einer Datei mit "Öffnen" über das Kontextmenü funktioniert nicht zuverlässig, wenn Fritz Photo noch nicht geladen ist. Der Menüpunkt ist ohnehin erst sichtbar und von Belang, wenn mindestens ein ausgewählter Dateityp auf Fritz Photo registriert wurde. Alternative: "Senden an" verwenden (ist zudem auch performanter).

Die Sache scheint trivial – ist sie aber nicht. Eventuell ist es aber auch schon sehr spät.

Standardmäßig übergibt Windows beim "Öffnen mit" (im Kontextmenü) dem ausgewählten Programm nur einen einzigen Parameter. Mehr als eine Datei lässt sich auf diese Weise nicht öffnen.

Registriert man eine Anwendung für einen bestimmten Dateityp, dann lassen sich mit "Öffnen" (im Kontextmenü) zwar mehrere Dateien laden, aber Vorsicht, it’s cool man: Windows startet dann für jede selektierte Datei eine neue Instanz des verknüpften Programms! Programmtechnisch lässt sich das natürlich verhindern (indem man nur eine einzige Instanz zulässt). Auch die Folge-Parameter können (z. B. mit Sendmessage) an die 1. Instanz weitergeleitet werden. Das funktioniert alles bestens, wenn sichergestellt ist, dass die 1. Instanz vollständig geladen ist. Was aber, wenn ich mit "Öffnen" mehrere Dateien auswähle und die Hauptanwendung, die 1. Instanz, noch gar nicht geladen ist? Die nachfolgenden "Pseudoinstanzen" können unter Umständen die Hauptanwendung überholen und eine Nachrichtenübermittlung (Übergabe der Parameter) ist nicht möglich. Manchmal geht's gut, manchmal nicht. Ein Lotteriespiel, wie ich festgestellt habe. Warten, bis die Hauptanwendung vollständig initialisiert ist, geht auch nicht.

Aus diesen Gründen habe ich die Nachrichtengeschichte (Übermittlung der Parameter an das bereits laufende Programm) vorerst mal auf Eis gelegt. Werde mir hierzu aber noch meine Gedanken machen.

Keine Probleme bereiten Aktionen, wo die ausgewählten Dateien komplett als Parameter übergeben werden, z. B. bei "Drag-and-Drop-Operationen" auf die ausführbare Datei.

Vorerst findet also nur die Abfrage der Parameter statt. Auch kann das Programm jetzt nur noch einmal gestartet werden.

Wobei, es spricht ja nichts dagegen, wenn man so was (Eintrag im Kontextmenü) als zusätzliche Option (frei wählbar) in der Installationsroutine anbietet.

Natürlich ginge das. Andererseits aber will ich auf dem jeweiligen Rechner so gut wie keine Veränderungen vornehmen. Derzeit werden die Dateien ja nur an ihren Ort kopiert und im Startmenü die Verknüpfungen erzeugt. Mehr passiert da momentan nicht.

Ich benutze sogar noch die alte Version von Immaavs (Version 1.32), nur damit ich keine DLLs ins Systemverzeichnis kopieren muss. Neuere Immaavs-Versionen funktionieren nämlich nur, wenn sich die benötigten DLLs im Systemverzeichnis befinden. Aber vielleicht erbarmt sich Wilbert, der Autor, ja doch noch und stellt den "alten Zustand" (DLLs auch im Programmverzeichnis möglich) wieder her.

Bei reinen Computerduellen mögen diese Ratinglisten durchaus eine gewisse Aussagekraft haben, aber wenn es um eine Empfehlung für eine Engine für das Spiel Mensch gegen Maschine (für das Spiel zwischendurch) geht, dann würde ich aus diversen Gründen dann doch nicht auf einer dieser "hochgezüchteten Rennpferde" setzen. Wenn, dann müsste das Programm schon eine sehr ausgiebige Testzeit hinter sich haben. Auch müsste es einen "nicht unangenehmen Spielstil" aufweisen. :lol:

Wenn ich mir die genannten Engines so anschaue, dann bleiben eigentlich nur noch Crafty 23.0, Fruit Beta 05/11/03 und Glaurung 2.2 übrig, die nicht durch "Klonung" entstanden sind (sicher gibt es da auch noch andere). Glaurung dürfte allerdings etwas unangenehmer zu spielen sein (StockFish, der Ableger davon, spielt noch aggressiver). Speziell Fruit Beta 05/11/03 - die letzte bearbeitete Version von Fabien Letouzey - hat es mir hinsichtlich des Spielstils angetan. Man kann schön seine Figuren entwickeln, die Gedanken schweifen lassen und wird nicht gleich überrannt. :lol:

Zitat

Fruit spielt sehr ausgeglichen. Fruit hat keine außergewöhnlichen Stärken aber auch kaum nennenswerte Schwächen. Fruit entwickelt sich aktiv in der Eröffnung, findet die taktischen Schläge im Mittelspiel und konvertiert einen schmalen Vorteil zum Gewinn in einem technischen Endspiel. Fruits Stärke liegt mit Sicherheit nicht im kompromisslosen Angriff, sondern in der Ausweitung und Verwertung kleinster Vorteile ohne dabei taktische Verwicklungen zu scheuen.

Quelle >>

Das, was bei Fritz7 noch funktioniert hat, dem Computer durch Passivität regelmäßig ein Remis abzuluchsen, funktioniert hier allerdings nicht mehr.

Addendum: Ich habe mir seinerzeit das Buch "Schach am PC" von Dieter Steinwender und Frederic A. Friedel gekauft. Darin wurden auch die Grundlagen der Schachprogrammierung erklärt. Ein Quellcode für ein Schachprogramm durfte dabei auch nicht fehlen. Das Programm nannte sich "MiniMax" und war in QuickBASIC geschrieben (es gab auch eine Version in C). Das Programm kam allerdings "ohne Strümpf' und Schuh'" daher. Es unterstützte z. B. keine Hashtabellen und war auch sonst an einigen Stellen verbesserungswürdig (schließlich handelte es sich um ein didaktisches Schachprogramm). Ich bin allerdings nie dazu gekommen, mir das näher anzusehen. Und genau für dieses Programm gibt es auch eine Portierung für Arena (Winboard-Version). Da kommt Nostalgie auf. :lol:

"Wild Wild West": Da wurde in der Vergangenheit offenbar die 1.0-er Version von Rybka dekompiliert, ein paar Änderungen eingebracht und unter anderem Namen ("Strelka") wieder veröffentlicht. Andere wiederum nehmen den Quellcode von Fruit her, ändern ein paar Dinge und "verkaufen" das als eigene Produktion (ohne irgendeinen Hinweis darauf, dass das Ganze auf Fruit basiert).

Und fast alle nähren sich am Busen des Quellcodes von Fruit. Selbst der Autor von Rybka, Vasik Rajlich, erwähnte dies in einem Interview:

Zitat

20. Alexander Schmidt:
The increase in playing strength of the latest chess engines is unbelieveable. We have since some time with Fruit 2.1 by Fabien Letouzey a very strong open source engine. Do you see a relation between the published sources of such a strong engine and the increase of strength in computer chess in general? How much influence do the ideas of Fruit have on the future of computerchess?

Vasik Rajlich:
Yes, the publication of Fruit 2.1 was huge. Look at how many engines took a massive jump in its wake: Rybka, Hiarcs, Fritz, Zappa, Spike, List, and so on. I went through the Fruit 2.1 source code forwards and backwards and took many things.

It is a bit of a pity that Rybka won't make the same contribution to the computer chess community, but at the moment I must also think about protecting my secrets. It's the eternal struggle for a computer chess programmer.

21. Alexander Schmidt:
We had our first contact when I had questions about a similarity to Fruit in the search, others found similarities in the evaluation. Some people where a little bit suspicious that Rybka could be a clone of the open source engine. In the meantime it is clear that Rybka is no clone but you used ideas of Fruit (I guess all other serious engine programmers had a look at Fruit too). How strong would Rybka actually be if the Fruit code would have never been published?

Vasik Rajlich:
It's a good question. I don't want to get too specific about which ideas from Fruit I think are really useful, but they fall into two categories:

1) Very specific tricks, mostly related to search.
2) Philosophy of the engine (and in particular of the search).

Fruit could really hardly be more useful along both of these dimensions. Fabien is a very good engineer, and also has a very clear and simple conception of how his search should behave.

Anyway, if I really had to give a number - my wild guess is that Rybka would be 20 rating points weaker had Fruit not appeared.

Quelle >>

Alles anzeigen

Ob der letzte Satz zutreffend ist, sei jetzt mal dahingestellt.

Nachdem es hier einen so schönen Schach-Thread gibt, kann ich nicht umhin, hier mal die derzeit interessantesten Freeware-Engines - meiner bescheidenen Meinung nach - aufzulisten.

Bright 0.4a
Crafty 23.0
Rybka 2.2n2
StockFish 1.4 JA
Toga II 1.4.1 SE

Im mobilen Bereich (Pocket-PC etc.) gibt es zwar auch eine Reihe guter Freeware-Lösungen (vor allem, was die Spielstärke anbelangt), wie z. B. CEBoard, Mobile ThinkerBoard und Scid Pocket (bereits erwähnt), trotzdem habe ich mir mittlerweile den kommerziellen PocketGrandmaster zugelegt.

Was du noch machen könntest, ist die Anzahl der B-Frames auf 1 zu reduzieren bzw. ganz auf die B-Frames zu verzichten. Das Deaktivieren von CABAC bringt auch noch mal einen ordentlichen Performance-Schub. Und als letzten Notnagel kannst du auch noch das Deblocking deaktivieren (allerdings nicht empfehlenswert). Kompensieren sollte man das alles mit einer Erhöhung der Bitrate.

Beschwer' dich aber nicht über die Qualität. :floet:

Zitat von Guybrush

Dort habe ich alle möglichen Einstellungen ausprobiert und komme schließlich mit H.264 auf viel bessere Ergebnisse als mit DivX oder XVid.

Wenn XviD etwa die 1,5-fache Bitrate von x264 spendiert bekommt, dann sehen die XviD-Videos – in meinen Augen - mindestens genau so gut aus (getestet anhand von Fernsehaufnahmen bei niedrigen Bitraten). Wenn du eine gewünschte Bitrate (Mpeg-4 AVC) nicht abspielen kannst, dann bist du bei Xvid & Co. besser aufgehoben.

tritical hat das "Problem" durch ein Update behoben. Eine aktualisierte Version ist hochgeladen.

Von NNEDI gibt's mittlerweile eine verbesserte Version, wie manche sicher schon wissen. NNEDI2 heißt das gute Stück. Die Ergebnisse sehen jedenfalls schon mal ganz vielversprechend aus.

Einziger Wehrmutstropfen ist die noch fehlerhafte CPU-Erkennung. Wenn ich den Automatik-Modus aktiviert lasse (opt=0), dann macht das Programm auf meinem Notebook die Grätsche. :eek: Laut Autor liegt das an der aktuellen AviSynth-Version (2.58), die bei einer entsprechenden Abfrage (durch das Plugin) einen falschen Flag zurückliefert.

Aus diesem Grunde stelle ich das Script mal so zur Verfügung (einfach als NNEDI2.avs im Resize-Verzeichnis abspeichern). Den opt-Parameter (ganz unten im Script) bitte entsprechend anpassen bzw. entfernen, um den Automatik-Modus entscheiden zu lassen. :floet:

# ==============================================================================
# [url]http://forum.doom9.org/showthread.php?t=147695[/url]
# ==============================================================================
rfactor = 2
qual    = 2
pscrn   = True
cshift  = "Spline36Resize"
# ==============================================================================


LoadPlugin("plugins\NNEDI2\nnedi2.dll")


Import("lib\FritzPhoto\FritzPhoto.avs")


isYV12() ? Eval("""
  YV12toRGB32()
  fp_nnedi2_rpow2(rfactor=rfactor, qual=qual, pscrn=pscrn, cshift=cshift)
""") : Eval("""
  alpha = last
  fp_nnedi2_rpow2(rfactor=rfactor, qual=qual, pscrn=pscrn, cshift=cshift)
  %%KeepAlphaChannel%% == True ? MergeARGB(alpha.ShowAlpha().fp_nnedi2_rpow2(rfactor=rfactor, qual=qual, pscrn=pscrn, cshift=cshift).ShowBlue("YV12"), last, last, last) : last
""")


function fp_nnedi2_rpow2(clip input, int "rfactor", int "qual", bool "pscrn", string "cshift") {
  input.ConvertToRGB24(matrix="pc.601")
  nnedi2_rpow2(rfactor=rfactor, qual=qual, pscrn=pscrn, cshift=cshift, opt=3)
  ConvertToRGB32(matrix="pc.601")
}

Im Anhang habe ich zum Vergleich mal beide Versionen gegenübergestellt. Das 1. Bild ist das Original, das 2. Bild wurde mit NNEDI vergrößert und das 3. Bild mit NNEDI2.

Nach all den Vergleichen, werde ich nun generell bei XviD bleiben. Die Unterschiede sind einfach zu groß. Zudem ist Speicherplatz ohnehin nicht teuer. Der einzige Wehrmutstropen war noch, dass mit XviD eine vorgegebene Bitrate - aus bekannten Gründen - nicht immer hinreichend genau eingehalten wurde. Also habe ich die Werte für "Overflow control strength", "Max Overflow improvement" und "Max Overflow degradation" etwas angepasst. Lustig, ein "Overflow control strength" von 0 bedeutet in Wirklichkeit einen Wert von 10. Ich habe letztendlich die Werte 8-8-4 eingetragen. Damit wird die Bitrate für mich hinreichend genau getroffen.

TMPGEnc – ja, das waren noch Zeiten. Für die Audiokonvertierung habe ich allerdings immer tooLAME verwendet (kann man in TMPGEnc einbinden).

Zitat von Alien01

Wie muss korrekterweise ein script aussehen in dem nur wav-dateien drin sind die zu einer MP2-Datei (für auf DVD) verbunden werden sollen?

a = WAVSource("Paris.wav")
b = WAVSource("Hilton.wav")
a + b

Zitat von Kriksen

Ist denn ein Umwandeln des Quellmaterials nach Divx auch ohne spürbaren Qualitätsverlust möglich? Evtl. mit einer hohen Bitrate (2500 kbps oder höher?).

Wenn das Material interlaced enkodiert werden soll, dann wirst du mit 2500 kbps nicht weit kommen. Rechne lieber mal mit etwa 5500 kbps - nur um mal 'ne Hausnummer zu nennen. Das dürfte dann (abhängig vom Quellmaterial) in etwa Procoder-Niveau (bei einer mittleren Videobitrate von 6500 kbps) haben. Die Ersparnis ist hier nicht all zu groß. Im Vergleich zu einer guten Mpeg-2-Enkodierung wirst du mindestens 80 bis 85 % (abhängig vom Quellmaterial) der Mpeg-2-Bitrate benötigen.

Wer lesen kann, ist klar im Vorteil. Ich habe bei der Average Bitrate in MeGUI (AutoEncode) immer die Videobitrate angegeben. Richtig aber wäre gewesen, die Summe aus Audio und Video.

Zitat

Average Bitrate: After the audio has finished encoding (if there is any), the video bitrate is adjusted so that the final bitrate of the file (including audio) reaches an average of what is set.

Damit ändern sich natürlich die Zahlenwerte. Das "800-er" x264-Video hatte letzthin nur eine mittlere Videobitrate von 665 kbps und das "1200-er" XviD-Video nur 1017 kbps, wie ich durch den Bitrate Viewer festgestellt habe. Der scheint das auch korrekt zu ermitteln. An den Proportionen hat sich aber nicht viel geändert: 665 kbps sind ca. 65% von 1017 kbps. Die "600-er" x264-Videos hatten eine Videobitrate von 426 kbps und das vermeintliche "550-er" x264-Video hatte gar nur eine Videobitrate von 286 kbps.

http://img34.imageshack.us/i/bitrateviewer.jpg/

Für die 640x352-er Auflösung komme ich durch Testen nun auf eine mittlere Videobitrate von etwa 384 kbps (Benchmark knapp unterhalb von 120 %).

Die Einstellungen für XviD habe ich entsprechend angepasst. Hier erscheinen 1300 kbps für 640x480 und 1000 kbps für 640x352 sinnvoll. Bei einer Auflösung von 640x480 sollten Videobitraten bis knapp über 3000 kbps kein Problem darstellen. Maximale Wiedergabequalität erreicht man letzthin nur mit XviD.

Jetzt ist doch noch ein Omnibus gekommen. Und ein Platz war auch frei. :lol:

Um mich nicht misszuverstehen, mit der Qualität des x264-Videos, welches ich im Übrigen mit 600 kbps enkodiert habe, bin ich im Grunde genommen ja zufrieden (sieht auf dem iPAQ ganz gut aus). Im Umkehrschluss heißt das aber, dass ich meine bisherige XviD-Bitrate von 1200 kbps noch weiter nach unten schrauben könnte, um in etwa auf das Niveau des x264-Videos zu kommen.

Ich habe das x264-Video jetzt mal mit 800 kbps enkodieren lassen. Und siehe da, jetzt sieht die Sache schon ein wenig anders aus. Jetzt scheint das x264-Video einen kleinen Tick besser zu sein. In meiner "Verzweiflung" hatte ich sogar eine kurze SSIM-Analyse gemacht. Mit dem gleichen Ergebnis: Das x264-Video (Q = 0,9504) war einen kleinen Tick besser als das XviD-Video (Q = 0,9477). Auch der Kurvenverlauf war etwas günstiger. Der Unterschied war aber nicht all zu groß. So über den Daumen gepeilt, hat das schon mal ganz gut funktioniert, soll heißen, die SSIM-Analyse entsprach in etwa meinem subjektiven Eindruck.

19,9 MB, so die Dateigröße des x264-Videos, entsprechen in etwa 69 % der Dateigröße des XviD-Videos (28,7 MB). Wobei ich XviD gar nicht optimal konfiguriert habe, z. B. konnte ich QPel nicht verwenden, da der CorePlayer damit Probleme hatte (der Benchmark änderte sich bei einem Testclip von ca. 140 % auf ca. 65 %).

So als groben Richtwert würde ich mal sagen, dass x264 im vorliegenden Fall (Quellmaterial und Bitratenbereich beachten) etwa 66 % der Bitrate von XviD benötigt.