Auf unserem Streaming Server läuft mAirList Professional 6.2.8 für den 24h-Betrieb. Hin und wieder taucht im Log eine Meldung wie z.B.
Warnung Fehler beim Puffern von "Living a Lie ": unsupported file format (BASS error 41)
auf und natürlich wird dieser Song dann auch nicht gespielt, was manchmal zu dem sehr unschönen Folgeproblem führt, dass die Playlist leer läuft.
Seltsamerweise (oder auch nicht) kann ich den Song in meiner lokalen Home Studio Version (ebenfalls 6.2.8) über mAirListDB anstandslos in die Playlist ziehen und abspielen.
Mit einer physischen Kopie der mp3-Datei hat mein lokales mAirList auch klein Problem, die Server-Version allerdings schon.
Irgendeine Idee, woran das liegt?
Die gleiche Aufstellung haben wir auch drum häng ich mich dem Thema mal an.
Was mir als erstes einfallen würde, ist die Konfiguration der Server mAirlist zu sichern und in eine lokale mAirlist Pro mit Testlizenz zu laden.
Dabei werden zwar bestimmte dinge nicht funktionieren wie Datenbank oder Audio geräte (die auf dem Server ja nicht existieren) aber zum Testen kann man ja schnell ein Standart Audio Gerät einstellen. Dann die Datei ins Playout laden und schauen ob sie läuft.
Andere Fragen.
Welches Dateiformat verwendet ihr allgemein und speziell mit diesem Lied?
Das würde schlichtweg bedeuten er kennt das Dateiformat nicht auf dem server. Warum kann es dann aber die lokale mAirlist version?
Tritt dieser Fehler nur mit dieser einen Datei auf oder bei mehreren?
Inwiefern unterscheidet sich dieser Song denn von den anderen im Datenbestand? Anderer Codec, für den ihr auf dem Server vielleicht nicht die passende BASS-Bibliothek geladen habt?
Schau doch mal die beiden Konfigs vergleichend an, unter…
Konfiguration > Audio-Einstellungen > Allgemein > Info
Könnte es daran liegen?
Das wüsste ich auch gern! Es gibt ein paar Songs, bei denen das bisher aufgetreten ist, allesamt mp3-Dateien, von denen wir ein paar zehntausend haben.
Aber in der Tat unterscheiden sich die Audio-Einstellungen ein wenig. Auf dem Server ist zusätzlich noch ein Plugin für mpeg-4 installiert, da wir auch einige hundert von der sorte haben.
Obwohl ich mir kaum vorstellen kann, dass das die Ursache ist, werde ich das Plugin auch mal lokal installieren.
Liegt defnitiv am Codec. Und damit an der verwendeten Windows-Version.
Einige Formate (MP3, WAV, Ogg) hat BASS direkt mit eingebaut.
Für andere Formate (z.B. AAC) braucht BASS einen externen Codec. Wenn nicht gerade das passende BASS-Plugin installiert ist, versucht BASS die im Windows-System vorhandenen DirectShow-Decoder zu benutzen. Und das kann eben je nach System variieren.
Also erstmal genau schauen, um was für ein Dateiformat es sich handelt. Und davon ausgehen dann, um auf Nummer sicher zu gehen und von den Windows-Codecs unabhängig zu sein, das passende BASS-Addon installieren.
Es ist mp3 (MPEG 1 Layer III)
Wie ich schon schrieb, sind die meisten Songs von der Sorte. Mit den übrigen Songs des gleichen Albums gibt es keine Probleme.
Wie ich schon vermutet habe, hat die Installation des mpeg-4 Plugins sich nicht ausgewirkt.
05 Living a Lie.mp3 hochgeladen
Danke für die Datei. Mal sehen, was Torben dazu sagt.
Das ist das, was mich so wundert.
Hast du diesen Titel entweder beim Taggen oder in der Bibliothek extra geändert, also etwas angepasst, was mit dem Tag zu tun haben könnte? Also eine Änderung, die nicht alle Titel des Albums betrifft, sondern nur diesen einen?
Ich habe da so eine ganz unscharfe Idee, muss dem aber noch tiefer nachgehen und mich mit Torben absprechen.
Aus dem mAirList-Forschungslabor: Würdest du bitte noch eine andere Datei dieses Albums (die also ebenso gerippt und getaggt wurde), die jedoch einwandfrei abspielbar ist, hochladen?
Torben folgt einer Spur, aber wir müssen das mit einer “normalen” Datei abgleichen.
Vielen Dank. 
sync mit Torben
Hex-Editor sagt: Da sind 64kB Nullbytes am Anfang der Datei. Warum nur der eine MP3-Decoder darüber stolpert und der andere nicht, kann ich nicht sagen.
Vermutung: BASS selbst erkennt sie nicht als korrekte MP3-Datei und übergibt sie Windows zur weiteren Prüfung. Und auf den beiden Windows-Systemen sind unterschiedliche MP3-Decoder vorhanden, von denen der eine sie erkennt und der andere nicht.
04 Valley of Sin.mp3 hochgeladen.
Die Audio-Einstellungen sind auf beiden Systemen jetzt gleich:
OS auf dem Server ist WIN Server 2012 R2, bei mir lokal WIN 10 Pro Version 1909
Danke. Gerade auf meiner Windows-10-VM die beiden Dateien verglichen und im Debugger den Channel-Type überprüft, den BASS meldet:
- 04 Valley of Sin.mp3: BASS_CTYPE_STREAM_MP3
- 05 Living a Lie.mp3: BASS_CTYPE_STREAM_MF
Erklärung der Werte siehe hier: http://www.un4seen.com/doc/#bass/BASS_CHANNELINFO.html
Meine Vermutung ist also korrekt, dass BASS die Datei von sich aus nicht als MP3-Datei erkennt (vermutlich aufgrund der vielen Nullbytes am Anfang) und versucht sie mit Hilfe von Windows (korrekterweise Media Foundation, nicht wie oben geschrieben DirectShow, das war einmal) zu öffnen.
Das “Media Foundation”-Framework ist Bestandteil von Windows und enthält u.a. Decoder für diverse Dateiformate, die z.B. vom Windows Media Player genutzt werden. BASS ist in der Lage, diese mitzuverwenden für Dateiformat, die BASS selbst nicht dekodieren kann.
Und wie es aussieht, ist der MP3-Codec von Windows 10 in der Lage diese Datei zu erkennen und abzuspielen, der ältere in Windows Server 2012 offenbar noch nicht.
Woher die Nullbytes am Anfang kommen, kann ich dir nicht sagen. @UliNobbe vermutet einen Zusammenhang mit dem APE-Tag. Aber aus der Spekulation halte ich mich raus 
Ok, besten Dank. Die Erklärung leuchtet ein, zumal auf dem Server kein Audiogerät installiert ist. Glücklicherweise sind das nur wenige Einzelfälle, die fliegen dann raus aus der Datenbank oder werden durch neuere Versionen ersetzt.
Genau da setze ich mit der Analyse an (und verfolge das alleine weiter, weil es nicht mehr in Torbens Bereich fällt):
Wenn beide Dateien gemeinsam gerippt wurden, müssten sie ja anfangs auch identisch gewesen sein. Aber irgendwas muss geschehen sein, das die eine Datei (05) so korrumpiert hat und die andere (04) nicht. Ich tippe immer noch auf einenen nachträglichen Tag-Edit, der schiefgelaufen ist.
Mach dir nicht zu viel Mühe. 2016 sind die damaligen Musikdateien auf einen anderen Server umgezogen. Was davor war, wird sich kaum rekonstruieren lassen.
Eine Sache ist mir allerdings aufgefallen. Beim Import in die mAirList Datenbank hat der Titel ein paar zusätzliche Leer- oder sonstwie unsichtbare Zeichen bekommen, die man der Datei mit z.B. mp3tag nicht ansieht.
Stimmt, mp3tag ist unauffällig.
Ich importiere die beiden Dateien nachher nal in meine Datenbank und schaue mir das mal an.
Um ehrlich zu sein, ich halte ID3v(x) APEv2 immer noch für … auffällig, kann es aber (noch?) nicht so richtig begründen. An irgendeiner Stelle knallt es.
Hast du vielleicht diese Datei(en) mal in der mAirListDB bearbeitet und danach “Import in ID3-Tag” benutzt? Ist nur so ein Verdacht, ins Blaue geschossen…
Nein, ich vermute auch niemand anders, denn das Änderungsdatum auf dem Server ist aus 2016, das war der Serverumzug. mAirList haben wir erst seit Anfang 2019.
Bei “Living a Lie” liest er gar keine Metadaten aus, da BASS die Datei ja schon gar nicht als MP3 erkennt und folgerichtig auch nicht nach ID3- oder APE-Tags sucht.
Bezüglich der Leerzeichen gibt es eine Einstellung bei den Datei-Import-Optionen, ob diese abgeschnitten werden sollen.
(Wobei dies, zugegebenermaßen, bei ID3v1 aufgrund der festen Datenstruktur immer erfolgen sollte, unabhängig von der Einstellung - ich ändere das mal.)
Ist auf dem Server die Desktop Experiance installiert? Wenn nicht, dann hat die BASS.DLL gar keinen mp3 decoder in Windows, an den sie das übergebn könnte und die Wiedergabe schlägt vielleicht deshalb fehl.
1 Like