Presonus VSL-Interfaces und El Capitan

tl;dr: Presonus hat den Software-Support der VSL-Soundinterfacereihe für OSX El Capitan eingestellt. Kein Beinbruch: mit Ultraschall/Reaper lassen sich bessere Ergebnisse erzielen.

Ausgangslage: immer Ärger mit Presonus

Über die schwierige Hassliebe von PodcasterInnen zu den VSL-Audiointerface-Produkten der Firma Presonus habe ich mich schon einmal länger ausgelassen. Zum einen bieten sie guten Klang, viele Eingänge und Echtzeit-Effekte zu ca. 50% des Preises, den andere Firmen für vergleichbare Features aufrufen. Zum anderen hatte man aber nie den Eindruck, dass die Treiber und Mixeroberflächen wirklich 100% robust waren. Jedes Apple-Update brachte Probleme mit sich. Die Informations- und Supportkultur von Presonus ist und bleibt eine Katastrophe.

Nun zu OSX El Capitan der Paukenschlag: jegliche Weiterentwicklung der VSL-Linie wird eingestellt. Der Gerechtigkeit halber für die Windows-Welt gleich mit. Äh – what? Nur weil Apple sonderbare (wenn wohl auch sinnvolle) Updates im Core-Audio-Bereich herausgibt, müssen die ca. 9/10tel Windows-KäuferInnen gleich mit leiden?

So tickt Presonus.

Wenn man die VSL-Politik wie ich seit Jahren verfolgt, ergibt sich hier ein klares Bild: Sie haben eigentlich von Tag 1 an die technischen Probleme dieser Modellreihe (Aussetzer, Knacksen) nie wirklich in den Griff bekommen und sehen das Update jetzt als willkommene Gelegenheit für einen Exit.

Etwas lapidar heißt es in ihrer Ankündigung (paraphrasiert): „Nun, Eure Interfaces funktionieren ja weiter als Class-Audio Geräte, ihr müsst nur unsere Treiber- und Mixersoftware komplett entfernen.“

Hier entsteht zunächst ein mehr als schaler Beigeschmack: Die VSL-Reihe war deshalb besonders, weil sie in ihrer Mixer-Software nicht nur ein brauchbares Routing zwischen den 8 Eingängen und 8 Ausgängen (!) ermöglichte, sondern vor allem auch für Podcasting hochinteressante Echtzeiteffekte mitbrachte: EQ, Kompressor, Limiter, Noisegate. Diese entfallen nun komplett ohne die Mixer-Software; übrig bleibt ein relativ schlichtes Stück Audio-Hardware, das lediglich Ein- und Ausgänge im OS bereitstellt. Da kann das mobile Zoom H6 mehr (von der Anzahl der Eingänge abgesehen).

Der Grund für all diese Probleme liegt in der sehr speziellen Treiberarchitektur der VSL-Geräte. Der niedrige Preis konnte nur realisiert werden, da in den Geräten schlicht nichts IST als simple Audio-Hardware – und eben keine teuren DSP-Effektbausteine wie bei der teuren Konkurrenz. Das Audio der VSL-Geräte wurde IMMER durch den USB-Stack des Rechners geroutet, softwareseitig durch die Mixer-Software mit Effekten angereichert und dann in die Hardware zurückgeschickt. Das erklärt auch, warum in den VSL-Geräten nie etwas zu hören ist, wenn sie nicht gleichzeitig an einem Rechner hängen – es gibt schlicht kein direktes, in Hardware gegossenes Monitoring im Gerät selbst.

Um nun diesen aufwändigen Weg durch den Rechner ohne allzu große Latenz gehen zu können, wurden etliche Tricks angewandt und Spezifikationen ausgereizt. Apple hat wiederum im Audio- und USB-Bereich – vor allem beim Wechsel von USB 2 nach 3 – sehr viel und wohl nicht immer glücklich an den Spezifikationen gedreht. Presonus – bzw. deren Programmier-Auftragsschmiede – kam da nur extrem schleppend hinterher (etlichen anderen Audio-Buden erging es jedoch ähnlich).

Die Situation ist also offiziell die: keine Effekte mehr, vermutlich kein Monitoring. Für nicht wenige PodcasterInnen eine mittlere Katastrophe.

@gglnx und @rstockm gehen in Klausur

@gglnx und ich wollten das so nicht hinnehmen. Mit viel Liebe hatten wir uns fesche Audio-Racks gebaut, bestehend aus 1818VSL und 8-Kanal Kopfhörerverstärker. Zumindest wollten wir sicher gehen, dass es wirklich keinen Ausweg gibt außer das Update auf El Capitan auszusetzen.

Praktisch im Rack mit einem 8-fach Kopfhörerverstärker

Praktisch im Rack mit einem 8-fach Kopfhörerverstärker

Unser grundsätzlicher Ansatz: Solange das Interface sauber gebaut ist, könnte es möglich sein zumindest die Monitoring-Funktionen über das Betriebssystem zu realisieren – oder noch besser über die DAW Aufnahmesoftware (Ultraschall/Reaper).

Im Ergebnis wäre so die Presonus-Software komplett überflüssig, man könnte dieselben Features direkt in Reaper/Ultraschall abbilden. Die Grundlegenden Mechanismen des Audio-Routings und Monitorings habe ich hier schon einmal erläutert.

Entscheidend für die Alltagstauglichkeit einer solchen Lösung ist dabei die Latenz, also die Verzögerung, mit der das Audiosignal die Wegstrecke vom eigenen Mund über das Mikrofon, A-D Wandler, USB-Stack, DAW-Software, USB-Stack, D-A Wandler und zurück zum Kopfhörer zurücklegt. Gemessen wird die Latenz in Millisekunden (ms) – je kleiner, desto weniger Latenz und desto besser.

Wie misst man diese Latenz von Mikro zu Kopfhörer? Dazu habe ich eine eigene Ultraschall-Folge aufgenommen: Das verwendete Tool „Acoustic Ruler Pro“ hat – egal ob auf iPhone oder iPad eingesetzt – absolut nichts an seiner Nützlichkeit eingebüßt und wird nach wie vor jedem empfohlen, der mal Grund in sein Setup bringen möchte. Es gibt schlicht keinen einfacheren, zuverlässigeren und günstigeren Weg, um wirklich zu messen was im eigenen Headset vor sich geht.

CQp9sm_WoAAkWeH.jpg-large

Auf Kopfhörer ganz zu verzichten ist für versierte PodcasterInnen keine Option, denn:

  • Immersion: man fühlt und spricht anders mit der eigenen Stimme im Kopf
  • Skype und Mumble: wenn auch nur ein Gesprächspartner nicht im selben Raum sitzt, ist ein Kopfhörer unumgänglich
  • Einspieler: Intro, Jingles, andere Soundquellen – all das will man live hören und nicht erst im Schnitt hinzuarbeiten.

Grundlagen: Was Latenz mit Körper-, Direkt- und Reflektionsschall zu tun hat

Kritisch ist nur die Latenz der eigenen Stimme. Hält man sich die Ohren fest zu oder versiegelt sie komplett und spricht, hört man sich immer noch selber. Der Schall der eigenen Stimme wird vom Knochengerüst des Körpers ins Ohr geleitet. Zwar dumpf und nicht allzu laut, aber dennoch gut genug. Dieses Phänomen ist als „Körperschall“ bekannt und der Grund dafür, dass wir unsere eigene Stimme auf Aufnahmen nicht ausstehen können – sie klingt immer eindimensional und ohne Bass. Dies sind genau die Anteile im Frequenzspektrum und die Laufzeitverschiebungen, die der Körperschall unserer eigenen Stimme hinzufügt. In diesem Fraunhofer-Beitrag ist das schön zusammengefasst: es gibt nur exakt einen Menschen, der unsere Stimme scheinbar „normal“ hört. Und das sind wir selbst.

Aus diesem Grund setze ich, gerade für Podcast-EinsteigerInnen – gerne EQ-Filter schon bei der Aufnahme im Monitoring ein: dreht man den Bass einfach etwas hoch um 110KHz, so hört sich die Stimme für die SprecherIn viel „normaler“ an, nicht so fremd.

Warum ist nun Latenz bei der eigenen Stimme so ein großes Problem? Der Körperschall kommt praktisch unmittelbar in unserem Ohr an – er muss sich nicht durch Luft arbeiten und reflektieren, sondern geht direkt durch Knochen und Zähne. Alles was wir sprechen, kommt also mit 0ms Verzögerung im eigenen Ohr an. Unser Gehirn ist es gewohnt, eine weitere Quelle mit einzurechnen: den reflektierten Schall unserer Stimme wie er von Wänden, Möbeln etc. an unser Ohr zurück kommt. Dieser Klang der eigenen Stimme überlagert sich zwar mit dem Körperschall und kommt – je nach Raum – einige Millisekunden verzögert an. Aber das ist das Gehirn ein Leben lang gewohnt. Bedingt durch die Schallgeschwindigkeit von 343 Metern pro Sekunde ergibt sich eine gerundete Latenz von ca. 3ms pro Meter. Sitzt man 3 Meter von einer reflektierenden Wand entfernt, ergibt das hin und zurück 6 Meter, also 6×3 = 18ms Latenz. Ziemlich viel. Im Audio-Bereich für Sprache eigentlich komplett inakzeptabel, warum ergibt das im Alltag dennoch kein Problem? Das liegt an der neben Körperschall und Reflektionsschall bisher unterschlagenen, dritten Klangquelle unserer Stimme: dem Direktschall von Mund zu Ohr. Der ist zwar minimal langsamer als der Körperschall, die wenigen Zentimeter Entfernung werden aber dennoch in weniger als 1ms zurückgelegt. Dieser Direktschall ist auch dafür verantwortlich, dass wir beim Sprechen im Freien etwas von unserer Stimme hören, außer dem Körperschall – denn Reflektionen fehlen ja etwa auf einer grünen Wiese (wir bleiben mal bei einem einfachen Modell ohne Wind).

Dieser Direktschall von Mund zu Ohr ist relativ laut. Ich habe leider keine wissenschaftlichen Quellen dazu gefunden, würde aber vermuten, dass sich die Komponenten unserer Stimme, in einem normalen Raum gesprochen, in etwa so zusammensetzen: 30% Körperschall, 50% Direktschall, 20% Echo/Reflektionsschall (wenn jemand eine Messung hat: gern her damit).

Was passiert nun in einer Podcast-Situation? Man hat ein Mikrofon direkt vor dem Mund, dazu mehr oder weniger gut abschirmende Kopfhörer auf. Der Körperschall bleibt immer gleich laut. Durch den Kopfhörer werden jedoch die anderen beiden Anteile stark gedämpft – je nach Kopfhörer unterschiedlich stark. Dafür wird jedoch der Monitor-Klang des Soundinterfaces eingespielt, quasi als Ersatz für Direktschall und Reflektionsschall. Wird nun der latenzfreie, sonst dominante Direktschall ersetzt durch latenzbehafteten Monitoring-Schall, gerät unser Gehirn ins Trudeln, die Laufzeiten sind nicht die erwarteten.

Die Toleranz für Latenz ist bei jedem Menschen unterschiedlich. Alles unter 4ms ist unkritisch. Der Bereich von 4ms bis 6ms wird mal mehr, mal weniger als etwas irritierend empfunden. Von 6ms bis 10ms hören alle Menschen den Effekt, manche können ihn noch so eben tolerieren. Ab 10ms ist das vorbei: die Latenz ist so groß, dass man beginnt langsamer zu sprechen um die Laufzeiten auszugleichen, ein entspanntes Sprechen ist nicht mehr möglich.

Zurück zu unserem Presonus-Problem. Ausgestattet mit Acoustic Ruler, einem Zoom H6 als Referenzinterface, meinem Presonus VSL 1818, Beyerdynamics Headsets, einem Early 2015 MacBook Pro, OSX 10.11 El Capitan, Ultraschall und 5 Stunden Zeit haben @gglnx und ich alles durchgemessen was uns sinnvoll erschien.

Erster Test: Das Zoom H6 als Referenz

Ein Monitoring im Hardware-Soundinterface kommt – ordentliche A/D-D/A Wandler vorausgesetzt – praktisch immer latenzfrei daher. Eine Überraschung erlebt man hier beim Zoom H6: die Grundlatenz des Monitorings liegt schon bei 3,9ms ohne jegliche aktivierte Effekte. Für die Praxis absolut brauchbar,  aber doch erstaunlich hoch. Nimmt man Effekte wie Limiter oder Kompressor hinzu, steigt die Latenz auf grenzwertige 5,2ms. Da sich aber bisher noch niemand lautstark über diese Latenz beschwert hat, bestätigt sich obige Regel: alles unterhalb von 6ms ist in Ordnung.

Zweiter Test: Presonus ohne Effekte

Der wichtigste Test kam zuerst: welche Latenz wird erzielt, wenn man über die Routing-Matrix von Reaper/Ultraschall das eigene Mikrofonsignal unbearbeitet wieder an das VSL1818 zurückschickt? Wäre dieser Wer zu hoch (> 6ms) stünde ein Verkauf des Gerätes an – man würde schlicht die eigene Stimme nicht hören können.

Die gute Nachricht: die erzielte Latenz lag mit 4,4ms im grünen Bereich – nur knapp über dem H6 ohne Effekte. Dies ist insofern beachtlich, als dass in dem oben verlinkten Grundlagenartikel von Presonus als maximal erzielbare Latenz 5ms angegeben wurde. Wir sind also mit dem neuen Setup sogar schneller als wir es mit dem alten jemals waren.

Einen deutlichen Einfluss hat hierbei die in Reaper/Ultraschall einstellbare Block-Size für den Audio-Buffer. Generell gilt: je kleiner, desto niedriger kann man die Latenz drücken, unterhalb von 16 ergibt sich jedoch keine Verbesserung mehr. Unsere Messwerte:

  • Buffer bei 512: nicht mehr messbar hoch
  • Buffer bei 128: 9,1ms
  • Buffer bei 64: 6,5ms
  • Buffer bei 32: 5,1ms
  • Buffer bei 16: 4,4ms
  • Buffer bei 8: 4,4ms
  • Buffer bei 4: 4,4ms

Generell gibt es hier einen Trade-Off zwischen Stabilität und Performance. Buffer unter 16 sind für Aussetzer und Knackser definitiv anfällig. Je älter der Rechner, desto höher muss man den Buffer setzen. Wir liefern Ultraschall mit einem sehr konservativen Wert von 512 aus. Bisher wurde ja die eigene Stimme nicht durch Reaper für das Monitoring geführt, und bei allen anderen Stimmen ist die Latenz schlicht egal dank fehlendem Körperschall.

Will man diesen neuen Monitoring-Weg beschreiten, sollte man daher sorgfältig probieren, wo die Performance des eigenen Rechners liegt und wann Störungen hinzukommen.

Dritter Test – Effekte

Generell ermutigt haben wir als nächstes getestet, welchen Einfluss Effekte in Reaper/Ultraschall auf die Latenz haben. Das VSL1818 hatte – wie oben erwähnt – Effekte, und auf diese möchte man eigentlich nicht verzichten.

Der erste Versuch war wenig ermutigend: der von uns geliebte „Dynamic Processor“ Effekt – Limiter, Kompressor und Expander kombinierend – ließ die Latenz auf nicht akzeptable 15ms hochschnellen.

Sehr viel besser sah es aber bei den mit Reaper mitgelieferten, von Cockos handgeschmiedeten Rea* Effekten aus. EQ, Limiter, Noisegate und Kompressor bringen keine nennenswerte zusätzliche Latenz in die Kette. Selbst wenn alle gleichzeitig aktiviert sind, werden 5,1 ms nicht überschritten. Das ist knapp besser als das H6. Und im Ergebnis schlicht der Durchbruch: alle im VSL bisher angebotenen Effekte können im neuen Setup ebenfalls genutzt werden, ohne dass die Latenz steigt. Dazu kann man sie wesentlich flexibler parametrisieren als das in der doch eher kargen VSL-Mixersoftware je der Fall war.

Selbst wenn es die Mixersoftware für El Capitan gäbe, würden wir diese neue, rein Reaper-interne Behandlung empfehlen – je weniger Komponenten in der Kette, desto besser.

Möglicherweise ist dieses Verfahren auch für andere Soundinterfaces geeignet: hier wären wir sehr an Vergleichsmessungen interessiert. Auch ist noch unklar, welchen Einfluss die CoreAudio Überarbeitungen von El Capitan auf die Latenz haben, und welche Werte unter Yosemite erzielt würden.

Vierter Test – Aggregate Device und Skype N-1

Eine Teststrecke war noch wichtig: wie verhält sich das Setup, wenn zusätzliche Komplexität in Form eines Aggregate Device und Skype N-1 Schaltung hinzukommt? Erste, wenig überraschende Erkenntnis: die Tage von Soundflower unter El Capitan sind beendet. Unser letzter, angepasster USH-Treiber – im Kern immer noch auf Soundflower basierend – läuft zwar, allerdings immer mit extremem Knacksen und Störungen. Auch bei hoch eingestelltem Buffer von 128.

Abhilfe bringt hier der von Daniel gerade neu entwickelte Ultraschall Hub Treiber: El Capitan only, und direkt entlang der neuen Core-Audio-API entwickelt. Skype wurde nutzbar, wenn auch zu einem Preis. Bei einem Buffer von 16 stieg die Latenz von 4,4ms auf 5,2ms und es kam relativ regelmäßig zu Knacksern. Bei 32 verschwanden diese fast vollständig, die Latenz lag ebenfalls um 0,7ms höher: 5,8 statt 5,1. Keinerlei Störungen gab es mehr bei einem Buffer von 64: die 7,2ms Latenz haben uns dann jedoch schon ziemlich gestört.

Generell ist hier noch Grundlagenforschung notwendig, auch die Arbeiten am Hub sind noch nicht abgeschlossen. Wir sind aber zuversichtlich, hier mit unserer Ultraschall 2.0 Release zum #ppw15b Klarheit zu haben.

Fazit

Im Ergebnis ist der eingestellte Presonus-Support für die VSL-Geräte wohl nicht die gefürchtete Katastrophe. Der Device „Scheitern als Chance“ folgend haben wir – zumindest auf aktuellen Macs – gute Chancen, mit größerer Kontrolle ein besseres Setup zu fahren als bisher – solange man keine Aggregate Devices benötigt. Für diese Ferngesprächs-Setups ist noch weitere Forschung notwendig – Messwerte gerne im Sendegate einbringen!

 

Yosemite, Ultraschall und Podcasting

Yosemite, die neuste Inkarnation von OS X (Version 10.10) ist nun seit etlichen Tagen als Final verfügbar. Leider bringt diese Release für die Podcastwelt eher Probleme mit sich als Lösungen oder Verbesserungen. Im Folgenden versuche ich den aktuellen Forschungsstand zusammenzufassen:

 

Reaper und Yosemite

Es gibt derzeit keine Anzeichen dafür, dass Reaper als Aufnahmesoftware – bzw. unser Ultraschall-Theme – zu irgendwelchen Problemen in Yosemite führt. Hier kann Entwarnung gegeben werden. Auch Nicecast scheint problemlos zu laufen.

Soundflower und Yosemite

Hier fangen die Probleme an. (Wer sich fragt, wozu Soundflower zum Podcasting gut sein soll: das erkläre ich in meinem Screencast ab Folge 9) Der häufigste Fall nach einem Update von Mavericks mit installiertem Soundflower-Treiber – egal ob das Original oder unsere optimierte Ultraschall-Version – scheint zu sein: alle neu angelegten Kanäle bzw. virtuellen Soundkarten sind in der Audio-Midi Steuerung verschwunden. Eine Neuinstallation der Treiber scheitert in der Regel.

Der Grund scheint darin zu liegen, dass Yosemite bei einem Upgrade die schon recht tief ins System eingreifenden Treiber vorsichtshalber löscht, jedoch nicht gründlich genug. Reste der Treiber verhindern dann nach einem Upgrade eine einfache Neuinstallation. Die händische Entfernung dieser Reste ist relativ aufwändig.

Die Lösung: Heiko aus unserem Team hat einen Uninstaller gebaut, der rückstandslos alle vorherigen Soundflower/Ultraschall Spuren beseitigt und eine Neuinstallation ermöglicht. Da man nicht einfach so jedem daher gelaufenen Script vertrauen sollte, könnt Ihr hier den Quellcode einsehen. Ihr findet unseren Uninstaller hier:

Achtung: wir hatten noch keine Zeit, den Uninstaller so zu modifizieren, dass die Bildschirm-Texte Sinn ergeben – man installiert nichts, sondern Deinstalliert. Lasst Euch dadurch nicht irritieren und klickt einfach immer auf „Weiter“.

Sind die Altlasten erst einmal entfernt, läuft die Neu-Installation von Soundflower problemlos durch. Eventuell müsst Ihr die Rechte im System anpassen, so dass auch Software von nicht-lizensierten Entwicklern zugelassen wird. Wir arbeiten noch an diesem Detail:

sicherheit

Für die Neuinstallation könnt Ihr entweder auf die bewährte Distribution von Marius Eisenbraun zurück greifen oder aber unsere eigene, weiter reduzierte Fassung probieren:

Dieser Treiber nutzt dieselbe technische Grundlage wie die alte Fassung, reduziert aber weiter die Anzahl der Kanäle: die Skype-Devices etwa sind nun sinnvoller Weise beide in Mono gehalten. Das schafft insgesamt mehr Übersicht und schont Ressourcen.

Wir arbeiten gerade noch an einem Geheimprojekt, das aber wohl erst zum Podlove Workshop Ende November das Licht der Welt erblicken wird. Mit dem Verfahren oben solltet Ihr jedoch – bis auf die unten zu diskutierenden Probleme – prinzipiell wieder aufnahmefähig sein.

Yosemite und Audioprobleme

343Max fasst es leider sehr treffend zusammen:

max

Man muss leider feststellen: es vergeht derzeit kein Tag, an dem mich nicht Katastrophenmeldungen aus dem Lager der PodcasterInnen erreichen nach Updates auf Yosemite. Diese lassen sich grob in diese Rubriken unterteilen:

  • Knistern auf Aufnahme/Stream/Kopfhörern. Dieses Problem ist derzeit ungemein weit verbreitet und uns wohl bekannt: einige Mavericks-Versionen reagierten in Kombination mit USB2 Soundinterfaces an USB3 Ports ganz ähnlich. Entgegen ersten Vermutungen sind hiervon nicht (mal wieder) vor allem Presonus-Geräte betroffen, sondern mindestens auch Focusrite und Steinberg, vereinzelt auch M-Audio. Zusammengefasst lässt sich sagen: wir sind wieder auf dem Stand von vor ca. 12 Monaten. Clemens hat in der Freakshow dazu alles Wesentliche gesagt: die Firmen kommen trotz langer Beta-Testphase mal wieder nicht aus dem Quark. Mögliche Lösungen fallen hier sehr unterschiedlich aus. Bei meinem 1818VSL hat es geholfen, ein Downgrade auf den vorletzten Treiber vorzunehmen. Da keinerlei Features hinzu kamen, ist das bis auf weiteres ein brauchbarer Weg. Andere berichten dass es hilft, in der Audio-Midi Steuerung die Drift-Korrektur zu deaktivieren (diese regelt eigentlich das zeitlich synchron laufen der verschiedenen aggregierten Devices). Eventuell hilft auch das Zwischenschalten eines zusätzlichen, strombetriebenen HUBs. Generell muss man sagen, dass hier noch Grundlagenforschung nötig ist – ich aktualisiere diesen Bereich sobald sich Neues ergibt.
  • Ausfall von Soundflower/Ultraschall Devices. Scheint zum Glück deutlich seltener vorzukommen, dann aber scheinbar unmittelbar und ohne Vorwarnung im Betrieb – also während der Aufnahme, dann wenn man es wirklich nicht brauchen kann. Muss weiter beobachtet werden, Vorkommnisse bitte hier in den Kommentaren posten!
  • Das Soundinterface startet gar nicht erst. War auch bei meinem 1818VSL der Fall, hier hilft wohl vor allem ein „Hot-Plugin“: im Betrieb das laufende Gerät aus der USB-Buchse heraus- und wieder hineinstecken. Was dann nur zu besagtem Knister-Problem (s.o.) führte. Es lohnt sicherlich auch, die Herstellerseiten abzuklappern und nach aktualisierten Treibern zu forschen. Oder eben gerade – wie im Fall von Presonus – ältere zu nehmen. Eine sehr unbefriedigende Situation.

Fazit: derzeit kann für all diejenigen, die störungsfrei Podcasts auf dem Mac produzieren wollen und ein stabiles System schätzen, von einem Update auf Yosemite nur abgeraten werden. Die Probleme sind relativ konfus aber breit gestreut. Möglicherweise wird das alles mit dem nächsten Patch behoben, der Angriff Steiner erfolgt oder jemand findet den Schlüssel zu all den unterschiedlichen Problemen. Derzeit bringt das Update auf Yosemite aber keinerlei Vorteile sondern eher nur Stress. Bleibt bei Euren stabilen Setups, produziert coole Sendungen und lest hier mit, wie sich die Lage entwickelt.

Alle von Euch, die Probleme haben, oder aber auch Lösungen gefunden haben: bitte schreibt hier in den Kommentaren rein, was Euer Setup ist und wo Probleme auftauchen. Wenn alles fehlerfrei läuft: auch das ist eine Erwähnung wert, immer bitte mit Angabe der genauen Hardware (Mac+Audiointerface).

 

 

 

HowTo: Zeitversatz bei Kapitelmarken beheben

Wenn man wie in Ultraschall Folge 3 beschrieben Kapitelmarken in Reaper erzeugt, so war die Wahrscheinlichkeit sehr hoch dass diese nach einer Bearbeitung durch Auphonic einen Versatz um mehrere Sekunden in der fertigen M4A Datei aufwiesen. Je nachdem wie exakt sie gesetzt wurden merkte man diesen Effekt mal mehr, mal weniger. Eine Anfrage im Reaper-Forum brachte keine Erkenntnisse.

Im Zuge meiner Ultraschall-DR Edition tauchte die Frage wieder auf und so habe ich heute mal eine Teststrecke aufgebaut: ein exakt drei Stunden langes Audiofile. Um den Schwierigkeitsgrad zu erhöhen war dieses in 44.1k aufgenommen und in ein 48k Hz Projekt importiert. Einfach kann ja jeder. Ich habe dann an glatten Stellen mutwillig einen extremen Audio-Peak eingebaut, und zwar an die Stellen 30 Minuten, 2 Stunden sowie direkt kurz vor dem Ende bei 2:59 Stunden. An ebendiesen Stellen habe ich drei Kapitelmarken gelegt und verschiedene Setups ausprobiert.

marker

Ergebnis: der Fehler tritt recht reproduzierbar auf: pro Stunde entsteht ein Versatz um ca. 4 Sekunden. Dieser bildet sich ebenfalls in der Gesamtlänge des Projektes nach dem Rendern ab. Die Kernfehlerursache ist hierbei die von Reaper normalerweise vorgegebene Project Framerate von 23.976. Die Project Framerate legt fest, welche Unterteilungen Reaper unterhalb einer Sekunde verwaltet. Der sonderbare Wert stammt aus dem AV-Bereich (NTSC) und soll wohl dazu führen, dass integrierte Videospuren out of the box synchron laufen. Um uns Podcaster macht sich mal wieder niemand Gedanken.

Stellt man diesen Wert um auf einen der ganzzahligen um – in meinem Fall auf 75, also die höchste Auflösung –  und zugleich sämtliche Settings in Reaper von „Beats“ auf „Time“ so sieht die Welt sofort ganz anders aus: das 48k Hz Projekt ist bis auf das einzelne Frame exakt 3:00:000 lang, alle Peaks sitzen an der richtigen Stelle auch nach einem Render-Export, der Render-Dialog gibt exakt die richtige Länge an.

Settings

Hierbei ist noch zu beachten, dass es eine weitere wenig beachtete Preferences-Einstellung gibt: unter Audio/Render findet sich eine „Tail“ Einstellung mittels der man in ms angeben kann wieviel zusätzliche Stimme man am Ende des Projektes hinzufügen möchte, die steht standardmäßig auf 1.000 also eine Sekunde. Setzt man die auf 0 hat man immer verlässlich Projektzeit = Renderzeit.

Ein Test mit dieser Datei in Auphonic führt ebenfalls zu einem einwandfreien Ergebnis:

Auphonic_result

Zur Dokumentation habe ich sämtliche Dateien hier abgelegt: das .m4a kann man zur Kontrolle lokal laden und in Quickview öffnen – da kann man direkt links die Kapitel anspringen.

Nach einigen Debatten mit nitramred haben wir noch eine weitere Verbesserung erzielt: das bisher präferierte Zeitformat in Reaper hours:minutes:seconds:frames ist brauchbar, aber für unsere Zwecke perfekt ist minutes:seconds. Bei letzterem entsteht de fakto ein hours:minutes:seconds.milliseconds Format in Transporter-Zeitanzeige und Kapitelmarkendatei, und das ist exakt das was wir wollen.

tl;dr
die richtigen Settings für exakte Kapitelmarken aus Reaper zu Auphonic gibt es morgen in meiner nächsten Ultraschall-DR Release Beta 3. Dann wird alles gut.

 

 

Gesucht: Betatester für Ultraschall-DR Edition von Reaper

Die vielen Rückmeldungen zur letzten Folge – Reaper für Podcasting tunen – haben mich auf den Gedanken gebracht, noch konsequenter in diese Richtung zu arbeiten. Erstes Etappenziel ist dabei die Bereitstellung ein Themes, das die Vorzüge des zuletzt vorgestellten Analog Default noch stärker auf das Podcasting bezieht. Es soll diesen Anforderungen genügen:

  • Sauberes, klares, einfaches Design. Wir halten es hier mit Adolf Loos und dem Namensgeber DR.
  • Redundanz vermeiden: Die normalen Reaper-Themes leiden unter dem Umstand, dass Funktionen an mindestens zwei, manchmal noch mehr Stellen angezeigt/angeboten werden. Dies gilt es drastisch zu reduzieren, vor allem im Bereich der TPC (der Bereich links neben den Wellenformen).
  • Abschalten nicht benötigter Funktionen: Podcaster benötigen nur ca. 10% der Funktionen von Reaper. Innerhalb eines Themes hat man die Möglichkeit, Elemente einfach auszublenden bzw. sich auf einen aussichtsreichen Weg zu konzentrieren. Ca. 2/3 der bisherigen GUI-Elemente wurden im Ergebnis bereits von mir entfernt.
  • Orientierung am Workflow: in Folge 13 stelle ich am Ende das von vielen gefeierte Workflow-View Konzept vor. Ich gehe dabei von der Annahme aus, dass jede Podcastfolge in drei Schritten entsteht: 1) Setup – das Einrichten der Spuren, Effekte, Routing, Aussteuerung. 2) Sendung – Aufnahme, Einspielen externer Quellen und setzen von Kapitelmarken 3) Nachbereitung – Schnitt, Feintuning der Kapitelmarken, Export Kapitelmarken, Export Audio. Während dieser drei Phasen benötigt man unterschiedliche Werkzeuge und Optionen. Daher wurde das Workflow-View Konzept konsequent weiter gedacht: Nicht nur die Fensteranordnung wechselt nun über die Tastenkombinationen F7/F8/F9, sondern auch die GUI-Elemente innerhalb der Fenster werden entsprechend ein- oder ausgeblendet – was hoffentlich die Fokussierung auf die jeweilige Aufgabe erleichtert. So zeigt etwa der Mixerbereich im Setup-View noch relativ viele Funktionen, ist aber im Sendungs-Modus drastisch reduziert auf die reine Pegelanzeige. Während der Sendung sind Schalter eher gefährlich. Im Nachbereiten-View verschwinden sowohl TPC als auch der komplette Mixerbereich – und machen Kapitelmarken und Birds-Eye-View Navigator Platz.
Workflow

Die drei Views Setup, Sendung und Nachbereitung (von oben nach unten)

Ich habe nun einen Beta-Downloadbereich für dieses Paket zusammengestellt und würde mich freuen, wenn sich eine Handvoll Freiwilliger melden könnten: Wie sie damit klar kommen, ob die generelle Richtung stimmt, ob zu viel abgeschaltet wurde etc. Im Kern importiert man das komplette Setup über Preferences/General/Import Configuration und wählt als Projekttemplate „Ultraschall“ aus – es mag aber sein, dass dann immer noch einige Schalter zu setzen sind. Bitte hier in den Kommentaren oder auf ADN/Twitter melden, ich schreibe dann noch einmal eine detailliertere Anleitung wie die Installation gelingt. Dieses Setup geht in einigen Punkten noch über das in Folge 13 gezeugte hinaus: so habe ich etwa die Trackpadsteurung an die MAC-Gepflogenheiten angepasst, Zoom erfolgt nun über eine Pinch-Bewegung.

Wenn sich dieser Ansatz stabilisiert, baue ich dazu eine neue Screencastfolge. Perspektivisch wäre auch denkbar, ein komplett eigenes Podcast-Design umzusetzen – die Templating-Engine von Reaper gibt das problemlos her. Dafür müsste man dann aber talentierte GUI-Designer an den Start bekommen.

Folge 13 – Reaper für Podcasting tunen

Es kann nicht schaden, diese Folge direkt als zweite (nach der wohin soll die Reise gehen) zu schauen: hier werden viele nützliche Tipps und Tricks vermittelt, wie man die für Musiker entwickelte Software Reaper optimal für das Podcasting geradebiegt. Im Zentrum steht dabei eine reduzierte, elegante Anmutung die sich an den drei Workflowschritten Setup, Sendungsaufzeichnung und Nachproduktion orientiert. Vielleicht – ganz vielleicht – ist das dann ja ein beherzter Schritt ins Podcast-Wunderland.

Downloadseite des Themes: Analog Default

Folge 12 – Monitoring und Routing-Foo

In dieser Folge beschäftigen wir uns mit Fragen des Audio-Routings innerhalb von Reaper und zurück zu unserem Mischpult. Diese Lektion ist entscheidend dafür, dass wir auf unseren Kopfhörern nicht sonderbare Chorus-Effekte hören. Wichtig und in der Folge nicht erwähnt: zum Rausrendern der fertigen Folge müssen die Master-Sends in der Routing-Matrix wieder aktiviert werden!

Folge 11 – Skype N-1 Schaltung Digital

Dank der in der letzten Folge installierten virtuellen Soundflower-Soundkarten können wir heute endlich unsere Skype N-1 Schaltung umsetzen. Rein digital, ohne Kabel. Hier geht es zu der Soundflower Ultraschall Edition von @ms_eis

Folge 10 – Soundflower erweitern

Um die abschließenden Folgen – etwa die rein digitale Skype N-1 Schalte – umsetzen zu können, müssen in die Eingeweide von Soundflower eingreifen. Diese Folge zeigt, wie das geht. Im Prinzip kann man sich diese Folge mittlerweile fast sparen, da @mr_eis alle Probleme mit dieser speziellen Soundflower-Distribution löst: Und jetzt flattern alle #podcaster mal den @Mr_Eis für seine grandiose Soundflower-Distribution

Folge 9 – Einspieler ohne Kabel

Die Kabel müssen überwunden werden! Es ist doch etwas absurd: die einzuspielende Audiodatei befindet sich schon auf dem Rechner, auf dem auch aufgenommen wird – warum kriegt man die nicht direkt in Reaper? Ganz so einfach ist es nicht, aber auch nicht unlösbar. Die Software, die dies ermöglicht und uns auch durch die nächsten Folgen begleiten wird heißt Soundflower

Folge 8 – Externe Zuspieler

Ein Podcast wird lebendig, wenn man live Einspieler verwendet. Wie bringt man aber nun Jingles, Musik und sonstige Einspieler live und elegant in den Podcast? In dieser Folge schauen wir uns dazu zunächst eine sehr robuste, klassische Umsetzung an – der Einsatz eines externen Zuspielers.