Ich höre Stay Forever in Music Assistant (weil es das Audio via Sendspin in meine ganze Wohnung verteilt, ganz ohne proprietäre Protokolle). Die bisherigen Episoden waren dort schon immer „dodgy“, wenn es ums Seeken/Skippen/Pause+Play ging – aber es hat mit mehreren Versuchen immer gut genug geklappt.
Die neue Episode „Die Welt von Tomb Raider“ hingegen funktioniert gar nicht mehr. Sobald ich irgendeine Operation vornehme, und sei es nur kurz Pause+Play, startet die Episode von vorne. Seeken und Chapter anspringen geht auch nicht. Ich hab das als Issue bei Music Assistant aufgemacht:
Der verlinkte Kommentar einer der Hauptentwickler (und dessen AI) ist vielleicht für euch interessant:
Variable Bit Rate tracks with Xing/VBRI TOC (each time slice could be a different amount of bytes of data, with no map on what is how big) which means ffmpeg’s mp3 decoder can’t convert time into a byte offset (location) so it has to go frame by frame from the start to get to the desired time. This is a bit of an unfortunate intersection of "Things that are awkw
An der Stelle bricht sein Kommentar leider ab, aber die wichtigsten Infos scheinen drin zu sein.
Würde es helfen, wenn ich auf den offenen Feed auf eurer neuen Platform umstelle? (Wobei es gar keinen offiziellen offenen Feed auf der neuen Platform gibt – das verlinkte RSS ist noch auf Podigee. Man muss sich das im Feed-Mixer selbst zusammenbauen.)
Ich hab mal eine Unterstützer-Episode von eurer neuen Platform ausprobiert. Dort scheint zumindest das Seeken zu funktionieren, weil das MP3 eine fixe Bitrate (128 kbps) zu verwenden scheint. Aber Chapter anspringen funktioniert ebenfalls nicht.
Wir kodieren immer in CBR. Auch die Tomb Raider-Folge von Podigee scheint konstant zu sein. Kommt mir nicht so vor, als das von dem Entwickler die korrekte Diagnose.
Frag ihn mal: "Thanks. The podcaster say the episode was encoded as CBR, not VBR. Could you tell us which exact FFmpeg output or file property makes Music Assistant classify it as VBR? Is FFmpeg detecting a Xing rather than an Info header, a missing/invalid TOC, or a mismatch between the Xing file-size field and the actual HTTP content length? A CBR stream should normally permit time-to-byte estimation without a VBR TOC. We can provide the direct MP3 URL and an older working episode for comparison.
Gibt eine Reihe von Ursachen dafür, die in der Tendenz eher nicht bei uns liegen. Da das ja alles in Podcast-Apps funktioniert, können wir nicht allzu viel Zeit in die Recherche eines Einzelfalls stecken, fürchte ich. Es gibt allerdings eine kleine Wahrscheinlichkeit, dass Podigee da irgendeinen Quatsch macht, den normale Podcast-Apps, die auf die extrem robusten Player von Android / iOS aufsetzen, irgendwie kompensieren. Das würde ich schon gern wissen
Allerdings ist da ja ein zweiter Stream embedded, nämlich der mit den Grafiken/Kapiteln. Macht das das Seeken dann nicht ebenfalls problematisch, so dass die Aussage in dem Ticket trotzdem nicht ganz falsch ist?
Zunächst mal aus dem Feed. Aber mit der URL, die ich gerade gepostet habe, hab ich’s auch mal direkt im Firefox probiert und der spielt das MP3 vorbildlich ab, inkl. seeken, preloaden und cachen. Nur der Stream mit den Grafiken/Kapiteln fehlt halt komplett.
Das ist ja auch ein Podcaststream und FF ist kein Podcastplayer.
Es ist cool zu hören auf welchen Setups und Systemen ihr uns hört, aber wir können nicht für jedes exotische Setup Verantwortung übernehmen oder Support leisten. Wir liefern einen Podcast-Feed, der ein bisschen an die Grenzen geht, weil wir stark auf Kapitelbilder und -Marken setzen. Die einzigen von uns empfohlene Tools zu Nutzung sind Podcast-Apps auf mobilen Geräten. Mit Abstrichen auch auf Desktop, aber das ist schon problematischer.
Ich verstehe nicht? Im Ticket geht es um VBR und dass das Parsen damit schwierig ist, wenn ein Inhaltsverzeichnis fehlt. Aber weder ist das MP3 in VBR, noch fehlt der TOC. Oder checke ich da was nicht?
Die Bilder und Metadaten sind nicht Teil des Streams und auch kein eigener Stream per se. Diese Informationen stehen am Anfang der MP3 und dürften daher auch nichts an der Bytefolge des eigentlichen Audios ändern.
Naja im Ticket geht es einerseits um die falsche Einschätzung, dass das MP3 VBR sei ( was dort inzwischen bestätigt wurde – es ist CBR). Und andererseits um das reale Problem, das ich habe. Du hast vielleicht gesehen, dass Chris sich das nochmal anschauen will.
Ich gehe im Moment davon aus, dass es da einiges auf Seite von Music Assistant zu fixen gibt. Denn so richtig rund läuft dort derzeit kein Podcast, sobald man ne kurze Hörpause einlegt. Wenn am Schluss noch irgendwas übrig bleibt, was vielleicht auf eurer Seite verbesserbar wäre, dann melde ich mich nochmal.
Übrigens am Rande, Music Assistant könnte für euch eine Lösung sein, eure neue Platform mit den proprietären Multi-Room-Systemen der User zusammenzubringen. Bislang empfehlt ihr diesen ja noch, auf Patreon/Steady/YouTube zu bleiben. Mit Music Assistant kann man beliebige Audio-Quellen (auch proprietäre/kommerzielle) auf beliebigen Audio-Senken (auch proprietäre) ausgeben.
Ich hab mir diesen Motion-JPEG-Stream noch nicht näher angeguckt, aber ich wäre davon ausgegangen, dass immer wenn ein neues Kapitelbild kommt dieses dann zwischen den Daten des MP3-Streams eingebettet ist weil die Streams parallel laufen. Das würde bedeuten, dass man ähnlich wie bei VBR-MP3 nicht mehr simpel Zeitmarke mit Bitrate multiplizieren kann (plus Offset), um zur gewünschten Zeit zu springen.
Also wie gesagt, der Ball liegt derzeit bei Music Assistant und ich verfolge das dort weiter.
Ich bin da überhaupt nicht im Thema, hab mein Sonos vor Jahren abgeschafft, weil mir das zu unflexibel war und Apple/Google kommen mir nicht ins Haus. Aber grundsätzlich kann man die Systeme doch wie andere Lautsprecher auch aus den Podcast-Apps ansteuern, Airplay und so? Oder zählt das nicht?
Nein, das stimmt nicht. Der von ffprobe angezeigte zweite Stream ist kein parallel zum Audio laufender Motion-JPEG-Stream, sondern das eingebettete Episodencover. Steht da auch:
Entscheidend auch die Kennzeichnung (attached pic). FFmpeg bildet ein JPEG-Cover intern als Videostream mit einem einzelnen Bild ab.
So funktioniert die Technologie nicht. In der MP3 liegen die Bilder als APIC-Block im ID3-Tag am Dateianfang und werden über Metadaten aufgerufen, die liegen nicht zeitlich verteilt zwischen den MP3-Audioframes. Das Cover verursacht also höchstens einen einmaligen Offset vor dem Audio, den ein MP3-Demuxer normalerweise berücksichtigt. Es macht eine CBR-Datei auch nicht VBR-ähnlich. Auch die angezeigte Zeitbasis von 90 kHz bedeutet nicht, dass dort ein fortlaufender Videostream oder 90.000 Bilder pro Sekunde enthalten sind.
Sorry, das ist die ganz falsche Richtung
Andere Apps haben mit der Folge ja offenbar keine Probleme. Daher liegt es wahrscheinlich an der speziellen Art, wie Music Assistant, FFmpeg und Sendspin hier zusammenspielen, möglicherweise in Verbindung mit der ungewöhnlich langen beziehungsweise großen Audiodatei.
Zur Sicherheit noch einmal: Hast du ausprobiert, die MP3 zunächst vollständig herunterzuladen und dann als lokale Datei in Music Assistant abzuspielen, also nicht über den Podcast-Feed beziehungsweise die HTTP-URL? Damit ließe sich prüfen, ob das Problem mit dem Streaming-Abruf zusammenhängt, etwa mit HTTP-Range-Requests oder der Art, wie Music Assistant und FFmpeg beim Streamen innerhalb der Datei springen.
Ich wollte euch ja nicht weiter auf damit auf die Nerven gehen, aber nachdem du nochmal konkret fragst:
Ich hab das MP3 in die lokale Musiksammlung abgelegt und MA angewiesen, es zu finden.
Damit kann ich’s wunderbar abspielen und wild darin herumspringen. Auch das Titelbild wird angezeigt. Aber Kapitel und -bilder gibt’s so natürlich nicht.
