6 kleine mp3 Dateien mit <audio> hintereinander abspielen
1 0 
Felix Riesterer
6 kleine mp3 Dateien mit <audio> hintereinander abspielen
Der Martin
TS
Matthias ApselMit ffmpeg zu einer Datei zusammenfügen wäre eine gute Lösung. Aber der Provider unterstützt das nicht. Es muss bei jedem Aufruf neu gemacht werden, weil es tausende Kombinationen gibt. Kennt jemand eine eine Lösung? Danke für Hilfe. Walter
-
mp3's kannst Du einfach aneinanderhängen. MFG
-
Lieber pl,
mp3's kannst Du einfach aneinanderhängen.
ob das gut und sinnvoll ist, bleibt zu prüfen. Vorausgesetzt, alle MP3-Dateien haben eine identische Bitrate, dann kann man das machen, aber dann hat man wiederum redundante Header-Daten mitten in der Datei, die man im Idealfall vorher herausfiltern will.
Liebe Grüße
Felix Riesterer
-
Hallo Felix,
mp3's kannst Du einfach aneinanderhängen.
ob das gut und sinnvoll ist, bleibt zu prüfen. Vorausgesetzt, alle MP3-Dateien haben eine identische Bitrate, dann kann man das machen
das kann man auch bei unterschiedlicher Bitrate, weil die in mp3 in jedem einzelnen Chunk steht. Nur so ist bei mp3 auch VBR möglich.
Deswegen kann man tatsächlich mehrere mp3-Dateien jeweils mit readfile() nacheinander durchreichen. Beim Client kommt's an, als wäre es eine einzige.aber dann hat man wiederum redundante Header-Daten mitten in der Datei
Nein, mp3 hat keinen Header. Oder anders gesagt, jeder Chunk (entsprechend 10ms, IIRC) hat seinen eigenen Header.
Ciao,
Martin--
Sei n die Anzahl der bekannten Fehler in einer Software, dann gilt stets: n = n+1-
Lieber Martin,
aber dann hat man wiederum redundante Header-Daten mitten in der Datei
Nein, mp3 hat keinen Header. Oder anders gesagt, jeder Chunk (entsprechend 10ms, IIRC) hat seinen eigenen Header.
ich habe nachgesehen und festgestellt, dass ich mit "Header-Daten" diese ID3-Tags meinte.
Liebe Grüße
Felix Riesterer
-
Hallo Felix,
aber dann hat man wiederum redundante Header-Daten mitten in der Datei
Nein, mp3 hat keinen Header. Oder anders gesagt, jeder Chunk (entsprechend 10ms, IIRC) hat seinen eigenen Header.
ich habe nachgesehen und festgestellt, dass ich mit "Header-Daten" diese ID3-Tags meinte.
ah, verstehe. Ja, wenn ID3-Daten vorkommen, hat man die tatsächlich mehrfach und mittendrin. Das ist aber auch nicht weiter schlimm; dann ändert sich eben während des Abspielens die Anzeige des Titels im Player (wenn er ID3-Tags überhaupt auswertet). Auf das Parsen und Anspielen der Audio-Daten hat das aber keinen Einfluss.
Schönen Sonntag,
Martin--
Sei n die Anzahl der bekannten Fehler in einer Software, dann gilt stets: n = n+1-
Hello,
aber dann hat man wiederum redundante Header-Daten mitten in der Datei
Nein, mp3 hat keinen Header. Oder anders gesagt, jeder Chunk (entsprechend 10ms, IIRC) hat seinen eigenen Header.
ich habe nachgesehen und festgestellt, dass ich mit "Header-Daten" diese ID3-Tags meinte.
ah, verstehe. Ja, wenn ID3-Daten vorkommen, hat man die tatsächlich mehrfach und mittendrin. Das ist aber auch nicht weiter schlimm; dann ändert sich eben während des Abspielens die Anzeige des Titels im Player (wenn er ID3-Tags überhaupt auswertet). Auf das Parsen und Anspielen der Audio-Daten hat das aber keinen Einfluss.
"Mittendrin", also am Anfang jedes Blocks ("Frames"), stehen nur die MP3-spezifischen Metadaten, wie z.B. Bitrate, Version, Sampling Rate, ...
ID3-Tags stehen heutzutage am Amfang der Datei. Dadurch kann man sie auch leicht auslesen, ändern oder abschneiden.
PHP bietet dafür spezielle Funktionen an und im Web findet man auch komfortable Classes, die die Bearbeitung noch einfacher machen.
Glück Auf
Tom vom Berg--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.-
Hello,
und als Zusatzinfo noch der Link zu einem netten Gimmick:
Lyrics speichern in ID3-Tags.
Glück Auf
Tom vom Berg--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn. -
Hallo Tom,
ah, verstehe. Ja, wenn ID3-Daten vorkommen, hat man die tatsächlich mehrfach und mittendrin.
"Mittendrin", also am Anfang jedes Blocks ("Frames"), stehen nur die MP3-spezifischen Metadaten, wie z.B. Bitrate, Version, Sampling Rate, ...
ID3-Tags stehen heutzutage am Amfang der Datei. Dadurch kann man sie auch leicht auslesen, ändern oder abschneiden.
ja, schon klar - den Quellen zufolge, die ich auf die Schnelle gefunden habe, kann ein ID3-Datenblock je nach Version aber auch am Dateiende stehen.
Aber egal ob am Anfang oder am Ende: Wenn man mehrere mp3-Dateien mit ID3-Tags zusammenfügt, hat man auch ID3-Datenblöcke irgendwo mitten in der Datei. Und dann gilt:Das ist aber auch nicht weiter schlimm; dann ändert sich eben während des Abspielens die Anzeige des Titels im Player (wenn er ID3-Tags überhaupt auswertet). Auf das Parsen und Abspielen der Audio-Daten hat das aber keinen Einfluss.
Denn der mp3-Parser sucht, wenn er das Ende eines Frames erreicht hat, stur sequentiell nach der SYNC-Marke (die Sequenz 0xFF, 0xFx), die den Anfang des nächsten Frames markiert. ID3-Daten oder sogar irgendwelchen Schrott ignoriert er dabei (zumindest was das Abspielen der Audio-Daten angeht).
Und ja, in der Spezifikation für mp3 ist von Frames die Rede. Der Begriff Chunks, den ich vorgestern benutzt habe, stammt aus der Spezifikation für GIF.
Schönen Abend noch,
Martin--
"Hmm? Hast du was gesagt?" - "Nö. Das war gestern."-
Hello,
ID3-Tags stehen heutzutage am Amfang der Datei. Dadurch kann man sie auch leicht auslesen, ändern oder abschneiden.
ja, schon klar - den Quellen zufolge, die ich auf die Schnelle gefunden habe, kann ein ID3-Datenblock je nach Version aber auch am Dateiende stehen.
Darum schrieb ich heutzutage. Am Ende ist ungefähr solange her, wie Windows 98SE :-)
Vielleicht könnte das ja mal jemand ausprobieren, eine Datei künstlich mit mehreren ID3-Tags zu impfen, was dann da die Player anzeigen? Wechselt da z. B. die Titelanzeige mitten im Abspielvorgang? Ich hab gerade keinen Hexedotor griffbereit, um eine MP3-Datei an Framegrenzen zu zerlegen.
[2019-12-10]
Habe eben mal versucht, mir das auf meinem "Absturzlappi" anzusehen. WinMediaPlayer, HxD und VLC installiert und in das MP3 "Jingle-Bells" reingeschaut. Das ist komplizierter, als man denkt. Die MP3-Datei enthält auch gleich alles, was geht:- ID3-Tag-Bereich am Anfang
- ID3-Extensions
- Grafik
- Bit Reservoire
- usw.
Man erkennt auch gut, dass das Programm, mit dem das MP3-File erstellt wurde, die Paddingbereiche der Einzelangaben nicht voll überschrieben hat, sondern nur jeweils den Zero-Terminator geschrieben hat und den Restmüll aus dem Hauptspeicher hat stehen lassen. Nicht ungefählich solche Programme!
Der Windpws-Media-Player zeigt das Coverbild an. VLC kann es nicht.
Wo nun genau die einzelnen Frames anfangen, konnte ich noch nicht eindeutig identifizieren. Ich wollte ja den ID3-Tag-Bereich einfach nochmal mittendrin einfügen (mit geänderten Daten). Das hat leider noch nicht geklappt.
Glück Auf
Tom vom Berg--
Es gibt nichts Gutes, außer man tut es!
Das Leben selbst ist der Sinn.
-
-
-
-
-
-
-
mp3's kannst Du einfach aneinanderhängen. MFG
Die Alternative ist eine Playlist. MFG
-
Hallo,
mp3's kannst Du einfach aneinanderhängen. MFG
Die Alternative ist eine Playlist.
ja, aber mit Nebenwirkungen.
Dann musst du damit rechnen, dass der Player zwischen den mp3-Clips jeweils eine kleine Pause macht. Das kann erwünscht sein, vielleicht aber auch nicht.
Beim direkten Verketten und Ausliefern als eine mp3-Ressource gibt es diese Pausen nicht. Wenn man sie doch will, muss man jeweils eine mp3-Datei dazwischenschieben, die nur z.B. 2s Stille enthält. Zumindest hat man diesen Aspekt dann unter Kontrolle.
Ciao,
Martin--
Sei n die Anzahl der bekannten Fehler in einer Software, dann gilt stets: n = n+1-
Es kommt darauf an wie groß die Dateien sind. Der Browser streamt die nämlich nicht sondern nimmt die komplett in den Hauptspeicher und spielt erst ab wenn alles angekommen ist.
Und was die Übertragung großer Brocken betrifft, gibts weitere Überlegungen hinsichtlich Transfer-Encoding serverseitig. Gzip ist nämlich auch schlecht, weil der Server die ganze Datei in seinen Hauptspeicher nimmt um sie zu packen. Also bei großen Dateien die Komprimierung abschalten damit die mit Transfer-Encoding chunked rausgehen. MFG
-
Hallo
Es kommt darauf an wie groß die Dateien sind. Der Browser streamt die nämlich nicht sondern nimmt die komplett in den Hauptspeicher und spielt erst ab wenn alles angekommen ist.
das ist browserspezifisch unterschiedlich, vor allem auch von den Einstellungen abhängig. Meine Browser würden das zum Speichern anbieten; andere würden es an den Media Player (z.B. VLC) übergeben, der erst ein Stückchen vorauslädt und dann mit der Wiedergabe beginnt.
Ciao,
Martin--
Sei n die Anzahl der bekannten Fehler in einer Software, dann gilt stets: n = n+1 -
Es kommt darauf an wie groß die Dateien sind. Der Browser streamt die nämlich nicht sondern nimmt die komplett in den Hauptspeicher und spielt erst ab wenn alles angekommen ist.
Das ist nicht richtig. Wenn es bei Dir anders ist, liegt es irgendwo in Deinem Setup. Aber im Regelfall beginnt die Wiedergabe von MP3 bereits, nachdem ein ausreichend großes Stück vom Kuchen übertragen wurde. Analog beispielsweise auch bei MPEG4.
Darüber hinaus melde ich große Zweifel an der These an, dass gängige Clients stumpf alles in den Hauptspeicher laden und lokale Speichermedien ignorieren würden.
Und was die Übertragung großer Brocken betrifft, gibts weitere Überlegungen hinsichtlich Transfer-Encoding serverseitig. Gzip ist nämlich auch schlecht, weil der Server die ganze Datei in seinen Hauptspeicher nimmt um sie zu packen. Also bei großen Dateien die Komprimierung abschalten
Auch hier melde ich Zweifel an, dass alles stets immer über den Hauptspeicher läuft. Aber ja, Komprimierung gibt es nicht umsonst. Daher konfiguriert man das vernünftigerweise mittels einer Positivliste, dass es nur für passende Mime-Types greift: html, json, css...
Das ist viel zielgerichteter, als die Dateigröße in Betracht zu ziehen. In 99% der Fälle sind große Files bereits komprimiert und eine weitere Komprimierung nahezu nutzlos: PDF, MPEG4, Archive...
damit die mit Transfer-Encoding chunked rausgehen.
Das ist kein nötiges Kriterium für die Anforderung.
-
Hallo pl,
Es kommt darauf an wie groß die Dateien sind.
Walter schrieb von 6 kleinen Dateien.
Und was die Übertragung großer Brocken betrifft,
Walter schrieb von 6 kleinen Dateien.
Bis demnächst
Matthias--
Du kannst das Projekt SELFHTML unterstützen,
indem du bei Amazon-Einkäufen Amazon smile (Was ist das?) nutzt.
-
-
-
-
mp3's kannst Du einfach aneinanderhängen. MFG
Das geht sogal lokal mit bischen JS, hier das Beispiel. MFG
-
mp3's kannst Du einfach aneinanderhängen. MFG
Das geht sogal lokal mit bischen JS, hier das Beispiel. MFG
Interessant für Playlists ist das ended Ereignis vom <audio>-Tag. Damit kannst Du auch für den Besucher sichtbar machen, welche MP3-Datei grad gespielt wird. Beispiel siehe oben.
MFG
-
-
-
Lieber Walter,
Mit ffmpeg zu einer Datei zusammenfügen
ich nutze eine PHP-Klasse, die ich einst im Internet fand. Leider ist die Seite aktuell nicht erreichbar, so dass ich Dir hier nur das 500+ Zeilen lange Listing anbieten könnte - worauf ich aber verzichten möchte.
In besagter Klasse gibt es eine Methode
mergeBehind, mit der ich verschiedene MP3-Dateien zusammenfügen kann. Da bei mir alle die gleiche Bitrate haben, gelingt das mit dieser recht simplen Klasse problemlos.Vielleicht findest Du eine andere PHP-Klasse, die MP3-Dateien handhaben kann, die auch über eine ähnliche Methode verfügt, und die wesentlich aktueller ist, als die von mir in Benutzung befindliche.
Liebe Grüße
Felix Riesterer
-
Hallo,recht herzlichen Dank für die hilfreichen Vorschläge. Nach einigen Tests habe ich mich für das Kopieren mit fread und fwrite entschieden. Glücklicherweise wird der Titel nicht angezeigt. Und dass die Abspieldauer nur von der ersten Datei angezeigt wird, spielt bei den kurzen Dateien keine Rolle. Damit ist das Problem gelöst. Nochmals Danke an alle. Walter
-
Hallo Walter,
Nach einigen Tests habe ich mich für das Kopieren mit fread und fwrite entschieden.
das heißt, du erzeugst eine temporäre Datei und speicherst die? Wenn ja, warum? Was gefällt dir an meinem Vorschlag nicht, die Dateien einfach direkt eine nach der anderen mit readfile() an den anfragenden Client durchzureichen?
Für den Client ist das Ergebnis exakt dasselbe, aber der Server hat weniger Dateioperationen, wird also weniger gefordert.
Und dass die Abspieldauer nur von der ersten Datei angezeigt wird, ...
Ist das so? Das wäre sehr eigenartig. Denn eigentlich scannt ein mp3-Player die gesamte Datei von Anfang bis Ende durch, um die Spieldauer zu ermitteln, bevor er überhaupt mit dem Abspielen beginnt. Falls das nicht möglich ist (z.B. weil die mp3-Daten gestreamt werden und die Gesamtlänge nicht bestimmbar ist), zeigt er normalerweise gar keine Spieldauer an.
Ciao,
Martin--
Sei n die Anzahl der bekannten Fehler in einer Software, dann gilt stets: n = n+1-
Lieber Martin,
Und dass die Abspieldauer nur von der ersten Datei angezeigt wird, ...
Ist das so? Das wäre sehr eigenartig. Denn eigentlich scannt ein mp3-Player die gesamte Datei von Anfang bis Ende durch, um die Spieldauer zu ermitteln, bevor er überhaupt mit dem Abspielen beginnt.
soweit die Theorie. Als ich mich mit dem Thema beschäftigt habe, ist mir dieses Verhalten auch aufgefallen. Deswegen hatte ich mich damals dazu entschieden, eine "korrekte" MP3-Datei zu erzeugen, anstatt die Teildateien einfach zu konkatenieren.
Falls das nicht möglich ist (z.B. weil die mp3-Daten gestreamt werden und die Gesamtlänge nicht bestimmbar ist), zeigt er normalerweise gar keine Spieldauer an.
In diesem Fall wird wohl bis zum letzten sequenziell erkannten Frame geparst, anstatt alle Frames in der Datei zu finden. ID3-Daten könnten hieran schuld sein.
Liebe Grüße
Felix Riesterer
-
Hallo Felix,
Denn eigentlich scannt ein mp3-Player die gesamte Datei von Anfang bis Ende durch, um die Spieldauer zu ermitteln, bevor er überhaupt mit dem Abspielen beginnt.
soweit die Theorie. Als ich mich mit dem Thema beschäftigt habe, ist mir dieses Verhalten auch aufgefallen. Deswegen hatte ich mich damals dazu entschieden, eine "korrekte" MP3-Datei zu erzeugen, anstatt die Teildateien einfach zu konkatenieren.
früher[tm] habe ich zum Abspielen von mp3-Dateien vor allem Winamp benutzt, und dem war sch+$%egal, was zwischen den Frames an Nicht-mp3-Daten vorkam, der hat's eisern durchgezogen.
Mittlerweile benutze ich vor allem VLC, und auch da ist mir noch kein seltsames Verhalten aufgefallen. Entweder er kann die Spieldauer bestimmen, dann ist sie in der Regel auch korrekt, oder er kann es nicht, dann wird sie nicht angezeigt. Zum Beispiel wenn ich nebenher den SWR3-Livestream laufen lasse.Falls das nicht möglich ist (z.B. weil die mp3-Daten gestreamt werden und die Gesamtlänge nicht bestimmbar ist), zeigt er normalerweise gar keine Spieldauer an.
In diesem Fall wird wohl bis zum letzten sequenziell erkannten Frame geparst, anstatt alle Frames in der Datei zu finden. ID3-Daten könnten hieran schuld sein.
Okay, kann sein. Die Player, mit denen ich bisher engeren Kontakt hatte (Winamp. VLC), scheinen davon nicht betroffen zu sein.
Schönen Abend noch,
Martin--
Jedesmal, wenn mich eine schöne Frau anspricht, bekomme ich weiche Hände und feuchte Knie. ... Oder war es andersrum?-
Lieber Martin,
früher[tm] [...] Winamp [...] Mittlerweile [...] VLC
denkst Du bitte auch an die
<audio>-basierten Player in den Browsern? Was machen die denn, wenn zwischen den Frames noch ID3-Daten stehen? Also je nach Browser versteht sich...Liebe Grüße
Felix Riesterer
-
-
-
-
-