掌上百科 - PDAWIKI

 找回密码
 免费注册

QQ登录

只需一步,快速开始

查看: 3966|回复: 9

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

[复制链接]

该用户从未签到

发表于 2016-7-21 01:56:55 | 显示全部楼层 |阅读模式
本帖最后由 idict 于 2016-10-16 12:33 编辑 & j/ c( y( {2 {9 L0 v1 P+ [
1 Y+ n* C& M& T2 S( D. G
对声音文件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已经有看到踪迹了.
8 |) y3 z& `5 ^* T8 o8 d# \8 y: S8 K& B) t* j; O2 B/ _8 I! J
附opus主要开发者: Jean-Marc Valin
  {9 Z3 H) x5 x1 l* Rhttps://jmvalin.ca/( w" ^5 f1 U2 q) a) T: u
https://commons.wikimedia.org/wiki/Opus_(audio_codec)1 t) Q+ I) ^) Q0 \8 R) S
5 d" I6 p) r3 h$ p$ i8 F
题外话: 当初压缩CD时, 有比较过mp3和ogg, 最终使用ogg. mp3最少需要是192kbps(128kbps的话有较大差别), ogg就128kbps可以了. 如果ogg用192kbps, 质量要好. 文件大小与mp3相同码率相当. (现在不折腾了opus)
7 I0 Y- L/ `3 N1 |
! l) s" |' B3 X6 V5 U$ w$ Q人耳可以听到的声音范围20 - 20kHz. 但音乐与语音的频率范围是有区别的. mp3会将16kHz以上的音乐信息削掉. 虽然说可以至20kHz. 但很多人都未必听得出有什么区别的. 语音的话, 只需要200Hz - 5kHz就满足人耳的要求了.& q8 h& b5 K# I5 ^) z" a
https://zh.wikipedia.org/wiki/%E8%81%BD%E9%96%BE# e$ r/ z% b/ j6 d8 f

$ A7 w1 A6 t4 ?  [3 `( B- v4 X2 |/ X
至于对语音的优化压缩, 也有很多. 没有什么了解. 最初看到录音文件有amr, 不知道是什么. 现在在了解mdx过程接触到spx, 于是找资料看. 原来也是针对语音压缩的文件格式. 采用ogg容器. CELP算法. (现在speex已经停止开发, 推荐使用opus, 在MDict_PC测试不支持opus.)2 A8 G5 V0 F, u' n, t
http://www.speex.org/1 ~$ @# i3 h! K& V: v

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

+ ]7 K& u, @/ \* l/ D7 G# {0 |如果原来是128kbps的mp3文件转换到spx, 优势很大.
- [$ ]7 V3 E9 `& ^8 p4 t0 }' L/ {16kHz的信息两者全部都没有了. 10kHz以下的, 没有明显区别, 5kHz以下, 应该是全部保存. mp3还有很多的空洞, 而spx编码时会补全空白. 技术优势吧.
: X! H3 t3 a' P& F) x& r(左/上为mp3, 右/下为spx)
) l. H& o7 q7 b( W2 Y- y6 s. F+ A% |$ `% Z1 P5 e- Y
( M7 `" z$ h  |6 W' x0 T
例二, bank teller
+ o1 T8 I4 @) E$ o. Q
mp3 24kbps mono 16bit 22.05kHz 2,430 bytes 来自原源
spx 24kbps mono 16bit 32kHz 2,484 bytes 转换自之上mp3文件
= = = + +

8 S" Q/ T8 d' C2 m& E- x9 j如果原来已经是低码率的mp3文件, 就没有什么优势, 能保持质量就已经很好的了. 因为低码率的mp3本身已经没有质量的保证, 并且损失很大, 也有空洞. 显示有只有6kHz以下的频率.9 ^1 H) G. e0 g
而转换后的spx, 虽然保有6kHz的, 但显示少了. 可是4.5kHz以下的应该是全部保存的, 即语音方面是基本保底的. 所以听起来, 低音多了. 实质是高频减少了. 而且也补全了mp3空白的地方.
- q5 m1 M6 r( v(左/上为mp3, 右/下为spx)
  B9 |  `* L6 ?  J, @  ?
1 n+ |7 r  V- D
* V6 Z1 p0 U$ v5 ?  J) D在经过牛力般的测试, 偶有得一点粗粗浅的看法:6 z( P# N* F: L: s
如果要mp3录语音的话, 64kbps, stereo/mono, 16bit, 22.05kHz/44.1kHz(选44.1kHz最好, 但有些软件会自动设为22.05kHz). 如果是音乐的话, 192kbps, stereo, 16bit, 44.1kHz. 这样质量会有最起码的保证. ogg的话, 192kbps已经很满意了.. u2 l8 x; w- t3 F, z) d5 A7 P
如果是转换spx语音的话, 按上图二显示 24kbps就已经很好了. spx针对8/16/32kHz采样率有特别优化. 所以需要根据mp3的情况而定, 必要时重新采样.
" i( P2 y* ]/ G; B如果是由低码率mp3转换成spx, 就要想想是否必须了. 对我来说是必须的, 因为想兼容MDict_PC啊.& g4 Z' N$ l; s9 |! C
所以低于64kbps的mp3, 全部转为: 24kpbs/32kHz. 这样spx的质量有保证.( n3 t; s' p. B/ U$ d( C7 w" U
128kbp的mp3, 全部转为: 32kbps/32kHz. 这样spx的各样优势都很大. 质量相当(语音优化后可以说是没有区别的, 例一图是24kbps的情况), 但文件大小会小很多很多很多. 即128kbps/32kbps = 4, 即只是mp3的1/4; 如果想狠一点用24kbps, 即只有原来的1/5.33333333...) B! [9 m) k: J6 h# S; U" t% a

/ z4 ^: V7 W1 V看来speex不是吹的, 的确是对语音优势压缩, 而非mp3所能及的. 这个对比是基于mp3转spx的两者比较. 如果是分别都是转自wav的话, 就可以参详一些专业的测试结果.  p) s$ @1 Y$ X" j" j( Z6 m) z
也测试过11kbps/16kHz的mp3转为11kbps/16kHz之spx. 就有爆破音了, 即使是24kbps/32kHz的spx, 也很不能有好的保留质量. 因为本身mp3的质量好不到那里去, 质量损失已经太大了, 也有爆破音, 只是没有那么明显而已. 建议不要转换了. 毕竟需要花时间了.
7 n( X2 b- x1 Q$ x0 c
2 V3 e3 L- x/ e# S2 h' r6 s& [+ E之前有一个dos的mp3转spx的命令行文件, 后来增加一个py的多线程转换脚本文件, 轮换效能高了不少. 但笔记本电脑谨慎使用. 因为是根据CPU核心数量100%全开的, 发热量很大.
: ?$ C* E5 b1 F
7 {) x+ ~& ~2 V3 w附件是其中各两个mp3/spx文件只是用作测试的. 无需要下载.
. k7 x7 C% V+ [& e, K% K$ w- p( J/ L/ p+ l! Y5 {  S8 }

本帖子中包含更多资源

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

x

该用户从未签到

发表于 2016-7-21 08:41:51 | 显示全部楼层
本帖最后由 onlyXXenglish 于 2016-7-21 11:34 编辑   O5 J9 D# M8 R& G) s

( n8 U: z1 I/ Y学习一下。
! q) E% L) C: H$ |- V- q0 A4 q2 j1 L. P7 E9 Q# J
PS:我的观点是希望MDict支持的格式越多越好,词典原版数据是什么格式的就可以用什么格式的,音频转换是一件很痛苦的事并且还要考虑损耗问题,数量小还好,偏偏词典的音频都是几万...几十万...的,转换起来实在痛苦。

该用户从未签到

发表于 2016-7-21 11:22:42 | 显示全部楼层
之前也是觉得语音的话64kbps够用了,后来很多音频采用了128kpbs以上,再回去听64就发现已经不能听了
: \! M; D. f  {2 i! Z

该用户从未签到

发表于 2016-8-2 17:38:40 | 显示全部楼层
感谢分享知识!9 q! {9 s6 y/ f6 f4 ~
我下的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:406 |" }1 n1 F: H0 |$ H4 V* ?' P* C4 X
    请问您是用什么软件把MP3转换成SPX的?能否分享一下转换软件?谢谢。

    3 m# l6 A7 _( \, M使用lame.exe解码, speexenc.exe编码. 写了个批处理和py.5 p* _& D7 y$ k0 F/ F1 Z" Q/ s
    在最后的附件里(详见说明注意部分):
    ; v8 S8 G# V0 B, ~6 u7 ihttps://www.pdawiki.com/forum/fo ... &fromuid=201568
      F5 Q" w' x- P; ?& e; S( d6 w1 c- ~1 g- K( Z+ O5 |+ \! c
    不作参考.
  • 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-6-9 19:17 , Processed in 0.067335 second(s), 9 queries , MemCache On.

    Powered by Discuz! X3.4

    Copyright © 2001-2023, Tencent Cloud.

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