Wenn es korrekt ist, warum kann EMC damit nicht umgehen?
Darum geht es doch.
Wenn es korrekt ist, warum kann EMC damit nicht umgehen?
Darum geht es doch.
Nein darum geht es nicht du verdrehst hier alles, ich sagte doch schon dass andere .eit kaputt sind und daher versucht EMC über chardet die korrekte Codepage zu finden. Bei dem besagten .eit von alpha erkennt er einfach etwas falsches (das ist nicht die Regel).
Ich hatte den Eindruck, dass es noch Zweifel gibt, wo die "Fehlinterpretation" der Charsets passiert und wollte nur Richtung .eit helfen.
Um kaputte andere eits geht es doch hier schon lange nicht mehr
@juanito_perez
Okay danke, also mir war das bereits klar. Mir ist auch klar warum es bei alpha kaputt geht. Nur hab ich halt aktuell keine sinnvolle Lösung die immer funktioniert. Ich kann das nach EN300468 decodieren ändert aber nix an der Tatsache dass EMC dann bei anderen .eit was kaputtes ausgibt (weil die halt fehlerhaft sind, warum auch immer, ich weiß nicht wo die herkommen die Files).
Zum "ü":
Das Problem ist klar, zum Verständnis muss man aber was über eits wissen:
Die Descriptoren in EITs dürften max 255 Bytes lang sein. Da im Extended Descriptor längere Texte gespeichert werden können, müssen diese in Blöcke aufgeteilt werden.
Beim Dekodieren muss entsprechend der Text wieder zusammengefügt werden.
Das Problem in diesem speziellen Fall ist, dass das "ü" kodiert aus zwei Bytes besteht und das erste Byte noch zu einem Block gehört, das zweite Byte aber schon im nächsten Block gespeichert ist.
Konvertiert man den Text blockweise, dann geht das "ü" baden.
Man muss also erstmal alle Blöcke einlesen, alle Texte zusammenfügen und darf dann erst die Konvertierung machen.
Hier der relevante Part aus der .eit:
byte 344: 0x53 : 83 / S /01010011
byte 345: 0x63 : 99 / c /01100011
byte 346: 0x68 : 104 / h /01101000
byte 347: 0x6F : 111 / o /01101111
byte 348: 0x63 : 99 / c /01100011
byte 349: 0x6B : 107 / k /01101011
byte 350: 0x20 : 32 / /00100000
byte 351: 0x66 : 102 / f /01100110
byte 352: 0xC3 : 195 / Ç /11000011
--- hier endet ein Block, das 0xC3 gehört aber eigentlich zum "ü"
--- hier fängt der nächste Block an
byte 353: 0x4E : 78 / N /01001110
byte 354: 0xFF : 255 / ˜ /11111111
byte 355: 0x12 : 18 / /00010010
byte 356: 0x65 : 101 / e /01100101
byte 357: 0x6E : 110 / n /01101110
byte 358: 0x67 : 103 / g /01100111
byte 359: 0x00 : 0 /
byte 360: 0xF9 : 249 / — /11111001
byte 361: 0x15 : 21 / /00010101
--- hier geht's im Text weiter...
byte 362: 0xBC : 188 / ¬ /10111100
byte 363: 0x72 : 114 / r /01110010
Alles anzeigen
mit edEit oder mit EITitor die .eit bearbeiten hilft meist
ich verwende noch immer EITitor weil man damit auch die .ts.meta gleichzeitig bearbeiten kann
Ich würde sagen, dass das Problem - wie eben beschrieben - daran liegt, dass die einzelnen Descriptoren dekodiert werden, anstatt erst den gesamten Text aus den Blöcken zusammenzufügen und erst dann zu dekodieren.
Im Ergebnis kommt es immer zu Fehlern, wenn ein Sonderzeichen über zwei "Descriptoren" verteilt ist.
Wer jetzt aber "falsch" dekodiert (EMC, E2) vermag ich nicht zu sagen.
Ja, aber wer will denn zu einer Aufnahme ständig die eit bearbeiten?
Danke für die Info zu der Sache mit den Blöcken.
ich verwende noch immer EITitor weil man damit auch die .ts.meta gleichzeitig bearbeiten kann
Ist hier OT, aber edEIT kann schon seit einer gefühlten Ewigkeiten auch .ts.metas bearbeiten und sogar automatisiert mit den eit-Infos synchronisieren.
Mach' mal ein Update
PS: Soll kein Bashing sein, bitte nicht missverstehen. Ich kann aber nur davor warnen aktuelle EITs mit den alten Editoren zu bearbeiten. Die Wahrscheinlichkeit, dass sie dadurch kaputt gehen, ist sehr groß.
danke @juanito_perez.
dann ist das ein bug im emc.
@dhwz: koennte das die ursache sein, warum das chardet manchmal nicht funktioniert?
mit edEit oder mit EITitor die .eit bearbeiten hilft meist
Klar, ein einfaches, zusätzliches Leerzeichen kann schon helfen, weil dann das Sonderzeichen komplett auf den nächsten Descriptor verschoben wird.
Ob das aber die Lösung ist?
Das mit dem „ü“ hatte ich ja heute auch mit der Abendschau auf BR HD.
In der EPG-Info war es noch korrekt.
Aber in der EMC-Info-Taste auch fehlerhaft.
Beim GP MoviePlayer hat die Info dagegen funktioniert.
Vielleicht finden wir ja noch die Ursache.
Nur um Missverständnissen vorzubeugen.
In meinen Beiträgen oben war Block = Descriptor.
Es müssen also erst alle EED-Descriptors eigelesen werden, der gesamte Text zusammengefügt werden und erst dann darf die Charset-Konvertierung erfolgen.
@'Sevn H'
Dass es wiederholt ein "ü" betrifft, dürfte reiner Zufall sein. Kommt halt einfach häufig vor
Häng' mal die .eit hier rein und ich schaue sie mir gerne an. Vermutlich ist es aber das gleiche Problem.
Es müssen also erst alle EED-Descriptors eigelesen werden, der gesamte Text zusammengefügt werden und erst dann darf die Charset-Konvertierung erfolgen.
Ja, das passiert auch erst ganz am Schluss.