arte subtitle extraction funktioniert seit 4.8.2015 nicht mehr

[Cypheros]

Vielleicht weiß er das ja selber nicht, wenn er gar nicht AUTOR dieser Teletextroutine ist

Doch ist er 

was passiert bei Parity Errors wirklich, werden die X.26 Substitutions ausgewertet

Bei mehr als 2 Fehlern wird die Zeile weggelassen. X26/X27/X28/M29 werden ausgewerten soweit benötigt (Sonderzeichen, Umlaute, Code-Tabellen, etc.).

Wer kann und will DVB-Subtitles in sein Entwicklungspaket aufnehmen und macht das überhaupt Sinn?

Fast fertig und kommt noch dieses Jahr. Die Bitmaps werden per OCR in SRT-Untertitel gewandelt, mit Farbinformationen (für Mam) 
Erste Betas werden in Kürze an ausgewählte Beta-Tester verteilt.

[Derrick]

..dann noch würden mich diese Fehler und die entsprechenden Zeilen interessieren. Der Fehlerschutz ist ja schließlich nicht für den digitalen Empfang über DVB gedacht, sondern erst später, wenn analoge Strecken hinzu kommen. Insofern verstehe ich die Relevanz für den TSD noch immer nicht

[Mam]

Hmm, ich bin immer noch am Grübeln, ob wegschmeissen, oder nicht...

Sein Beispiel:

Code Auswählen Erweitern

10
00:00:52,220 --> 00:00:54,480
Elle a connu des vicissitudes,
h       ures medicales. TURQ    23h55


Zeigt ja eigentlich, dass die angemeckerte Zeile so gar nichts mit dem Film zu tun hat, also nicht nur ein Zeichen verkehrt ist (oder zwei), sondern völlig aus der Luft gegriffen (dazu muß man dann aber schon die ganze Datei durchlesen und ein wenig französich verstehen) ist.
Also wäre Löschen der Zeile durchaus korrekt...

@PePo: wie bist Du eigentlich an die gelöschten Zeilen rangekommen, wo der Doc sie doch gar nicht abspeichert? ? ?

[Mam]

Der Fehlerschutz ist ja schließlich nicht für den digitalen Empfang über DVB gedacht, sondern erst später, wenn analoge Strecken hinzu kommen. Insofern verstehe ich die Relevanz für den TSD noch immer nicht

Aber er ist nun mal da und verändert natürlich den Text. Also muß der Doc ihn zumindest rausrechnen, sonst steht da nur Matsche. Parity kann nur Ein-Bitfehler erkennen und liefert keinerlei Reparaturinfos, ist also quick but very dirty.

[Cypheros]

..dann noch würden mich diese Fehler und die entsprechenden Zeilen interessieren. Der Fehlerschutz ist ja schließlich nicht für den digitalen Empfang über DVB gedacht, sondern erst später, wenn analoge Strecken hinzu kommen. Insofern verstehe ich die Relevanz für den TSD noch immer nicht

Code Auswählen Erweitern

  for i := StartByte to Packet^.DataUnitLen - 1 do
  begin
    LTextByte   := Packet^.Data[i] and 127;  //Remove parity bit

    if (EBU_ParityTable[LTextByte] = Packet^.Data[i] shr 7) then
      Inc(ParityErrors);

    if LTextByte < 8 then
      LMocaicsMode := False;
    ...


Ich weiss nicht ob Dir der Codeabschnitt was nützt, aber die meisten Sender codieren das Parity-Bit schon korrekt. Vermutlich wird der gleiche Teletext-Encoder verwendet, wie zu analogen Zeiten.

Unter Einstellungen/Optionen/Teletext kannst Du die Paritätsprüfung abschalten.

[PePo]

@PePo: wie bist Du eigentlich an die gelöschten Zeilen rangekommen, wo der Doc sie doch gar nicht abspeichert? ? ?/quote]

Lieber Mam!

Ich dachte ja eigentlich, dass mein Summary diese Forum Diskussion abschliesst, aber ich sehe, dass sie Diskussion weiter geht!

Die "gelöschten Zeilen" waren in meinem .srt File einfach VORHANDEN und nicht gelöscht. Viel interessanter ist, dass der zweite dekodierte -srt stream fast eine genaue Replica der Fehler enthält. Bitte schau Dir die beiden noch mal an (siehe einige Beiträge vorher!).

Ich bin da noch auf eine zweite wilde Vermutung gestossen. ARTE verwendet für das Erstellen der Untertitel verschiedene Firmen. Da gibt es z.B. eine Firma, die im Elsass beheimatet ist. Diese Untertitel sind praktisch immer perfekt und völlig fehlerfrei.
Dann gibt es andere Firmen, bei denen die Untertitel eine Katastrophe sind.

Könnte es sein, dass die "Untertitelfirmen" einen fertigen File liefern, der nur mehr in den Stream eingeklinkt werden muss und dann flugs zum Satelliten geht? Nicht, dass ARTE dann aus dem Schneider wäre, es soll ja sowas wie Qualitätskontrolle geben ....

Ich hab versucht, ob es irgendwo bei ARTE einen technical support gibt, mit dem man vernünftig reden kann, aber einfach NICHTS gefunden!

An den "Scheffe": Der Codeabschnitt ist ein wenig kurz; wie wir der TTX stream extrahiert? Ich kann C, C++, Java, Python, objective C  etc. ganz passabel lesen, nur mit den Functional Languages tue ich mich noch ein wenig hart.

[PePo]

Fast fertig und kommt noch dieses Jahr. Die Bitmaps werden per OCR in SRT-Untertitel gewandelt, mit Farbinformationen (für Mam) 
Erste Betas werden in Kürze an ausgewählte Beta-Tester verteilt./quote]

Kann ich an Diesen beta Test teilnehmen und/oder was sind die Voraussetzungen?

[Cypheros]

Der Codeabschnitt ist ein wenig kurz; wie wir der TTX stream extrahiert? Ich kann C, C++, Java, Python, objective C  etc. ganz passabel lesen, nur mit den Functional Languages tue ich mich noch ein wenig hart.

Programmiersprache ist Pascal (Delphi), ne Mischung aus C++ und Java. Der DVBViewer ist übrigens mit Delphi programmiert.
Die ganze Unit zur Teletext-Dekodierung ist etwa 1500 Zeilen lang und beinhaltet nur die Extraktion des Texts und der Farbe, also keine Grafik-Dekodierung oder sowas. Werde ich hier aber nicht vollständig posten. Du findest entsprechenden Sourcecode zur Teletextdekodierung bei ProjectX (Java) oder anderen Opensource-Tools.

Kann ich an Diesen beta Test teilnehmen und/oder was sind die Voraussetzungen?

Ist noch in Planung aber gute Kenntnisse des TS-Doctors, von Windows und gängigen Multimedia-Formaten werden vorausgesetzt. Ich werde zuerst die alteingessenen Experten hier ansprechen wie Mam, Djfe, ErichV, Derrick usw. ob die Lust darauf haben. Werde im Forum nachfragen, wenn dann noch Leute gebraucht werden.

[Mam]

Lieber Mam!
Ich dachte ja eigentlich, dass mein Summary diese Forum Diskussion abschliesst, aber ich sehe, dass sie Diskussion weiter geht!

Träum weiter   
Wenn wir einmal Blut geleckt haben, gibt es kein Halten mehr 

Dann gibt es andere Firmen, bei denen die Untertitel eine Katastrophe sind.
Könnte es sein, dass die "Untertitelfirmen" einen fertigen File liefern, der nur mehr in den Stream eingeklinkt werden muss und dann flugs zum Satelliten geht?

Nee nee, die Ursache dafür ist viel trivialer, eigentlich hat die Firma mit den viele Fehlern die "besseren" Untertiteln.
Das Problem liegt nun mal in der Parität begründet, die klaut zwangsläufig ein Bit aus dem Byte für den Buchstaben. Damit bleiben nur noch 7 Bit übrig, und die reichen nun mal nur für US-ASCII, oder, wenn man auf ein paar Steuerzeichen verzichtet, noch gerade so für deutsche Umlaute, aber auf keinen Fall für alle Variationen der Akzente in der französischen Sprache.  Und so muß man sich entscheiden, ob man es lieber "falsch" schreibt (z.B. "'a" statt "á") oder riskiert das 8te Bit trotzdem zu benutzen, in der Hoffnung, dass der Dekoder es mitmacht und ein à ausgibt, statt einem Paritätsfehler. Das ist zwar dreist, aber "legal", da ja keine Norm existiert, die es verbieten würde.
Wir sind hier also im Grenzbereich, wo Elektronik aufhört und Glauben anfängt 

Ich hab versucht, ob es irgendwo bei ARTE einen technical support gibt, mit dem man vernünftig reden kann, aber einfach NICHTS gefunden!

Kein Wunder, ARTE ist nur ein halber Sender. Für die Technik wirst Du wohl im Sendezentrum der ARD nachfragen müssen.

An den "Scheffe": Der Codeabschnitt ist ein wenig kurz; wie wir der TTX stream extrahiert? Ich kann C, C++, Java, Python, objective C  etc. ganz passabel lesen, nur mit den Functional Languages tue ich mich noch ein wenig hart.

dann ist ja gut, das Pascal/Delphi eine prozenduale Sprache ist. Funktionen sind hier eigentlich die Ausnahme :-)))
Der Ausschnitt hat doch die komplette Analyse des Textes gezeigt, allerdings wurden erkannte Fehler nur hochgezählt, es fehlte der "was passiert dann..." Teil. Aber egal, grundsätzlich Bit 7 löschen, den Rest als Index in eine vorher gespeicherte Tabelle (die nur 0 und 1 Einträge enthält) nehmen und den Tabellenwert mit dem um 7 Bit nach Rechts geshifteten (also eigentlich nur das isolierte Bit 7) Wert vergleichen.

Ist nur etwas umständlich verklausuliert, vor allen, wenn man bedenkt, dass der X86 Prozessor selbstständig Parity Tests durchführen kann. Die Schleife kann man also auch so schreiben:

Code Auswählen Erweitern

for i := StartByte to Packet^.DataUnitLen - 1 do
  begin
  __asm {
            mov ax,Packet^.Data[i]
            jpe ParityOk
            inc ParityErrors
:ParityOk
            }
  end


Geht viel schneller und ganz ohne Shifterei und Boolsche Algebra. Aber das ist nichts für Müslifresser  (ich weis auch nicht, ob Delphi überhaupt direkte Assemblerbefehle mit einbauen kann)

[PePo]

Ja danke für den Assembler code, ich glaub, ich hab den Delphi Code schon verstanden.

Bleibt mir also nichts übrig, als TTX Decoder in der Open Source Domain zu finden und zu durchforsten. Da werd' ich hoffentlich bei ProjectX fündig werden, obwohl ja dieses Programm schon lange im Limbo steckt und offensichtlich auch nicht mehr gewartet oder erweitert wird, wenn man sich die Timestamps anschaut. Aber auch in obsoleten Programmen lauern noch manchmal Schätze.

Die Anspielung mit den Müslifressern hab ich nicht ganz verstanden, bitte um Erläuterung!

Und weiss jemand, wo man bei ARD einen kompetenten Ansprechpartner in der Technik findet?

[Djfe]

Die Anspielung mit den Müslifressern hab ich nicht ganz verstanden, bitte um Erläuterung!

"Schwächling" bzw. auch unbeholfene Jugend und technisch Unversierte
weil die Leute von heute nix mehr mit Assembler anzufangen wissen

ist nicht ganz ernstgemeint, aber du hast Mams Humor ja sicherlich schon vorher bemerkt

wegen ProjectX auch wenn ichs nie benutzt hab, ist alles was ich davon hier gehört hab nur gutes
wurde halt eingestellt, wegen H.264 und den Lizenzen

wieso eigentlich wo es x264 gibt und dieses für Open-Source Software kostenlos nutzbar ist? oder hatte der Entwickler keine Zeit/Lust das umzusetzen/den neuen Code dafür zu schreiben?

[Mam]

Die Anspielung mit den Müslifressern hab ich nicht ganz verstanden, bitte um Erläuterung!

Wie so oft, irrt Dfje hier, allerdings gilt für ihn die Gnade der späten Geburt. Er ist einfach zu jung, um die Story zu kennen 

So 1983 rum gab es ein Buch "echte Männer essen kein Müsli" (Heyne Taschenbuch 6290), aus dem ein intelligenter Mensch in den Staaten den Text "real programmers don't use PASCAL" (hier die offizielle deutsche Übersetzung) abgeleitet hat.
Grundsätzlich werden Programmierer darin in "echte Männer" (die, die Sprachen mit Speicherarithmetik verwenden) und "Müslifresser" eingeteilt. Letztere verwenden Programmiersprachen, die es nicht erlauben, Speicher direkt zu addressieren und manipulieren.

Letztendlich geht es aber um die Frage, wie groß die Abstraktionsebene zur Maschine sein darf, damit der Programmierer noch seine Arbeit als geistiges Eigentum betrachten kann. Erlaubt man ihm nicht mehr, bestimmte Fehler zu machen, dann produziert das erstmal "bessere", da stabilere, Programme. Langfristig erzeugt es aber "dumme" Programmierer, die sich auf diese Dinge verlassen und darauf angewiesen sind. Nimmt man ihnen diese schützende Hülle ("Shell" / "Framework") sind sie nicht mehr in der Lage, sich die Schuhe zuzubinden.
Das erzeugt eine Mehrklassengesellschaft, die wir heute schon faktisch haben. Mikrosoft z.B. versucht mit jeder neuen Compilerversion die Programmierer weiter wegzulocken von der Maschine. Zugriff auf "alte" Funktionen wird immer weiter eingeschränkt (siehe aktuell den Thread "wie finde ich die richtige Windowsversion in Windows 10 raus?"). Dabei benötigt man diese aber, um das System selber zu erstellen oder zu erweitern. Ganz bewußt wird hier der Masse die Chance gegeben, etwas wirklich Neues für Windows zu entwickeln. Somit wird ein externer Programmierer begrenzt auf harmlose Klicke-Die-Klick Programme, äääh "Apps". Eine App erfordert etwa Kindergartenniveau, echte Programmierer laecheln gnädig, wenn es um Apps geht: KINDERKRAM!
Und als Mac Benutzer gehts Dir nicht besser, im Gegenteil, bei Apple hatte Steve Jobs diese Idee von Anfang an zur Firmendoktrin erhoben, Apple hat keine Kunden und Entwickler, sonder nur melkende Kühe und gnädige Schafe...


Und da Delphi ein direkter Nachfolger von PASCAL ist, kann es nur von Müslifressern bedient werden. Wenn auch zugegebenermassen die Erbauer in Delphi versucht haben, genau die Teile nachzurüsten, die ein echter Programmierer braucht. Aber kaum jemand ist auf das Lockangebot reingefallen und so fristet die Sprache ein Nieschendasein und wird mittelfristig vom Aussterben bedroht sein. Irgendwann muß dann mal jedes Delphi Programm umgehoben werden in eine richtige Programmiersprache 

Der Begriff "Müslifresser" entspringt also nicht meinem kranken Hirn 

[Djfe]

So 1983 rum gab es ein Buch "echte Männer essen kein Müsli" (Heyne Taschenbuch 6290), aus dem ein intelligenter Mensch in den Staaten den Text "real programmers don't use PASCAL"

ach stimmt hattest du schonmal irgendwo erwähnt hab ich aber wieder vergessen

die Jugend von heute würde dazu sagen: "Von Salat schrumpft der Bizeps" (Abstumpfung durch die falschen Werte xD)
https://www.youtube.com/watch?v=5BPdbUTD4oM

[PePo]

Wie ich schon einmal sagte, bin ich nicht religiös, was Maschinenarchitekturen, Betriebssysteme und Sprachumgebungen betrifft. Da die Diskussion um TTX jetzt wieder mal heftig in einer semantischen Kurve schleudert, möchte ich doch - wenn auch mit gebotener Vorsicht - zum Bremsmanöver beitragen.

1. zu Mac's empfehle ich 2 Bücher:
Walter Isaacson, Steve Jobs, Simon & Schuster, 2011, ISBN 978-1-4516-4853-9
und dort die Kapitel 7 "Crisann and Lisa: He Who is abandoned" und Kapitel 18 "NeXT: Prometheus unbound"
Jonathan Levin,  OS® X and iOS Internals, TO THE APPLE'S CORE, John Wiley & Sons, 2013, ISBN 978-1-11805765-0

Ich sollt' da noch hinzufügen, dass praktisch alle Leute, die damals im Stanford University EE-CS Department und/oder in HP Labs arbeiteten, mindestens zwei NeXT am Arbeitsplatz oder in der Garage zuhause stehen hatten (so wie auch ich).

2. den Originalartikel, der frei von Übersetzungsfehlern ist: "Real Programmers Don't Use PASCAL", eine wirklich eine köstliche Persiflage als Anhang

3. Das in der damaligen Computerwelt berühmteste Gedicht/Essay über einen fiktiven Hacker "Mel", die Version in freier Versform siehe Anhang.

4. Und Delphi war sicher auf dem richtigen Weg, wenn man die ersten 1995 Kommentare liest wie etwa:
Delphi, the new oject-oriented rapid application tool released by Borland in early 1995. Andrews discusses two of Delphi's major selling points: its completely object-orientedVisual Component Library (VCL) and its ability to generate tight, executable files at record speeds. Works with either 16- or 32-bit programs.

God bless You all!

[Mam]

>Ich sollt' da noch hinzufügen, dass praktisch alle Leute, die damals im Stanford University EE-CS Department und/oder in HP Labs arbeiteten, >mindestens zwei NeXT am Arbeitsplatz oder in der Garage zuhause stehen hatten (so wie auch ich).

Na ja, ich hatte auch ne Lisa, war wirklich ein tolles Gerät bis der Mac kam. Der war.... #*´@"! (na gut, lassen wir das.. meine Freunde wissen allerdings dass ich damals bewiesen habe, Macs können auch fliegen! sogar durch geschlossene Fenster des 2ten Stocks, leider war die Landung unten auf dem harten Beton des Hofes nicht sehr elegant und mein Werkstattleiter kam nach dem Knall nur aus seinem Kabuff, sah die Misere und rief über den Hof rauf zu mir "Scheff! Komm nicht auf den Gedanken, ich könnte die Kiste wieder flicken! Aber ich ruf schon mal nen Glaser, damit die Fenster repariert werden...")
Ich fühlte mich damals von diese Obstfirma dermassen ver@#+!, mir ist fürderhin kein Gerät von denen untergekommen und alle Angestellten erhielten striktes Appleverbot.
(ich bin irgendwann doch noch mal schwach geworden, und hab mir son Newton gekauft, aber wir wissen ja, wie der endete. Muss hier noch in irgendeiner Ecke liegen... oder als Bücherstütze? oder zumindest als abschreckendes Beispiel).