Daoxi Sun

Hi @m-i-n-a-r, since you mentioned "translation/library update", would you be able to include the [recently opened pull request that brings Traditional Chinese (zh-rTW) translation to 100%](https://github.com/m-i-n-a-r/birday/pull/286) in that update?

> > > > js脚本可能需要修一修了，或者说是增加一个功能。 一张专辑的封面：[压缩后的图片](https://is1-ssl.mzstatic.com/image/thumb/Music112/v4/81/0f/63/810f63df-9d75-0f49-81e0-5221ed11c83a/302910022.jpg/592x592bb.webp) https://is1-ssl.mzstatic.com/image/thumb/Music112/v4/81/0f/63/810f63df-9d75-0f49-81e0-5221ed11c83a/302910022.jpg/592x592bb.webp 上面这个图片可以正常访问，使用您的js脚本获取原图链接为：[原始图片](https://a1.mzstatic.com/us/r1000/0/Music112/v4/81/0f/63/810f63df-9d75-0f49-81e0-5221ed11c83a/302910022.jpg) https://a1.mzstatic.com/us/r1000/0/Music112/v4/81/0f/63/810f63df-9d75-0f49-81e0-5221ed11c83a/302910022.jpg > > 但是获取到的原始图片链接并不能访问，然而把url开头位置的a1改为2~5的任意一个，却可以访问。所以，能不能给js脚本增加一个1或5随机的功能，可以让与原始对应的数字出现的概率大一些。 抱歉才看到，之前忙工作所以有段时间没上Github看了。 关于 > “但是获取到的原始图片链接并不能访问” 这可能是国内网络线路问题或苹果服务器暂时出了问题，因为我现在访问你提供的原图链接并未遇到任何问题。你如果在国内的话可以换个VPN线路试试。 关于 > “能不能给js脚本增加一个1或5随机的功能，可以让与原始对应的数字出现的概率大一些。” 实际上现在的脚本已经对应数字了，你压缩后图片链接里的数字是1（“is1-ssl”），原图链接里的数字（“a1”）也是1。 顺带一提，建议以后关于该脚本的提问或建议直接在[那个repo](https://github.com/daoxi/itunes-image-link-converter)下的[Issues](https://github.com/daoxi/itunes-image-link-converter/issues)里提，这样既方便我管理，也方便以后万一有其他用户能看到。 这个Issue感觉如果@jitwxs不打算添加新回复的话，可以关闭了。

First of all, thanks a lot for the detailed explanation for the reasoning behind this. > Let's say for example that your new car has rubbish sound system software (I...

Thanks a lot for making the change

可以参考[这个Issue](https://github.com/jitwxs/163MusicLyrics/issues/171)内2楼的讨论内容

巧了，我也使用类似的方法来保证原文+译文的歌词能在任何播放器中都正常显示（注意译文歌词永远不会高亮，而是在显示原文歌词时顺带显示），但我的格式跟你稍有不同，我不但“_将译文歌词的时间戳改为下一句原文歌词的时间戳_”，在此之上还**对这句译文歌词的时间戳减去最小时间单位**，比如： [00:01.50]第1句歌词原文 [00:02.49]第1句歌词译文 [00:02.50]第2句歌词原文 [00:03.49]第2句歌词译文 [00:03.50]第3句歌词原文 (第3句歌词译文的时间戳 = 第4句歌词原文的时间戳 - 最小时间单位) ...... 之所以要“_减去最小时间单位_”，是因为理论上[LRC格式](https://zh.wikipedia.org/wiki/LRC%E6%A0%BC%E5%BC%8F)并不支持时间戳完全相同的多行歌词（因为理论上每次仅高亮一行歌词，绝大多数播放器都是这样），故播放器在遇到这种情况时的处理方法也**各不相同**（比如有的可能仅显示Unicode编号最靠前的那一行），所以“_减去最小时间单位_”这步**可以保证歌词绝对在自己想要的顺序被显示**。 \ \ \ 顺便说下我是如何用Notepad++转换成以上所述格式的： 1. 首先你要有一份原文歌词，一份译文歌词，并且保证这两份歌词的有效歌词部分（不包含如歌曲名，歌手名等信息的那些“非歌词”内容）能逐行对应（两者的时间戳有细微差别也没关系，因为我们可统一使用原文歌词的时间戳以规避此问题），并且原文歌词的最后一句歌词需是空白歌词 2. 复制原文歌词的时间戳部分（不含歌词本身），并将这些时间戳减去最小时间单位(我用的是[LyricEditor](https://github.com/BYJRK/LyricEditor))，之后将译文歌词粘贴到这些时间戳的下移一行后的位置 3. （非必要）按时间戳进行排序（Notepad++的某排序功能可以实现），类似于变成app里的“合并”格式 \ \ \ 不知道作者能否考虑在app中添加自动生成以上格式的功能？(算是个**兼容性要好很多**的“_合并_”歌词格式，**在几乎任何播放器里(包含传统的竖向滚动模式和题主说的卡拉OK模式)都能正常显示**) 实现该功能时可能遇到的歌词例外(exception)： - 原文/译文歌词的时间戳有误差：使用已有的“译文匹配精度”解决...

> 这确实是一个很棒的解决方案，可惜navidrome不支持多行（好气 如果只使用本地播放，那么手机和电脑的歌单似乎没有很好的办法同步吧 上面这个格式的最大好处是，哪怕播放器不支持同时显示多行歌词（其实大多数都不支持...），只要能在显示当前歌词的时候能看到下一行歌词是什么就行（常见的滚动歌词应该是可以的），如果navidrome是只能看到一行歌词的话那确实是没办法了 同步要手动弄这个确实是本地播放的痛点（对于更新音乐库不频繁的我影响不大），Plex（我没用过但之前见很多人推荐）应该类似于navidrome，就是不知道对同步歌词的支持如何

> 了解了 我去看看 😊 根据[Plex官网关于本地歌词的介绍](https://support.plex.tv/articles/215916117-adding-local-lyrics/)，其支持外挂的.lrc同步歌词（“_The following formats are supported for external/sidecar lyric files: LRC (.lrc) – timed lyric file using the LRC format_”），但很遗憾的是目前不支持内嵌歌词（"_Note: Lyrics embedded in track metadata (such as...

> 我已经部署了Emby，目前看来是没有问题的。只不过它的歌词功能需要开会员，或者自行选择开心版。看起来还是比较好用的。 image 之后打算给我的工具加上你上面描述的功能，以便让Emby支持多语歌词~ 所以你是说Emby也没法同时显示双行时间戳相同的歌词，对吗？那样的话，2楼提到的格式应该确实能解决此问题。 顺带问一下，你用的Emby支持的是内嵌歌词AND/OR外挂歌词？如果支持内嵌歌词的话，用[之前跟你说的方法](https://github.com/jitwxs/163MusicLyrics/issues/167)内嵌歌词后的MP3文件能在Emby中正常滚动同步歌词吗？

“歌曲名的最后一个字为点时网易云不会输出该点而该软件会” ：说实话这反而听起来像是网易云的问题，因为哪怕字符串的最后一位是点，**也没有理由不输出完整的曲名/艺术家名**（涉及到不允许的特殊字符时除外）... 我感觉这个app的设计逻辑是导出任何平台的歌词给任何地方下载的歌曲来使用，而并非仅限于某平台的歌词只给同一平台下载的歌曲用（当然，这也要看app作者本人的想法了）。匹配不了的话可以考虑手动复制下整个文件名也很快的（善用F2重命名和复制粘贴快捷键）。 还有据我所知，Windows环境下的文件名并不允许标准斜杠“/”，所以上面的斜杠实际上其实都不是标准的，不允许的字符我个人都用下划线“_”代替（只是自己的方案，仅作参考）