Könntest Du bitte nochmal Deine Messgeräte bemühen, ob alles umgesetzt wurde.
Hehe, "die Messgeräte". Es ist da, wo ich gerade bin, ein als WISI gelabelter HDTV-Twin-Sat-Receiver von LaSAT/Bemondis aus Rötz und Neunburg vorm Wald (also Made in Bavaria), gefertigt Ende 2009, gekauft 2021 (bzw. das aktuell installierte Gerät gekauft 2022 nach inzwischen aber auch behobenem Schaltnetzteil-Defekt des zuerst gekauften Gerätes) in den Kleinanzeigen. Der erste 15 EUR plus Versand, der zweite ich glaube 45 EUR plus Versand. Dazu ein 16-GByte-USB-Stick ausm Rossmann (fürs Radio reichts), im receiverspezifischen LaFAT-Format formatiert. Dazu dann noch ein via Composite-Video angeschlossener Mini-TFT für die Menüs, denn ich besitze keinen Fernseher.
Aktuell läuft Software V.0260A auf dem Gerät, damit ich auch die SDT mit aufgezeichnet bekomme. Danach gehe ich sofort wieder zurück auf V.0241A für schlanke Aufnahmen (kein Mitschnitt von SDT, EIT usw.) oder vielleicht auf Software V.0290A, die auch LC-AAC 5.1 wenigstens verwertbar in Stereo ausgibt (kein Downmix, nur Front L/R des 5.1 auf Stereo). Das ist aber nur bei WDR 3 und MDR Kultur hin und wieder stundenweise nötig.
Bei ADTS (bis Ende 2021 bei Radio Regenbogen) hängen sich diese Geräte gnadenlos auf. Mit LC-AAC LATM-verpackt stereo können alle 3 genannten Softwares umgehen, und zwar bestmöglich, extrem nah am FFmpeg und offenbar ohne Dynamikmanipulation mittels DRC. Kenne bislang keine besser LC-AAC decodierende Receiverfamilie und würde gern mal mit dem Output eines Qbit oder 2wcom vergleichen. HE-AAC können sie aber nicht (da kommt schwerer Murks raus).
Auswertung mit
https://mediaarea.net/de/MediaInfo
für den AAC-Typ
und
DVB Inspector, a open source java tool for analyzing DVB streams
www.digitalekabeltelevisie.nl
für den Einblick in die Tabellen und das Timing (PCR, PTS). Beides ist Freeware.
Hier steht also wirklich nichts teures in Benutzung, sondern teils Zeugs, das andere loswerden wollten.
Na dann wollen wir mal. 3 frische Mitschnitte von heute ca. 18 Uhr.
Alle 3 Programme sind natürlich weiterhin in LATM verpackt und
nicht wie im UKWTV-Forum orakelt in ADTS. Wer sich auch nur ein kleinwenig mit den ARD-Programmen beschäftigt hat oder wenigstens einmal einen TS-Mitschnitt in ein entsprechendes
Infotool gesteckt hat, weiß das.
Alle 3 Programme haben weiterhin ca. 125 ms Abstand PCR-PTS. Das sollte voraussichtlich auf allen Geräten im Timing stabil laufen, auf denen auch die ARD-Programme von BR, NDR und Radio Bremen stabil laufen ohne zu knacken oder ständig hektisch an der Ausspielgeschwindigkeit zu drehen. Möglicherweise bestand das bei der ARD zugrunde liegende Problem bei ABy dank Q561 auch überhaupt nicht, so dass auch mit nur 65 ms Differenz bereits alles stabil war.
SDT
Descriptor: service_descriptor: 0x48 (72)
+-descriptor_tag: 0x48 (72) => service_descriptor
+-descriptor_length: 0x1E (30)
+-descriptor_data: 0x020B426574614469676974616C1086414E54454E4E45872042415945524E "..BetaDigital..ANTENNE. BAYERN"
+-service_type: 0x2 (2) => digital radio sound service
+-service_provider_name_encoding: default (ISO 6937, latin)
+-service_provider_name_length: 0xB (11)
+-service_provider_name: BetaDigital
+-service_name_encoding: default (ISO 6937, latin)
+-service_name_length: 0x10 (16)
+-service_name: ANTENNE BAYERN
Descriptor: service_descriptor: 0x48 (72)
+-descriptor_tag: 0x48 (72) => service_descriptor
+-descriptor_length: 0x1C (28)
+-descriptor_data: 0x020B426574614469676974616C0E86524F434B20414E5487454E4E45 "..BetaDigital..ROCK ANT.ENNE"
+-service_type: 0x2 (2) => digital radio sound service
+-service_provider_name_encoding: default (ISO 6937, latin)
+-service_provider_name_length: 0xB (11)
+-service_provider_name: BetaDigital
+-service_name_encoding: default (ISO 6937, latin)
+-service_name_length: 0xE (14)
+-service_name: ROCK ANTENNE
Descriptor: service_descriptor: 0x48 (72)
+-descriptor_tag: 0x48 (72) => service_descriptor
+-descriptor_length: 0x1B (27)
+-descriptor_data: 0x020B426574614469676974616C0D4F4C44494520414E54454E4E45 "..BetaDigital.OLDIE ANTENNE"
+-service_type: 0x2 (2) => digital radio sound service
+-service_provider_name_encoding: default (ISO 6937, latin)
+-service_provider_name_length: 0xB (11)
+-service_provider_name: BetaDigital
+-service_name_encoding: default (ISO 6937, latin)
+-service_name_length: 0xD (13)
+-service_name: OLDIE ANTENNE
In der SDT wird immer noch service_type 0x2 signalisiert, das ist der "digital radio sound service", der auch bei MPEG 1 Layer II genommen wird, gegen den aber offenbar auch bei AAC nichts spricht. Es gibt für AAC und andere "advanced codecs" zwar den service_type 0xA ("advanced codec digital radio sound service"), den auch die ARD nimmt, aber offenbar ist es nicht nötig, diesen Typ zu signalisieren. Klare Regeln für die Verwendung kenne ich nicht, außer der, dass für MPEG 1 Layer II 0x2 genommen werden soll:
(
https://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.18.01_60/en_300468v011801p.pdf)
Möglicherweise ist dieser service_type 0x2 daran schuld, dass die Kompaktkopfstelle Astro QAM-Box weiterhin MPEG-Radio anzeigt (aber dennoch das LC-AAC ordentlich decodiert):
Gerade noch mal geschaut und zwar in der QAM Box werden ABy immernoch als MPEG Radio deklariert!?
Könnte diese Stelle sein. Wenn man statt
service_type: 0x2 (2) => digital radio sound service
auf
service_type: 0xA (10) => advanced codec digital radio sound service
umstellt, könnte (!) eventuell die QAM-Box auch richtig anzeigen. Ist aber, da ansonsten keine Fehlfunktion vorzuliegen scheint, wohl nur ein kosmetischer Fehler.
Mir fällt aber jetzt in der SDT noch etwas auf, das wir noch gar nicht angeschaut hatten, das aber vielleicht eine Jahre alte Skurrilität klären könnte.
@Tomtulpe , schau Dir mal die descriptor_data an:
0001 0203 0405 0607 0809 0A0B 0C0D 0E0F 0123456789ABCDEF
0x000000 020B 4265 7461 4469 6769 7461 6C10 8641 ..BetaDigital..A
0x000010 4E54 454E 4E45 8720 4241 5945 524E NTENNE. BAYERN
0001 0203 0405 0607 0809 0A0B 0C0D 0E0F 0123456789ABCDEF
0x000000 020B 4265 7461 4469 6769 7461 6C0E 8652 ..BetaDigital..R
0x000010 4F43 4B20 414E 5487 454E 4E45 OCK ANT.ENNE
und im Vergleich die neue
0001 0203 0405 0607 0809 0A0B 0C0D 0E0F 0123456789ABCDEF
0x000000 020B 4265 7461 4469 6769 7461 6C0D 4F4C ..BetaDigital.OL
0x000010 4449 4520 414E 5445 4E4E 45 DIE ANTENNE
Was sind das für Sonderzeichen bei ANTENNE BAYERN und ROCK ANTENNE mitten im Namen und auch davor? Das ist mir vorhin in MediaInfo aufgefallen:
Die neu aufgeschaltete OLDIE ANTENNE hat diesen Murks nicht. Angezeigt werden diese skurrilen Zeichen an den mir bekannten Geräten nicht, mit einer prominenten Ausnahme:
TechniSat Cablestar 100 (und vielleicht auch Cablestar 400, ich weiß es nicht). Die Cablestar 100 zeigten schon seit Jahren (zu MP2-Zeiten) in den Kabelnetzen mit 1:1-Übernahme an:
Jetzt weiß ich endlich, warum. TechniSat hat dazu sogar was in den FAQ - auch seit Jahren (!):
(
https://www.technisat.com/de_DE/Akt...fe/352-515/?article=0000/3915&productID=22893)
Möglicherweise haben wir hier die Antwort. Die werten beim Cablestar 100 nicht den service_name aus, sondern die descriptor_data. Dazu könnte man sich nochmal mit TechniSat kurzschließen, Kontakt könnte ich evtl. vermitteln.
Da die Motorhaube ohnehin schonmal geöffnet ist, könnte man das vielleicht auch bei BetaDigital gleich mit gerade ziehen. Ich weiß aber nicht, ob man dabei in Kabelnetzen bei 1:1-Übernahme irgendwas anrichten kann (z.B. dass man aus Pass-Filtern rausfliegt und manuell wieder eingepflegt werden muss, die DVB-Welt ist voller Überraschungen).
Neben " NTENNE BAYERN" und " OCK ANT NNE" sind auch Sunshine Live (" unshine live") und Klassik Radio (" lassik Radio") betroffen bei BetaDigital. Hier TSID 0x7 inkl. Sunshine Live in der Anzeige des VLC:
Skurril, dass offenbar nur das DVB-Kabelradio Cablestar 100 von TechniSat mit diesen Zeichen Mist baut. Aber wieso gehören diese Zeichen da transportstromseitig überhaupt rein?
So, den Rest mache ich in einem Folgepost, es wird sonst mit den Anhängen zu unübersichtlich.
