feat(deps): bump waveflow-core and decode user text files with its decoder

Cargo.toml

@@ -26,10 +26,16 @@ base64 = "0.23"
 blake3 = "1"
 bytes = "1"
 chacha20poly1305 = "0.11"
+# Both arrive with `waveflow-core`, whose `text_encoding` decodes the text
+# files users bring. Named here so an imported playlist can say which
+# encoding it was read as (`playlist_file`), which the core does not answer.
+# Same versions as the core's, so nothing new is compiled.
+chardetng = "1"
 chrono = "0.4"
 clap = { version = "4", features = ["derive"] }
 dashmap = "6"
 dotenvy = "0.15"
+encoding_rs = "0.8.42"
 futures-util = "0.3"
 hex = "0.4"
 lofty = "0.25"
@@ -75,7 +81,7 @@ utoipa-scalar = { version = "0.4", features = ["axum"] }
 url = "2"
 uuid = { version = "1", features = ["v4", "v8", "serde"] }
 walkdir = "2"
-waveflow-core = { git = "https://github.com/InstaZDLL/WaveFlow", rev = "9b50f3de288d62b0ff9f867ab7bda504b255cc5c", default-features = false }
+waveflow-core = { git = "https://github.com/InstaZDLL/WaveFlow", rev = "102df0031bef8ba44062e03337807592b3d51102", default-features = false }
 
 [dev-dependencies]
 http-body-util = "0.1"

docs/api-v2-guide.md

@@ -424,7 +424,9 @@ its hash — a shared cache keyed on the URL would hand one tenant's artwork to
 another with no credential presented. A private cache is the client's own and
 loses nothing by the restriction.
 
-Lyrics return embedded or UTF-8 `.lrc`/`.txt` sidecar content. Synchronized
+Lyrics return embedded or `.lrc`/`.txt` sidecar content. A sidecar need not be
+UTF-8: a byte-order mark names its encoding, and otherwise one such as GB18030,
+Big5, Shift_JIS or a Windows code page is recognised from the bytes. Synchronized
 line starts are milliseconds; plain lines omit `start`:
 
 ```bash
@@ -738,8 +740,14 @@ name `comment` in `clear`. Shares use the same rule for `description` and
 JSON. The encoding of a playlist file is part of the problem (`.m3u` is
 frequently not UTF-8), so the bytes have to arrive as bytes; a JSON envelope
 would have forced the caller to decode them first, which is the one decision it
-cannot make correctly. The server reads UTF-8 when the bytes are UTF-8 and
-Windows-1252 otherwise, and **says which it used** in the response.
+cannot make correctly. A byte-order mark names the encoding (UTF-8, UTF-16 LE or
+BE); otherwise the server reads UTF-8 when the bytes are UTF-8 and recognises
+the encoding from the bytes when they are not — GB18030, Big5, Shift_JIS,
+EUC-KR, Windows-1252 and the like — and **says which it used** in the response,
+as the encoding's WHATWG name in lower case (`utf-8`, `utf-16le`, `shift_jis`,
+`windows-1252`…). A GB18030 file is reported as `gbk`: the detector never
+names GB18030, and the GBK decoder is the GB18030 one, so the text is read in
+full under either name.
 
 ```bash
 # What it would do, without doing it

docs/subsonic-api-guide.md

@@ -193,8 +193,10 @@ curl -X POST https://music.example.com/rest/getLyricsBySongId.view \
   --data-urlencode "id=TRACK_UUID"
 ```
 
-WaveFlow returns embedded text and UTF-8 `.lrc`/`.txt` sidecars. LRC timestamps
-are milliseconds. The legacy `getLyrics` exact artist/title lookup is also
+WaveFlow returns embedded text and `.lrc`/`.txt` sidecars. A sidecar need not
+be UTF-8: a byte-order mark names its encoding, and otherwise one such as
+GB18030, Big5, Shift_JIS or a Windows code page is recognised from the bytes.
+LRC timestamps are milliseconds. The legacy `getLyrics` exact artist/title lookup is also
 implemented.
 
 Stream an original with a byte range: