MeGui problem with QAAC

[UserName351]

Hello,

I'm trying to encode the audio of mkv files using MeGUI, i choose to not re-encode the video. The audios are DTS and I want to convert them to AAC LC using QAAC.
I already downloaded the quicktime installer and sent it to the script to get the QTfiles. But it still keeps saying that the CoreAudioToolbox.dll file is needed, but the file is right there. (I tried the Itunes installer but it doesn't have the right Apple support msi file)

I have the latest MeGUI according to videohelp's page to download MeGui (MeGUI-2913-64)

I have no idea what to do.

[hello_hello]

I'm using 32 bit MeGUI but from memory the 64 bit version comes with qaac.exe and qaac64.exe. Does MeGUI's options include a way of telling it which to use? And I assume you need either 32 or 64 bit iTunes/CoreAudioToolbox.dll to match.

Apparently Apple changed the file naming scheme so makeportable.cmd that comes with MeGUI probably won't work with the latest itunes, but I'm pretty sure the official version was updated. It looks like it's called makeportable2.cmd now.
https://github.com/nu774/makeportable/blob/master/makeportable2.cmd

If none of that helps track down the problem, maybe post the MeGUI log file to see if it provides any clues.

[UserName351]

I'm using 32 bit MeGUI but from memory the 64 bit version comes with qaac.exe and qaac64.exe. Does MeGUI's options include a way of telling it which to use? And I assume you need either 32 or 64 bit iTunes/CoreAudioToolbox.dll to match.

Apparently Apple changed the file naming scheme so makeportable.cmd that comes with MeGUI probably won't work with the latest itunes, but I'm pretty sure the official version was updated. It looks like it's called makeportable2.cmd now.
https://github.com/nu774/makeportable/blob/master/makeportable2.cmd

If none of that helps track down the problem, maybe post the MeGUI log file to see if it provides any clues.

Using that other makeportable with iTunes did the job thank you. I guess the QuickTime installer must have been 32 bit, since there was not mention of either in the whole page I didn't even think about it.

I have a question about the output file, if the frame rate for the audio changed to half, that's fine right? it sounded fine to me but I don't know much.

[hello_hello]

From memory, all lossy encoders divide the audio into little sections, with each section containing a certain number of audio samples, and each of those sections is called a frame. Therefore lossy encoders technically have a frame rate, which changes according to the audio sample rate (48k or 44.1k etc) but it has nothing to do with the video frame rate, so it's nothing to worry about.

[UserName351]

From memory, all lossy encoders divide the audio into little sections, with each section containing a certain number of audio samples, and each of those sections is called a frame. Therefore lossy encoders technically have a frame rate, which changes according to the audio sample rate (48k or 44.1k etc) but it has nothing to do with the video frame rate, so it's nothing to worry about.

Alright, thx again for your help

[UserName351]

From memory, all lossy encoders divide the audio into little sections, with each section containing a certain number of audio samples, and each of those sections is called a frame. Therefore lossy encoders technically have a frame rate, which changes according to the audio sample rate (48k or 44.1k etc) but it has nothing to do with the video frame rate, so it's nothing to worry about.

Sorry to bother you again with a really picky question, I just noticed this, there's a Delay relative to video of -7 ms according to mediainfo even though I didn't tell mkvtoolnix to do that. That's barelly anything but I feel like something went wrong, or is it normal?

[johns0]

It's normal.

[UserName351]

It's normal.

alright, thank you for the help both ;D

[hello_hello]

Except there's no such thing as a negative delay for MKVs. You must have a positive video delay which MediaInfo converts into a negative audio delay, or as it describes it, a delay relative to the video. Why you have a delay, I don't know. Did you split the video with MKVToolnix at all?

Here's a quick home-made example. There's a 500ms video delay and a 209ms audio delay, which makes the audio delay relative to the video -291ms. gMKVExtractGUI will show you what's really happening. Not that any of it matters much as long as the audio and video are in sync.


[Attachment 62713 - Click to enlarge]


[Attachment 62714 - Click to enlarge]

There's also a "no delay" checkbox in MeGUI's QAAC encoder configuration. Lossy encoders always add padding (silence) to the beginning of the audio, causing a slight delay (usually in the vicinity of 40ms or so). MKVToolNix will compensate for it when muxing by removing the padding, but it can only do so by removing whole audio frames, so it usually has to add a small audio delay as well to be exact, usually under 10ms.

Anyway, the "no delay" option gets QAAC to remove the extra padding itself, so none of what I've described when muxing needs to happen. Once again though, it doesn't matter which way you do it.

[UserName351]

Except there's no such thing as a negative delay for MKVs. You must have a positive video delay which MediaInfo converts into a negative audio delay, or as it describes it, a delay relative to the video. Why you have a delay, I don't know. Did you split the video with MKVToolnix at all?

There's also a "no delay" checkbox in MeGUI's QAAC encoder configuration. Lossy encoders always add padding (silence) to the beginning of the audio, causing a slight delay (usually in the vicinity of 40ms or so). MKVToolNix will compensate for it when muxing by removing the padding, but it can only do so by removing whole audio frames, so it usually has to add a small audio delay as well to be exact, usually under 10ms.

Anyway, the "no delay" option gets QAAC to remove the extra padding itself, so none of what I've described when muxing needs to happen. Once again though, it doesn't matter which way you do it.

Actually, the file that I got from MeGUI doesn't have the delay, I had the no delay checkbox on.
However when I finished converting the audio to aac, I muxed the audios with mkvtoolnix to with another video, that's after that, that the delay appeared on all the files, the same -7ms delay.
I checked with gMKVExtractGUI, the video has a delay of [7ms][7ms] and audios [0][-7ms]

EDIT: Somehow the final files got corrupted overnight (idk why, but I had made a copy elsewhere (still same delay but maybe there's a connection))

[hello_hello]

It probably just means the file you muxed the audio with already had a 7ms video delay. When you open a source file with existing streams, MKVToolNix will keep any existing delay for those streams if they're included in the output MKV. There's no reason why your source files couldn't have a video delay. I don't know why, or where they came from though.

Assuming you extracted the audio from a file with video too....
When you extract it, MeGUI should save it with any existing delay in the file name, but if you re-encode it, by default MeGUI removes some audio or adds silence to the beginning to remove the delay. It also changes the delay in the output file's name to zero. That aside...

The "correct" audio delay really depends on what you're muxing it with. MeGUI ignores any video delay and uses the absolute audio delay as the delay for the extracted audio. If you re-encode the video though, the original video delay is lost. For example if there was no audio delay and a 100ms video delay, MeGUI would extract the audio as though it had no delay. If you remux the encoded audio with MKVToolNix by opening the original file and adding the audio, the original video delay will be kept and everything will be fine. If you've re-encoded the video, the audio should be muxed with a -100ms delay to compensate for the fact that there's no longer a video delay.

Extracting audio with gMKVExtractGUI works the opposite way. The delay written to the extracted audio is the delay relative to the video, under the assumption the video will be re-encoded too and the original video delay lost. So it'll write -100ms to the same extracted audio stream. If you remuxed that audio with the original MKV though, the audio delay should be zero, or a -100ms delay should be applied to the video. If the video has been re-encoded and it's original delay lost, then a -100ms audio delay would be correct.

I don't know how much sense that all makes, but for a single source file one solution is to open it first with gMKVExtractGUI to check for a video delay. If there is one, lets says 20ms, open it with MKVToolNix and apply a -20ms delay to every stream in the file to set the video delay to zero and delay the other streams to match, then remux and use the new MKV as your source file. It's pretty hard to go wrong that way.

If you're muxing audio and video originating from different sources, then all bets are off anyway because there's no guarantee the AV sync will be the same.

Edit: By the way, as there's no such thing as a negative delay for MKVs, applying a negative audio delay when muxing will cause MKVToolNix to cut the delay amount from the beginning of the audio. Generally it can't do that exactly as it can only cut full audio frames for lossy audio. So if three audio frames = 120ms, applying a -100ms audio delay would cause MKVToolnix to remove 3 audio frames or 120ms worth of audio from the beginning, and the output MKV would have an audio delay of +20ms to make up the difference.

[hello_hello]

Actually, the file that I got from MeGUI doesn't have the delay, I had the no delay checkbox on.

The no delay option prevents the encoder from adding padding (silence) to the beginning of the audio, which effectively adds a delay where there wasn't one before. An audio delay written to the source container (MKV or whatever) is a different thing.

[UserName351]

I don't know how much sense that all makes, but for a single source file one solution is to open it first with gMKVExtractGUI to check for a video delay. If there is one, lets says 20ms, open it with MKVToolNix and apply a -20ms delay to every stream in the file to set the video delay to zero and delay the other streams to match, then remux and use the new MKV as your source file. It's pretty hard to go wrong that way.

I checked the "audio source" video and there was no delay, and checked if both videos were frame synchronised using a avs script and Virtual Dub but forgot to check the "video source" video for any delays, it indeed has that delay.
Thank you for your help