Small amount of blank space added to audio when converting with Handbreak

[Rowsinator]

I have noticed something relatively small and was wondering if I have really have an issue, or if I am thinking about this too much. I looked around on this and other websites to see if I could get an answer, and I would say this topic does not come up at all.

I'll first describe my workflow so you can understand the context of what I am asking.

1. I record a video using OBS and the lossless UT Video Codec. It has 2 audio streams, one for my voice, and another for the desktop sound.
Specifically I use AVI for the video container and PCM as the audio format. I have attached a picture of my OBS settings.

2. I use Davinci Resolve to edit my videos. In order to make the video compatible with Resolve, I convert the same video using handbrake two different times. The First time in high quality so the video compatible with Resolve, the second time for a proxy for easy editing within resolve.

This is where my lack of experience is getting the better of me. When I run the video through Handbrake, no matter the audio format I chose, it always re-encodes it with a bit of "extra" blank space at the beginning of the audio stream. I have attached a picture for what I mean. The video is the converted video, the top audio track is the converted audio track that is ahead, and the bottom audio track that was extracted from the original non-converted video, and is the one that is "correct".

I have drawn a line in yellow to illustrate that they do not match up.


I have tried changing the audio codec to AAC or AC3 in OBS to alleviate this problem, but the audio streams extracted from those videos also have those "extra" bits.

I have a couple of concerns that I would like to understand better within that context.

1. When converting the video using handbrake and the audio changes, does the video portion change to match that small change? I am under the impression it does not.

2. If I record with OBS using AAC as a format (for example), even though it adds that extra space, will it matter in the end video product due to some compensation? Does the video account for that extra space added?

3. As a work around I can extract the audio from the original source files and then add them in resolve after conversion, but I am concerned for the same reason as #2.

My ultimate goal is to have the audio and video match exactly as it was recorded, after conversion. I will state that when it comes to picture and audio quality, I am happy with the overall video and audio quality produced, but I see the post conversion audio/video mismatch as "making a mistake".

Is what I am asking for possible, am I overthinking this, and is what I want even desirable?

[Selur]

Check the headers of the output of handbrake, I assume that it has a/v delay info which compensated the delay you showed.

[Rowsinator]

So I after some googling, I downloaded MediaInfo which produced a lot of useful information, but I am unsure how to parse ~80% of it. This was the output from the converted file, pardon it's verbosity.

Is MediaInfo the correct tool for this, or is there a better way to look at the headers of the video file?


General
Complete name : D:\Re-Renders\
Format : MPEG-4
Format profile : Base Media / Version 2
Codec ID : mp42 (mp42/iso2/avc1/mp41)
File size : 1.73 GiB
Duration : 46 min 23 s
Overall bit rate : 5 324 kb/s
Encoded date : UTC 2021-09-14 12:10:01
Tagged date : UTC 2021-09-14 12:10:01
Writing application : HandBrake 1.4.1 2021081500

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : Baseline@L4.2
Format settings : 4 Ref Frames
Format settings, CABAC : No
Format settings, Reference : 4 frames
Format settings, GOP : M=1, N=60
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 46 min 23 s
Bit rate : 4 679 kb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 60.000 FPS
Standard : Component
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.038
Stream size : 1.52 GiB (88%)
Encoded date : UTC 2021-09-14 12:10:01
Tagged date : UTC 2021-09-14 12:10:01
Color range : Limited
Color primaries : BT.709
Transfer characteristics : BT.709
Matrix coefficients : BT.709
Codec configuration box : avcC

Audio #1
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : ac-3
Duration : 46 min 23 s
Source duration : 46 min 23 s
Bit rate mode : Constant
Bit rate : 320 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 106 MiB (6%)
Source stream size : 106 MiB (6%)
Title : Stereo
Service kind : Complete Main
Default : Yes
Alternate group : 1
Encoded date : UTC 2021-09-14 12:10:01
Tagged date : UTC 2021-09-14 12:10:01
mdhd_Duration : 2783611

Audio #2
ID : 3
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : ac-3
Duration : 46 min 23 s
Source duration : 46 min 23 s
Bit rate mode : Constant
Bit rate : 320 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Frame rate : 31.250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 106 MiB (6%)
Source stream size : 106 MiB (6%)
Title : Stereo
Service kind : Complete Main
Default : No
Alternate group : 1
Encoded date : UTC 2021-09-14 12:10:01
Tagged date : UTC 2021-09-14 12:10:01
mdhd_Duration : 2783611

[Selur]

Nope, no delay indication there.
Mediainfo would show a 'Delay relative to video'.
You might also want to look at the data of the input file wo see whether there is a delay info.

[Rowsinator]

This is the MediaInfo Output from the original recorded file.


General
Complete name : E:\Recordings\The Room Game\The Room The Game - Week 1.avi
Format : AVI
Format/Info : Audio Video Interleave
Format profile : OpenDML
File size : 76.1 GiB
Duration : 46 min 23 s
Overall bit rate : 235 Mb/s
Writing application : Lavf58.29.100

Video
ID : 0
Format : YUV
Codec ID : ULH0
Codec ID/Info : Ut Video Lossless Codec
Codec ID/Hint : Ut Video
Duration : 46 min 23 s
Bit rate : 229 Mb/s
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 60.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Compression mode : Lossless
Bits/(Pixel*Frame) : 1.839
Stream size : 74.1 GiB (97%)

Audio #1
ID : 1
Format : PCM
Format profile : Float
Codec ID : 00000003-0000-0010-8000-00AA00389B71
Codec ID/Hint : IEEE
Duration : 46 min 23 s
Bit rate mode : Constant
Bit rate : 3 072 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Bit depth : 32 bits
Stream size : 1 019 MiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 21 ms (1.28 video frame)

Audio #2
ID : 2
Format : PCM
Format profile : Float
Codec ID : 00000003-0000-0010-8000-00AA00389B71
Codec ID/Hint : IEEE
Duration : 46 min 23 s
Bit rate mode : Constant
Bit rate : 3 072 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48.0 kHz
Bit depth : 32 bits
Stream size : 1 019 MiB (1%)
Alignment : Aligned on interleaves
Interleave, duration : 21 ms (1.28 video frame)

[Selur]

Nope,no delay either, so this is probably a by product of handbrakes processing. (as a side note: as long as the delay is really short you won't notice it)

[Rowsinator]

The small "delay" also happens when I change my OBS audio codec to AAC or AC3. I think this might be a quirk of the codecs.

I put the files in audacity and you can see the delay more easily explained. Its more like an added silent wave form at the beginning. I have attached a picture of what I mean.

Top is AAC, the middle is AC3, and bottom is PCM. All were recorded using their respective codecs in OBS and stripped from the video file. Sound was playing constantly for each separate recording, and before the recording started.

[Selur]

Question is:
a. do you see/here the delay during playback when muxed (note that depending on the container and format there might be an additional delay, no clue whether handbrake compensates these, on muxing)
b. assuming you want to compensate the delay adding the delay info to the muxed container should help. (or alternativelay adjusting the audio stream) Since I don't use Handbrake at all I have no clue whether it allows to add a/v delay infos to the container. You could always use ffmpeg to remux and change the audio delay.

There's probably a handbrake user somewhere here in the forum that might be able to help with whether there is an option in handbrake to delay an audio/video stream.

Cu Selur

[Rowsinator]

To answer question a.
When I edit the file in Davinci Resolve, and I do an a/b test for the different audio streams, it is noticeable that the original PCM stream lines up better.

When you play them together, you get a strange echo(?) effect, due to the delay. The problem with this is that Davinci Resolve does not allow for small enough increments to edit and fix the audio.


As for question b.
These files are not the final products, and as such playback won't matter in the editor, at least as far as I can tell.

Unfortunately, even though handbrake supports audio codecs that do not add silence to the beginning of the audio, they are in a container (MKV) that Davinci Resolve will not support at least for the audio as the video comes over fine.

Sorry if this isn't helpful.

[Selur]

-> If handbrake creates audio but doesn't add a delay your best bet is probably try other tools for the conversion and see how they fair.