Probleme mit mp3 Dateien

Hallo zusammen,
ich hab mir, bzw meinem Sohnemann nun auch so ein Ding gebastelt. Schon ein tolles Teil.
Jedenfalls hat beim Testen alles einigermaßen gut geklappt aber jetzt geht es darum, die Box mit Content zu befüllen. So habe ich also aus meiner mp3 Sammlung die Kinderlieder raus gekramt die ich vor einigen Jahren noch auf CD erstanden und gerippt habe und drauf geladen. Insgesamt sind das bisher so 4 Alben zu je 30 Tracks. Generell funktioniert es, aber bei ca 5%, also so ungefähr 2 Lieder pro Album hab ich das Problem, dass die Box über das Ende des Liedes stolpert. Das heisst, wenn das lied fertig ist, dann springt sie plötzlich 20 Sekunden oder so zurück und spielt das Ende des Liedes nochmal ab. Das bleibt dann so in der Endlosschleife hängen bis man durch Interaktion eben stoppt oder etwas anderes startet.

Um das zu beheben, hilft es in der Regel wenn ich die mp3 Datei ein mal duch einen Encoder schicke (z.b. ffmpeg) und wieder auf die Box spiele. Manchmal gehen die Dateien dabei aber auch komplett kaputt und ich kann sie dann nur mehr mit ruckeln/hüpfen auf dem ESPuino abspielen.

Ich konnte bisher noch keinen Zusammenhang zwischen dem Problem und z.b. Bitrate, Größe, Samplerate, etc der mp3 Datei erkennen. Es scheinen einfach zufällig immer wieder Datein vom Problem betroffen zu sein.

Wichtig anzumerken ist natürlich, dass alle diese Dateien an allen getesteten anderen MP3 playern Problemlos abzuspielen sind. Die mp3s sind also nicht generell kaputt. Nur der ESPuino stolpert darüber.

Kennt jemand das Verhalten bzw gibt’s Tips wie man das umgehen könnte, ohne jedesmal das ganze Album nach dem aufspielen probezuhören zu müssen und die „kaputten“ tracks nochmal neu zu encoden?

vlt das gleiche wie hier:

sonst lade mal eine hoch dann können die Experten hier gucken…
@Wolle

Dieses Verhalten ist bei mir tatsächlich auch letztens aufgetreten, aber nur ein einziges Mal.

Das würde ich pauschal nicht ausschließen, gerade wenn das neu codieren den Fehler behobt oder die Datei gänzlich unbrauchbar macht ist das ein Indiz auf eine Beschädigung.
Hatte ich auch auf einer alten HDD mit Media content, der VLC ignoriert solche Fehler konsequent und man hört vielleicht mal ein knacken oder in Videos einen Block im Bild. Aber die Fehler sind in der Datei vorhanden.
Ist meist ein BitFlip bei dem einzelne bits die Werte ändern.

Das Thema hatten wir vor noch gar nicht so langer Zeit schon einmal. Defekte mp3 Dateien würde ich nicht vermuten. In der Testumgebung kann ich ohne Probleme vorwärts oder rückwärts spulen. Kommt denn das Event audio_eof_mp3() wirklich nicht?
Intern läuft ein Zeiger mit. Der Zeiger kann nicht vor dem Audioblock gesetzt werden und auch nicht über das Dateiende hinaus. Und vorwärts/rückwärts bedeutet nur, dass der Wert des Zeigers verändert wird.

Nun, ich habe es auch schon mit 2 (von insgesamt 6) mp3s die ich frisch mit youtube-dl gezogen hatte… Klar, so ganz 100% ausschießen würde ich defekte mp3 Dateien auch nicht, aber dennoch erscheint es mir ziemlich unwahrscheinlich in der Häufigkeit und Konstellation in der ich es beobachte…

OK. also ich kann es reproduzieren indem ich dieses Lied mal testhalber so hole:

youtube-dl -x --audio-format mp3 https://youtu.be/h-tg7paEptg

Dieses dann per Web interface auf die Box geladen und es passiert reproduzierbar.

Die logs dazu sehen so aus:

Der Sprung passiert ei timestamp 171065

[ 31854 ]  Modus: Einzelner Track
[ 31863 ]  Neue Playlist empfangen mit 1 Titel(n)
[ 31863 ]  Free heap: : 79984
[ 31916 ]  info        : PSRAM found, inputBufferSize: 283615 bytes
[ 31917 ]  info        : buffers freed, free Heap: 80616 bytes
[ 31917 ]  info        : Reading file: "/bboxtest/Wenn du fr�hlich bist-test.mp3"
[ 31941 ]  info        : MP3Decoder has been initialized, free Heap: 60456 bytes
[ 31948 ]  '/bboxtest/Wenn du fr�hlich bist-test.mp3' wird abgespielt (1 von 1)
[ 31968 ]  info        : Content-Length: 2277376
[ 31968 ]  info        : ID3 framesSize: 45
[ 31968 ]  info        : ID3 version: 2.4
[ 31987 ]  info        : ID3 normal frames
[ 32007 ]  no cover image for SD-card audio
[ 32016 ]  no cover image for SD-card audio
[ 32025 ]  no cover image for SD-card audio
[ 32091 ]  id3data     : SettingsForEncoding: Lavf59.27.100
[ 32099 ]  no cover image for SD-card audio
[ 32208 ]  info        : Audio-Length: 2277331
[ 32350 ]  info        : stream ready
[ 32354 ]  info        : syncword found at pos 0
[ 32362 ]  info        : Channels: 2
[ 32362 ]  info        : SampleRate: 48000
[ 32362 ]  info        : BitsPerSample: 16
[ 32363 ]  info        : BitRate: 64000
[ 32382 ]  info        : VBR recognized, audioFileDuration is estimated
[ 60008 ]  RSSI: -59 dBm
[ 120063 ]  RSSI: -60 dBm
[ 171065 ]  info        : MP3 decode error -1 : INDATA_UNDERFLOW
[ 171069 ]  info        : syncword found at pos 104
[ 171072 ]  info        : syncword found at pos 0
[ 171075 ]  info        : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 171078 ]  info        : syncword found at pos 106
[ 171083 ]  info        : syncword found at pos 0
[ 171088 ]  info        : MP3 decode error -9 : INVALID_HUFFCODES
[ 171093 ]  info        : syncword found at pos 0
[ 171104 ]  info        : Channels: 2
[ 171104 ]  info        : SampleRate: 48000
[ 171104 ]  info        : BitsPerSample: 16
[ 171106 ]  info        : BitRate: 192000
[ 180063 ]  RSSI: -61 dBm
1 „Gefällt mir“

Ah, also ansonsten passt alles, ich kann das Lied an-skippen, ich kann darin spulen, ich kann aus dem Lied heraus aufs nächste skippen. Alles ok. Erst wenn er am Ende des Liedes ankommt passiert der Sprung.

Die Datei
youtube-dl -x --audio-format mp3 https://youtu.be/h-tg7paEptg
habe ich geladen, ich musste erst
sudo apt install ffmpeg
dann hat es funktioniert. Die Datei hat viele „Füllbits“ am Anfang und am Ende des Audioblocks, aber das ist kein Problem. Der Audioblock beginnt bei 45 und ist 2277600 lang. Das zeigt mir der HEX Editor auch an. Hab mehrfach vor und zurück gespult, auch unsinnige Werte probiert, alles okay. Ich kann mir den Fehler nicht erklären.

FWIW, ich habe mittlerweile auf Arduino-2 und der aktuellsten ESP32-audioI2S lib upgedatet. Eigentlich wollte ich damit Ruckler bei der Wiedergabe bei MQTT und LPCD simultan beheben wie in einem anderen Thread beschrieben, aber ein netter Nebeneffekt davon war, dass jetzt auch dieses Problem Geschichte zu sein scheint. Zumindest kam er über die 2 Lieder die bisher problematisch waren gerade Problemlos drüber.

Sorry, da hab ich mich wohl etwas zu früh gefreut… Es scheint jetzt definitiv bei ein paar Liedern die das vorher zuverlässig hatten nicht mehr aufzutreten. Allerdings bin ich jetzt gerade wieder bei einem in das Problem gerannt.

Habe das selbe Verhalten bei einzelnen MP3 Dateien. Am PC gibt es keine Probleme diese Dateien abzuspielen, aber scheinbar haben die irgendein Problem.
Hier ist die Ausgabe dazu:

[ 1147847 ]  info        : MP3 decode error -1 : INDATA_UNDERFLOW
[ 1147850 ]  info        : syncword found at pos 93
[ 1147853 ]  info        : syncword found at pos 0
[ 1147856 ]  info        : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 1147869 ]  info        : syncword found at pos 176
[ 1147872 ]  info        : syncword found at pos 0
[ 1147875 ]  info        : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 1147878 ]  info        : syncword found at pos 93
[ 1147881 ]  info        : syncword found at pos 0
[ 1147894 ]  info        : MP3 decode error -6 : INVALID_FRAMEHEADER
[ 1147897 ]  info        : syncword found at pos 1
[ 1147900 ]  info        : syncword found at pos 0
[ 1147904 ]  info        : MP3 decode error -8 : INVALID_SCALEFACT
[ 1147917 ]  info        : syncword found at pos 213
[ 1147920 ]  info        : syncword found at pos 0
[ 1147932 ]  info        : Channels: 2
[ 1147932 ]  info        : SampleRate: 48000
[ 1147932 ]  info        : BitsPerSample: 16
[ 1147932 ]  info        : BitRate: 224000

Dass kommt dann in Endlosschleife, wann immer die Datei wieder das Ende erreicht.
Kann es auf Arduino 1 und 2 zuverlässig reproduzieren…
Hier noch eine Datei mit diesem Vehalten:
musicfile.zip (2,3 MB)
Wenn man bisschen spult muss man den ganzen Rest nicht ertragen :wink:
Es passiert immer ganz am Ende der Datei.
@Wolle scheinbar gibt es hier irgendein Problem mit dem letzten Frameheader. Hast du Tools um so was besser zu analysieren? Bin da nicht so tief drin in Audioencoding…

Ich habe mal bisschen in der Audio.cpp gesucht und dort folgendes in der Funktion „sendBytes“ in Zeile 3180 angepasst:

	 if((ret == -1) || (bytesDecoded == 0 && ret == 0)){ // unlikely framesize

Ich habe ehrlicherweise keine Ahnung was für Auswirkungen das sonst so hat, in meinem Fall löst es aber das Problem und die Meldung sieht entsprechend so in der Konsole aus:

[ 60545 ]  info        : framesize is 0, start decoding again
[ 60546 ]  info        : Closing audio file
[ 60546 ]  info        : End of file "NAME_OF_FILE.mp3"
[ 60557 ]  eof_mp3     : NAME_OF_FILE.mp3

@Wolle ist das in Ordnung oder wie beurteilst du diese Änderung?

1 „Gefällt mir“

Ich habe mit deiner Datei etwas rumprobiert.
Für Linux gibt es ein Programm namens MP3Check - leider habe ich ein defektes Paket auf meinem Linuxrechner und kann da gerade nix installieren (anderes Thema).
Ich habe dann Foobar2000 auf Windows installiert. Dort kann man „Verify integrity“ auf Dateien anwenden. Da wird gesagt, die Datei ist in Ordnung. Es gibt aber noch einen weiteren Punkt „Fix VBR MP3 header“. Die damit bearbeitete Datei funktioniert.
Meistens sollen Probleme am ID3-Tag liegen aber der ist bei dir gar nicht ausgefüllt.
musicfile_fix.zip (2,3 MB)

1 „Gefällt mir“

Vielen Dank für deine Antwort! Das ist ja spannend :slight_smile: .
Wenn die Datei ansich in Ordnung ist, dann sollte der Espuino sie auch spielen können.
Ich habe eigentlich auch viele weitere Dateien ohne ID3-Tags die ohne Probleme funktionierne. Also ist vermutlich doch ein header defekt, auch wenn die Datei „in Ordnung“ ist?

Edit: im Hexeditor sieht man als Diff wirklich nur Änderungen am Anfang der Datei. Für mich macht das irgendwie kein Sinn, dass es dann am Ende abbricht…

Ich Stocher auch bloß im dunkeln.
Es hat sich tatsächlich bloß der Header geändert.
These (ohne, dass ich genau weiß was alles im Header steht), wenn dort eine fehlerhafte Liedlänge steht, dann verhaspelt sich der ESPUINO eventuell ???

Ist vielleicht nur ein Problem bei VBR

Klingt plausibel, jetzt müssen wir nur noch herausfinden was der inhaltliche Unterschied des headers bedeutet und und dann überlegen, ob der Espuino das auch „fehlerhaft“ abspielen können soll und wenn ja, wie am besten der Workaround dafür aussieht :slight_smile: .
Für heute muss ich mich aber verabschieden. Wünsche noch einen schönen Abend!

Ich vermute, dass wir da vom gleichen Problem reden, wie auch hier: Slow Stream - #2 von Wolle.
Weil ich habe vorhin, als diese Probleme wieder auftraten, nochmal genauer geschaut und bin dann auch auf dieses „INVALID FRAMEHEADER“ gestoßen. Die Art, wie sich das jetzt genau anhört, hat sich in letzter Zeit (subjektiver Eindruck) auch irgendwie geändert.

Das ist irgendwie elend
Ich habe jetzt noch EncSpot Pro v2.2 installiert.
Da bekommt man ein Haufen Werte angezeigt. Die sind bei beiden Dateien identisch. Außer „Total Bitstream Bytes“ im „Lame Header“.
Gefixt:
fix
Original:
original

Was das bedeutet weiß ich aber auch nicht. Ich muss jetzt ins Bett

1 „Gefällt mir“

Kommt bei dem slow -stream die header-Meldung als erstes oder als Folgefehler?
Im Fall der Datei ist der header erst der Folgefehler von dem Underrun Fehler.
Das würde auch zu den unterschiedlichen Längenangaben passen.