For some reason i feel that mkvmerge was not auto-applying the 44ms delay (negatively) from the iTunSMPB m4a file field.
Maybe you could add a "--nodelay" parameter to qaac. Since you already have implemented a delay switch, I guess it's trivial for you to implement and it could be useful for video encoding where gap-less playback does not matter.
Yes, basically. Of course also use the correct value for non-LC and write 0 ms delay into the iTunSMPB tag (or none at all).
For --no-delay, I'm thinking of implementing as follows:1. Prepend 960 samples of silence to the beginning (before sending to encoder). Then total amount of delay becomes 960 + 2112 = 3072 = 3 * 1024. For SBR, these numbers are doubled.2. Drop first 3 AAC frames after encoding.This method has a danger of introducing some pops/clicks, but can reduce zeroes at beginning when decoded, and also beginning of the input can be (hopefully) more or less restored (instead of just discarding them).Any comments?You can try this by the attached experimental implementation:
--no-delay Quicktime normally adds an encoder delay that is recorded in iTunSMPB tag. This flag compensates encoder delay by trimming a few frames from the beginning and then does not write iTunSMPB. This option is mainly intended for video, and don't use this if you don't understand what you are doing.
If you get exact length, it is because the decoder/demultiplexer you use takes care of iTunSMPB and removes trailing padding.
In lieu of installing Application Application Support, you may use qaac in a completely portable manner by including the following required files in a directory named "QTfiles" in the same location as qaac.exe:QTfiles\ASL.dllQTfiles\CoreAudioToolbox.dllQTfiles\CoreFoundation.dllQTfiles\icudt46.dllQTfiles\icuin40.dllQTfiles\icuuc40.dllQTfiles\libdispatch.dllQTfiles\libicuin.dllQTfiles\libicuuc.dllQTfiles\objc.dllQTfiles\pthreadVC2.dllQTfiles\Microsoft.VC80.CRT\Microsoft.VC80.CRT.manifestQTfiles\Microsoft.VC80.CRT\msvcp80.dllQTfiles\Microsoft.VC80.CRT\msvcr80.dllThere is a script available on the download page named makeportable.cmd that will extract these necessary files for you from installer package QuickTimeInstaller.exe available from Apple. To use - place both makeportable.cmd and QuickTimeInstaller.exe in a common directory - run makeportable.cmd - and it will extract the required files into a QTfiles subdirectory.
Per MediaInfo 0.7.61, the original video length was 23.790 secs. Without the --no-delay option, the encoded video is 23.872 sec. With the --no-delay option it is 23.807 sec. I was expecting it to exactly match the original. Thoughts?
I tried the --no-delay option on a video encode using Virtualdub 1.10.3 with x264 and qaac as external encoders and MP4Box as the muxer, all 32 bit, on a Windows 7 64 bit system.Per MediaInfo 0.7.61, the original video length was 23.790 secs. Without the --no-delay option, the encoded video is 23.872 sec. With the --no-delay option it is 23.807 sec. I was expecting it to exactly match the original. Thoughts?
mp4box -std -diso foo.m4a | grep SampleCount
mp4box -std -diso foo.m4a | grep Duration
Should I understand this like qaac is breaking gapless playback?I didnot encounter any length mismatches so far (using qaac via pipe from foobar)
Quote from: Anakunda on 17 January, 2013, 05:45:11 AMShould I understand this like qaac is breaking gapless playback?I didnot encounter any length mismatches so far (using qaac via pipe from foobar)Don't use --no-delay;Without --no-delay everything is same as before.--no-delay is just a HACK, which tries to resolve A/V sync issue of video, which should properly be solved by container/demultiplxer of video in the first place, and has nothing to do with AAC encoder like qaac.
I have always used a custom positive or negative delay for AAC conversions from AC3 or DTS as the audio was always badly out of sync with default delay (50-200ms in most cases)