Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
lyswhut opened this issue May 26, 2024 · 52 comments
Open

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

lyswhut opened this issue May 26, 2024 · 52 comments

Comments

@lyswhut
Copy link
Owner

lyswhut commented May 26, 2024

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

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

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

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

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

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

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

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

里程碑2

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

里程碑3

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

里程碑4

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


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

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

@lyswhut lyswhut pinned this issue May 26, 2024
@lyswhut lyswhut changed the title LX Music 项目发展调整与新项目启动计划 LX Music 项目发展调整与新项目计划 May 26, 2024
@3gf8jv4dv
Copy link
Contributor

Will new projects use Electron or other software frameworks?

@lyswhut
Copy link
Owner Author

lyswhut commented May 26, 2024

Will new projects use Electron or other software frameworks?

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

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

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

@Gimmick13
Copy link

谢谢 你们洛雪团队

@Zeuyel
Copy link

Zeuyel commented Jun 1, 2024

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

@lyswhut
Copy link
Owner Author

lyswhut commented Jun 1, 2024

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

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

@subframe7536
Copy link

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

@lvzhenbo
Copy link

lvzhenbo commented Jun 1, 2024

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
Copy link
Owner Author

lyswhut commented Jun 1, 2024

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

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

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

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

@daihanpi
Copy link

daihanpi commented Jun 1, 2024

考虑有下载歌曲功能吗?

@JackMerryYoung
Copy link

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

@gitbruc
Copy link

gitbruc commented Jun 2, 2024

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

@shiyihang2007

This comment was marked as off-topic.

@SeaRat
Copy link

SeaRat commented Jun 2, 2024

提几个小建议

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

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

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

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

@xuetao8687
Copy link

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

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

@bunai1996
Copy link

支持

@lyswhut
Copy link
Owner Author

lyswhut commented Jun 3, 2024

会有模块化么

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


能把lx的歌单导过去吗

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


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

@SeaRat

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

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

@xuetao8687

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

@MaXiaofei2014
Copy link

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

@shenuadm
Copy link

shenuadm commented Jun 3, 2024

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

@gaphrodite
Copy link

真的很感谢!

@Star710355635

This comment was marked as off-topic.

@xinyu-yang
Copy link

大佬加油!

@Renjiangfeng
Copy link

一直在用,非常感谢。

@Forever-Cx
Copy link

会有鸿蒙版本吗

@timor-m
Copy link

timor-m commented Jun 5, 2024

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

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

@InoriHimea
Copy link

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

@tpu01yzx
Copy link

tpu01yzx commented Jun 7, 2024

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

@Torstentjh
Copy link

Torstentjh commented Jun 8, 2024

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

@ameaninglessname
Copy link

ameaninglessname commented Jun 8, 2024

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

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

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

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

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

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

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

@ICEY1W32
Copy link

ICEY1W32 commented Jun 9, 2024

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

@VictorSu000
Copy link

感谢洛雪团队!有个小小的建议如下:

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

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

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

@citydirector
Copy link

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

@anand-lyn
Copy link

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

@citydirector
Copy link

citydirector commented Jun 21, 2024 via email

@anand-lyn
Copy link

我还没遇到过封号的问题,但就目前来说,如果直接给客户端返回链接,企鹅的账号老是会掉,如果服务端先缓存再传输就不掉,怪怪的。 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
Copy link

yz-qc commented Jun 23, 2024

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

@dhrw444
Copy link

dhrw444 commented Jun 24, 2024

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

@citydirector
Copy link

citydirector commented Jun 26, 2024 via email

@NINGlingL
Copy link

加油

@ElementBridge
Copy link

感觉有点像椒盐音乐的云端WebDAV产品,青盐云听一样的实现,但是这俩个的动画效果都要比lx要好,可以考虑参考这个嘛。
椒盐音乐

@jw20082009
Copy link

新项目还开源吗

@Cymbalsm

This comment was marked as duplicate.

@Duo-DD
Copy link

Duo-DD commented Jul 12, 2024

大佬,NEXT会适配吗?有本地播放功能就行

@Duo-DD
Copy link

Duo-DD commented Jul 13, 2024 via email

@1239675905
Copy link

建议歌名和歌手同样但不同歌曲的歌也可以一起下载下来,自动备注另一个

@ColoMovo
Copy link

ColoMovo commented Aug 9, 2024

加油大佬!用落雪用了很久了!也期待你们的新作品哦~
你们的开发计划想法非常不错,用LX用了一个学年了,我个人用,班上听歌也用的LX,也给同学推荐了,我们选择落雪是因为其实用性以及其强大的下载能力,也感谢你们做出了如此优秀的项目,这里提出我们班里同学的一些反馈:
1:性能优化(为什么单单一个LX就要吞掉整整1个G的运存)
2:界面美化(可以尝试半拟物化,参考酷狗概念版)
3:MV!!!
我仅仅只是一个初中生,也确实不是专业的(我主要是python),但我希望落雪会越做越好!加油!

@Nova648
Copy link

Nova648 commented Aug 13, 2024

请问下会提供歌曲下载的支持吗
比如我用作服务器的主机上有一万首歌曲,其中100首收藏了,怎么把这100首下载到手机里
有直接的方式最好,如果不方便的话,是否能够提供将添加到歌单/收藏的歌曲复制到某个路径,这样可以通过微力同步或类似的软件来实现同步,也很方便
感谢

@roccox
Copy link

roccox commented Aug 15, 2024

会适配Navidrome吗?谢谢

@k631583871
Copy link

我尝试近期使用 自定义源脚本 实现一个 歌曲管理服务 (还没有开源).
尝试使用发现还是很好用的.
大佬有没有想法发放更多的 API , 例如: 注册新的歌曲来源对象,并且开放歌曲查询 API 供其他开发者使用.
其他开发者就可以开发 歌曲管理服务 或者 适配其他的 已存在的歌曲管理服务

@lyswhut
Copy link
Owner Author

lyswhut commented Aug 24, 2024

会有鸿蒙版本吗

@Forever-Cx 涉及 Java 层代码,如果兼容安卓应用的话那就可以,不然暂无计划

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

@timor-m 应该会在发布 beta 版本的阶段开源

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

@ICEY1W32 计划允许扩展除了提供音乐来源,还提供操作收藏列表及控制播放器的能力,所以按理说都可以实现

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

@VictorSu000 现在的设计就是这样的,UI层不包含与服务端的通信方式,所有通信都会通过特定服务端提供的preload层与其通信,大概的通信方式是:

  | --- Electron preload - Electron
UI层
  | ---    Web preload   - Web 服务端

各preload层将提供相同的方法名供UI层调用

请问下会提供歌曲下载的支持吗

@Nova648 可以实现,但可能不是在初版

有没有想法发放更多的 API , 例如: 注册新的歌曲来源对象,并且开放歌曲查询 API 供其他开发者使用.
其他开发者就可以开发 歌曲管理服务 或者 适配其他的 已存在的歌曲管理服务

@k631583871 之前旧版在开发这个功能的时候确实是有这个想法,事实上这种API调用方式就是给这种场景预留的,但现在没有更多时间去继续完善,而是将时间用在新项目上

@15941127712ly
Copy link

请问以后会支持第三方音乐平台账号登录吗,如果可行的话,就可以用自己的账号收听VIP歌曲了

@timor-m
Copy link

timor-m commented Aug 28, 2024

请问以后会支持第三方音乐平台账号登录吗,如果可行的话,就可以用自己的账号收听VIP歌曲了

参考一下 https://github.com/Binaryify/NeteaseCloudMusicApi 关闭的原因,我就是自己fork 这两个项目实现了网易云账号登录

@KelseySking
Copy link

大佬会支持Navidrome音乐流媒体的api吗

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests