DV to MP4: audio sync issue and global pipeline question

[dasumin]

Hi, doom9 forum members!
I'm new to this forum, I tried to find solution for my problem here and at videohelp.com, but, anyway, sorry if this topic was discussed.

I'm now working on near-lossless conversion of my school's video archive (several years, near 5Tb video data, everything in AVI DV). I managed to use the following pipeline:

1. DV 25i to MP4 50p (AviSynth with TempGaussMC is encoded with x264, --crf 15)
2. Sound from dv is converted to WAV and encoded with neroAacEnc (-q 1) to an .aac file
3. .mp4 from 1 and .aac from 2 are merged with ffmpeg to a resulting mp4

The goal is to decrease the amount of video in bytes but to save quality.
Everything is nearly fine, the quality is not decreased (actually, I don't see it). In some sense, it is increased because of good deinterlacing.

BUT, I have an audio sync issue. The audio is behind video for some 0.05475 seconds (found it out with AudioGraph for AviSynth) constant for different files or through one file (in the beginning or in the end of video).

I have read something on the issue and understood that aac encoding is not possible without this delay. Then, as I understood (please, correct me), two ways are possible: muxing with the information about this delay or just shifting of audio.
I tried -async 1 in step 3, but it doesn't work for me.

So, what it better, to shift audio manually or to deal with it using some delay flag? Or, maybe, there is some other best way to fix it? Please, advice me)
And, globally, would you improve something in this conversion workflow?

[sneaker_ger]

Shifting the audio is probably the safest way to do it. Delay flags are more suited for music encoding with gapless concerts - a thing usually not needed for videos.

You could simply do it via e.g.:
eact3o input.wav output.m4a -55ms
or pipe
eac3to input.wav stdout.wav -55ms | neroaacenc -ignorelength -if - -of output.m4a

Some encoders - like qaac - allow to automatically drop it:
qaac -i --no-delay --adts input.wav -o output.aac

You may be able to speed up the process if you make it use less disk operations. Like do everything in ffmpeg (or a x264cli version with patched-in audio) in a single step or at least pipe the audio directly from e.g. ffmpeg to the aac encoder instead of writing a wav file first.

Beware of the following:
1. neroaacenc always outputs aac in m4a container with delay flagging. So if a muxer is able to automatically read these flags, it might try to correct that since it doesn't know you already shifted the input by 55ms. ffmpeg does not do that AFAIK, though.
2. the delay changes depending on encoding profile and samplerate. As long as you keep both the same you won't run into any problems.

[Blue_MiSfit]

Be aware, converting DV into H.264 is a great idea from an archival perspective. However, it's not necessarily a great idea from an editing perspective. Do you foresee the need to edit any of this content in the future? If so, I'd strongly advise you to keep it in DV.

[dasumin]

sneaker_ger, thank you for a detailed answer!

Shifting the audio is probably the safest way to do it. Delay flags are more suited for music encoding with gapless concerts - a thing usually not needed for videos.

Understood!


You could simply do it via e.g.:
eact3o input.wav output.m4a -55ms
or pipe
eac3to input.wav stdout.wav -55ms | neroaacenc -ignorelength -if - -of output.m4a

Some encoders - like qaac - allow to automatically drop it:
qaac -i --no-delay --adts input.wav -o output.aac

Here I have a question then, what aac encoder is worth using?
I was adviced to use neroaacenc, but I generally don't know its advantages.


Beware of the following:
1. neroaacenc always outputs aac in m4a container with delay flagging. So if a muxer is able to automatically read these flags, it might try to correct that since it doesn't know you already shifted the input by 55ms. ffmpeg does not do that AFAIK, though.
2. the delay changes depending on encoding profile and samplerate. As long as you keep both the same you won't run into any problems.
Ok! Thank you, got it!

[dasumin]

Be aware, converting DV into H.264 is a great idea from an archival perspective. However, it's not necessarily a great idea from an editing perspective. Do you foresee the need to edit any of this content in the future? If so, I'd strongly advise you to keep it in DV.

Blue_MiSfit, thank you!
Why is editing of AVC is not a great idea? Decoding and processing times or quality issues?

[Blue_MiSfit]

NLEs don't generally support it well - especially not in homegrown flavors as you're attempting to create.

AVCHD and AVC-Intra are notable exceptions, but those are their own beasts. There's no equivalent standard for progressive SD as you're encoding.

You might find a platform that supports it well, but there's nothing wrong with staying conservative.

[sneaker_ger]

Here I have a question then, what aac encoder is worth using?
I was adviced to use neroaacenc, but I generally don't know its advantages.

NeroAacEnc is a good, free, lightweight and easy to use aac encoder. If you're happy with it, you can continue using it. In the latest listening tests it was beaten by Apple (can be used through the aforementioned qaac), Fraunhofer and Coding Technologies, though. These can be a bit harder to "install" on the downside.