MusicPlayer2 icon indicating copy to clipboard operation
MusicPlayer2 copied to clipboard

无法正确分割名称包含“/”的艺术家和专辑名

Open rinscr3003 opened this issue 2 years ago • 9 comments

有一个艺术家名称为“22/7”,在自动拆分艺术家时出现了这样的故障: image 能否设置白名单以对特定的艺术家名称中的“/”不拆分?

rinscr3003 avatar Aug 05 '22 08:08 rinscr3003

image 文件例

rinscr3003 avatar Aug 05 '22 08:08 rinscr3003

在程序本身不做出改变的前提下,建议阁下使用如下替代解决方案: 使用Unicode符号\u2571(制表正斜杠), 即 "╱" , 代替 "/" 使用Unicode符号\u2044(分数正斜杠), 即 " ⁄ " , 代替 “/” 使用Unicode符号\u2215(除法正斜杠), 即 " ∕ " , 代替 "/"

SheepChef avatar Aug 09 '22 07:08 SheepChef

确实存在这个问题,不过有一点让我疑惑的是,网易云音乐下载的歌曲含有多个艺术家时,多个艺术家是使用“/”分隔的,资源管理器能够正确识别成多个艺术家: image image 但是为什么对于“22/7”,资源管理器就认为是一个艺术家呢?

zhongyang219 avatar Aug 10 '22 12:08 zhongyang219

是flac的原因,windows资源管理器无法(不会)分割flac的多艺术家

~更新:可能是要设置flac多艺术家应当使用分号分割而不是"/"~

我的想法是把一首歌的艺术家作为一个整体出现在媒体库艺术家列表不进行主动拆分 但是如过其中的一个艺术家也有单曲则也把这首多艺术家的也添加进去

例如22/7不会主动分割为22和7,但是如果存在其他艺术家为22的歌曲则 左侧列表里有 22;22/7 且都含有这首歌

lrisora avatar Aug 10 '22 12:08 lrisora

在程序本身不做出改变的前提下,建议阁下使用如下替代解决方案: 使用Unicode符号\u2571(制表正斜杠), 即 "╱" , 代替 "/" 使用Unicode符号\u2044(分数正斜杠), 即 " ⁄ " , 代替 “/” 使用Unicode符号\u2215(除法正斜杠), 即 " ∕ " , 代替 "/"

由于我的个人音乐库全部使用这一份副本,而且购买的数字正版也是以“/”(半角ASCII斜杠)进行分割。贸然更改这个斜杠不仅不利于美观,也可能引起不可确定的问题。

rinscr3003 avatar Aug 14 '22 16:08 rinscr3003

是flac的原因,windows资源管理器无法(不会)分割flac的多艺术家

~更新:可能是要设置flac多艺术家应当使用分号分割而不是"/"~

我的想法是把一首歌的艺术家作为一个整体出现在媒体库艺术家列表不进行主动拆分 但是如过其中的一个艺术家也有单曲则也把这首多艺术家的也添加进去

例如22/7不会主动分割为22和7,但是如果存在其他艺术家为22的歌曲则 左侧列表里有 22;22/7 且都含有这首歌

这显然是一个针对特例的做法,实际上并不存在22和22/7的歌曲存在关联的可能性。又或者说,如果曲库出现了一首歌的艺术家字符串是NMB46/22/7,又各自有22/7NMB46/AKB48这样的艺术家字符串,程序会产生怎样的结果?(本处不作任何关于这三个团的推测和期望,仅仅是用于举例) 并且不如添加白名单(PowerAmp的做法,默认添加了“AC/DC”和“+/-”)简单。
但是如果近期的迭代中能够修复该问题,我很乐意看到PotPlayer的继任者出现在我的电脑上。期待作者的更新!

rinscr3003 avatar Aug 14 '22 16:08 rinscr3003

关于举例,按我上述做法程序会正常工作,这个方案代价是 可能会有识别不出的(会和其他艺术家组合出现),不会有不存在的 就是说假设真的同时存在“22/7”与“22”并不会导致“7”单独出现

关于白名单,由于没有用过不太清楚,这里说的是一个程序全局的字符串列表吗? 如果是的话,这也是一个针对特例的处理,是在赌下述情况不会出现 比如对“22/7”设置不拆分并且真的存在艺术家“22”与“7”就会出问题,只是可能性很低

我觉得全局白名单的方案更好一些

lrisora avatar Aug 14 '22 17:08 lrisora

关于举例,按我上述做法程序会正常工作,这个方案代价是 可能会有识别不出的(会和其他艺术家组合出现),不会有不存在的 就是说假设真的同时存在“22/7”与“22”并不会导致“7”单独出现

关于白名单,由于没有用过不太清楚,这里说的是一个程序全局的字符串列表吗? 如果是的话,这也是一个针对特例的处理,是在赌下述情况不会出现 比如对“22/7”设置不拆分并且真的存在艺术家“22”与“7”就会出问题,只是可能性很低

我觉得全局白名单的方案更好一些

你这么说的话,我仔细想了下,确实都有各自的弊端。不过如果自动识别的那个方案是可行的话,用户应该会很乐于接受不需要自己动手设置白名单的体验。(大概代价是写算法费点脑细胞+扫描慢一点?)
目前能想到的就是出现假设某人下载的歌曲全都是NMB46/AKB48这样的字符串的话,会看见有一个NMB46/AKB48,并且找不到AKB48这个艺术家,可能会懵逼,而意识不到这是没有自动拆分。~~不过厨到只听联合演唱的用户可能要么以为是常年联合演唱要么就是死忠粉吧~~
~~肥秋也真是的,公式文件居然用的都是ASCII的半角斜杠,直接坑死一片。~~
~~包括我的自动根据metainfo重命名文件都翻车了(“./22/7 - 理解者.flac”,中间那个斜杠被认为是路径了)~~


期待尽快添加这个feature

rinscr3003 avatar Aug 15 '22 14:08 rinscr3003

路过,考虑到“AC/DC”是个著名乐队,那么其它播放器是如何正确处理的?已知PowerAmp的做法。

TaicEart avatar Oct 01 '22 01:10 TaicEart

咕了一年的更新 我这里出问题的艺术家如下 "AC/DC","+/-","22/7","ave;new","ハロー、ハッピーワールド!","リリィ、さよなら。","MYTH & ROID","Meghan & Lucas" 实际上使用‘/’,‘;’,‘&’以及‘、’4个字符分割

lrisora avatar Aug 17 '23 07:08 lrisora