查看完整版本: [-- 太较真就让人纠结了~ --]

『漫游』酷论坛 -> 『影音数码技术学习交流』 -> 太较真就让人纠结了~ [打印本页] 登录 -> 注册 -> 回复主题 -> 发表主题

52wy 2010-06-01 00:34

太较真就让人纠结了~

发现wav音频转成aac后长度总会发生变化,用megui、neroaac都试过了~难怪每次做完dvdrip总觉得音频有些异样,一直以为是自己太敏感了,今天仔细比对了一下长度才发现有玄机啊。。。。

这种情况兄弟们都怎么办?无视之还是手动填补差距呢。。。。。

辉耀 2010-06-01 01:24
呃,您能详细说一下么?我之前确实没注意过这个问题,刚试了试没事啊……(随便抓了个tta->wav->aac)

52wy 2010-06-01 01:41
有50毫秒左右的差异吧。aac长度会比wav多50毫秒左右。

比如一段dvd抓出来的音频,原始ac3是40:00:224,通过dgindex直接分离出wav格式,也是40:00:224,然后将此wav转成aac后,长度变成40:00:299,也就是说多了75毫秒,差距也是比较可观的。。。。

如果这75毫秒是整体被拉长的,那即使在最后合并时设置负延迟75毫秒貌似也没啥意义。

辉耀 2010-06-01 02:23
记得ac3如果存在delay的话,decode ac3->wav的时候会自动在开头部分加上空白令wav与ac3时长不同,不过这已经弄好了的wav转aac怎么会……

似乎是Win7的因素(?)我这decode ac3->wav无效,也没法试了……我还是匿了等大大们的结果吧~

roozhou 2010-06-01 02:39
aac开头会的确会有延迟,有些解码器无视这个延迟就会在开头出现在一段空白
另外tta->wav也有可能悲剧

52wy 2010-06-01 08:24
引用
最初由 roozhou 发布
aac开头会的确会有延迟,有些解码器无视这个延迟就会在开头出现在一段空白
另外tta->wav也有可能悲剧


也就是说转aac的确会造成长度变长咯?只是开头延迟吗?那就需要做负延迟修正?

52wy 2010-06-01 08:25
引用
最初由 辉耀 发布
记得ac3如果存在delay的话,decode ac3->wav的时候会自动在开头部分加上空白令wav与ac3时长不同,不过这已经弄好了的wav转aac怎么会……

似乎是Win7的因素(?)我这decode ac3->wav无效,也没法试了……我还是匿了等大大们的结果吧~


老点的dgindex才能把ac3直接抓成wav,新的似乎都不行。

我用的是0ms的ac3,所以不存在延迟的问题。

roozhou 2010-06-01 11:58
像nero,faac这样的编码器输出mp4格式时这个延迟会自动添加。但如果抽取为aac这个延迟就没了。

52wy 2010-06-01 19:52
还是没看懂。。。

一个0延迟的wav为何输出成aac就变长了?然后按照roozhou的意思nero如果输出成mp4就会对这个音频做负延迟修正?如果输出成aac则不会做延迟修正?

也就是说在合并音频的时候如果是mp4就不要设置延迟,如果是aac则需要设置延迟了?

其实不单单是aac,即便转成mp3长度也会发生变化,只不过误差很小而已,基本可以忽略。

52wy 2010-06-01 20:17
测试了一下,果然将wav输出aac为mp4的时候长度一致,输出为.aac时,长度发生变化。

然后将mp4封进mkv再拆出来长度就会变成和.aac的一致。看来现在我们一般用的mp4的raw,只要拆出音轨再合并,必然会存在2~30毫秒的误差了。由于无法得知原音频的真正长度,所以再次封装也就没有一个值可参考了。。。

果然折腾啊。。。。

264768502 2010-06-01 20:49
nero不是只能中出mp4的么..

52wy 2010-06-01 23:24
nero6带的waveditor可以输出成.aac

roozhou 2010-06-02 11:32
关于这个延迟,我以前做个实验,不同的编码器不一样的。以nero 44KHz为例,LC-AAC比较短,是15~21ms,而HE-AAC大概是48ms,而HE-AACv2最长,可以到112ms。

这个延迟的值可以从mp4的tag里获取,当然MediaInfo是不会显示的,要自己想办法去找了。

52wy 2010-06-02 16:48
嗯是的,我试过用megui压了一个mp4,延迟更甚,达到100毫秒多。

目前还是用nero waveeditor压出来的mp4最准。有啥软件能显示mp4的tag?

reekilynn 2010-06-05 04:40
值得注意的是我用eac3to通过NeroAACEnc转wav的*.aac.m4a默认会带一个Chapter文件
里面可能记录了相关的信息
不过我最后封装mkv的时候都是不勾选这个Chapter的
不知道会不会有影响
有的话以后倒不如直接把wav转成Vorbis或者ac3

roozhou 2010-06-06 00:39
应该和chapter无关。另外mp4和mkv实现延迟的方式不一样,mkv有先天缺陷。

zeas 2010-06-06 15:34
我曾拿一段wav格式的loop素材做了个试验:
源是16位立体声0xB5E(2910)采样的wav文件
然后删去头4个字节(一个采样)再将wav头的长度及data段后的长度减去4另存为一份供对比
参数用neroaacenc -q 0.12 -hev2 -if in.wav -of out.mp4
(Nero AAC codec / 1.5.4.0,因为hev2延迟最明显,故用hev2做测试)

对比两者转出的mp4,忽略头部的修改日期信息和数据段,两者仅在esds、stsz,还有itunsmpb字段的信息出现不同
考虑到AAC数据已完全不同,长度也不一样,故stsz产生的不同可以忽略
关键决定长度和偏移的只有esds和itunsmpb字段了
用neroaactag -list-meta out.mp4 显示itunsmpb字段
原始的wav转的mp4: itunsmpb = 00000000 00000AF8 000001A9 0000000000000B5F (后面都是00了,就不列出来)
减短的wav转的mp4: itunsmpb = 00000000 00000AF8 000001AA 0000000000000B5E
可见itunsmpb的第4项记录了原始长度信息

esds段(有03,04,05号,但不同的只有04):
原始:04 80 80 80 19 40 15 00 00 DC 00 00 15 78 00 00 4D 08
减少:04 80 80 80 19 40 15 00 00 DC 00 00 15 D8 00 00 4E 60
貌似没有什么明显的规律?

再分别用neroaacdec和faad2(用源代码自带的aacDECdrop例子)解码原始长度的mp4
nero.wav:长度准确,回放无缝loop
faad.wav:总采样数0x2800(而itunsmpb的总和AF8+1A9+B5F=1800 !),而真正无缝的第一个采样是第0xDF0(AF8+1A9=0xCA1 !)个采样

我实在不知道要如何才能将FAAD2的解码数据和这些信息对应,算出正确的第一个采样的偏移来……

52wy 2010-06-16 20:24
发现就算封成mp4没有延迟只要再重新封进mkv依然会变成有延迟的状态,无语啊。

angering 2010-06-17 03:11
引用
最初由 52wy 发布
发现就算封成mp4没有延迟只要再重新封进mkv依然会变成有延迟的状态,无语啊。


請問也就是說成品MP4(音視頻都有)→mkv都會產生延遲么…… = =
那麼我們要用什麽格式好呢……
之前又聽說MP4比mkv略遜一籌……囧rz,國外都喜歡用MP4啊……搞不懂了……


啊……原來如此,受教了~

roozhou 2010-06-17 14:38
只要能正常播放,没什么好不好的。

52wy 2010-06-18 13:01
引用
最初由 angering 发布


請問也就是說成品MP4(音視頻都有)→mkv都會產生延遲么…… = =
那麼我們要用什麽格式好呢……
之前又聽說MP4比mkv略遜一籌……囧rz,國外都喜歡用MP4啊……搞不懂了……


啊……原來如此,受教了~


也不是,如果没有对音频重新编码,那么封成mkv或者mp4是不会产生延迟的。譬如大部分我们用的mp4 raw,只要你没重压音频就不用顾虑。

如果你将音频编码成aac就存在这个问题,比如dvdrip里的音轨是wav,你压成了aac,就会有延迟,压成mp4虽然没有延迟,但是封进mkv后延迟会恢复成和aac一样的状态,封成mp4则延迟略小。而且mmg对aac音频进行延迟处理也不能很精确到毫秒,总有10~20毫秒的误差,所以如果特别纠结音频问题的话还是别用aac了,我试过ogg音频不会延迟。

辉耀 2010-06-18 13:54
感谢总结性发言,之前看的有点迷糊了……

不过这样还是比较纠结啊……
mp4 raw如果要进行音频重压肯定就是要压到比较低的码率了,这时候舍弃HE AAC还是比较可惜啊……
即使是WAV的DVD,用OGG就没法用MP4封,兼容就差些了(PS3认不了MKV&OGG、MKV在PC也没略缩图==);而且现在解不了OGG的MP4也挺多的……便携看片党也……

roozhou 2010-06-18 14:15
不知道mp3有没有这样的问题

52wy 2010-06-18 14:16
mp3也有哦,我测试了几种,只有ogg比较靠谱。

52wy 2010-06-18 14:17
引用
最初由 辉耀 发布
感谢总结性发言,之前看的有点迷糊了……

不过这样还是比较纠结啊……
mp4 raw如果要进行音频重压肯定就是要压到比较低的码率了,这时候舍弃HE AAC还是比较可惜啊……
即使是WAV的DVD,用OGG就没法用MP4封,兼容就差些了(PS3认不了MKV&OGG、MKV在PC也没略缩图==);而且现在解不了OGG的MP4也挺多的……便携看片党也……


那就继续封aac呗,反正10~20毫秒的误差还是能接受的。

52wy 2010-06-18 14:29
送上一组测试数据

原始:audio.wav 23:24.821
megui输出的lc-aac:23:24.885 封成mka后:23:24.885
megui输出的he-aac:23:24.928 封成mka后:23:24.928
megui输出的ogg:23:24.821 封成mka后:23:24.834
megui输出的mp3:23:24.864封成mka后:23:24.887
nero6输出的lc-aac mp4格式:23:24.821 封成mka后:23:24.842
nero6输出的lc-aac aac格式:23:24.843 封成mka后:23:24.843


单看精确度,ogg和nero6输出的mp4和原始wav一模一样,但是用mmg封一次后,只有megui输出的mp4和nero输出的.aac没有rp。ogg、mp3都存在不同程度的rp。

至于这些转换编码带来的长度误差到底会不会造成视频不同步,我没有科学地对比过,因为很多只有几十毫秒的误差,靠肉眼看和耳朵听很难明确判断出差距。但愿有高人能做出权威的测试。

roozhou 2010-06-18 15:15
楼上你的长度值是哪里来的?不要去相信mediainfo显示的信息,一定要再解码成wav才能得到确切的值。

megui输出的mp4就是nero输出的mp4,如果用mp4box封装,不会丢失delay。一旦将其换成mkv,aac或者用ffmpeg系的解码器解码或封装,延迟就会消失,长度就会增加。

52wy 2010-06-18 16:10
引用
最初由 roozhou 发布
楼上你的长度值是哪里来的?不要去相信mediainfo显示的信息,一定要再解码成wav才能得到确切的值。

megui输出的mp4就是nero输出的mp4,如果用mp4box封装,不会丢失delay。一旦将其换成mkv,aac或者用ffmpeg系的解码器解码或封装,延迟就会消失,长度就会增加。


用千千静听看的:cool:

MP4box的delay很多都不认吧~

alusta 2016-01-21 04:24
啊 挖個墳

我也遇到類似問題了 現在有解嗎?

30fps的視頻

原始是fraps+pcm的avi文件

然後視頻流用vs的ffms2源濾鏡引出來x264壓制

音頻流用ffmpeg的copy到wav文件 然後使用neroAacEnc的恒定碼率處理wav文件到aac

然後使用mp4box封裝.h264的視頻流和.aac的音頻流

我使用aegisub3.2.2進行了測試
載入原始的avi文件                                               --- 沒問題 音頻和視頻都是準確的
載入壓制后的.h264和.aac文件                             --- 沒問題 同原始文件相同
載入封裝好的mp4文件                                         ---  出問題了  音頻方面比視頻晚了55ms左右
嘗試將.h264和.aac重新使用mmg封裝為mkv
然後aegisub載入封裝好的mkv文件                      --- 這還是有問題 音頻方面會比視頻快10ms不到的樣子
雖然10ms一般是不影響什麼啦
但是那55ms就有問題了
從aegisub的頻譜上來看 是音頻頭部產生了55ms的空白所導致的

盤.百度.com/s/1jHndTrC
這是測試用的片子 也虧得是這片子 才讓那50ms的差別那麼明顯
aegisub分別載入h264和aac的話是準確的 和原始文件相同
但是一旦將h264和aac封裝進mp4之後 音頻就出現延遲了


解决方案:
不要使用裸流
nero直接輸出mp4封裝好的音頻留
x264的視頻流也封裝進mp4

然後使用lsmash的remuxer混流兩個mp4就能完美解決這個問題



查看完整版本: [-- 太较真就让人纠结了~ --] [-- top --]


Powered by phpwind v8.5 Code ©2003-2011 phpwind
Time 0.034694 second(s),query:3 Gzip disabled