掌上百科 - PDAWIKI

 找回密码
 免费注册

QQ登录

只需一步,快速开始

查看: 3948|回复: 9

[讨论] spx和mp3的一点粗粗浅看法

[复制链接]

该用户从未签到

发表于 2016-7-21 01:56:55 | 显示全部楼层 |阅读模式
本帖最后由 idict 于 2016-10-16 12:33 编辑 , d4 l  Z; E6 o" R! `% i7 X
+ h' r( ]1 @$ ]; A; G: M/ }; s, X
对声音文件wav的有损压缩的算法和容器/格式有很多很多... 其中最早最有名的是mp3, 后来有ogg, aac等等, 到现在的opus. mp3的优势是广泛普及, 容易编辑(用dos的copy/b命令就可以合并了). 94年已经有编码器了, 98年在lame和winamp的相助下, 迅速普及. 缺点是有专利(但后来个人使用免费). 编码质量和压缩比于今天来说已经不算好, 特别是低码率(小于64kbps)质量损失比较大. ogg是其中一个很好的编码容器. 无论高中低编码率和压缩比都比mp3要好. 而且免费开源. 缺点不容易编辑. 编辑后要重新编码. aac与ogg质量和压缩比相当, 优点是支持多音轨. 所以电影里的音频多是aac的, 可以容纳中文和英文等等多国音频一起打包. 缺点是需要授权. 现在的opus, 采用高编码率使用CELT, 低编码率用SILK, 中编码率取用无逢的混合编码(即SILK + CELT. [这是什么东东, 我不知道. 只是照抄的]). 所以全频顾及. 也支持多音轨. 而且开源免费. 现在在YouTube已经有看到踪迹了.
0 Z/ r& r8 \$ x' ?0 H- \0 O4 Y$ I  i( _# r6 \4 K/ j7 E# |
附opus主要开发者: Jean-Marc Valin% @  w, J6 b& z: X4 l8 U+ s
https://jmvalin.ca/) |  m0 o0 l" a
https://commons.wikimedia.org/wiki/Opus_(audio_codec)
. u  E. _: P" x! d1 T( \# b1 Z$ \8 E0 t) h
题外话: 当初压缩CD时, 有比较过mp3和ogg, 最终使用ogg. mp3最少需要是192kbps(128kbps的话有较大差别), ogg就128kbps可以了. 如果ogg用192kbps, 质量要好. 文件大小与mp3相同码率相当. (现在不折腾了opus)( M# u8 G' h& A& K, x
3 \- t7 n3 ^% J9 \9 d) S
人耳可以听到的声音范围20 - 20kHz. 但音乐与语音的频率范围是有区别的. mp3会将16kHz以上的音乐信息削掉. 虽然说可以至20kHz. 但很多人都未必听得出有什么区别的. 语音的话, 只需要200Hz - 5kHz就满足人耳的要求了.
) ]5 o/ m" ~4 \0 v7 S2 Lhttps://zh.wikipedia.org/wiki/%E8%81%BD%E9%96%BE8 p( j; B- R/ G! `' a, n6 @( v
$ c" W5 G4 W$ A$ E, m: t
1 k1 t4 g* Z. _/ b
至于对语音的优化压缩, 也有很多. 没有什么了解. 最初看到录音文件有amr, 不知道是什么. 现在在了解mdx过程接触到spx, 于是找资料看. 原来也是针对语音压缩的文件格式. 采用ogg容器. CELP算法. (现在speex已经停止开发, 推荐使用opus, 在MDict_PC测试不支持opus.)
+ ^+ |; S7 z" ]7 x. Ahttp://www.speex.org/" z2 L0 G7 G5 ^( l4 P2 @$ T

% D# F, {$ ]2 H4 F( n$ ^. D% l在经过一番考虑之后(虽然有选择困难症), 还是使用spx格式吧. 原因有MDict_PC支持的格式(最重要); 编码质量与压缩比相对mp3有很大优势. 至于只20-60ms的延时, 更是有巨大的优势, 虽然在MDict_PC用不着, 所以网络电话(VoIP)都不会使用mp3来编码的. 网络电台有会采用mp3格式(当年是rm的天下)
6 x& |7 i' y/ u( V0 ^https://www.opus-codec.org/comparison/
' B* b4 T: m! M* r* `! n' N( A4 U0 `
. j$ x7 E1 }8 K& \& @+ N) U
以上是自家格式说自家的好(有很多测试报告, Google的也有, 但只有各自编码后的结果测试, 以下示例是mp3转spx后对比测试). 以下使用Audacity通过频谱显示(foobar2000也有频谱, 颜色只有灰度)来做一些实例.
3 a+ K# {: l8 S; ~) y+ |9 Y频谱显示的设置, 声频增益: 20dB (红色 - 白色, 不能设置颜色的, 只是说明一下), 频谱范围: 80dB (蓝色 - 白色)6 |- b( {6 z) b. P7 L# B  j6 f& ^
附件是其中各两个mp3/spx的比较文件. (我等没有技术的, 只能用蛮力做测试了)1 K- v( q  O+ V$ z1 |
例一, opposite angles
) U7 a8 d, h# s' q0 L0 A# |$ ]
mp3 128kbps mono 16bit 44.1kHz 21,632 bytes 来自网络
spx 24kbps mono 16bit 32kHz 3,852 bytes 转换自之上mp3文件
- = = - -

: L# R; i- g' i$ @- J. ?如果原来是128kbps的mp3文件转换到spx, 优势很大.- }- k) m* ?0 z0 |% G' n" b: w
16kHz的信息两者全部都没有了. 10kHz以下的, 没有明显区别, 5kHz以下, 应该是全部保存. mp3还有很多的空洞, 而spx编码时会补全空白. 技术优势吧.) P) j4 s; b0 ~  [$ N/ P
(左/上为mp3, 右/下为spx)7 f$ M% f* |. D" ?4 f
) t* b: U# N8 p' v* Y# U* f5 Y- L
6 b$ [8 G: V# ^2 H0 J
例二, bank teller3 }1 |! U, M9 a* L( G3 b1 O" A* r
mp3 24kbps mono 16bit 22.05kHz 2,430 bytes 来自原源
spx 24kbps mono 16bit 32kHz 2,484 bytes 转换自之上mp3文件
= = = + +

1 l5 L0 c  U& A4 i' o  o, @* e( I如果原来已经是低码率的mp3文件, 就没有什么优势, 能保持质量就已经很好的了. 因为低码率的mp3本身已经没有质量的保证, 并且损失很大, 也有空洞. 显示有只有6kHz以下的频率.
" X4 }6 O$ }$ r# H而转换后的spx, 虽然保有6kHz的, 但显示少了. 可是4.5kHz以下的应该是全部保存的, 即语音方面是基本保底的. 所以听起来, 低音多了. 实质是高频减少了. 而且也补全了mp3空白的地方.
# C/ f9 n4 {: Y: X6 K  E(左/上为mp3, 右/下为spx)' o4 `$ R( y0 x* s3 m! P
% M# s, U* C- ~* N% t! f

7 \# }2 i1 r  U在经过牛力般的测试, 偶有得一点粗粗浅的看法:
6 O% g2 `; G1 L7 L2 t2 a; j% c如果要mp3录语音的话, 64kbps, stereo/mono, 16bit, 22.05kHz/44.1kHz(选44.1kHz最好, 但有些软件会自动设为22.05kHz). 如果是音乐的话, 192kbps, stereo, 16bit, 44.1kHz. 这样质量会有最起码的保证. ogg的话, 192kbps已经很满意了.* i, i6 f5 e) s/ h/ b9 n4 Y( M
如果是转换spx语音的话, 按上图二显示 24kbps就已经很好了. spx针对8/16/32kHz采样率有特别优化. 所以需要根据mp3的情况而定, 必要时重新采样.( i: Q; ^3 ]/ X% V7 q
如果是由低码率mp3转换成spx, 就要想想是否必须了. 对我来说是必须的, 因为想兼容MDict_PC啊.! d$ n+ \9 x: h
所以低于64kbps的mp3, 全部转为: 24kpbs/32kHz. 这样spx的质量有保证.
, B& @! S) X( J: e3 l" l128kbp的mp3, 全部转为: 32kbps/32kHz. 这样spx的各样优势都很大. 质量相当(语音优化后可以说是没有区别的, 例一图是24kbps的情况), 但文件大小会小很多很多很多. 即128kbps/32kbps = 4, 即只是mp3的1/4; 如果想狠一点用24kbps, 即只有原来的1/5.33333333...
  A) [1 Y' e; s0 I  h# p+ l# q. R5 M; i3 o
看来speex不是吹的, 的确是对语音优势压缩, 而非mp3所能及的. 这个对比是基于mp3转spx的两者比较. 如果是分别都是转自wav的话, 就可以参详一些专业的测试结果.
/ Q  R: `- t  A' C) {也测试过11kbps/16kHz的mp3转为11kbps/16kHz之spx. 就有爆破音了, 即使是24kbps/32kHz的spx, 也很不能有好的保留质量. 因为本身mp3的质量好不到那里去, 质量损失已经太大了, 也有爆破音, 只是没有那么明显而已. 建议不要转换了. 毕竟需要花时间了.
3 y4 [- m/ `: r/ [% E% T: R+ g0 ?) i) w: w, q/ k& n8 X' A
之前有一个dos的mp3转spx的命令行文件, 后来增加一个py的多线程转换脚本文件, 轮换效能高了不少. 但笔记本电脑谨慎使用. 因为是根据CPU核心数量100%全开的, 发热量很大.
+ O1 K8 }2 J" K  |
" O0 A+ r# {) q8 \) m/ d5 g附件是其中各两个mp3/spx文件只是用作测试的. 无需要下载.& D* |, s7 E$ U) \" h  _
$ X. y( f: @/ P7 H4 G/ G4 [5 \

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?免费注册

x

该用户从未签到

发表于 2016-7-21 08:41:51 | 显示全部楼层
本帖最后由 onlyXXenglish 于 2016-7-21 11:34 编辑 / D5 L! }6 q( p7 Z+ m% \1 Q5 P1 e
- m+ d7 a& L# u0 f! M' k' b# n
学习一下。/ C5 L. Z" T1 e' `

+ V$ y6 O2 k! g+ G5 S, D/ e7 [PS:我的观点是希望MDict支持的格式越多越好,词典原版数据是什么格式的就可以用什么格式的,音频转换是一件很痛苦的事并且还要考虑损耗问题,数量小还好,偏偏词典的音频都是几万...几十万...的,转换起来实在痛苦。

该用户从未签到

发表于 2016-7-21 11:22:42 | 显示全部楼层
之前也是觉得语音的话64kbps够用了,后来很多音频采用了128kpbs以上,再回去听64就发现已经不能听了
1 r* @6 L& j9 z# ?. B: ~

该用户从未签到

发表于 2016-8-2 17:38:40 | 显示全部楼层
感谢分享知识!! g5 E$ I+ B) M! o) A4 T# }* h
我下的128k mp3有声电子书都是用itunes转换为16k单声道acc格式的,用肉耳听听也没啥区别,但是可以节约8倍的空间,呵呵!下次试试转成spx有啥区别:)

该用户从未签到

发表于 2016-8-14 20:13:34 | 显示全部楼层
某种意义上说,现在AAC是首选了。
  • TA的每日心情
    开心
    2023-4-9 01:23
  • 签到天数: 1746 天

    [LV.Master]伴坛终老

    发表于 2016-10-13 19:40:16 | 显示全部楼层
    请问您是用什么软件把MP3转换成SPX的?能否分享一下转换软件?谢谢。

    该用户从未签到

     楼主| 发表于 2016-10-17 10:27:12 | 显示全部楼层
    qwertzui 发表于 2016-10-13 19:40
    ( S0 k' j8 Q3 R请问您是用什么软件把MP3转换成SPX的?能否分享一下转换软件?谢谢。
    8 A( Q, s; K) T# h. q
    使用lame.exe解码, speexenc.exe编码. 写了个批处理和py.
    6 g9 G2 E8 P- c+ p) _在最后的附件里(详见说明注意部分):9 N. I" P4 Z; p9 `6 K
    https://www.pdawiki.com/forum/fo ... &fromuid=201568+ l4 \! N& @0 M( H( m
    ! Z* J% m2 f9 M4 V: Q1 L: j7 N
    不作参考.
  • TA的每日心情
    开心
    2019-3-1 09:24
  • 签到天数: 1 天

    [LV.1]初来乍到

    发表于 2016-10-19 21:52:31 | 显示全部楼层
    语音还需要这么纠结吗
  • TA的每日心情
    开心
    2020-2-19 00:15
  • 签到天数: 6 天

    [LV.2]偶尔看看I

    发表于 2020-2-16 18:28:14 | 显示全部楼层
    谢谢分享宝贵经验,但我的情况相反,我想把大量spx文件转为mp3格式,你知道怎么样最优吗,真心请教
    您需要登录后才可以回帖 登录 | 免费注册

    本版积分规则

    小黑屋|手机版|Archiver|PDAWIKI |网站地图

    GMT+8, 2024-5-9 05:12 , Processed in 0.061957 second(s), 9 queries , MemCache On.

    Powered by Discuz! X3.4

    Copyright © 2001-2023, Tencent Cloud.

    快速回复 返回顶部 返回列表