GoldenDict 和 Dictionary Universal 下 StarDict 词库单词或例句的音频发音研究 audio sound

探寻 StarDict 词库的发音问题很久, 前后历程有 8, 9 年了, 一直想做出一个与 MDict 一样功能的词库 (能否实现? 本文的最末会为您揭晓). 之前努力了 3-4 次, 但一直搞不定的是词库的发音问题, 本已打算放弃治疗了, 这次在 @ johannhuang 帖子的大力感召之下, 再次对这个问题进行了探究, 并最终在 johannhuang 的大力帮助下, 对 StarDict 词典对音频的处理方式有了大致的结论, 不敢私藏, 写出来与大家共享. 不知能否算是词典制作经验吧, 如果发帖的位置不对, 烦请版主帮忙移动, 但请保留这个帖子, 这对仍在使用或者将要使用 StarDict 词库的同学们估计会有一定的帮助…

首先说结论: StarDict 词库能否实现单词或例句的发音? 答案是: … 可以, 但不一定满足你的需求, 且实现方法并不简便

实现方式 (这里只提供大略的思路, 具体的步骤不做过多阐述):

  1. StarDict 词库源文件使用 xdxf 格式编写, 编译后 .ifo 文件中的 sametypesequence=x , 音频文件和图片放在 res 目录下, res目录与词典文件放在一起, res 目录在 GD (GoldenDict) 中不支持压缩为 zip, 但 DU (Dictionary Universal) 支持 res.zip
  2. 如果 StarDict 词库源文件采用 html 格式编写, 则发音文件的链接必须根据 GD 或 DU 的私有的发音协议改写, 类似在 MDict 词库里音频地址的 href=“sound://…” 写法, 只是类似, 实现起来并不简单…
  3. 对于 DU, 还有一种方式是由作者提供的: 将音频文件全部放入一个文件夹中, 但音频文件的文件名必须严格对应单词词头, 该文件夹支持 zip 压缩. 如果单词有多种发音, 则要放在不同的音频文件夹中, 具体的实现方法可以看 DU 的帮助文档.

以上不同方法的优劣:

  1. 对于第一种方法, xdxf 格式实际上是 xml 结构, 全套自有标签, 除非获得的原始资源就是这种结构, 否则从 html 转过去估计不太容易, 且样式固定, 不如 html 灵活, 想要做出漂亮的 StarDict 词库非常费劲, 想要如 MDict 词库一样各种花式跳转, 切换, 变化是不可能实现的, 但这种格式层级非常清晰, 感兴趣的同学可以自行研究
  2. 对于第二和第三种方法, StarDict 词库可以采用 html 格式来编写, 除了音频的发音处理与 MDict 词库不同之外, 其它的东西应该 (正在进一步尝试) 都能和 MDict 词库一样, 跳转, css 改变样式, js 代码处理页面都可以做到, 也就是说, MDict 词库的源文件只需要做很少的改动, 就可以完全转换为 StarDict 的词库.

为什么执着于 StarDict 词库?
这都要从词典软件说起, 话说 10 年前当我需要一部能离线使用的电子词典 (小语种) 时, 全网只有一个中国留学生做出了一部 dsl 格式的, 而那时, 苹果的 App Store 里支持这个格式的词典程序评分最高的的就是 Dictionary Universal 这个软件, 在经过越狱手机上的 免费 试用后果断买票上车, 但这个软件只支持 StarDict 词库和简单的 dsl 词库, 而 StarDict 软件在更久的以前因为工作需求就曾经接触过, 所以就开始了自己制作使用 StarDict 词库的道路, 跟之后的 MDict 大行其道可以说是完美的逆行…

再啰嗦几句关于 Dictionary Universal 这个软件
这个软件是我在苹果 App Store 里付费的第一个软件, 用了这么多年, iOS 系统从 3.x 升级到现在的 13.x, 10 个大版本, 作者一直在更新, 虽然不是很勤, 但每次 iOS 大版本升级后产生的问题都能修复, 可以说是相当的良心了, 多年前也曾因为软件更新后支持了 css 和 js 但不知如何使用而写过邮件给作者, 作者也回复并帮助我解决了疑惑. 其与其它 MDict 词库的软件使用感受上最大的不同是横向滑动切换不同的词库, 其它的功能: 自定义词库组, 生词收藏导出, 点击查询, 链接跳转…都差不太多.

好了, 写了 N 多的废话, 如果你坚持看到这里, 那么最终揭示答案的时候到了:

到底能不能做出与 MDict 词库显示效果和功能一样的 StarDict 词库?
可以! 但不同的词典软件方法不同, GD 下完全没有必要, 毕竟有那么多 MDict 资源; DU 之下, 我似乎应该是猜出了 DU 的私有音频协议的写法, 目前正在以 html 格式重新制作那本我用了快 10 年的小语种词库, 这次会把音频功能加入其中, 也终于可以了却一个执着了将近 10 年的心愿. 之后应该会挑选合适使用的 MDict 词库转化一波.

再次感谢坛友 johannhuang 在这次实践中的大力支持, 感谢你的代码支持和充满灵感的提示, 助我终于了此心愿, 感谢!

4 Likes

看了全文,以示尊重。我当下有一点疑问: 抛除软件方面,单从词库格式本身而言,楼主对stardict词库的执着源于:

  1. xdxf代码层级整洁美观,满足自己的审美
  2. 楼主对过往经历的缅怀,或者说过往经历带来对stardict的亲切感

如果普通用户没有类似的需求,仅关注词典内容本身,是否可以认为stardict格式相对于mdict格式并没有优势。

没有恶意,只是讨论。

客气客气!多多交流,共同进步。

这个问题,我也辅助回答一下吧。

xdxf的优点是没有html凌乱,所以对计算机程序特别友好,因此做词典的进一步加工衍生非常方便。如果性格相对于偏设计师更多一点工程师的话,喜欢xdxf胜过html是很好理解的。

我还是个人观点,StartDict相对于mdx+mdd有很多优点,mdx+mdd相对于StarDict没几点优点但有中国市场的优势。

  1. StarDict在软件支持方面,远远多于mdx+mdd
  2. StarDict词典格式官方开源,词典程序官方开源,名正言顺
  3. StarDict词库支持多种源语法,包括xdxf,html以及plain text
  4. StarDict的.info, .dict, .idx, .syn设计让词典格式就是词典格式,执行效率更高,源码更清晰,可扩展性更强(相比之下,其实mdx+mdd真的没什么设计,或者说就是简单,结果也导致凌乱而不便于做数据进一步运用)
  5. StarDict是人使用的词典格式,mdx+mdd是计算机使用的词典(key-value)格式

对于StarDict与mdx+mdd的选择,看如何定义“普通用户”。如果只是单纯的拿来主义的使用用户,资源数量决定喜好;如果更多词典数据希望能够拿来运用(词典辅助学习,有快速定位等需求;源码处理及衍生层面),那么好好对待StarDict后,你会发现,mdx+mdd真的限制了你对一本人用的词典应该是怎样的的视野。相关一帖 J̥H́-交流 - Apple Dictionary特征收集与整理

1 Like

十分清晰明了,多谢答疑解惑!

已经有人根据这个思路搞出 Android 手机上的 GD 让 StarDict html 格式的词库发音了, 不过应该不是最简单的办法, 直接在源文件里处理音频路径或者再加上点 js 辅助应该可以更简化.

https://www.pdawiki.com/forum/thread-40344-1-1.html

但是这种针对某个平台某个软件所做的具体的针对性的修改, 这样做出来的词库没有啥兼容性, 甚至可能手机上能用, 同一软件的电脑版却不能用或者功能受限都是很有可能的.

这也是我和 johannhuang 搞出来之后并没有发布具体步骤的原因: 一个是我们只做了电脑上 GD 的测试, 搞清楚原理之后觉得绕很大的弯路非要达到一个很具体的功能, 而且用了些看着就很丑的方法和路子, 都觉得不是我们本来想要的东西; 二是没有测试更多的软件, 连手机端的 GD 都没测试 (没设备), 所以也就没啥可拿得出手的.

再之后, 由于本人对 Dictionary Universal 这个 App 的执着, 进一步针对该软件测试之后, 猜出了 DU 的私有音频协议的写法, 测试用的两个单词的 HTML 格式的 StarDict 词库在 DU 下显示和功能效果与 MDict 下无异, 准备做两个完整的词库试试, 但终归这些词库只能在 DU 下正常工作, 拿到 GD 上, 音频功能必然失效, 其它功能应该还能保持.

2 Likes