Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: QAAC: discussion, questions, feature requests, etc. (Read 679245 times) previous topic - next topic
0 Members and 3 Guests are viewing this topic.

QAAC: discussion, questions, feature requests, etc.

Reply #325
Thank you sneaker, very helpful.

I just found that qaac was always outputting to m4a container but that I can force it to output ADTS AAC with "--adts" option.
If I output to ADTS AAC with qaac "--adts" option - then does the encoder delay also get added in that scenario?. I cant find a tool that can give me millisecond precise length information about an ADTS AAC file to see if my ADTS AAC created file is longer than my WAV or not.
I would prefer to create ADTS AAC and just use that directly inside of mkvmerge if it means that I do not have to muck around with any delays or paddings and am assured I am retaining perfect millisecond alignment in my resulting video file. For some reason i feel that mkvmerge was not auto-applying the 44ms delay (negatively) from the iTunSMPB m4a file field. Also when I didn't manually specify a negative delay for it - mkvmerge created a mkv file for me that had a slightly different video and audio duration as shown in MediaInfo and the audio seemed a tiny bit off. Best scenario would be if I could give mkvmerge an audio and video file with the exact same millisecond duration.

QAAC: discussion, questions, feature requests, etc.

Reply #326
ADTS files also suffer from delay and padding, but since there is no container to write the delay and padding information into, you have to take care of it yourself, by doing one of the following things:
1.) enter the delay manually into mkvmerge
2.) already cut a bit from the input file, e.g. cut the first 44 ms (*) with a wave editor or use the new --delay function of qaac.
(Don't do either of these with m4a output, though!)

(*) it is 2112 samples for LC, so you have to calculate the delay for different sample rates:
2112 / 48 (kHz) = 44 (ms)
2112 / 44,1 (kHz) = 48 (ms)
etc.

I would ignore the information about the mkv durations for now, as they are more irritating than helping.

Quote
For some reason i feel that mkvmerge was not auto-applying the 44ms delay (negatively) from the iTunSMPB m4a file field.


Feeling does not help, you have to make proper tests.

QAAC: discussion, questions, feature requests, etc.

Reply #327
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.

Well, by --nodelay what kind of implementation do you have in mind? Is that same as "--delay=-2112" ?
(--delay just chops the beginning / prepend silence before feeding input to encoder).

QAAC: discussion, questions, feature requests, etc.

Reply #328
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).


QAAC: discussion, questions, feature requests, etc.

Reply #330
Thanks for the link. I remember bringing up the issue some time ago when we still regarded this as a simple error on Apple's and Fraunhofer's part and only Nero seemed to make any sense.

 

QAAC: discussion, questions, feature requests, etc.

Reply #331
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:
[attachment=7286:qaac.zip]

QAAC: discussion, questions, feature requests, etc.

Reply #332
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:
[attachment=7286:qaac.zip]

@nu774 - Just tested qaac 2.11_NO_DELAY_TESTING - and it is working great. The m4a file produced with "--no-delay" flag is the exact same number of milliseconds as the source WAV.  Remuxing then gives me a perfectly synced and working video.

Also seems that the resultant file is not having end padding anymore since the beginning silence you are introducing + encoder delay results in a size aligned to a byte(?) boundary thus quicktime not adding end padding anymore correct?

Perhaps a bit more detail in the flag description would help referencing that this about the delay that iTunSMPB talks about. Such as follows:
Quote
--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.

QAAC: discussion, questions, feature requests, etc.

Reply #333
Well, you might be misunderstanding.
There's no way to remove trailing padding from AAC bitstream itself. Resultant length will be  always multiple of 1024 (1024 = frame length of AAC).
If you get exact length, it is because the decoder/demultiplexer you use takes care of iTunSMPB and removes trailing padding.

Having said that, --no-delay surely produces zero delay AAC bitstream, and would be enough for video even with trailing padding.
To be on the safer side, use LC-AAC only.

QAAC: discussion, questions, feature requests, etc.

Reply #334
If you get exact length, it is because the decoder/demultiplexer you use takes care of iTunSMPB and removes trailing padding.

Well, or it might be because of edts...
qaac doesn't put enough information into edts to achieve gapless playback, but valid length (in samples) is written there.

QAAC: discussion, questions, feature requests, etc.

Reply #335
My source comes from ac3 5.1 files which are downmixed to 2.0 through eac3to. In the case of source ac3 files - it seems that the sample counts are already divisible by 1024 probably because ac3 has a similar frame size requirement. So now I can input.ac3 > eac3to -downDpl > qaac --no-delay > output.m4a with exact same length as original ac3.

Before, if input sample count was already divisible by 1024 (as it already is for many files which may be used as input) - it was adding 2112 samples to beginning and 960 samples to end.

Now, with --no-delay if the input sample count is already divisible by 1024 - then the output file is exact same length as input. Otherwise if input file sample count is not divisible by 1024, the output file will have a few extra samples of silence padded onto the end until sample count is divisible by 1024. Either way - the beginning sync with the video stays intact.

If a person wants to produce an output file with exact same length as input file - they know that now it is possible by making the source have a sample count divisible by 1024 and running qaac with "-no-delay".

Thanks for helping me get perfectly aligned audio! Cheers.

QAAC: discussion, questions, feature requests, etc.

Reply #336
Just a suggestion, it would be helpful to add the following text to this page. For a long time I was having to run QuickTimeInstaller.exe or AppleApplicationSupport.msi on my computers to use qaac - only recently I found the fully portable solution via this forum. It would be helpful if text such as follows would be included in the documentation Installation page.

Quote
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.dll
QTfiles\CoreAudioToolbox.dll
QTfiles\CoreFoundation.dll
QTfiles\icudt46.dll
QTfiles\icuin40.dll
QTfiles\icuuc40.dll
QTfiles\libdispatch.dll
QTfiles\libicuin.dll
QTfiles\libicuuc.dll
QTfiles\objc.dll
QTfiles\pthreadVC2.dll
QTfiles\Microsoft.VC80.CRT\Microsoft.VC80.CRT.manifest
QTfiles\Microsoft.VC80.CRT\msvcp80.dll
QTfiles\Microsoft.VC80.CRT\msvcr80.dll

There 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.

QAAC: discussion, questions, feature requests, etc.

Reply #337
Please read from #280 in this thread.
I know many feel comfortable with portable version, and you are feel free to use it... but I'm hesitating to recommend using it officially.
It's Apple's encoder, they created it, and qaac is merely utilizing it (although I'm not an Apple fan-boy or something).

QAAC: discussion, questions, feature requests, etc.

Reply #338
[qaac] release 2.12 (refalac 1.12)
posted 16 minutes ago by nu 774
Add --no-delay option. (Read the discussion at HA thread from here).

--no-delay will compensate encoder delay (2112 samples) by prepending silence of 960 samples before sending input to encoder, then trimming 3 AAC frames at beginning (2112 + 960 = 3072 = 1024 * 3, where 1024 is the frame length of AAC. So total amount of delay will be exactly equals to length of 3 AAC frames). Note that these numbers are doubled in case of SBR.

This option is meant for video as a mean to resolve A/V sync issue. The resultant AAC will have exactly zero-delay, but might have pops/clicks at the beginning. Use with care.

QAAC: discussion, questions, feature requests, etc.

Reply #339
Actually I'd rather have it implemented as cutting off the delay from the input as to not have any clicks/pops since we can't have a gap-less playback with this anyways. But this is also ok - I guess I just didn't answer fast enough.

QAAC: discussion, questions, feature requests, etc.

Reply #340
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?

(Great tool, btw.)

QAAC: discussion, questions, feature requests, etc.

Reply #341
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?

Your expectation is simply wrong.
Read post #335.

QAAC: discussion, questions, feature requests, etc.

Reply #342
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?

Since AAC LC frame size is 1024 samples - the "qaac --no-delay" encoded audio file will have silence padding added onto the end of it until the last AAC frame is full (so that sample count becomes divisable by 1024).
If you give "qaac --no-delay" an input file with sample count already divisable by 1024 - then the duration exactly matches the original.

You can get "Samples count" in MediaInfo in "Debug > Advanced Mode".

QAAC: discussion, questions, feature requests, etc.

Reply #343
@nu774 - I am getting a discrepancy which I think may be a bug in qaac 2.12 when you use "--no-delay" with an input that doesn't have sample count already divisable by 1024. The numbers are correct if my input file has sample count divisable by 1024 - but the numbers don't add up when "qaac --no-delay" is given a file with sample count not divisable by 1024. See below the test case:

Input: S01E12.wav
Samples count                        : 127772160
Duration(ms)                          : 2661920

Console Command
>qaac.exe --tvbr 127 --quality 2 --rate keep --no-delay "S01E12.wav" -o "S01E12.m4a"
qaac 2.12, CoreAudioToolbox 7.9.8.2
S01E12.m4a
AAC-LC Encoder, TVBR q127, Quality 96
[100.0%] 44:21.940/44:21.940 (28.8x), ETA 0:00.000
127773120/127773120 samples processed in 1:32.468
Overall bitrate: 250.912kbps

Outut: S01E12.m4a
Samples count                            : 127772688
Duration(ms)                              : 2661931
iTunSMPB(hex)    00000000 00000000 00000200 00000000079DA600
iTunSMPB(dec)    00000000 00000000 512          127772160

PROBLEM: Number of samples in S01E12.m4a should be 127772160 + 512 = 127772672 which is divisable by 1024.
Instead S01E12.m4a has sample count which is 127772688 which is wrong and also not divisable by 1024.

QAAC: discussion, questions, feature requests, etc.

Reply #344
Thanks for reporting, I will look into it.

QAAC: discussion, questions, feature requests, etc.

Reply #345
Ah, it seems that I missed your point.
I don't know why MediaInfo shows something like that as "Sample Count", but I think it's not problem of qaac.

You can dump mp4 file structure by tools like mp4box or boxdumper (of L-SMASH), which is FAR more reliable than MediaInfo when you want to inspect MP4.
You can see AAC frame count by the following command in case of mp4box:
Code: [Select]
mp4box -std -diso foo.m4a | grep SampleCount

(In case of Windows use "findstr" instead of grep. "Sample" is a bit confusing, but this "Sample" means AAC frame).

For duration, you can do similarly the following:
Code: [Select]
mp4box -std -diso foo.m4a | grep Duration

This will give you several lines.
Duration of MovieHeaderBox(mvhd), MediaHeaderBox(mdhd), TrackHeaderBox(tkhd) will be all same, and will be equal to 1024 * SampleCount.
You will also get EditListEntry, duration in which give you the actual valid length, and which is equal to the value inside of iTunSMPB.

QAAC: discussion, questions, feature requests, etc.

Reply #346
Should I understand this like qaac is breaking gapless playback?
I didnot encounter any length mismatches so far (using qaac via pipe from foobar)

QAAC: discussion, questions, feature requests, etc.

Reply #347
Should 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.

QAAC: discussion, questions, feature requests, etc.

Reply #348
Should 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)

QAAC: discussion, questions, feature requests, etc.

Reply #349
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)

If your input has some amount of DTS/PTS offset, of course you have to take it into account.
However, what --no-delay does has nothing to do with the offset already in the source. --no-delay kills additional (fixed amount of) delay introduced by AAC encoder, and that's all.
You shouldn't use this for ordinary music encoding, or when you can solve A/V sync issue at video container level (by specifying amount of audio delay or something), and your player(demultiplexer) properly supports it.