Problème sur l'EPG de France 3 Alpes

[pa.babao]

Oui, il faut qu'ils commencent leurs champs texte avec un code visant la bonne ISO 8859 s'ils utilisent des accentuations qui ne sont pas dans la table par défaut. Le 0x05 n'est peut-être pas le plus adapté mais c'est celui qui avait été mis en oeuvre pour corriger le Ô de France Ô (en fait il existe dans d'autres tables) et qui est a priori supporté par les tv depuis un bail.
Au début de chaque champ texte de l'EPG il devrait donc y avoir ce code "invisible" pour dire au récepteur "attention, affiche avec la table de caractères correspondante".

L'EN 300 468 décrit les EIT (5.2.4 de la v1.3.1 98, la première trouvée et prise au pif, je reconnais) et précise les descripteurs qu'on peut utiliser, parmi ceux-ci (6) en ici notamment les short_event_descriptor (qui contient le résumé court et potentiellement d'autres infos), qu'on retrouve décrit en 6.2.27 et extended_event_descriptor (qui contient le résumé long et potentiellement d'autres infos) en 6.2.9 qui précisent un code ISO_639_language_code qui n'a rien à voir avec la restitution du texte (mais qui permet d'identifier le résumé comme écrit en langue "française" ou autre, mais pas d'indication relative à la table de caractères à utiliser) et surtout pour la boucle texte qu'elle doit être codée comme précisée en annexe A (c'est un labyrinthe les normes) relative au codage des caractères textuels (on y est!).

Pour reprendre France Ô, le codage par défaut de D4 (le Ô) était normalement "™", en utilisant 0x01 en début de champ on obtiendrait un caractère cyrillique ou grec (j'atteins mes limites), 0x02 un caractère arabe, 0x03 un tau grec en capitale (?), 0x04 rien de spécial (ça doit être fun à tester sur un terminal) et 0x05 le fameux Ô.
Il y a des façons complémentaires (dans l'annexe aussi) de signaler une table de caractères et il y a de plus récentes version de la 300 468 qui intègrent des tables complémentaires (dont la 8859-15 je crois), donc ce n'est peut-être pas l'utilisation spécifique de ce simple "caractère invisible" qui est en cause ici mais ça y ressemble quand même. Le copyright n'est pas placé au même endroit entre la table 00 et les tables 03 à 05. Je trouve juste bizarre que vous voyez deux caractères faux (A+copyright) au lieu d'un.
Si y'a moyen de récupérer un bout d'enregistrement, ça peut se "voir" relativement facilement (pas tant que ça en fait, je viens de regarder un vieil enregistrement xD enfin, on voit bien la présence du caractère invisible dans le champ texte) avec tsr ou au pire un éditeur hexadécimal (mais faut se taper toute la structure des tables pour arriver jusqu'au descripteur, c'est plus simple si vous avez un interpréteur de paquets pour vous éviter cette partie.

[Franck Morin]

Il y a des façons complémentaires (dans l'annexe aussi) de signaler une table de caractères et il y a de plus récentes version de la 300 468 qui intègrent des tables complémentaires (dont la 8859-15 je crois), donc ce n'est peut-être pas l'utilisation spécifique de ce simple "caractère invisible" qui est en cause ici mais ça y ressemble quand même. Le copyright n'est pas placé au même endroit entre la table 00 et les tables 03 à 05. Je trouve juste bizarre que vous voyez deux caractères faux (A+copyright) au lieu d'un.

j'ai le même probleme en DAB+ avec l'affichage des caractères spéciaux (ç, é, à, ï etc) dans ma C3, ils sont tous remplacés par deux caractères hétéroclites avec des & ou @.
cela ne vient pas de la diffusion car je n'ai aucun soucis avec mes autres appareils DAB+ ni les logiciels QIRX ou DABplayer. C'est probablement l'autoradio qui interprète mal la table de caractères imposée par la diffusion.

Après pour le cas de julien, si le problème n'existe qu'à certains moments de la journée et que sur certains appareils, il y a peut-être un mixe d'erreurs qui se cumulent entre son récepteur et la diffusion.

[pa.babao]

Je n'ai plus trop suivi le DAB+ depuis qu'on a lâché le DMB mais en effet, ça peut venir du contenu émis et du codage ou du terminal utilisés (et parfois des deux). Le fait que ce soit remplacé par deux caractères au lieu d'un me paraît bizarre (il n'y a de code envoyé et malinterprété que pour un caractère) mais c'est probablement parce que je n'ai pas suffisamment d'expertise sur le sujet pour le comprendre.
Ca ne serait pas outre-mesure surprenant que les tables de caractères soient les mêmes (y'a pas mal de proximités entre les systèmes de broadcast, souvent parce qu'on y retrouvait les mêmes experts et c'est issus des travaux ISO de toute manière), il faudrait regarder de plus près la norme DAB+. En DVB, les termes accentués en français sont surtout sur la colonne E des tables précitées et on retrouve des signes bizarres dans la table par défaut (si le code invisible ou plus généralement la table à utiliser sont ignorés en faveur du codage par défaut). Ce qui explique peut-être une restitution sur deux caractères qui ressemblent plus ou moins au caractère bizarre à restituer.


Dans le cas de Julien si ce n'est que sur une chaîne, ça vient à 99% de la chaîne. Contrairement au DAB+ la TNT est en France en mode cible et pépère depuis 2016 (ça va resecouer un peu avec l'UHD mais sur des nouveaux services), normalement ça marche et c'est stable.

Dans le cas historique de France Ô on avait certains récepteurs qui même après le correctif avec le caractère en 0x05 continuaient de ne pas afficher le Ô, parce qu'ils n'avaient pas bien implémenté la norme.