{"trackinfo":{"pausePlay":false,"currentTrackNumber":2,"numberOfTracks":2,"volume":4,"name":"(2/2): /test-mp3s/03 Kapitel 3 Der heimliche Gast.mp3","posPercent":0,"playMode":5}}
{"pong":"pong","rssi":-45}
{"coverimg":"coverimg"}
WebSocket connection to 'ws://192.168.1.207/ws' failed: Could not decode a text frame as UTF-8.
Socket encountered error: undefined Closing socket
I [113125] info : Reading file: "/test-mp3s/03 Kapitel 3 Der heimliche Gast.mp3"
I [113134] info : MP3Decoder has been initialized, free Heap: 138616 bytes , free stack 3212 DWORDs
N [113139] '/test-mp3s/03 Kapitel 3 Der heimliche Gast.mp3' wird abgespielt (2 von 2)
D [113156] no cover image for SD-card audio
D [113163] no cover image for SD-card audio
I [113176] info : Content-Length: 1496128
I [113177] info : ID3 framesSize: 344
I [113177] info : ID3 version: 2.3
I [113199] info : ID3 normal frames
I [113250] id3data : Length (ms): 75453
I [113298] id3data : Title: aa bb cc �
D [113309] ws[/ws][4] error(1002): Invalid UTF-8 in text frame
D [113311] ws[/ws][4] disconnect
D [113311] ws[/ws][1] disconnect
I [113357] id3data : Artist: Friederun Reichenstetter gelesen von Markus Grimm
I [113403] id3data : Album: So leben die kleinen Eichhörnchen
I [113451] id3data : Year: 2008
I [113502] id3data : Track: 03
I [113548] id3data : ContentType: Unknown
I [113600] info : Audio-Length: 1495784
I [113659] info : stream ready
I [113659] info : syncword found at pos 0
I [113667] info : Channels: 2
I [113667] info : SampleRate: 44100
I [113667] info : BitsPerSample: 16
I [113667] info : BitRate: 128000
I [118436] Kontroll-Kommando empfangen via Queue: 3
I [118437] Kommando: Pause
D [118643] ws[/ws][5] connect
D [118718] ws[/ws][5] error(1002): Invalid UTF-8 in text frame:2,"numberOfﾭ�xV���?�
D [118718] ws[/ws][5] disconnect
Ich denke es kommt schon falsch kodiert aus den MP3-Metadaten/Audiobibliothek.
Ich habe mehrere MP3 mit Umlauten/ß, da wird der Titel in der Web-UI richtig angezeigt.
Evt. ist das Problem so ähnlich wie hier (da ging es um Umlaute im Dateinamen)?
Auch wenn das Zeichen falsch codiert ist, die meisten Programme können damit umgehen, deshalb ist es für einen Anwender nur schwer als Problem feststellbar.
Schön wäre, wenn wir solche Probleme schon abfangen könnten, bevor ws die Connection schliesst. Irgend wo stellt er das ja fest und wirft die Fehlermeldung.
Gemäss WebSocket Setup - ESP32 Remote Control with WebSocket ist der event WS_EVT_ERROR vom client ausgelöst, es könnte also sein, das ESPuino gar kein Prolem damit hat, aber der Webbrowser/Javascript, welches das Zeichen interpretieren muss.
Habe es mit der MP3 gerade getestet & es ist wirklich gruselig: Die Weboberfläche reagiert praktisch gar nicht mehr.
Soweit ich es verstanden habe wird im Websocket-Paket eine gültige UTF-8 Kodierung erwartet. Das ist normalerweise der Fall & wohl auch bei Umlauten noch gültig, nur eben nicht bei einem „ß“ im Titel.
Lösung wäre jetzt auf gültiges UTF-8 im Titel zu prüfen & falls nicht es dann mit UTF-8 zu enkodieren? Oder sollte der Fehler im Javascript abgefangen um das Websocket nicht zu schließen?
So ganz habe ich es noch nicht geblickt
Was ich gerne machen würde, ist den string beim ersten ungültigen Zeichen abschneiden. Aber leider habe ich das noch nicht hingekriegt, strcpy geht nicht, das die anzahl bytes pro zeichen unbekannt sind.
Evt. lässt sich das Enkoding-Problem auch von der Wurzel anpacken:
Ich schreibe ja den Autor der AudioI2S-Bibliothek nur ungern an weil er viele andere Dinge um die Ohren hat. Aber wenn die Audio-Bibliothek die Metadaten, insbesondere den Titel immer als UTF-8 liefert wäre Alles fein. Die Info ob Ansi oder UTF-8 liefern die ID3-Metadaten normalerweise mit. Wir bekommen sie halt nicht im Ereignis.
@Wolle Was meinst Du dazu, wäre das machbar? Wenn ich jetzt eine Webradio Anwendung mit Display machen würde hätte ich vermutlich das gleiche Problem mit der korrekten Anzeige des Titels.
Die Idee ist, dass ID3 Tags immer in UTF-8 ausgegeben werden, auch wenn die mp3 Datei latin-1 benutzt.
In der Konvertierungsroutine wurde der Bereich 0xD0…0xDF nicht berücksichtigt und damit das ‚ß‘ ignoriert. Das ist jetzt bereinigt.
Das war sicher wieder so ein Grenzfall, die Frage ist, ob man das noch zusätzlich im ESPuino Code überprüft, wir können eigentlich davon ausgehen, dass der Titel immer als UTF-8 ankommt.
Hier kommt noch eine Ergänzung, das ist noch nicht perfekt. Es kann sein, dass UTF-8 als latin-1 erkannt wird und irrtümlich Zeichen konvertiert werden.
Das ist schwer zu sagen. Ich gehe davon aus, dass sie TAG Editoren die Bits richtig setzen.
Ich habe bisher darauf vertraut, dass ich UTF-8 von anderen Textkodierungen unterscheiden kann. „Nicht ASCII“ Zeichen belegen in UTF-8 mindestens zwei Byte, wobei das erste Byte größer gleich 0xC2 ist und das folgende Byte immer >= 0x80 sein muss. Falls an irgend einer Stelle gegen diese Regel verstoßen wird kann es nicht UTF-8 sein. Ich hatte das letzte Zeichen leider nicht berücksichtigt, daher wurde „aabbccß“ nicht erkannt.
Allerdings gibt er Kombinationen die sowohl in UTF-8 wie in Latin-1 gültig sind, wie " ÆÇÈßÉÊË", aber keinen Sinn ergeben.
Hier hat mir ein User aus Polen weitergeholfen, die in ihrem Alphabet besondere Zeichen wie „Ą Ć Ę Ł Ń Ś Ó Ź Ż ą ć ę ł ń ś ó ź ż“ haben.
Ich hoffe, dass das Problem jetzt vom Tisch ist.
Wenn ihr noch Unstimmigkeiten bei der Darstellung der ID3 Tags findet, lasst es mich gerne wissen.
