Ich hatte hier heute das Problem das eine Anwendung die ich auf einem Remotesystem über eine etwas ältere Version des Teamviewers angeschaut habe nur ein leeres weißes Fenster dargestellt hat. Schnell war rausgegoogelt dass das an Unverträglichkeiten mit der hardware-beschleunigten Grafikausgabe zusammenhängt.
Wie deaktivert man also Quellcodeseitig das Hardware-Rendering eines WPF-Fensters? Software Rendering für WPF Anwendung/Fenster erzwingen weiterlesen
Ich hab ja neulich am Ende des Artikel über unser Podcast-Streaming-Setup angekündigt mich mal kurz zu Markdown und meiner Verwendung auf dem Mac und Windows zu äußern.
Auf dem Mac verwende ich als Vorschau- und Preview-Applikation Marked und genau über die Verwendung vom Marked in Verbindung mit einem normalen Texteditor habe ich das weiter unten eingebettete Video gemacht.
Aber vielleicht zuerst ein kurzer Überblick darüber was Markdown eigentlich macht und wozu man es braucht.
Markdown ist eine einfache Markup-Sprache die von John Gruber erdacht wurde um, vermutlich vornehmlich sich selbst, das Bloggen zu erleichtern. Jeder der sich schonmal im Backend eines heutigen CMS-basierten Blogs eingeloggt hat kennt die lustigen Rich-Text-Editoren die man dort präsentiert bekommt um seine Artikel zu verfassen. Jeder der schonmal versucht hat dort einen längeren Artikel zu geschrieben hat wird früher oder später Flüche aller Art gen Himmel ausstoßen und diese Editoren verdammen.
Marked ist also angetreten um das verfassen von Text in einfachem HTML (Styles und so weiter werden ja über CMS automatisch hinzugefügt) zu erleichtern. Daher kann man beispielsweise Links einfacher setzen, Aufzählungen und Überschriften sowie einfach Textmarkierungen wie kursiv oder fett sind sehr schnell und ohne Griff zur Maus, aber eben auch ohne HTML-Tags, zu bewerkstelligen.
Den “Quell-Text” zu diesem Artikel sieht man zum einen im Video, aber ich hab ihn euch hier auch nochmal zum direkt anschauen verlinkt.
Marked ist ein kleine Mac-Anwendung aus dem Mac-AppStore die zum einen Markdown-Übersetzer enthält, als auch ein schnelles HTML-Preview ermöglicht. Die Software bekommt durch einfaches Drag’n’Drop ein File zur Überwachung gereicht und zeigt fortan jedesmal wenn dieses (Text-)File gespeichert wurde eine aktualisierte Vorschau an.
Ist man mit seinem Artikel fertig läßt man sich von Marked die HTML-Repräsentation des Artikels in die Zwischenablage kopieren und fügt diese im Backend der Website einfach nur noch ein. Schon ist der Blogpost fertig zur Veröffentlichung.
Auch unter Windows gibt es natürlich Editoren die Markdown unterstützen, dazu habe ich mir kürzlich Writemonkey angesehen und für sehr tauglich befunden.
Seit kurzem bastel ich an einem Streaming-Setup für den Sneakpod. Ziel ist es die Sendungen live zu streamen, aber nach wie vor lokal aufzunehmen. Im Anschluß an die Live-Sendung steht die normale Nachbearbeitung um dann eine neue Podcast-Folge zu veröffentlichen. Dazu habe ich mich mal in Icecast und die Möglichkeiten vom Mac zu streamen vergraben möchte das derzeitige Setup kurz darlegen.
In der Artikelserie zum Thema Podcast-Setup habe ich das grundsätzliche Setup unseres Podcasts (aus damaliger Sicht) bereits dargelegt, bei Bedarf (schreibt Kommentare) werde ich da vielleicht nochmal ein Update geben, da sich schon einiges geändert hat.
Da ich erstmal das Thema Streaming überhaupt an den Start bringen wollte und mir das Thema HTTP-LiveStreaming zwar schon verlockend vorkam, aber dann doch (noch) sehr Apple-zentrisch ist, fiel die Wahl erstmal auf klassisches Icecast/SHOUTcast-Streaming. Das geht auch über HTTP, macht allerdings noch nicht so den ganzen modernen Foo mit unterschiedlichen Qualitätsstufen und ist natürlich auch nicht in der Lage als Nebenprodukt eine Re-Live-Möglichkeit abzuwerfen. Dafür gibt es für Icecast eine breite Unterstützung an Clients auf Hörerseite, dazu aber später mehr.
Eine Entscheidung für bestimmte Audioformate muss man an dieser Stelle noch nicht treffen, da sowohl HTTP-LiveStreaming, als auch Icecast-Streams in MP3, AAC und Vorbis streamen können. Jedoch habe ich mich entschlossen 2 Streams parallel anzubieten. Zu ersteinmal einen MP3-Stream und zum anderen einen AAC(HE)-Stream.
MP3 dürfte da draußen in der weiten Welt immer noch den kleinsten gemeinsamen Nenner darstellen wenn es um Massenkompatibilität geht, also müssen wir natürlich in MP3-Streamen. Um den Server bei mehr Hörern zu schonen streamen wir nur in Mono und zwar mit 64kBit/s (ABR).
Den AAC-Stream bieten wir mit niedrigerer Bitrate speziell mit Hintergedanken an Verbindungen mit sehr niedriger Bandbreite an. Solltet Ihr also beispielsweise vorhaben uns von unterwegs über UMTS (oder schlimmer), bespielsweise am Handy, zu hören dann ist dieser Stream mit nur 32kBit/s ABR der Richtige. Der Decoder den Ihr einsetzt sollte aber auf jeden Fall High Efficiency-AAC unterstützen, sonst klingt der Stream eher fürchterlich.
Als Server verwenden wir ((bis auf weiteres)) unseren normalen Sneakpod.de-Server, auf dem auch dieses Blog läuft. Wieviele Hörer der aushält ist vorerst unbekannt. Je nachdem ob die Bandbreite oder die CPU-Last den Stream als erstes killt. Vorerst halten sich die Hörerzahlen unserer bisherigen Experimente stark in Grenzen und wir werden erstmal sehen müssen wie das weitergeht. Eine kleine Beispielrechnung sagt mir das man unseren beiden Streams (zusammen 96kBit/s) über 1000x parallel über eine 100MBit/s-Anbindung schieben könnte – ich gehe daher davon aus, dass der Server vorher an seinen eigenen Querelen (aka CPU-Last) eingeht.
Der Server läuft, nach wie vor, unter CentOS und dort habe ich Icecast2 installiert. In der Datei /etc/icecast2.xml kann man nun so diverse Limits für den Server einstellen. Ich habe hier das meiste bei den Defaults belassen.
<clients>100</clients> limitiert uns erstmal auf 100 Zuhörer, keine Ahnung ob der Server das überhaupt mitmacht, aber bislang haben wir dieses Limit noch nicht erreicht – wenn es so kommt sehen wir weiter.
Die Zugangsdaten legt man im Bereich authentication fest, hier trägt man Usernamen und Passwörter für die Source-Clients ein, also die Daten, mit denen man sich später anmeldet um etwas über diesen Server zu streamen.
Im unteren Bereich der XML-Datei muss man noch die Pfade für’s webroot anpassen, damit Icecast seine eigenen Webseiten richtig ausliefern kann, man wählt sich einen Port ≠ 80 um dem normalen Webserver nicht auf die Füße zu treten.
Unsere Audiodaten, also unser Podcast ensteht ja aber logischerweise nicht auf dem Server, sondern irgendwo im Studio und da haben wir maximal einen Laptop. Natürlich streamt man nicht von diesem Laptop zu allen Zuhörern, sondern von dort aus nur mit einem Stream zum Server und dieser verteilt den Stream an die Hörer. Wir sind also für den Server eine sogenannte Source, eine Quelle, und brauchen dafür eine Client-Software um den Icecast-Server zu füttern. Da ich den Stream mit einem Mac betreibe kommen eigentlich nur 2 Produkte in Frage: Ladiocast oder Nicecast. Ersteres ist eine kostenlose japanische Software, zweiteres ein Rogue Amoeba-Produkt das Geld (($59 um genau zu sein)) kostet.
Die Entscheidung fiel also erstmal auf Ladiocast und das muss man nun einrichten. Ladiocast kann 2 Streams gleichzeitig aussenden, somit können die beiden oben erwähnten Streams problemlos konfiguriert werden.
Gestreamt wird zu sogenannten Mountpoints. Effektiv sehen diese für den Webbrowser wie Ressourcen hinter einem URL aus. Dieser kann, in der Standardkonfiguration durch die Source festgelegt werden ((es lassen sich auch feste Mountpoints in der .xml-Datei festlegen)). In unserem Fall legen wir die Mountpoints Live.mp3 und Live.heaac durch die Einstellungen in Ladiocast fest.
Ladiocast besitzt im Haupfenster Mix-Möglichkeiten für den Main-Mix und zwei separate AUX-Mixe, in unserem Setup kommt diese Funktion allerdings nicht zum Einsatz. Wir geben einfach ein Line-In auf den Output, fertig. Das Line-In kommt im Falle einer Aufnahme über Skype oder bei mir im Heimstudio aus dem Mischpult ((dann auch über ein anderes Interface, aber ich schweife ab)) oder, im Falle einer Aufnahme über Stefans H2, direkt aus dem Aufnahmegerät.
Kommen wir zur Seite des Hörers. Um den Stream zu empfangen benötigt man natürlich eine Software die in der Lage ist auf den Streaming-URL zuzugreifen und Audio zur Ausgabe zu bringen. Hierzu gibt es unzählige Möglichkeiten, einige hatte ich bereits auf www.sneakpod.de/Live-Stream/ gelistet. Das vorgehen ist jedoch immer das gleiche – spielen wir das am Beispiel von VLC ((das gibt es für nahezu alle Platformen)) einmal durch.
Als erstes wählt man aus dem Menü Open Network...
um als nächstes den Stream-URL einzugeben und zu öffnen. Fertig. Mehr ist nicht zu tun, auch wenn es natürlich nur wirklich funktioniert während wir streamen. In der übrigen Zeit bekommt man eine Fehlermeldung. :-(
In meinen Testaufbauten war ich mit der Streamqualität ((rein was das Audioencoding anging)) recht zufrieden, auch wenn ich von einigen Hörern nach der ersten gestreamten Sendung das Feedback bekommen habe, dass zu wenig Pegel auf dem Stream gewesen sei – das wird zu erforschen bleiben.
Die Latenz, also die Verzögerung zwischen dem wirklich gesprochenen Wort und dem Augenblick in dem die Zuhörer es hören können, liegt irgendwo zwischen 5 und 10 Sekunden. Scheint für diese Art von Streaming ein übliche Größe zu sein, stellt kein großes Problem dar und macht sich immer sehr unterhaltsam in Chat bemerkbar.
Was wäre eine Live-Sendung auch ohne Chat. Natürlich haben auch wir einen. #Sneakpod auf Freenode. Wie man da hinkommt steht auch auf www.sneakpod.de/Live-Stream/.
Interessant? Lust mehr zu erfahren? Schreibt Kommentare.
BTW: Dies ist der erste Artikel im Blog den ich mithilfe von Markdown geschrieben habe – hat gut geklappt – ging entspannt und schnell von der Hand und ich könnte mir vorstellen das in einem zukünftigen Artikel zu beleuchten.
Backup, ein ekliges Thema für die meisten von uns, aber auch ein Wichtiges, das wissen wir ja alle ziemlich genau wenn wir mal in uns gehen. Wer von uns hat schon ein wirklich sicheres Backup, eines das nahezu allen Eventualitäten standhalten kann?
Teil 2 der Serie “Podcast-Setup” über mein Setup für die Aufnahme und Produktion meines Podcasts Sneakpod (mit Stefan, Martin und Christoph). Hier zum Teil 1 der Serie Podcast-Setup. Hier zu Teil 3 der Serie.
Zur Aufnahme eines Audiosignals genügt eigentlich schon der in Windows eingebaute Audiorecorder, wir jedoch nehmen mit Audacity auf. Das ist OpenSource und ich hab hier noch ein paar Einstellmöglichkeiten bezüglich Audiodeviceauswahl und dem Pegel der Aufnahme. Jetzt wird eigentlich nur noch Record gedrückt und dann heißt es diskutieren.
Wie im ersten Teil schon erwähnt fallen am Ende der Aufnahme an 3 Stellen (nämlich bei jedem von uns einmal), insgesamt 3 Audiodateien aus den Audacity-Instanzen. 2 davon werden nun übers Internet zu demjenigen von uns übertragen der die aktuelle Folge schneiden und bearbeiten wird. Das bin meistens ich, manchmal auch der Stefan. Wir übertragen meist über die Dateiübertragungsfunktion eines Instant-Messaging-Clients wie ICQ oder direkt über Skype – neuerdings auch öfter über die Share-Funktion von Dropbox.
Mein einigermaßen gutes Mikrofon mit der restlichen Kette an Geräten die danach kommt gegeben, klingt das Signal das jetzt auf meiner Platte liegt schonmal recht gut – allerdings ist es trotzdem noch nicht fertig. Es folgt als erstes eine Rauschentfernung um das letzte Hintergrundrauschen aus den Aufnahmen zu tilgen. In Stefans Aufnahmen ist oftmals ein leiser Pieps-/Pfeifton zu hören der wohl von seiner Soundkarte stammt, Martins Aufnahmen rauschen ein bißchen und auf meinen Aufnahmen ist meist mein eigener PC im Hintergrund leise rauschend zu hören. Heutige Audiosoftware kann hier sehr gut gegensteuern, man gibt Ihr einen Abschnitt des Audiofiles in dem nicht gesprochen wird (wo also wirklich nur das pure Rauschen zu hören ist) zur Analyse. Hierbei wird das Rauschprofil sozusagen identifiziert (an Frequenzgang und Pegel und so weiter) und im Nachhinein kann die Software dann dieses Rauschprofil von der gesamten Aufnahme abziehen. Der Filter ist in der Stärke einstellbar und führt, wenn man es nicht übertreibt, zu sehr brauchbaren Ergebnissen.
Nachdem alle 3 Spuren normalisiert ((Normalisierung bedeutet das alle Spuren derart in der Lautstärke verstärkt werden das Ihr jeweils lautester Ton einen vorher festgelegten Wert (normalerweise 0db) hat)) wurden folgt als nächster Schritt eine sanfte Dynamikkompression – dieses Thema hier in aller Tiefe zu behandeln würde jeglichen Rahmen dieser ohnehin schon extrem langen Artikelserie sprengen. Nach einigen Experimenten bin ich zu einer Einstellung gekommen die ganz gut funktioniert ohne übertrieben zu klingen. Hier muss wohl jeder selbst ein bißchen experimentieren. Es gilt die Stimmen schön satt und kräftig zu bekommen ohne es völlig zu übertreiben. Außerdem ziele ich hier auf eine gute Verständlichkeit. Unsere Hörer hören den Podcast oftmals mit kleinen Ohrstecker-Kopfhörern die nicht sehr gut von den Außengeräuschen (U-Bahn, Bus, Straßenlärm) trennen. Eine gleichmäßige Lautheit aller Sprecher ist also das oberste Ziel dieser Anpassungen, sodass der Podcast auch unterwegs gut gehört werden kann ((sowas hat mich oft genug bei anderen Podcasts aufgeregt)).
Der dritte Schritt ist der Equalizer, einige Frequenzen werden leicht angehoben – nix übertriebenes nur ein bißchen mehr Präsenz.
Nun wird noch ein leichter Raumhall hinzugefügt. Das ist eine Sache die wir nicht seit unserer ersten Folge machen. Der Tipp eines befreundeten Toningeneur gab mir hier den Anstoß. Fügt man den Stimmen die gleiche Art Hall hinzu und sorgt vorher bei der Aufnahme für einen möglichst trockenen Klang dann gelingt es eher, beim Hörer, den Eindruck zu erwecken das wir wirklich alle 3 in einem Raum sind und uns normal unterhalten. Außerdem hören sich Stimmen mit Hall angenehmer, weil wohl natürlicher, an.
Nach der Dynamikkompression und dem Halleffekt hat das Signal meist ordentlich an Pegel verloren ((bei der Kompression wird noch nicht normalisiert)), dieser Effekt wird im letzten Schritt der Bearbeitung ausgeglichen: Der Normalisierung. Die gesamte Datei wird auf 0db normalisiert damit alle 3 Spuren in etwa gleich laut sind. Nun ist die Bearbeitung der einzelnen Spuren (jede einzelne Spur erhält die eben beschriebene Behandlung separat, z.B. weil die Rauschentfernung für jede Datei separat abgestimmt werden muss) abgeschlossen. Wir haben jetzt 3 wohlklingende Spuren mit jeweils einer Stimme, diese müssen nun zusammengefügt werden – es braucht also den Schnitt.
Hierfür verwendet man jetzt also ein Audioprogramm das den Mehrspurschnitt beherrscht, z.B. wieder Audacity oder auch GarageBand, Audition oder ähnliches. Jeder der 3 Sprachdateien wird auf eine eigene Spur gelegt und auf eine vierte Spur kommen dann so Sachen wir unsere Intromusik oder Audiokommentare oder ähnliches. Diese Spuren müssen jetzt auf der Timeline irgendwie zueinander angeordnet werden, ich muss sie irgendwie wieder so synchron bekommen wie sie bei der Aufzeichnung liefen.
Aus der Erfahrung heraus hat sich gezeigt, dass sich dafür am ehesten die Lücken in der Begrüßung eignen. Gegen Ende der Begrüßung (gesprochen auf Stefans Spur) sagen Martin und ich jeweils einmal “Hallo” auf unseren Spuren. Zu diesem Hallo findt sich in der Wave-Form auf Stefans Spur je eine Lücke. Anhand dieser Zuordnung lassen sich die Spuren hinreichend synchron kriegen. Nach ein-/zweimal Testhören weiter vorn und weiter hinten hat man in der Regel das Optimum gefunden. Jetzt wird der gesamte so auf der Timeline wieder vollständig entstandene Podcast einmal durchgehört. Dabei werden eine Menge kleinerer Korrekturschnitte vorgenommen. Im wesentlichen wird nicht wirklich geschnitten ((im Inhalt verändernden Sinne)) sondern korrigiert. Aber natürlich fliegen hierbei versaute Takes raus ((die dann ja mit schöner Regelmäßigkeit in den Outtakes am Ende der jeweiligen Folge wieder auftauchen)) oder ich entzerre Stellen an denen wir alle durcheinander reden. Auch entferne ich viele kleine Lücken in denen Stille herrscht. Soetwas entsteht weil Skype eine gewissen Latenz mit sich bringt, die später beim zuhören recht unnatürlich klingen würde. Manchmal gehen wir auch während der Aufnahme in einen Off-Record-Modus, das heißt wir stimmen kurz ab wie die Aufnahme weitergeht ohne das diese Absprache zum Senden bestimmt wäre. Solche Teile werden hier ebenfalls rausgeschnitten.
Die entfernten Teile werden, sofern sie noch ein gewisses Outtakepotential besitzen, erstmal nicht wirklich gelöscht. Sie werden z.B. auf einer fünften, auf Stumm geschalteten Spur, gesammelt und später ans Ende der Timelime verschoben. Hier kann ich diese Teile nocheinmal anhören und entscheiden welche davon als Outtakes in die Folge kommen und welche stattdessen wirklich gelöscht werden.
Nachdem der Schnitt fertig ist muss der Podcast nur noch exportiert und fürs Web vorbereitet und natürlich schlußendlich veröffentlicht werden. Dazu mehr in der dritten und dann letzten Folge dieser Serie.
Teil 1: Equipment und Konferenztechnik
Teil 2: Aufnahme und Nachbearbeitung
Teil 3: Vorbereitungen fürs Web und Veröffentlichung
Es ist soweit, Firefox 3.0 ist da. Zum einen ist das an sich schon eine gute Nachricht, denn nach allem was man so über die RCs gelesen hat soll die neue Version wiedermal ein großer Wurf sein.