Vom gescannten PDF zum Hörbuch: Warum es schwierig ist und wie wir es gelöst haben

Fünf Sekunden Stille

Eine Leserin aus Chile meldete sich an, lud ein 74-seitiges PDF eines Kinderromans hoch — "¿Quién le tiene miedo a Demetrio Latov?" von Angeles Durini — und klickte auf Hörbuch erstellen. Fünfzehn Sekunden später kam eine E-Mail: "Dein Hörbuch ist fertig."

War es nicht. Die Datei war 5,6 Sekunden lang. Sie enthielt nichts.

Das ist die Art von Bug, die man nur in der Produktion entdeckt, denn die Test-PDFs, die wir verwendet hatten, enthielten eingebetteten Text. Ihres nicht. Das Buch war 2012 Seite für Seite mit Adobe Acrobat Pro eingescannt worden — und jede Seite war als Bild gespeichert. Für unsere Pipeline war das PDF 74 leere Seiten.

Warum gescannte PDFs Hörbuch-Pipelines zerbrechen

Ein PDF kann Text auf zwei völlig unterschiedliche Arten transportieren:

• Text-PDFs — Wörter sind als echte Zeichen mit Schriftart und Position gespeichert. Jede Bibliothek (pypdf, pdfminer, pypdfium2) kann sie in Millisekunden extrahieren.
• Bild-PDFs (Scans) — Seiten sind JPEG- oder TIFF-Bilder, eingebettet in den PDF-Container. Für eine Textextraktions-Bibliothek enthalten diese Seiten null Zeichen.

Alles, was aus einem Flachbettscanner, einer Handykamera oder einem alten Digitalisierungsprojekt stammt (man denke an Google Books, archive.org, gemeinfreie Nachdrucke, gebrauchte Kinderbücher), ist meist die zweite Sorte. Für das menschliche Auge sehen sie identisch aus. Für Software sind sie grundverschieden.

Als wir den fehlgeschlagenen Upload untersucht haben, hatte unser PDF-Parser für das gesamte 74-seitige Buch genau 17 Zeichen Müll zurückgegeben — Steuerbytes, keine Buchstaben. Unsere Pipeline hat diese 17 Bytes brav an die Sprachsynthese weitergereicht und 5 Sekunden Gemurmel produziert. Dann hat sie der Leserin eine E-Mail geschickt, dass ihr Hörbuch fertig sei.

Was wir gebaut haben

Die Lösung ist konzeptionell einfach: erkennen, wenn ein PDF keinen nutzbaren Text hat, dann jede Seite per OCR verarbeiten. Die Umsetzung hat ein paar erwähnenswerte Bausteine.

1. Ein Detektor für spärlichen Text

Bevor wir für jeden Upload blind OCR anwerfen, prüfen wir das Ergebnis der nativen Extraktion. Wenn das ganze PDF weniger als 200 Zeichen liefert, oder wenn der Durchschnitt über 4 oder mehr Seiten unter 30 Zeichen pro Seite liegt, behandeln wir es als Scan und greifen auf OCR zurück. Normale Text-PDFs — der Fall in über 90 Prozent — lösen den langsamen Pfad nie aus.

2. pypdfium2 + tesseract (durchgehend Apache 2.0)

Wir rendern jede Seite mit pypdfium2 (einem Python-Wrapper um Googles PDFium-Engine, Apache 2.0) bei 2,5-facher Skalierung — etwa 180 DPI, genug für zuverlässige Zeichenerkennung. Jedes Bild läuft durch tesseract mit einem mehrsprachigen Modell: eng+spa+por+fra+deu+pol+ita+tur. Tesseract ermittelt die tatsächliche Sprache anhand der Buchstabenformen selbst.

Wir sind bewusst von PyMuPDF abgerückt — der populärsten Python-PDF-Bibliothek — weil ihre AGPL-Lizenz für einen gehosteten Dienst unpraktisch ist. Der Wechsel zu pypdfium2 hat einen Nachmittag gedauert und die rechtliche Klippe komplett beseitigt. Gut zu wissen, wenn man irgendetwas PDF-bezogenes für ein kommerzielles Produkt baut.

3. Automatische Spracherkennung

Das Buch der Leserin war spanisch, aber ihre Oberflächensprache war englisch — selbst wenn OCR vor unserem Fix funktioniert hätte, hätte die Pipeline den spanischen Text also mit einer englischen Stimme synthetisiert (roboterhaft, falsch ausgesprochen). Jetzt nutzt die Spracherkennung selbst den per OCR gewonnenen Text. Nach drei Beispielseiten klassifiziert langdetect den Inhalt und wählt die richtige Stimme aus — in diesem Fall lateinamerikanisches Spanisch.

4. Ehrlicher Fehlerpfad

Wenn OCR weiterhin weniger als 100 Zeichen wiederherstellt (rein dekorative PDFs, defekte Dateien), werfen wir jetzt einen klaren Fehler, statt Stille zu erzeugen: "Dieses PDF enthält keinen extrahierbaren Text. Bitte lade ein EPUB, eine TXT-Datei oder ein textbasiertes PDF hoch." Der Hörbuch-Job wird als fehlgeschlagen markiert, es wird keine E-Mail versendet und es werden keine Credits abgezogen.

Das Ergebnis

Wir haben das PDF der Leserin durch die umgebaute Pipeline laufen lassen. Fünf Minuten OCR extrahierten 144.710 Zeichen sauberes Spanisch aus ihren 74 gescannten Seiten. Die Pipeline zerlegte den Text in 1.127 Segmente und produzierte ein 2 Stunden 43 Minuten langes Hörbuch mit Mitlese-Synchronisierung — Wort für Wort hervorgehoben, gekoppelt an das Audio. Wir schrieben ihr auf Spanisch, auf unsere Kosten, und entschuldigten uns für den ersten Versuch.

Der gesamte Neudurchlauf brauchte rund 90 Minuten Echtzeit: etwa 5 Minuten für OCR, 80 Minuten für die Sprachsynthese, ein paar Minuten für die Audionormalisierung (EBU R128) und die M4A-Finalisierung. Das ist langsamer als ein Text-PDF — aber es funktioniert. Vorher gar nicht.

Was das bedeutet, wenn du ein Regal voller Scans hast

Wenn du eingescannte Bücher hortest — alte Nachdrucke, vergriffene Romane, gemeinfreie Digitalisate von archive.org, deine eigenen Scans von Omas Rezeptbuch — sie sind nicht mehr auf Papier gefangen. Lad sie hoch. Wir übernehmen die OCR.

Aktuell führen wir OCR in 12 Sprachen aus: Englisch, Spanisch, Portugiesisch, Französisch, Deutsch, Polnisch, Italienisch, Türkisch, Arabisch, Japanisch, Koreanisch, Hindi. Das Hörbuch selbst lässt sich in jeder der 23 Stimmsprachen erzeugen. Falls dein gescanntes Buch in einer Sprache vorliegt, die wir noch nicht per OCR unterstützen, schreib uns kurz — ein tesseract-Sprachpaket hinzuzufügen, dauert ein paar Minuten.

Eine Anmerkung zur kommerziellen Lizenzierung

Der gesamte OCR-Stack, den wir verwenden — tesseract, pypdfium2, pytesseract — steht unter Apache 2.0. Das ist wichtig, wenn du etwas Ähnliches baust: PyMuPDF ist in Python die naheliegende Wahl für PDF-Rendering, aber seine AGPL-Lizenz zwingt dich, dein gesamtes SaaS quelloffen zu machen, wenn du es produktiv einsetzt. pypdfium2 + tesseract bieten dir die gleichen Fähigkeiten ohne rechtlichen Kater.

Der Bug, der uns besser gemacht hat

Die meisten Produktionsbugs werden in Tests gefangen. Dieser nicht, weil die Annahme — "PDFs enthalten Text" — für jede Entwicklerdatei galt, die wir je benutzt hatten. Es brauchte eine echte Leserin aus Chile, in ihrer ersten Stunde auf der Plattform, um ihn ans Licht zu bringen.

Also danke, echte Leser. Ihr findet die Bugs, die wir nicht finden können.