Was passiert, wenn die Verbindung während der Transkription auf dem iPhone abbricht?

Diese Frage kommt meist aus einer ganz bestimmten Situation: Eine Transkription lief, ein Aufzug kam, ein Tunnel begann, das Telefon wechselte beim Verlassen der Wohnung von WLAN auf Mobilfunk, und danach kam entweder nichts zurück oder ein offensichtlich sinnloser Text. Es lohnt sich, das, was tatsächlich passiert ist, von dem zu trennen, wonach es sich angefühlt hat, denn die beiden Fehlerwege auf dem iPhone sind nicht dasselbe und haben nicht dieselben Folgen.

Die beiden Versuche hängen nicht gleich stark von der Verbindung ab

iOS versucht immer zuerst die Erkennung auf dem Gerät. Dieser Durchlauf läuft vollständig gegen ein Sprachmodell, das bereits auf dem Telefon gespeichert ist — er hat keinen Netzwerkschritt, der unterbrochen werden könnte, sodass ein WLAN-Abbruch oder totes Mobilfunksignal während dieses Teils am Ergebnis nichts ändert. Wenn allein dieser erste Durchlauf die Transkription geliefert hat, war ein Verbindungsabbruch zu irgendeinem Zeitpunkt währenddessen nie ein Faktor.

Der Teil, der tatsächlich von einer Verbindung abhängt, ist der erneute Versuch: Kommt der Durchlauf auf dem Gerät leer zurück oder wirft einen Fehler, ist der übliche nächste Schritt ein zweiter Versuch mit deaktivierter On-Device-Erkennung, der das Audio an Apples Sprachdienst schickt und auf den zurückkommenden Text wartet. Das ist der einzige Moment im gesamten Ablauf, in dem der Verlust der Verbindung dem Ergebnis tatsächlich etwas antun kann.

Was ein Verbindungsabbruch dieser Anfrage antut

Der Server-Rückfall ist kein Datenstrom, der laufend Wörter nachliefert und plausibel die erste Hälfte eines Satzes zurücklassen könnte. Er wird als eine einzelne Anfrage gesendet und mit einer einzelnen Antwort beantwortet: Audio hinein, Text heraus, oder gar nichts. Es gibt keinen Zwischenzustand, in dem das Telefon drei Viertel einer Transkription erhalten hätte. Bricht die Verbindung ab, während diese Anfrage unterwegs ist, scheitert die Anfrage einfach daran, sich abzuschließen, und übrig bleibt genau das, was jeder andere fehlgeschlagene Versuch hinterlässt: eine leere oder fehlende Transkription, keine abgehackte oder wirre.

Das bedeutet auch, dass es nichts aufzuräumen gibt. Eine fehlgeschlagene Anfrage hinterlässt weder eine beschädigte Datei noch einen hängenden Prozess noch eine halb geschriebene Transkription in der App. Sie hinterlässt genau das, was ein Fehlschlag hinterlassen würde, der nie mit dem Netzwerk zu tun hatte: Nichts hat sich geändert, ein Versuch ist verbraucht, und es bleibt, es erneut zu versuchen, sobald die Bedingungen andere sind.

Bedeutet ein Verbindungsabbruch, dass trotzdem Audio hinausgegangen ist?

Das ist der ehrliche, etwas unbefriedigende Teil der Antwort. Eine Anfrage, die auf halbem Weg scheitert, ist nicht dasselbe wie eine, die nie begonnen hat: Ein Teil des Audios kann das Telefon durchaus schon verlassen haben, bevor die Verbindung abbrach, auch wenn nie eine Transkription dafür zurückkam. Es gibt keine verlässliche Möglichkeit für eine App, die auf dem Sprach-Framework des Systems aufsetzt, zu sagen, wie weit eine zum Scheitern verurteilte Anfrage gekommen ist, bevor sie abbrach. Was sich mit Sicherheit sagen lässt, ist enger gefasst, aber trotzdem nützlich: Eine fehlgeschlagene Anfrage liefert kein Ergebnis, also wurde mit dem, was teilweise hinausgegangen sein mag, nichts gewonnen, und die Quellaufnahme auf dem Telefon wird davon in keinem Fall berührt. Wer für eine bestimmte Datei wirklich die Garantie braucht, dass gar nichts hinausgegangen ist, bekommt sie nicht dadurch, dass er auf einen günstig getimten Abbruch hofft — sondern indem er im Flugmodus transkribiert, wo die Rückfall-Anfrage von vornherein keinen Weg nach draußen hat und nur der Durchlauf auf dem Gerät überhaupt laufen kann.

Wie sich das von einer aus anderen Gründen leeren Transkription unterscheidet

Eine leere oder fehlende Transkription durch einen Verbindungsabbruch sieht von außen genauso aus wie eine, die durch leises Audio, die falsch eingestellte Sprache oder ein fehlendes On-Device-Modell entsteht — in jedem Fall landet man vor einem leeren Ergebnis ohne jede Fehlermeldung, die erklärt, warum. Der Weg, sie auseinanderzuhalten, führt über die eigenen Bedingungen, nicht über die Transkription selbst: Wer weiß, dass die Verbindung zu dem Zeitpunkt instabil war, hat damit die wahrscheinlichere Erklärung — und die Lösung ist auch eine andere. Eine falsch gewählte Sprache verlangt, die Einstellung zu korrigieren. Leises Audio verlangt beim nächsten Mal ein näheres Mikrofon. Ein Verbindungsabbruch verlangt gar nichts zu ändern — nur eine stabile Verbindung und einen weiteren Versuch mit genau derselben Datei.

Was man konkret tun sollte

• Warten, bis eine vertrauenswürdige Verbindung besteht, und dieselbe Aufnahme erneut transkribieren. Am Audiofile hat sich nichts geändert, also gibt es keinen Grund, warum sich ein zweiter Versuch bei stabilem Netz anders verhalten sollte.
• Wer häufig zwischen WLAN und Mobilfunk wechselt — beim Verlassen eines Gebäudes, auf dem Weg zur Arbeit, beim Fahren durch ein Gebiet mit lückenhaftem Empfang —, sollte das als wahrscheinliche Ursache in Betracht ziehen, bevor er einen Fehler bei der Aufnahme selbst vermutet.
• Ist das lokale Modell für eine Sprache auf dem Telefon installiert, spielt ein Verbindungsabbruch während des ersten Versuchs keine Rolle, weil dieser Versuch nie ein Netz brauchte. Ein Abbruch zählt nur, wenn der Durchlauf auf dem Gerät bereits fehlgeschlagen ist und der erneute Versuch gerade läuft.
• Für alles, bei dem der genaue Wortlaut nicht verloren gehen darf, lieber dort transkribieren, wo eine verlässliche Verbindung besteht, statt ausgerechnet in der einen Funkloch-Stelle der gewohnten Strecke.

Wie Voice Studio das handhabt

Voice Studio folgt demselben zweistufigen Ablauf: zuerst die Erkennung auf dem Gerät, und nur ein erneuter Versuch gegen Apples Server, wenn dieser erste Durchlauf leer zurückkommt oder fehlschlägt. Bricht die Verbindung ab, während dieser erneute Versuch läuft, schlägt der Transkriptionsversuch fehl, und die Transkription kommt leer zurück, nicht teilweise oder beschädigt — die Aufnahme selbst bleibt völlig unberührt, da Transkribieren ein eigener Schritt ist, der sich jederzeit wiederholen lässt. Es gibt nichts rückgängig zu machen und keinen Zustand zu reparieren; die Transkription bei einer stabileren Verbindung erneut zu starten, ist bereits die vollständige Lösung.

Häufige Fragen

Kann ein Verbindungsabbruch meine Aufnahme beschädigen oder verkürzen?

Nein. Die Audiodatei ist bereits fertig und gespeichert, bevor überhaupt auf Transkribieren getippt wird. Eine fehlgeschlagene Netzwerkanfrage während der Transkription hat keine Möglichkeit, rückwirkend eine bereits bestehende Aufnahme zu verändern.

Bekomme ich eine teilweise Transkription, wenn die Verbindung mittendrin abbricht?

Nein. Der Server-Rückfall bekommt entweder eine vollständige Antwort oder gar keine — einen Zustand für eine teilweise Transkription gibt es nicht. Ein Verbindungsabbruch erzeugt ein leeres oder fehlendes Ergebnis, wie jeder andere fehlgeschlagene Versuch auch.

Wie erkenne ich, ob eine leere Transkription an einem Verbindungsabbruch lag oder an etwas anderem?

Die Transkription selbst verrät es nicht. Die eigene Erinnerung an die Bedingungen ist der bessere Hinweis — eine zu dem Zeitpunkt instabile Verbindung deutet auf einen Netzwerkfehler hin, während eine falsch gewählte Sprache oder sehr leises Audio auf etwas anderes hindeuten.

Gibt es eine Möglichkeit, sicherzustellen, dass nichts vom Telefon hinausgegangen ist, selbst wenn die Verbindung wackelig war?

Ja: im Flugmodus transkribieren. Ohne jedes verfügbare Netz hat die Rückfall-Anfrage keinen Weg nach draußen, sodass nur der Durchlauf auf dem Gerät laufen kann — entweder entsteht eine Transkription vollständig auf dem Telefon, oder es kommt nichts, ohne einen unklaren Zwischenfall.