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?
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)
Vielen Dank für deine Antwort! Das ist ja spannend .
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 ???
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 .
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:
Original:
Was das bedeutet weiß ich aber auch nicht. Ich muss jetzt ins Bett
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.
Die Datei „Sonne Mond und Sterne…mp3“ läuft in der Testumgebung ohne Probleme. Also habe ich sie dann im ESPUINO getestet und konnte den selben Fehler feststellen. Das Dateiende wird nicht korrekt erkannt, stattdessen gibt es einen Fehler vom Dekoder, es wird ein neues SyncWord gesucht (Überlauf im InBuff) und die Datei weiter abgespielt. Im InBuff sind noch Daten vorhanden, etwa 200KB, die in einer Schleife abgespielt werden. EOF wird nie erzeugt.
Ich hatte die Datei über das WebInterface auf die SD Karte geschrieben. Danach ist die Audiodatei aud der SD kürzer als das Original???, etwa 700 Bytes fehlen.
Danach habe ich die SD Karte aus den ESPUINO genommen und die Datei mit dem PC aud die SD Karte geschrieben, jetzt stimmt die Dateilänge und der Fehler ist verschwunden. Kann das bitte jemand überprüfen. Meine ESPUINO-SW ist vom Januar.
Das eine Datei beim Upload verstümmelt wird ist mir bisher noch nie aufgefallen. War auch noch nie Thema, außer jetzt bei der Sonne, Mond Sterne…mp3 Datei weiter oben im Thread, heißt dort musicfile.zip
Also es ist nicht 100% auszuschließen, dass es von SPI kommt. Wenn man ein File hochlädt, dann wird aus diesem Grund eine Statistik ausgegeben, wieviel Pakete erfolgreich übertragen wurden.
Da haben wir schon einiges an Zeit drin verbraten, aber bisher hat niemand rausgefunden, warum Dateien immer mal wieder (nicht immer) beim SPI-Transfer kaputtgehen. Der hört dann ab einem gewissen Punkt einfach auf, den Kram auf die SD zu schreiben und meldet das auch entsprechend zurück.
Hallo @Joe91,
ich bin der Meinug, dass die Datei auf der SD Karte von der Originaldatei in der Länge abweicht. MP3 decode error -1 : INDATA_UNDERFLOW
weist darauf hin. Damit nicht die Endlosschleife wirkt, habe ich eine Abbruchbdingung eingebaut. Bei einem Dekoderfehler wird jetzt ein EOF gesendet.
Im Log sieht das dann so aus:
[ 159695 ] info : MP3 decode error -1 : INDATA_UNDERFLOW
[ 159695 ] info : audio file is corrupt --> send EOF
[ 159696 ] info : Closing audio file
Vielen Dank für den fix!!
Aber zurück zur Ursache. Irgendwas an der Datei sorgt ja dafür, dass sie zuverlässig falsch übertragen wird und etwas Inhalt verloren geht wenn der ESPuino das macht.
Wurde jetzt ja auch mehreren Systemen nachgestellt.
Dass mit dem direkt auf die SD schreiben ist ziemlich verrückt .
Wenn der header „korrigiert“ wird klappt es ja wieder mit dem Webupload. FTP macht übrigens keinen Unterschied dabei…
Ich habe die ESPuino-mini 4Layer und die ist meines Wissen über SD_MMC angeschlossen. Bei mir ist der Fehler auch über den Webupload passiert. Daher würde ich SPI als Ursache auch ausschließen
Auch hier sd_mmc, bisher habe auch ich alle Dateien über das web interface hochgeladen und der Fehler tritt ziemlich häufig auf.
(Ich hab’s komischerweise noch nicht geschafft eine sd Karte so zu formatieren dass ich vom Rechner aus direkt was auf die Karte kopiere und der espuino das dann sieht… Der espuino scheint hier ausschließlich die Dateien zu sehen die mit dem web interface hochgeladen werden. FTP funktioniert hier auch gar nicht - aber das ist ein anderes Thema)
.
.