RICHTIGSTELLUNG BR schafft DAB-Plus-Kapazitäten zum Fehlerschutz

Schade. Ich hatte auf annehmbare Bitrate für Bayern 2 gehofft - 144 kbps LC-AAC wären angemessen für dieses Programm.

 

Qualitätssichernd kann sich auch auf die Tonqualität beziehen. Zudem sind die erwähnten Programme allesamt solche, die umziehen werden.

 

Sind überhaupt AAC LC mit 144kbit/s und EEP3-A möglich ohne den Bug mancher Geräte zu treffen ?

 

Die Bugs in manchen Geräten sollten kein Hinderungsgrund dafür sein, normkonform in besserer Qualität zu senden.

 

Das wäre aber doch arg übertrieben.

Finde 128 KBit/s für BR Klassik, 96 KBit/s für die meisten anderen Sender und 64 KBit/s für B5 aktuell sollten reichen.

 

Klar, so sendet ja BR-Klassik bereits, da gibt es keine Probleme.

 

Für die reinen Audiodaten, ja, aber es werden ja noch bis zu 16 kbit/s an Zusatzdaten (pro Hörfunkprogramm) übertragen u. diese werden bei den Datenraten ebenfalls mit dazu gezählt.

Weshalb sollten die Anbieter so senden dass die Fehler welche in einigen Empfanggeräten stecken keine Auswirkungen zeigen?
Nö. Der Kunde muss sich darum kümmern ein normgerechtes Gerät zu erhalten. Ein Gerät welches nicht 100% der Norm entspricht hat einen Produktmangel, und der Kunde hat ein Recht auf ein mangelfreies Produkt.

 

Der Bug auf den Du Dich beziehst ist offenbar der, dass zahlreiche Geräte nicht mit Services umgehen können, die mehr als 144 CU bei DAB+benutzen. Im EEP 3-A gehören zu 144 CU 192 kBit/s - also weit oberhalb dessen, was verwendet wird. 144 kBit/s ergeben im EEP 3-A 108 CU. Das sollten alle Geräte schaffen.

Problematisch kann es werden, wenn man regionale Netze aufbaut und versucht, bei viel Kapazität dank weniger regionaler Services an Sendeleistung oder Senderstandorten zu sparen, indem man den Fehlerschutz erhöht. Im EEP 2-A gehören 144 CU zu 144 kBit/s - da liegt eine realistische Grenze. Im EEP 1-A gehören 144 CU zu 96 kBit/s, da hat man ein echtes schmerzhaftes Limit. Oberhalb 144 CU geht bei vielen Empfängern nichts mehr: sie hängen sich auf, bleiben stumm oder geben alle paar Sekunden mal einen "Rülpser" ab.

Das ist dem DAB-Versuch in Bretzenheim passiert. Die hatten einen der Services testweise mit 128 kBit/s in EEP 1-A laufen. Sind 192 CU. Und prompt stiegen die Radios aus. Man ging dann auf 144 CU (entsprechend 96 kBit/s im EEP 1-A) zurück.

Die Mindestanforderungen an Empfangsgeräte stehen hier: WorldDAB Receiver Profiles | WorldDAB

"Decoding of a minimum of 144 Capacity Units (e.g. 256 kbps@EEP3B, 192 kbps@EEP3A, 96kbps@EEP1A) is mandatory for sub-channels containing DAB+ services."

Und für das alte DAB in MPEG 1 Layer 2:

"Decoding of a minimum of one sub-channel is mandatory. Decoding of a minimum of 280 Capacity Units (e.g. 256 kbps@UEP1) is mandatory for sub-channels containing DAB audio services."

Und dennoch gab es Geräte, die bei 256 kBit/s bereits ausgestiegen sind, wohl auch bei schwächerem Fehlerschutz.

Gerade der BR ist da ein gebranntes Kind. Als man dort komplett auf DAB+ umstellte, hatte ihnen das IRT allen Ernstes 96 kBiT/s LC-AAC empfohlen. Das ergibt nach Reed-Solomon eine netto-Bitrate von 86,4 kBit/s, abzüglich 8 kBit/s Slideshow bleiben dann halt nur noch ca. 78 kBit/s netto-Audio übrig. Das ist für LC-AAC zu wenig, zumindest bei DAB, wo der Codec noch das Korsett der Superframes vorgesetzt bekommt. Schon mit normkonformen Empfängern sind die Höhen weg ab ca. 13-14 kHz. Die Geräte mit "LC-Bug" produzierten grauenhaften Matsch. Nach 24 Stunden hatte der BR genug Beschwerden zusammen, um alle 96er von LC-AAC auf HE-AAC umzustellen. Grauenvolle Flanging-Effekte sind das (Kopfhörer aufsetzen!), hier drei Hörbeispiele: LC-AAC-Bug BR.zip - im Vergleich hört man dann auch noch super, wie HE-AAC zwar diesen Flanging-Effekt nicht mehr hat, dafür aber dieses kratzige, "schabende" Geräusch auftritt.

Auch der hr hat diese Probleme - sogar noch bei 120 kBit/s LC-AAC brutto: LC-AAC-Bug hr.zip - beim hr gibt man sich aber "unbeugsam" und ändert ganz bewusst nicht auf HE-AAC. Die Hörer mit den verbuggten Geräten (u.a. Kenwood-Autoradios älterer Generation) haben dann das Nachsehen.

Wäre selbst bei 128 kBit/s (brutto; netto-Daten sind dann 115,8 kBit/s, abzüglich Slideshow und FPAD sind es ca. 107 kBit/s netto-Audio) zu wenig. Das würde nicht mal annähernd die Qualität von 192 kBit/s MPEG 1 Layer 2 erreichen, die mal als DAB-Standard galten. 144 ist schon ok, hätte man sparsamere Slideshow, könnte man ggf. auch auf 136 kBit/s gehen. Wie 96 kBit/s HE-AAC inkl. Slideshow klingen, kannst Du ja oben im BR-Beispiel nachhören: kratzig-schabend.

Wenn es doch nur so einfach wäre. Die meisten Kunden wissen ja nicht einmal, dass der Matsch, den sie da hören, ein Bug ist - sie schieben es dann eher DAB allgemein in die Schuhe. Da kursiert auch noch die Story, es wären an Chipsatzhersteller (NXP und Gyrosignal werden da genannt) fehlerhafte Referenzcodecs rausgegangen, die dann in Hardware implementiert wurden. Das soll sogar mal im Fraunhofer-Blog gestanden haben - doch dazu findet man nichts im Netz. Auf Anfrage hieß es mir gegenüber seitens Fraunhofer IIS sinngemäß: dieser Vorgang wäre nicht bekannt und man habe auch nichts fehlerhaftes außer Haus gegeben. Für die Antwort ließ man sich Zeit, da sie im Hause abgestimmt werden müsse. Prof. Brandenburg, einst am IIS auch mit Codec-Entwicklungen befasst, antwortete mir gleich gar nicht, nach dem "bitte gedulden"-Bescheid des Sekretariats kam nie wieder etwas. Ich habe darauf verzichtet, weiter zu recherchieren und denke mir meinen Teil.

 

Angenommen, da wäre ein fehlerhafter Code übermittelt worden, dann wären aber auch die Erstmuster schlampig getestet worden. Vor der Serienfertigung eines Chips wird nämlich immer erst mindestens ein Testshuttle gefertigt.