1. Cookies optimieren die Bereitstellung unserer Dienste. Mit der Nutzung unserer Dienste erklärst Du dich damit einverstanden, dass wir Cookies verwenden. Weitere Informationen
    Information ausblenden
  2. Willkommen im Forum von DIGITAL FERNSEHEN - dem führenden Portal für digitales Fernsehen, Medien und Entertainment. Wenn du hier neu bist, schau dich ruhig etwas um und melde dich an, um am Forengeschehen teilnehmen zu können.
    Information ausblenden

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

Dieses Thema im Forum "DF-Newsfeed" wurde erstellt von DF-Newsteam, 1. März 2018.

  1. DF-Newsteam

    DF-Newsteam Lexikon

    Registriert seit:
    25. Januar 2007
    Beiträge:
    96.287
    Zustimmungen:
    695
    Punkte für Erfolge:
    73
    Anzeige
    Im Sommer soll es Anpassungen bei der Programmbelegung im Digitalradio des Bayerischen Rundfunks geben. Die frei werdenden Kapazitäten sollen dem Fehlerschutz dienen und nicht, wie zuerst auch hier spekuliert wurde, für einen neuen Kanal genutzt werden.

    Startseite | Weiterlesen...
     
  2. Radiowaves

    Radiowaves Silber Member

    Registriert seit:
    23. Oktober 2013
    Beiträge:
    695
    Zustimmungen:
    452
    Punkte für Erfolge:
    73
    Schade. Ich hatte auf annehmbare Bitrate für Bayern 2 gehofft - 144 kbps LC-AAC wären angemessen für dieses Programm.
     
  3. Terranus

    Terranus ErdFuSt

    Registriert seit:
    8. Mai 2002
    Beiträge:
    31.542
    Zustimmungen:
    7.373
    Punkte für Erfolge:
    273
    Qualitätssichernd kann sich auch auf die Tonqualität beziehen. Zudem sind die erwähnten Programme allesamt solche, die umziehen werden.
     
    Winterkönig gefällt das.
  4. Eheimz

    Eheimz Foren-Gott

    Registriert seit:
    2. Januar 2010
    Beiträge:
    12.772
    Zustimmungen:
    331
    Punkte für Erfolge:
    93
    Technisches Equipment:
    TS HD8-S
    Dreambox 500 HD
    Dreambox 7020HD V2;
    180cm Mabo 57°O-45°W
    Inverto Red Twin Flansch
    Sind überhaupt AAC LC mit 144kbit/s und EEP3-A möglich ohne den Bug mancher Geräte zu treffen ?
     
  5. KlausAmSee

    KlausAmSee Talk-König

    Registriert seit:
    8. Oktober 2004
    Beiträge:
    6.025
    Zustimmungen:
    2.372
    Punkte für Erfolge:
    163
    Die Bugs in manchen Geräten sollten kein Hinderungsgrund dafür sein, normkonform in besserer Qualität zu senden.
     
  6. Martyn

    Martyn Foren-Gott

    Registriert seit:
    7. Juni 2005
    Beiträge:
    13.636
    Zustimmungen:
    4.140
    Punkte für Erfolge:
    213
    Technisches Equipment:
    DVB-S: 5° W / 9° E / 13° E / 19.2° E via Wavefrontier T55
    DVB-T: Hoher Bogen, Ochsenkopf, Cerchov und Plzen-Krasov
    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.
     
  7. Andalus

    Andalus Senior Member

    Registriert seit:
    25. März 2002
    Beiträge:
    351
    Zustimmungen:
    15
    Punkte für Erfolge:
    28
    Klar, so sendet ja BR-Klassik bereits, da gibt es keine Probleme.
     
  8. TV_WW

    TV_WW Institution

    Registriert seit:
    10. Juli 2004
    Beiträge:
    16.585
    Zustimmungen:
    1.299
    Punkte für Erfolge:
    163
    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.
     
    Zuletzt bearbeitet: 5. März 2018
  9. Radiowaves

    Radiowaves Silber Member

    Registriert seit:
    23. Oktober 2013
    Beiträge:
    695
    Zustimmungen:
    452
    Punkte für Erfolge:
    73
    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.
     
    Medienmogul gefällt das.
  10. KlausAmSee

    KlausAmSee Talk-König

    Registriert seit:
    8. Oktober 2004
    Beiträge:
    6.025
    Zustimmungen:
    2.372
    Punkte für Erfolge:
    163
    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.
     

Diese Seite empfehlen