这个cli版本的停止维护了吗? #77

Closed
opened 2023-06-28 10:00:24 +00:00 by red-co · 7 comments
(base) PS C:\Users\r\Desktop\qmc_unlock> .\um-windows-amd64.exe -o .\output\ -i '.\A Tender Moon Tempo - 八木海莉.mgg'
2023/06/28 17:26:13.685 WARN    try decode failed
2023/06/28 17:26:13.701 FATAL   run app failed  {"error": "no any decoder can resolve the file"}
```
(不能上传mgg文件,所以我加了.txt后缀。就是这个文件)
web js 版本能正常解锁,但是 cli 版本无法解锁。
```` (base) PS C:\Users\r\Desktop\qmc_unlock> .\um-windows-amd64.exe -o .\output\ -i '.\A Tender Moon Tempo - 八木海莉.mgg' 2023/06/28 17:26:13.685 WARN try decode failed 2023/06/28 17:26:13.701 FATAL run app failed {"error": "no any decoder can resolve the file"} ``` (不能上传mgg文件,所以我加了.txt后缀。就是这个文件) web js 版本能正常解锁,但是 cli 版本无法解锁。
Author

(顺便问问,为什么不是使用 go 作为 back_end, 使用 ts 作为 front end 调用 back_end 的api ?
为什么要把 decrypt 写两遍?https://git.unlock-music.dev/um/web/src/branch/master/src/decrypt)

(顺便问问,为什么不是使用 go 作为 back_end, 使用 ts 作为 front end 调用 back_end 的api ? 为什么要把 decrypt 写两遍?https://git.unlock-music.dev/um/web/src/branch/master/src/decrypt)
Owner

项目开始的时候没考虑过 wasm 的可能,golang 后端是在 web 端之后诞生的项目。

项目组里没多少人会 golang,就 ix 一个人好像,他忙起来所以更新就减缓。

项目开始的时候没考虑过 wasm 的可能,golang 后端是在 web 端之后诞生的项目。 项目组里没多少人会 golang,就 ix 一个人好像,他忙起来所以更新就减缓。
Owner

如果你对 golang 有兴趣你可以研究一下具体问题提交 pr,不然就只能等 ix 之后慢慢修了。

如果你对 golang 有兴趣你可以研究一下具体问题提交 pr,不然就只能等 ix 之后慢慢修了。

同问老大,是不是不会再更新了,我一直关注更新,因为现在有些mflac解密不了。

同问老大,是不是不会再更新了,我一直关注更新,因为现在有些mflac解密不了。
Owner

同问老大,是不是不会再更新了,我一直关注更新,因为现在有些mflac解密不了。

请提交样本。

> 同问老大,是不是不会再更新了,我一直关注更新,因为现在有些mflac解密不了。 请提交样本。

同问。不太理解为什么 web 端可以解锁的文件却无法在 cli 解锁……
提交了一个样本(麻烦自行去掉 .txt 后缀)
在 Android Termux 上,先使用 Git 拉取最新版本,再用 go build 自行构建的 cli 端,运行结果如下:

~/go/bin/um1 -o md -i me/02.mgg

2024/07/06 16:50:11.884 WARN    um/main.go:270 try decode failed        {"source": "me/02.mgg", "error": "qmc: detect file type failed"}
2024/07/06 16:50:11.885 FATAL   um/main.go:69  run app failed   {"error": "no any decoder can resolve the file"}

(虽然似乎是很另类的构建条件,但是解锁我另一首 .kgm 成功了,证明构建没有问题。)

~/go/bin/um1 -o md -i me/00.kgm

2024/07/06 16:56:59.978 INFO    um/main.go:374 successfully converted   {"source": "me/00.kgm", "source": "me/00.kgm", "destination": "md/00.flac"}

使用 README 中教程构建的版本输出相同,使用最新一个 Pre-Release 中的 Windows 版本输出相同。
而另一方面,在 web 端解锁同一文件,它会显示「解锁成功」。无论是使用 1.10.6 版本的 http://unlock.music.hi.cn/,还是使用 1.10.3 版本的 https://demo.unlock-music.dev/,都能正常解锁。

同问。不太理解为什么 web 端可以解锁的文件却无法在 cli 解锁…… 提交了一个样本(麻烦自行去掉 .txt 后缀) 在 Android Termux 上,先使用 Git 拉取最新版本,再用 `go build` 自行构建的 cli 端,运行结果如下: ``` ~/go/bin/um1 -o md -i me/02.mgg 2024/07/06 16:50:11.884 WARN um/main.go:270 try decode failed {"source": "me/02.mgg", "error": "qmc: detect file type failed"} 2024/07/06 16:50:11.885 FATAL um/main.go:69 run app failed {"error": "no any decoder can resolve the file"} ``` (虽然似乎是很另类的构建条件,但是解锁我另一首 .kgm 成功了,证明构建没有问题。) ``` ~/go/bin/um1 -o md -i me/00.kgm 2024/07/06 16:56:59.978 INFO um/main.go:374 successfully converted {"source": "me/00.kgm", "source": "me/00.kgm", "destination": "md/00.flac"} ``` 使用 README 中教程构建的版本输出相同,使用最新一个 Pre-Release 中的 Windows 版本输出相同。 而另一方面,在 web 端解锁同一文件,它会显示「解锁成功」。无论是使用 1.10.6 版本的 [http://unlock.music.hi.cn/](http://unlock.music.hi.cn/),还是使用 1.10.3 版本的 [https://demo.unlock-music.dev/](https://demo.unlock-music.dev/),都能正常解锁。
2.3 MiB
Owner

使用 README 中教程构建的版本输出相同,使用最新一个 Pre-Release 中的 Windows 版本输出相同。
而另一方面,在 web 端解锁同一文件,它会显示「解锁成功」。无论是使用 1.10.6 版本的 http://unlock.music.hi.cn/,还是使用 1.10.3 版本的 https://demo.unlock-music.dev/,都能正常解锁。

文件没有内嵌密钥,不能正确解锁(解锁后的文件无法播放)。提示正常解锁为误报。

你需要降级 QQ 音乐到 19.51 或更之前的版本后重新下载该文件。

QQ 音乐 19.51 官方安装程序存档

> 使用 README 中教程构建的版本输出相同,使用最新一个 Pre-Release 中的 Windows 版本输出相同。 > 而另一方面,在 web 端解锁同一文件,它会显示「解锁成功」。无论是使用 1.10.6 版本的 [http://unlock.music.hi.cn/](http://unlock.music.hi.cn/),还是使用 1.10.3 版本的 [https://demo.unlock-music.dev/](https://demo.unlock-music.dev/),都能正常解锁。 文件没有内嵌密钥,不能正确解锁(解锁后的文件无法播放)。提示正常解锁为误报。 你需要降级 QQ 音乐到 19.51 或更之前的版本后重新下载该文件。 [QQ 音乐 19.51 官方安装程序存档](https://web.archive.org/web/20240109/https://dldir1v6.qq.com/music/clntupate/QQMusic_Setup_1951.exe)
jixunmoe added the
question
label 2024-07-06 18:39:31 +00:00
Sign in to join this conversation.
No description provided.