belight 'fix delays' question

[BabaG]

i've been trying to convert some 60i hdv tapes to 50i hdv and
have been following a process recommended in another thread.
complete thread is here:

http://forum.doom9.org/showthread.php?t=118440

i'm to the point of now having mpa files and m2v files. the mpa
files are those extracted from the original m2t 60i material. the
m2v files are the conversions to 50i. iow, i have 60i audio and
50i video.

it was recommended that i use belight to 'fix the delays and
change the fps of the audio file to fit the new M2V file.'

my questions:

how do i use belight to do this?
can i automate the process across many files?

belight version i have is: BeLight-0.22b9_Normal

thanks,
BabaG

[Kurtnoise]

By "fix the delay", you mean include the delay for audio transcoding ? If yes, when your filename contains a delay value, BeLight uses it automatically and applies it for the transcoding. Otherwise, you can specify the delay in BeSweet OTA.

Regarding fps change, go to Advanced Settings and Soundtouch option.

And btw, grab the last daily build...

[miztadux]

Hello,

I have a question that may be related to this thread, so I'll ask it here:


When encoding movie soudtracks in AAC, do you usually skip some frames in the beginning to compensate for encoder/decoder delay ?


More specifically:
- I've been noticing (very light) desync after encoding AC3 to AAC, whereas AC3 seemed synced
- I know that lame decoder "removes" its own encoder delay by skipping some frames prior to decoding....but I don't know what's the behavior of aac encoder/decoders
lame now compensates for the mp3 encoder delay. All mp3 encoders and decoders introduce a small delay (typically 1000-2000 samples). This is encoder dependent. Lame now removes its own 1105-sample encoder delay from every file it decode
- Yesterday I did some quick & dirty encoding/decoding tests, checking the results frame by frame with Cool Edit Pro (err. Audition) here is what I still can remember (it was really late in the evening, it's not accurate...):

source file: a .wav music file
file a: source encoded with Winamp CT @ 80kbps
file b: source encoded with Nero CLI @ 80kbps
(with dimzon/belight, big thk Kurtnoise13 !!!)

decoded with Winamp + DiskWriter:
file a: 96ms
file b: 105ms

decoded with neroAccDec:
file a: 50ms
file b: 0ms (something like 2/3 audio frames at max...)

decoded with GraphEdit + CoreCodec AAC + Wav dest:
file a: 50ms
file b: 59ms

Conclusions ?:
- Nero Dec correctly deals with Nero Enc, that's seamless integration (seams to be a hack on the decoder to recognize Nero encoded files and compensate for the known delay...)
- except from the Nero Enc/Dec combo, those results appears to be coherent, we might draw the following conclusions
* winamp decoder (acc wav disk out) introduces 46ms more delay than other decoders, but we don't care about that lazy-ass decoding method ;)
* with the winamp encoder, the total delay is 50ms
* with the nero encoder, the total delay is 59ms

- Sidenote: Nero encoded content is inversed, WACT handles that correctly

So ....
As AAC is decoded using CoreCodec DirectShow during playback on my current setup, i would be tempted to skip 50ms with WACT (59 with nero) before encoding, or at least introduce -50ms at muxing, but does other decoders behave differently? can we expect that, like lame dec does, ACC decoders might compensate this delay ?

Thanks for any feedback

EDIT: went home, fixed some values i failed to remember correctly and updated the conclusions

[tebasuna51]

- I know that lame decoder "removes" its own encoder delay by skipping some frames prior to decoding
But others mp3 decoders don't remove this delay.
....but I don't know what's the behavior of aac encoder/decoders
Similar test with a 10 sec. wav 44.1 KHz, include also the duration change, a few more decoders and CT mp4 obtained with mp4box:
CT CT Nero
.aac .mp4 .mp4
---------- ---------- ----------
Decoder Delay Dura Delay Dura Delay Dura
-------- ----- ---- ----- ---- ----- ----
Winamp 0 -97 16 -22 107 +124
NeroDec (1) 20 -16 0 0
CoreAAC 50 -15 20 -16 (2)
ffdshow 96 +31 53 +16 (2)
Faad 50 -15 20 -16 60 +60
foobar (3) 53 +16 0 0
BassAudio 50 +31 20 +16 60 +106

(0) All values in ms.
(1) moov box not found
(2) Could not construct a graph from this file
(Return code: 0x80004005)
(3) Decoder produced garbage at 0:00.000
I can't reproduce all your results, only the NeroEnc-NeroDec 0-0.
- Sidenote: Nero encoded content is inversed, WACT handles that correctly
Never I found a inverted signal, for me all is correct.

[miztadux]

Ok, thanks for your input tebasuna51

CT mp4 obtained with mp4box

Yes, i forgot to mention this...
I used CT aac encoder then muxed to mp4 with MP4Box and used this mp4 for all tests.
But winamp decoder would give me the same delay with the aac or the mp4 input so i disregarded the container.

To be accurate, the version strings of tools i used:
neroAACDec|Enc.exe : May 26 2006
Winamp: 5.31
caoreacc.ax: 1.2.0.573

I can't reproduce all your results, only the NeroEnc-NeroDec 0-0.

Let me reformat both result sets to be able to compare:

yours:
CT CT Nero
.aac .mp4 .mp4
------ ------ ------
Decoder Delay Delay Delay
-------- ----- ----- -----
Winamp 0 16 107
NeroDec (1) 20 0
CoreAAC 50 20 (2)

mines:
CT Nero
.mp4 .mp4
------ ------
Decoder Delay Delay
-------- ------ ------
Winamp 96 105
NeroDec 50 0
CoreAAC 50 59


There's some other matches also:
- Nero Enc/Winamp Dec: 105 ~ 107
- Winamp Enc / CC Dec: 50 = 50 (but you got this with the aac, i got the same results between aac and mp4)

It also seams the mp4 muxing as big impact on those tests.
And there's something fishy with the Winamp decoding (i found 96 dly and you 0 dly but -97 dura...)


Never I found a inverted signal, for me all is correct.

OK, my bad, as I said it was very late....
It's just that the Nero ouput was a lot more distorted than the Winamp output.
When comparing to the source it seems, at first sight, that the Nero output was reversed (that's what i remembered anyway),
after looking again carefully it's just more distorded than the winamp output...thus exact matches are harder to find
(i didn't say it's WACT is better, it just "looks" more like the source in cool edit with a ~100 samples range)

[miztadux]

I ran some other tests...

I tested faad.exe (Build: Jul 9 2004) as a decoding method.

Then I came across AudioCoding's in_mp4 plugin for winamp:
http://www.audiocoding.com/modules/mydownloads/viewcat.php?cid=1

I also tested ffdshow (latest tryouts) in GraphEdit using libfaad2

...

Everything here gave me the same results as CoreAAC (afterall all those decoders are based on faad2...):


Winamp Enc: 50ms
Nero Enc: 59ms


Anyway here's the (redundant) updated chart:

CT Nero
.mp4 .mp4
------ ------
Decoder Delay Delay
-------- ------ ------
Winamp 96 105
NeroDec 50 0
CoreAAC 50 59
Winamp+in_mp4 50 59
Faad 50 59
ffdshow+libfaad2 50 59


Also it seems that:
- Winamp's default decoder is false (As said on AudioCodings about their in_mp4: can be considered a correctly working replacement for in_mp4 included with Winamp5)
- Nero decoder handles nero files differently

[miztadux]

Lamer than ever, I quote myself...

Nero decoder handles nero files differently

OK, I wanted to make some more tests before saying aacNeroDec compensates the delay of Nero files only...

- I took the .mp4 encoded by nero that gives 59ms delay on all decoders but nero's (where there's no delay at all...),
- remuxed into mp4 via mp4box
- decoded it with neroAacDecoder.exe

and there was my 59ms delay again !!


I though neroAacDecoder had an "if ( neroEncodedMedia) {" somewhere, but perhaps the difference only comes from the way nero muxes the aac file in a mp4 container...
(i don't know nothing about mp4, but at least Nero/mp4box mp4 headers are different: "ftyp3gp6"/"ftypmp42")

Anyway the delay when encoding and decoding with nero wont be 0ms if the audio file is remuxed in the meantime.

[tebasuna51]

I though neroAacDecoder had an "if ( neroEncodedMedia) {" somewhere, but perhaps the difference only comes from the way nero muxes the aac file in a mp4 container... (i don't know nothing about mp4, but at least Nero/mp4box mp4 headers are different: "ftyp3gp6"/"ftypmp42").
I can't open nero mp4's in GraphEdit but mp4box mp4's work in GraphEdit directly with CoreAAC or ffdshow.

BTW my first ffdshow data is with realaac lib, with libfaad2 I get the same values than faad/coreaac (same versions than you):
CT CT Nero
.aac .mp4 .mp4
---------- ---------- ----------
Decoder Delay Dura Delay Dura Delay Dura
-------- ----- ---- ----- ---- ----- ----
Winamp 0 -97 16 -22 107 +124
NeroDec (1) 20 -16 0 0
Faad 50 -15 20 -16 60 +60
CoreAAC 50 -15 20 -16 (2)
ffdshow libfaad2 50 -15 20 -16 (2)
ffdshow realaac 96 +31 53 +16 (2)
foobar (3) 53 +16 0 0
BassAudio 50 +31 20 +16 60 +106
Is you wav 44100 Hz.?
I search the sync at 5 sec., not at begining.
Maybe this can explain the different values.

[miztadux]

I can't open nero mp4's in GraphEdit
It works on my comp. I have no idea why...

BTW my first ffdshow data is with realaac lib
...but realaac didn't work !


Is you wav 44100 Hz.?
I search the sync at 5 sec., not at begining.
Maybe this can explain the different values.

Yup, it's 44,1k.
And i got the same idea as you, I though you were syncing at the very begining and that could explain the difference.
Actually the wav I used also has some silence in the begining before the music starts.

I'll do some tests on others sources when I'll have time, perhaps the encoding delay depends on the source...

Anyway I feel the ct=50ms, nero=59ms values are valid for most decoders...I'll try to skip 50ms on the CT encode i was doing in the first place to see if the slight delay i could see is gone...