Mp3, UTF-16 und der Umlaut?

Deutsch / German Allgemein
1

Einleitung

Ich selber hatte lange nicht mehr damit zu tun, aber bei der letzten Promo-Sendung sind uns zwei ärgerliche Umlaut-Fehler passiert.

  • Bruce Kapusta - Das einzige was zählt

  • Dirk Leandro - Wer weiÃ? wann wir uns wieder sehen

Mir ist sowas seit Ewigkeiten nicht mehr untergekommen, und jetzt muss ich das einer möglichen mAirList-Neukundin erklären. Zumal ja auch ich stellvertretend eine dieser Sendungen fahren werde (die Urlaubszeit steht bevor!).
Da ich selber fast gar nicht mehr mit mp3-Dateien arbeite, muss ich mich da erst wieder einfuchsen.

Analyse

Die Promo-Songs werden uns halt so angeliefert, und mittels Mp3tag habe ich folgendes herausgefunden:

  • ID3v2.3 UTF-16

In Mp3tag, in der mAirList-Datenbank und -Playlist wurden die Titel korrekt angezeigt.
Der Encoder steht auf UTF-8.

Eingrenzung

Der Server stellt alle anderen ihm angelieferten Umlaute korrekt dar, soweit ich das beurteilen kann (“Auto-DJ” und andere Livestreams).

Erst beim Hörer kommen diese Metadaten “verquer” an (Berichte von Hörern, eigene Beobachtung im externen Player sowie oben zitierten Mitschnitte aus dem Audio Logger-Cuesheet).

Forensuche

Sonderlich viel habe ich nicht gefunden, lediglich einen Hinweis aus v4.2, und da ging es auch eher um den Server sowie die Kodierung in Mp3tag. Ist ein paar Tage her.

Fragestellung(en)

Es fehlen uns aktuell Erfahrungswerte mit *mp3 und UTF-16 in der Außendarstellung.
Die Metadaten unserer Jingles (ebenfalls mp3, ID3v2.3, UTF-16) werden dank mAirList nicht mit ausgesendet, daher fehlt es an Vergleichsmöglichkeiten.

Könnte mAirList damit Probleme haben? Oder gibt es einen Fehler unsererseits?
Wenn ja, welche Einstellung wäre korrekt?

Lösungsansätze

  1. Alle Dateien vorab in Mp3tag auf ID3v2.4 UTF-8 umschreiben lassen.
    Nicht gerade im Sinne des Erfinders - oder etwa doch?

Alternative:

  1. Umschreibung in Mp3tag auf ID3v2.3 ISO-8859-1 und mAirList zugleich im Encoder auf “Automatisch” bei der Zeichenkodierung stellen.

Zusammenfassung

Durch die Zusammenarbeit mit Promo-Agenturen ist dieses Problem bei uns erst jetzt an die Oberfläche gekommen. Andere Anwender könnten damit schon mehr Erfahrung haben und hier zu einem Erfahrungsaustausch beitragen.

“Call to action”

Jede Hilfe ist willkommen.
Für mich privat ist es tatsächlich ein Rückfall in längst vergessene mp3-Zeiten.

Da hier aber sicher noch viele Anwender mit mp3-Dateien arbeiten und diese Probleme nicht zu haben scheinen, wäre es hilfreich, hier die sogenannte “Schwarmintelligenz” zu bemühen.

:question: Frage am Rande

Warum kann man in der Zeichenkodierung der Metadaten nur “UTF-8” oder “Latin1” sowie “Automatisch” auswählen?
Was wäre aus mAirList-Perspektive das modernste Zeichensatz-Angebot? Nicht UTF-16?

2

Ich hatte mal Probleme, dass die Kodierung im MP3 nicht richtig war.
Hast Du dies genau überprüft?
Die Metadaten werden z.B. an Icecast weitergereicht und da gibt es keine andere Alternative.
UTF-16 ist nun wirklich nicht besonders verbreitet.

3

Nein, noch nicht.
Auf was genau sollte ich da achten?

Ich habe mich bislang darauf verlassen, dass die Labels bzw. Agenturen das Material sauber anliefern. Und wie ich schon schrub™, weder Mp3tag noch mAirList zeigen Auffälligkeiten.

Korrekt, es ist ein Icecast im Spiel.

4

Im allgemeinen liefern die Labels und Agenturen das Material auch sauber aus. Aber ich denke, es sind immer mal wieder neue Personen im Spiel. :wink:
In diesem Fall steckt der Teufel im Detail. Vermutlich ist an einer Stelle UTF-16 nicht sauber in UTF-8 kodiert worden. Manche Software hat keine Probleme mit UTF-16 Zeichen in in UTF-8. Aber IceCast mag es nicht.
Ich arbeite bei IceCast auch nur mit UTF-8, was ja auch die Standardeinstellung ist. Mein Verdacht ist, dass IceCast kein sauber dekodiertes UTF-8 bekommt. Da wäre es herauszufinden an welcher Stelle es hakt!
Als erstes würde ich die ID3-Tags mal mit MP3Tag auslesen und gucken ob alles passt.
Dann in mAirList die Tags über Eigenschaften noch einmal neu einlesen und kontrollieren.
Ist in IceCast eine playlistlog definiert?
Dann schau mal nach, was darin steht.

Ich habe in icecast.xml auch noch stehen. Die spitzen Klammern fehlen.
mount type=“default”
charset>UTF-8</charset
/mount

Da deutsche Umlaute grundsätzlich mit IceCast richtig übertragen werden, ist vermutlich auf dem Wege vorher etwas faul.

5

Moin zusammen,
das Thema habe ich auch schon irgendwann einmal durchgekaut.

Probleme gab es da meines wissens nach nur beim Icecast bei Streams die nicht OGG sind. Die Ursache liegt darin, dass in einer Version der Default Wert den Icecast erwartet, von ISO-8859 auf UTF-8 geändert wurde. Dann hat man bemerkt dass viele alte Software damit ein Problem hat und der Default Wert wurde wieder zurück gedreht auf ISO-8859.

Wir hatten das seinerzeit hier mal aufgerollt.

Das bedeutet also nicht, dass Icecast kein UTF-8 kann. Das was ich hin schicke und das was ich im Icecast Server Mountpoint konfiguriert habe, was er erwarten soll, muss halt zusammen passen.

Ich habe den alten Faden nicht noch mal komplett gelesen aber wenn ich das noch richtig im Kopf habe, wird ausgehend immer auf UTF-8 übersetzt.

UTF-16 wüsste ich nicht ob Icecast das überhaupt verarbeiten kann, geschweige denn was mAirlist vorher macht. Ich nehme mal nicht an, dass der ID-Tag einfach 1:1 raus gehauen wird, sondern eben in das Zielformat übersetzt wird, was im mAirlist Encoder eingestellt ist.

1 Like
6

Vielen Dank, das hilft schon mal weiter. Ich teste das auf meinem “mAirList-Spielplatz” demnächst in Ruhe aus, welche Einstellung welche Umlaute wie verwurstet.

In der Zwischenzeit habe ich mittels Mp3tag die angelieferten Promos mal kategorisiert (wobei einige doppelt kommen, sowohl als mp3 als auch als wav).

Elemente gesamt: 409

  • ISO-8859-1: 41, davon…

    • ID3v2.2 (mp3): 4
    • ID3v2.3 (mp3): 19
    • RIFF ID3v2.3 (PCM): 17
    • RIFF ID3v2.3 (WAV): 1

  • UTF-16: 312, davon…

    • ID3v2.3 (mp3): 298
    • RIFF ID3v2.3 (PCM): 14

Die restlichen 56 Titel können nicht einwandfrei kategorisiert werden.

Ergo: Die Mehrheit der mir vorliegenden Promos sind also UTF-16er.

Unsere Encoder stehen nun wieder auf “Automatisch”.
Wenn ich Zeit habe, quäle ich mal unseren Teststream damit. Die Ergebnisse gibt’s dann hier.

Offengestanden, ich habe keine Lust, jedes neue Promo in ein neues Tag-Gewand zu stecken. Das sollte mAirList doch eigentlich aus dem ff wuppen, oder nicht?

@shorty.xs Bei euch gibt es doch auch Promos. Kämpft ihr mit ähnlichen Problemen oder welche Erfahrungswerte habt ihr?

EDIT:
Wer es in Mp3tag selber kontrollieren möchte: Die Felder (Panel oder Spalten) sind %_tag%, %_id3v2_character_encoding% und %_codec%.
Ganz interessante Zusatzinfo für Ursachensucher.

7

Ja, wir haben auch reichlich Promos und die werden vom Tag her alle bearbeitet oder zumindest gesichtet. Aber ich gehe mal ganz stark davon aus, dass über die art der Zeichenkodierung noch keiner der Kollegen überhaupt ansatzweise nachgedacht hat.

Wir hatten da bisher keine Fehlerhafte Anzeige.
Allerdings ist das für die Automation immer bereits in die Datenbank importiert, dann greift ja der Tag der Datei im mAirlist Playout gar nicht mehr, die Metadaten werden dann doch aus der DB Benutzt. Kann es sein, dass beim Import schon die Kodierung angepasst wird?
In der Automation läuft nichts was nicht in der Datenbank ist, bei mir im Studio eigentlich auch nicht. Nur das Backend ist bei mir zu Hause ein anderes.

Auf dem Server läuft PostgreSQL und zu Hause SQLite.