LX Music 项目发展调整与新项目计划

[lyswhut]

由于最初 LX 的开发线路是抱着对技术的学习与研究的目的，集成国内常用音乐平台以解决音乐查找与播放问题，但随着大家对音乐版权的重视，以及来自官方音乐平台的压力，这条路已难以走下去。
为了在不违反相关法律法规的情况下能随时愉快的听歌，我决定发起一个全新的项目，用于提供一套面向个人用户的个人私有云音乐解决方案。
之前用于维护 LX 的业余时间现在大部分已投入到该项目的设计与开发上，LX 也将逐渐进入维护模式，没有特殊情况下预计不会有重大的改变。

新项目预计主要由 桌面端、移动端、同步服务、歌曲管理服务 等子项目组成，计划分为以下里程碑：

里程碑1（计划在今年年底之前提供一个预览版）

桌面端的开发，在集成 LX 桌面版大部分现有功能的基础上，主要计划的更改如下：

• 基于 LX 系列项目的开发经验，使用新的代码架构设计
• 希望提供一个现代化且符合常见播放器使用习惯的UI
• 独立的播放列表、最近播放列表
• 多层级收藏列表支持
• 播放行为统计
• 软件本身只是一个可以播放本地歌曲的播放器，没有第三方在线资源功能
• 全新的扩展功能，预计提供一组包括扩展数据存储、通知、上下文菜单扩展等的API（参考 vs code 扩展API，只是预计，还在规划中）
• 提供web端，web端与桌面端将共用一套UI层，web端本质将是一个运行在服务器的桌面端，但UI层运行在客户端的浏览器上

注：扩展功能将允许扩展为软件提供接入在线资源的能力，之所以不内置在线服务功能而采用这种设计：

希望在解耦各个服务的同时，允许对接多个 自建 的或如 WebDAV 等 其他来源 的歌曲存储服务。

待定：其中的扩展将通过类似扩展仓库的方式集中显示并允许设置第三方仓库等方式？

里程碑2

同步服务（用于多端数据同步），虽然允许支持第三方来源，但我仍然希望本项目有属于自己的同步服务，而且 WebDAV 之类的存储服务存在数据同步实时性问题。

里程碑3

移动端的开发，提供桌面端的简化实现版本（由于没有 IOS 相关开发环境，所以暂定仍只支持安卓）

里程碑4

歌曲管理服务（用于管理服务器上的歌曲，提供类似常用音乐平台的歌曲搜索、排行榜、歌单、歌曲链接等API服务[理想]）

---

以上内容只是一个计划，各里程碑的顺序也是暂定的。由于项目的开发是在业余时间进行，整个计划及开发节奏也可能会随我个人的生活情况改变，亦或者会出现项目被终止的情况。
最后，大家也可以在下面提供 建议。

为了防止订阅该讨论的人收到无意义的邮件通知，灌水请点击 reactions 表情代替，谢谢 ❤️

[3gf8jv4dv]

Will new projects use Electron or other software frameworks?

[lyswhut]

Will new projects use Electron or other software frameworks?

是的，对于现在来说，JavaScript 是我熟悉的语言，同时为了更好的复用各个项目的代码，仍会使用 Electron

计划用到的技术栈：Electron、Svelte、Node.js、React Native
后面可能会用 Rust 实现某些功能，不过现在我对它还不熟悉 (

另外，我计划用 Svelte 5，所以还在等 5.0 的发布，现在先写不涉及 UI 的逻辑

[Gimmick13]

谢谢 你们洛雪团队

[Zeuyel]

本地音乐播放器的一个问题是 由于本地源文件的多样性和多来源，如何统一化标签管理对于呈现的美观和乐曲管理很重要。
不知道大佬您有没有解决这个问题的想法，还是说还得使用其他第三方的标签管理软件？

[lyswhut]

如何统一化标签管理对于呈现的美观和乐曲管理很重要

可以内置mp3、flac格式的基本标签（歌曲名，歌手，专辑名，歌词，封面图片）标签编辑，这个功能现在的lx移动端已经有了，但目前只支持单个编辑在线匹配

[subframe7536]

我也有类似的想法，目前已经完成了一些基础库的开发，不知道有没有合作的考虑？

[lvzhenbo]

Will new projects use Electron or other software frameworks?

是的，对于现在来说，JavaScript 是我熟悉的语言，同时为了更好的复用各个项目的代码，仍会使用 Electron

计划用到的技术栈：Electron、Svelte、Node.js、React Native
后面可能会用 Rust 实现某些功能，不过现在我对它还不熟悉 (

另外，我计划用 Svelte 5，所以还在等 5.0 的发布，现在先写不涉及 UI 的逻辑

如果可以话，考不考虑tauri2.0，这样的话也不需要rn了

[lyswhut]

我也有类似的想法，目前已经完成了一些基础库的开发，不知道有没有合作的考虑？

其实整个项目已经准备了半年多，目前整个桌面端的设计基本已经定下来了，播放、列表模块也已初步完善，扩展系统的开发进度也已开发了近一半，所以非常抱歉，目前暂不考虑外部的合作 (

如果可以话，考不考虑tauri2.0，这样的话也不需要rn了

现在tauri的生态相比electron还差些，并且我现在对 rust 还不熟悉，不过以后可能会考虑迁移到这个，还有一个问题是现在全用ts开发，各端可以共用同一套ts类型，可以复用大部分代码

[daihanpi]

考虑有下载歌曲功能吗？

[JackMerryYoung]

会有模块化么（
虽然我知道这很难，但是我觉得可以整一个新生态

[gitbruc]

别的无所谓，能把lx的歌单导过去吗:D

[SeaRat]

提几个小建议

既然已经提供web服务了，不如直接取消本地界面，做一个纯服务端的音乐库平台。就像 AList 一样。不同的是 AList 是文件库平台，新落雪音乐是专精音乐的音乐库平台。如果想要在本地使用可以在本地安装服务端，并且用本地的浏览器访问使用。如果想要多端同步使用，可以部署在服务器上。虽然使用门槛提高，但是有效筛除了所谓的小白们，也间接降低了法律风险。

或者也可以同时提供服务端版本和本地播放器版本，并且本地播放器版本不仅可以独立使用，还可以通过服务端提供的 API 连接服务端同步使用就再好不过了

另外希望能够有完善的扩展、插件功能，以至于可以通过安装集成有第三方服务的插件来实现对第三方资源的检索和同步。这同时也可以在保证功能多样化的同时降低了法律风险。

最后感谢 lyswhut 作者大大和所有落雪音乐开发者，是你们的无私奉献才让我们在享受音乐上除了使用互联网大厂开发的巨无霸之外还能有一个小巧、便捷、简洁的产品选择。

[xuetao8687]

感谢落雪！！！
提几个小建议。

1. 通过用客户端发送命令，让服务器从其他源（其他源可使用第三方插件方式集成）下载音乐到服务器指定的路径。
2. 音频流能不能使用压缩方式传输（主要是手机流量受不了）；
3. 多用户，个人音乐列表。

[bunai1996]

支持

[lyswhut]

会有模块化么

@JackMerryYoung 计划做一个类似扩展市场的东西

---

能把lx的歌单导过去吗

@gitbruc 不会直接支持，但应该可以提供一个单独的数据转换工具

---

既然已经提供web服务了，不如直接取消本地界面
还可以通过服务端提供的 API 连接服务端同步使用

@SeaRat

1. web 服务只是一个便捷的使用方式，但代价是有限的 API 调用，无法调用本地的系统API，所以独立客户端非常必要。
2. 可以使用同步服务将数据同步过去

---

通过用客户端发送命令，让服务器从其他源（其他源可使用第三方插件方式集成）下载音乐到服务器指定的路径。
音频流能不能使用压缩方式传输（主要是手机流量受不了）；
多用户，个人音乐列表。

@xuetao8687

1. web端的话，扩展将安装在服务器上，数据也都保存在服务器上，可以理解为将一个桌面端安装在服务器上，然后远程访问UI，只是一些与本地系统API相关的功能（全局快捷键、托盘等）无法使用
2. 指降低音质？这个涉及音频转换，前期暂不考虑，可能后再看有什么解决方案
3. 这个到时候看情况，应该会支持吧

[MaXiaofei2014]

感谢！
如果能提供歌曲的导入或者扫描功能就更好了。

[shenuadm]

可以出套教程学习一下吗，视频或文档都行

[gaphrodite]

真的很感谢！

[xinyu-yang]

大佬加油！

[Renjiangfeng]

一直在用，非常感谢。

[Forever-Cx]

会有鸿蒙版本吗

[timor-m]

感谢洛雪团队！ 之前fork lx桌面端项目，改造了一个公司内部的点歌平台，非常好用，再次感谢大佬们！

想问一下新项目计划啥时候开源出来呢？

[InoriHimea]

等于要提供一个服务端，用于传输存入的音乐，歌词等内容，通过流的方式输送给客户端咯
用过navidrome，就是显示歌词有点不好使

[tpu01yzx]

感谢洛雪提供的优秀项目，目前我是把洛雪当做纯粹的播放器使用，个人感觉良好。因为长期以来，基本很少用第三方的歌曲，所以如果做纯粹的本地播放器的话，我有几个建议：
1）支持解耦第三方源，通过第三方扩展插件的方式实现，这也是目前规避法律风险的常用方法。
2）引入人工智能的小模型（也可以考虑在线模式，就怕服务器有压力），实现智能提取音频文件的各种标签，例如智能识别歌曲，自动从服务器端提取歌曲标签信息，并把本地的标签推送到服务器端用于训练之用。这部分数据基本不会涉及个人隐私，我觉得提前告知之后自动推送应该问题不大。
3）对于私有源，可以用官方扩展插件的方式实现，仅支持需要账号密码登录的各种在线源（例如某人搞个需要账号密码登录的代理来访问公开的第三方源），例如WebDav，群晖，HTTP, HTTPS, SSH, Samba, Rsync等。
4）就如1）所言，解耦第三方源很重要，但如何间接维护一个非官方扩展插件，这个可能需要官方维护一个“非官方”插件列表，以便用户区分（查找）。

[Torstentjh]

新项目移动端看了一下应该还是用rn吧？想参与学习学习，或者把主体搭好，然后开源出来，然后后面各个功能之类的可以制定一些规范，交由想要参与的人来做，可以考虑这种方式吗🤔，且个人觉得这样也会节省作者的一些工作之余的时间🤪

[ameaninglessname]

希望能有个本地的歌曲推荐功能.

我现在找新歌就是随机听一些比较新的歌单,然后把喜欢的歌收藏起来.

像主流平台那种,智能推荐,会比较容易接触到新的歌.

这个功能可大可小.极致的话,像楼上说的有个本地化的AI,同步一些服务端的分析/分类数据,然后根据本地歌单分析,然后推荐类似的,或者可能喜欢的歌曲.

简单点的话,就是把歌单的检索功能拓展下,比如按时间,播放量排序啥的,
方便找到好听的歌单, 用户自己去探索,偏传统的方式.
(现在的歌单页面,可能是直接获取平台的数据,只有分类 + 最热,我平常就翻几页,随缘点个歌单,尝试发现新歌,也确实发现不少新歌了)

总之就是希望能有机会跟上新歌潮流啥的.

新歌->收藏->发现类似的新歌->收藏,从而不断丰富自己的曲库,接触到更多好的音乐,希望这个小循环可以在lx内部完成.
而不是现在我在某平台发现一首热歌,然后来lx搜索收藏,仅此而已了.

[ICEY1W32]

我目前个人私有云音乐是基于jellyfin，这是一个比较成熟的开源多媒体服务器方案，请问可否考虑支持一下这个平台作为音乐源，同时在此基础上提供歌词封面等元信息匹配的功能？

[VictorSu000]

感谢洛雪团队！有个小小的建议如下：

建议对web端的UI层和服务器做好充分的解耦，并且对非核心关键功能（如消息通知、拓展列表等）允许服务器返回空对象。主要目的是这样可以比较容易地对前后端的数据交互做拦截。

有这个想法是因为，我想弄一个无服务器的可以部署在 Github Pages 上的纯前端 LX Music。可以配合浏览器插件如TamperMonkey，写一个script，将前端的获取歌单、获取音乐文件URL等跨域请求，转给TamperMonkey发起。这样一个静态页面+浏览器插件就可以完成核心的歌单和听歌功能。

如果需要的话，这个做法我可以自行实现并开源，再次感谢洛雪团队！

[citydirector]

支持IPv6非常重要，这样可以简单地部署在家里，出门在外也能随时使用。

[anand-lyn]

自建解析服务 是不是可以加一层代理 避免音源的链接直接暴露给客户端 这样是不是可以减小封号的可能

[citydirector]

我还没遇到过封号的问题，但就目前来说，如果直接给客户端返回链接，企鹅的账号老是会掉，如果服务端先缓存再传输就不掉，怪怪的。 Anand ***@***.***> 于2024年6月19日周三 16:35写道：

…

自建解析服务 是不是可以加一层代理 避免音源的链接直接暴露给客户端 这样是不是可以减小封号的可能 — Reply to this email directly, view it on GitHub <#1912 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6OEE5PSQSKYRG5VOASW4DZIE7EPAVCNFSM6AAAAABIJRYLGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZYGA4TAOBQGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[anand-lyn]

我还没遇到过封号的问题，但就目前来说，如果直接给客户端返回链接，企鹅的账号老是会掉，如果服务端先缓存再传输就不掉，怪怪的。 Anand @.> 于2024年6月19日周三 16:35写道：
…
自建解析服务 是不是可以加一层代理 避免音源的链接直接暴露给客户端 这样是不是可以减小封号的可能 — Reply to this email directly, view it on GitHub <#1912 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK6OEE5PSQSKYRG5VOASW4DZIE7EPAVCNFSM6AAAAABIJRYLGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZYGA4TAOBQGI . You are receiving this because you are subscribed to this thread.Message ID: @.>

你用的那个服务搭的

[yz-qc]

webdav好评，这个功能会相当实用，同步起来其实也很快，加油

[dhrw444]

歌单导入功能用不了比较麻烦，几千首歌搜的话要命了，现在只能手动添加一点先听

[citydirector]

已经知道问题了。python会掉，刷新账号相关实现(已经失效)要重写。 Anand ***@***.***> 于2024年6月21日周五 13:06写道：

…

我还没遇到过封号的问题，但就目前来说，如果直接给客户端返回链接，企鹅的账号老是会掉，如果服务端先缓存再传输就不掉，怪怪的。 Anand *@*. *> 于2024年6月19日周三 16:35写道： … <#m_-8778632168497451773_> 自建解析服务 是不是可以加一层代理 避免音源的链接直接暴露给客户端 这样是不是可以减小封号的可能 — Reply to this email directly, view it on GitHub <#1912 (comment) <#1912 (comment)>>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AK6OEE5PSQSKYRG5VOASW4DZIE7EPAVCNFSM6AAAAABIJRYLGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZYGA4TAOBQGI <https://github.com/notifications/unsubscribe-auth/AK6OEE5PSQSKYRG5VOASW4DZIE7EPAVCNFSM6AAAAABIJRYLGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNZYGA4TAOBQGI> . You are receiving this because you are subscribed to this thread.Message ID: @.*> 你用的那个服务搭的 — Reply to this email directly, view it on GitHub <#1912 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AK6OEEZ2JN5GTNXYNVSKSQLZIOYFZAVCNFSM6AAAAABIJRYLGWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOBSGAYDQMRQGI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>