和UCI类似,UCA的目标最佳低码率高质量的语音编码,以弥补HE-AAC在此领域的不足.
当前使用的是AMR-WB+的编解码内核实现,由于目标只是语音,所以编码只锁定在单声道,码率范围在10~24k
bp
s,有效采样率在24~38kHz.
0.11 (2010-02-01) 解码器改用VC2010(beta2)编译,修正编码时缺少结尾0.1秒音频的bug
0.1   (2009-09-19) 初始公开测试版本
0.11 公开测试版本(包含命令行的编解码器,解码DLL等):
http://d.namipan.com/d/acb56ccea5353561937e44a205b508c74aaea46d23b60200
http://www.brsbox.com/filebox/down/fc/7592d5ac1c0737167b18e2bb0f55e756
0.1 版发布贴:
https://tieba.baidu.com/f?kz=644960305
PS:
1. 编码器使用VC2010编译后,编码结果不正常,原因以后找时间再查
2. 编码后的音频是以帧为单位的,每帧80毫秒,0.11版在编码时如果不足一帧采样,会扩展成一帧


啥时有播放工具 or 插件？？？
就算没有，也把标准输出弄出来吧，也好中转到mplayer播放

解码器可以输出到stdout:
ucadec input.uca -o -
输出的是标准的wav文件内容

呵呵，
前排
。

有其他接口吗？
比如directshow或者winamp插件之类的？

winamp,foobar的普及率太低,不打算开发插件.
千千静听及其它国内使用率高的播放器不支持开发插件,
directshow的接口太复杂,
UCA主要面向语音压缩,解码器主要用于二次开发,
综上,暂不支持其它接口的支持.

希望公开spec，闭源+不公开格式有太多不方便了

3gpp网站上有AMR-WB+的开源代码,UCA的格式文档在压缩包里.和官方编码的raw文件对比一下就知道差别了,UCA省了每个帧头的几个字节.

3gpp的AMR-WB+有license问题，并非免费，所以ffmpeg转而用opencore-amrwb来代替libamrwb

嗯,找时间看看opencore-amrwb的实现如何

opencore的amrwb的代码里有这些注释,估计实现也是差不多的:
Portions of this file are derived from the following 3GPP standard:
    3GPP TS 26.173
    ANSI-C code for the Adaptive Multi-Rate - Wideband (AMR-WB) speech codec
    Available from http://www.3gpp.org

我在精简某游戏语音的时候，发现语音结尾常常出现乱七八糟的声音。
结果发现是UCADecode的问题：
在UCADecode调用malloc分配一块内存后，我用OD把这块内存填充为FF，然后再解码。结果得到的WAV是有问题的。
我把malloc改成calloc后就正常了。

我的意思是，如果malloc分配到的内存不全是零，那解码的结果就可能有问题。
正常情况下，无论分配到的内存里的内容是什么，解码的结果应该都是一样的吧？

解码结果和分配内存的原始数据无关,如果有结尾杂音的情况,可能是解码未完成导致的,具体原因还不清楚,所以需要样本,你也可以先用TestUCA或ucadec程序先测试一下,看看是否也有问题.

D大可以随便找一个样本，然后对比一下malloc后用0填充和用ff填充的结果，应该会发现结果是不一样的(我试了几次都是这样）。
既然解码结果和分配内存的原始数据无关，那么就不应该是这样的吧？

可能是编码参数的问题,我常用的参数并没有这种问题,请给出有问题的编码参数.

试了一下，-mi 17没这问题，-rate 26就有。

先暂时用-mi的参数,而不是-rate,后者很可能有问题,而且准备禁用.

前面是h t t p s

我在用UCA压一些wav的时候ucaenc会提示
Error: file too short!
但是这些wav都不是很小啊。
压缩包里的文件都有这个问题
d
l.dropbo
x.co
m/u
/359124
6/wa
v.7z
摆
肚
吞泥煤的楼..