记一次墨迹天气的音频提取
之前就想在音乐闹钟上加上定时天气预报, 说到底, 我懒. 每天定时播报也是极好的. 看上墨迹天气的语音预报, 然后想想如果提取出接口后做成一个api, 立马行动, 只不过..没想到比我想象的简单得多.
(English version translate by GPT-3.5)
说在最前
这个只是记录下折腾的过程, 不能保证接口能维持多久, 也不能保证这个方法能有效多久, 所以在看之前先注意下文章发布日期.
先上Charles进行抓包
二话不说直接Charles抓包看下, 在iPad上配置好后, 打开墨迹天气, 然后点击语音播报, Charles显示如下的信息
去掉无用的请求后, 如下
我去, 这太容易了吧, 需要的东西一目了然…竟然还是http接口…
再试听下音频
这些mp3内容如下
file | content |
---|---|
good_afternoon_zh_1.mp3 | 下午好 |
bg_rainy_heavy.mp3 | 带雷声的背景音乐 |
day2night_zh_1.mp3 | 今天白天到夜间 |
23_zh_1.mp3 | 二十三 |
temperature_zh_1.mp3 | 温度 |
today_zh_1.mp3 | 今天 |
完整的语音应该是:
1 | 下午好, 墨迹天气为您播报, 杭州, 今天白天到夜间, 大雨转小雨, 温度 20-23摄氏度, 东风3-4级, 今天不限行 |
原来墨迹天气用的是分段音频, 其中很多音频合并播放, bg_rainy作为背景音乐, 因为api极少, 直接看最有价值的http://v1.weather.moji.com/weather/pb/detail
最后得到音频
detail的内容如图所示, 看到重要的内容了
但是人家的黑色的乱码是啥情况, 我还是没有弄出来…但是中间的mp3, 格外醒目, 可以看到基本上要的东西都在了, 听一遍, 这些内容是:
fileName | content |
---|---|
bg_rainy_heavy.mp3 | 带雨声的音乐 |
bg_end.mp3 | 音乐的结尾部分 |
blank_new.mp3 | 空白2秒 |
{bless}_zh_1.mp3 | 下午好, bless被good_morning, afternoon,evening替换 |
now_is_zh_1.mp3 | 现在是 |
{time}# | 未知 |
hello_moji_zh_1.mp3 | 墨迹天气为您播报 |
city_143_zh_2.mp3 | 杭州 |
day2night_zh_1.mp3 | 今天白天到夜间 |
heavy_rain_zh_1.mp3 | 大雨 |
transfer_zh_1.mp3 | 转 |
light_rain_zh_1.mp3 | 小雨 |
temperature_zh_1.mp3 | 温度 |
20_zh_1.mp3 | 二十 |
to_zh_1.mp3 | 到 |
23_zh_1.mp3 | 二十三 |
centigrade_zh_1.mp3 | 摄氏度 |
e_zh_1.mp3 | 东风 |
3_zh_1.mp3 | 三 |
to_zh_1.mp3 | 到 |
4_zh_1.mp3 | 四 |
level_zh_1.mp3 | 级 |
today_zh_1.mp3 | 今天 |
no_limit_zh_1.mp3 | 不限行 |
完美了, 剩下就是搞定这个detail就行了, 直接说结论吧…其实…里面的token和identifier压根没用的…直接去掉就能请求到…
1 | 最后请求结果: |
我想法是通过匹配或截取, 然后得到要下载的列表, 下载这些文件到本地, 然后调用ffmpeg -i “concat:xxxx”的方式合并成单个文件, 然后混合背景音乐, 最后输出最终文件.
最后的效果是
结尾
其实我压根没想到会那么快, 很轻松就做好了, 希望这个接口能抗久一点吧, 我要把它放到到我的每日天气预报了, 每天上午上班前播放一次.
备份下曾经下载过来的所有音频文件
其中city开头的是一堆地名,基本上包含了几乎所有的音频了,哪怕做一个自用的语音播报都不在话下,但是这个应该是有版权的,自己研究学习,别用做商业应该没啥问题。