qaac
qaac copied to clipboard
nu774
Delays + QAAC
Hi Nu!
Not really much of an issue but...question for you. I'm noticing that QAAC is applying delays to things....I'm just curious as to why.
I have several projects I'm working on - a lot of them involve slowdown encoding pipe via eac3to and a lot of others are straight encodes from .wav formats. I notice the .m4a done by QAAC is almost identical to the .wav starting point formation....not noticing anything that would cause delay to go off (I'm not using --no-delay as I heard it can lead to sometimes audio being cut off incorrectly or pops/clicks). Not sure if true...anyways the audio delay is just fine because it didn't seem to add anything to the beginning! (Verified using Audacity)
Source : 23.06.917 Encode: 23.06.905
Yet the merged mkv shows a delay of 22ms...and the file when dragged into audacity shows that it begins 20ms before it should compared to wav and qaac .m4a...im curious as to why? :/
https://user-images.githubusercontent.com/26451301/36822208-ad23b450-1cab-11e8-8173-839b5ed6de73.png
^ Highlighted is equal to delay that mkvmerge puts to the source aka +22 ms (with this delay it would equal the .m4a....which is the same .m4a merged!) So confused :/
Unrelated: how does one calculate the sample count (if divisible by 1024 for AAC) for a specific audio source?
Read this: https://hydrogenaud.io/index.php/topic,85135.msg921707.html#msg921707 and this: https://hydrogenaud.io/index.php/topic,85135.msg945299.html#msg945299
Not directly related to this question, but is any way to deal with priming after encode in order to stay in sync with picture? I mean can we just cut this delay losslessly? For example Scenarist BD (SD) cuts priming in DTS, DD and so on without reencoding the stream. But I could not find the tool for adts.
Dear Nuu,
I read in detail about those topics you linked, specifically post # 1026.
Very informative, and I thank you very much. However, to me at least, it didn't answer my question regarding the delay and how come the mkvmerged file is 22 ms earlier...compared to the actual .m4a (with a delay on the container for +22ms to equal the .wav/.m4a original files). Is this its way of handling the iTunSMPB from QAAC on the .m4a indicating the AAC MDTC delay you mentioned?
When I do --no-delay - it changes nothing just like your thread mentions, considering mkvmerge uses the iTunSMPB.
Also - how does one calculate "sample count" so one can see if they have a 1024 AAC compliant file? Is it a matter of looking at the runtime? running it through a program? Apologies. I'm nowhere near your level of talent in understanding audio intricacies.
However, to me at least, it didn't answer my question regarding the delay and how come the mkvmerged file is 22 ms earlier.
Short answer: I don't know. Longer answer: It's an issue of either matroska file or decoder side; To isolate the problem, try different encoders and decoders, or multpilexing with ffmpeg. Try yourself. If I remember correctly, faad automatically trims priming 1024 samples .
Also - how does one calculate "sample count" so one can see if they have a 1024 AAC compliant file?
As for iTunSMPB it's a simple tag. Just google it. As for m4a file structure, you need to read it's spec but it's big (ISO base media file format). You can inspect mp4 file structure by tools like mp4box, boxdumper or something.
I am converting audio of video files. Do I need --no-smart-padding in addition to the --no-delay to avoid A/V sync issues? Thank you.
Can you please also tell me what is the status of HE-AAC regarding to the A/V sync? because the --no-delay option doesn't work with it.
In the documentation, for --no-smart-padding, it's not clear what do you mean by
This option also works as a workaround for bug of CoreAudio HE-AAC encoder that stops encoding 1 frame too early. Setting this option can lead to gapless playback issue especially on HE-AAC.
what is the gapless playback issue especially on HE-AAC that you are talking about?
--no-delay and --num-priming doesn't work if --no-smart-padding is specified. --no-delay and --num-priming doesn't work for HE-AAC.
SBR header, which is required to decode SBR part of HE-AAC, is not present on every AAC frame. SBR header is written by the encoder only once per 0.5 second or something. Therefore, if we cut the first AAC frame off, the decoder cannot decode SBR part until the next SBR header comes. This makes cutting HE-AAC files difficult. To cut HE-AAC files correctly, we need to copy SBR header around, which requires complete AAC bitstream parser and reconstuction of SBR payload. For this reason qaac doesn't support --no-delay for HE-AAC (which requires cutting a few frames at the beginning).
Anyway, video should need a lot more bitrate compared to audio. Can't you just use 96kbps～128kbps AAC-LC instead? I don't use HE-AAC at all.
This option also works as a workaround for bug of CoreAudio HE-AAC encoder that stops encoding 1 frame too early. Setting this option can lead to gapless playback issue especially on HE-AAC.
what is the gapless playback issue especially on HE-AAC that you are talking about?
Due to the additional SBR decoder delay (441 samples), HE-AAC files need more padding samples (at least 441l samples or greater) at the ending to be fully decoded. However, CoreAudio encoder doesn't append it. Because of the bug, about 40% of HE-AAC files encoded by iTunes couldn't be fully decoded (it becomes a bit shorter than the original). I don't know if this is still true.
I appreciate your kind and fast reply. So if I use AAC-LC, let's say we have quality levels of: 1-poor 2-average 3-good 4-very good 5-excellent. Which bitrate, in your opinion, considered to be (4-very good) for 2 channels stereo and for 5.1 channels?
Sorry for asking again, what does --no-smart-padding exactly do? because I don't know what does (beginning and ending of input is extrapolated) mean? Your reply was not clear if this option has any effect on the delay or not. Could you please be more precise in your replies?
--no-smart-padding disables extrapolater and also disables padding/trimming work to achieve --no-delay. Enabling and disabling --no-smart-padding doesn't affect amount of the encoder delay. It's always 2112 samples. However, if you enable --smart-padding, you cannot use --no-delay to cancel out the 2112 samples delay.
Basically, you should not use --no-smart-padding at all.
Any comments on the bitrate that I asked you please? I'm not newbie to this, I just want your opinion as I saw hundreds of numbers on the internet regarding the bitrate.
Alright man, thank you so much for making this tool available to us and maintaining it. And sorry if I took from your time or disturbed you by my questions.
I need a little more help with this. I think I've read through all the available information about it and I still don't know what to do.
I separated lossless media files into video and audio files. Video files were transcoded with ffmpeg. I encoded the audio files with qaac for higher quality. So I basically have mp4 (H.265) and M. wave files.
I asked them whether ffmpeg supported iTunSMPB, and they said yes.
So in theory, I don't need to use --no-delay.
However, I carried out several tests and I cannot verify that. How could I do so?
I remuxed the files with this command:
ffmpeg -i audio.m4a -i video.mp4 -map 0:a -map 1:v -c copy output.mp4
I made three videos. I opened them up with different editors (audacity, ardour, mediainfo etc) and they all said --no-delay was the closest to the original. For example the duration of the final results with mediainfo: Original (wav): Audio duration 9 s 160 ms Encoded with QAAC: Audio duration 9 s 216 ms Encoded with QAAC --no-delay: Audio duration 9 s 174 ms
With graphical editors like Audacity, I can see that even if they aren't perfectly aligned --no-delay is the closest, however the very first samples are missing. How can I make sure that everything is in sync? Do audio editors lie? Should I use --no-delay with ffmpeg or should I leave it out?
