lrisora

> 来个例子：foobar2000 EsLyric扩展的逐字歌词，扩展名就是.lrc 格式是一行一个歌词，然后每行每个字前面一个时间标签。 需要足量歌词文件作为参考，没有文档的的格式需要从文件总结语法 比如方括号时间标签与之后紧邻的尖括号时间标签是否一定相同 若不相同如何显示/以哪个为准，也不清楚尖括号时间标签内容是相对时间还是绝对时间

能发文件吗，7z或者zip，尽量多 issue可以发文件 我理解成了[这个](https://zh.wikipedia.org/wiki/LRC%E6%A0%BC%E5%BC%8F#%E5%A2%9E%E5%BC%BA%E6%A0%BC%E5%BC%8F)

扩展lrc已添加，需要测试（特别是有没有对原有歌词支持的负面影响） 已明确歌词闪烁仅发生在逐字歌词，目前未知原因 [这里下载](https://github.com/zhongyang219/MusicPlayer2/actions/runs/2434015558)

毕竟用的绘制技术GDI/GDI+诞生在连"帧"的概念都没有的年代，cpu消耗大可以理解 换DX/OpenGL的工作量太大，短时间不太可能 用我这1.1GHz的cpu 程序最小化到托盘后cpu消耗0.6% 桌面歌词打开就+5% 主界面+15%

我个人认为随机播放没有必要避免连续播放同一首歌 这样会失去其随机性，对于不想连续播放同一首歌的人应当使用无序播放 如果随机播放不随机那么和无序播放就没有任何区别了 下一首播放应该是可以设置多首的，在切换播放列表时复位（`void CPlayer::IniPlaylistComplate()`后面几行） 使用vector并以size等于0判断是否为原来播放模式 我原来的想法是在CPlayer::PlayTrack中的switch语句前塞一段处理下一曲播放，并跳过switch语句 我当时没有考虑同时维护无序列表的问题，按照无序播放定义这里应当处理（只是会大幅提升复杂度） 手动播放时清空下一首播放， 我没有想好的是下一曲播放的vector是先进先出还是后进先出，是队列还是栈 以及要不要去重(是否允许重复添加同一首歌)

网易云UWP实际播放的不是歌单，而是右下角的播放列表 这个播放列表全局单例，可以办到诸如“设定另一个歌单中的一首歌下一曲播放”之类的操作 平时播放歌单时程序实际的操作是“将歌单前999首加入播放列表并播放播放列表” 网易云的循环模式实现及下一曲播放都直接依赖这个播放列表结构（而不是歌单） MusicPlayer2使用的是另一套结构，播放的就是看到的播放列表 循环模式的设计实现也不同，没必要实现和网易云同样的逻辑 我原来的构想是设置一次下一曲播放就push_back一首， 在CPlayer::PlayTrack的switch前判断有下一曲播放就拿出一曲播放并跳过switch（单曲播放时不进行） 不过没打算维护无序播放列表（这个有点复杂但是是可以实现的） 也就是设置下一曲播放就会忽略除单曲播放外的循环模式进行指定下一曲 按照这个设计添加下一曲播放最大的坑是播放列表重新排序后存储的index就会失效 （可以通过存储SongInfo或key（在另一个pr）解决）

> 这个我比较喜欢PowerAMP的处理方式。 PowerAMP 是直接存一个单独的列表，专门就是存放下一首播放的列表。 如果列表放完了，下次加的时候清零再push_back，它存的应该是位置，所以换播放列表是不会影响下一首播放的。 以目前的设计，MusicPlayer2是没办法播放CPlayer::m_playlist之外的歌曲的 我没有用过，不过按照这个描述这样做类似网易云音乐UWP的实现 我认为这样做最大的问题是当前播放列表无法确定（或者说是动态生成的），这样的结构无法实现随机播放，只能是无序播放 现在这样的基于明确的播放列表的实现也很好用 只要加一个vector垫在CPlayer::PlayTrack前来实现下一曲播放就好

我没有理解，是如何做到跨播放列表维持下一曲播放的 MusicPlayer2是没办法播放CPlayer::m_playlist之外的歌曲这一点是难以更改的，比换媒体库的键要难得多 我设想的存储下一曲播放的vector会在设置下一曲播放时size+1 播放下一曲时size-1直到size==0（即播放会消耗其中存储），等于size等于0后恢复正常循环模式

> > 我没有理解，是如何做到跨播放列表维持下一曲播放的 MusicPlayer2是没办法播放CPlayer::m_playlist之外的歌曲这一点是难以更改的，比换媒体库的键要难得多 我设想的存储下一曲播放的vector会在设置下一曲播放时size+1 播放下一曲时size-1直到size==0（即播放会消耗其中存储），等于size等于0后恢复正常循环模式 > > 那不妨换个想法，存到同一个vector，然后设置个变量来区分当前列表和下一首播放列表（ 这种级别的播放列表对用户不可见我觉得是不可接受的，网易云的那个虽然烂不过至少如实告诉用户就添加了999首 这样做把背后的逻辑隐藏起来对用户来说实在难以理解， 现在MusicPlayer2的播放列表用网易云举例就是兼具“歌单”和“播放列表”两个功能 这个功能的添加用下一曲列表不合适，其实就是字面意义的“播放列表”， 就像是把现在的播放列表改为歌单，之后又加了一个“真播放列表”

暂时先用我那个下一曲播放方案吧 这个加“真·播放列表”的方案落实的话MusicPlayer2可以升大版本号了 这里会涉及的代码从初版就没变过，许多功能都在其基础上实现 UI也需要不小的改变