IPB

Welcome Guest ( Log In | Register )

32 Pages V  « < 12 13 14 15 16 > »   
Reply to this topicStart new topic
QAAC: discussion, questions, feature requests, etc., [originally a thread for a feature request]
robertcollier4
post Jan 15 2013, 21:20
Post #326





Group: Members
Posts: 33
Joined: 25-November 12
Member No.: 104754



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.

This post has been edited by robertcollier4: Jan 15 2013, 22:02
Go to the top of the page
+Quote Post
sneaker
post Jan 15 2013, 22:03
Post #327





Group: Members
Posts: 38
Joined: 26-May 02
Member No.: 2129



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.

This post has been edited by sneaker: Jan 15 2013, 22:06
Go to the top of the page
+Quote Post
nu774
post Jan 16 2013, 02:14
Post #328





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (sneaker @ Jan 16 2013, 02:02) *
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).
Go to the top of the page
+Quote Post
sneaker
post Jan 16 2013, 02:22
Post #329





Group: Members
Posts: 38
Joined: 26-May 02
Member No.: 2129



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).
Go to the top of the page
+Quote Post
nu774
post Jan 16 2013, 02:26
Post #330





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (sneaker @ Jan 16 2013, 10:22) *
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).

OK. However, "correct value for non-LC" is not that simple.
Please read: http://www.hydrogenaudio.org/forums/index....showtopic=98450
Go to the top of the page
+Quote Post
sneaker
post Jan 16 2013, 02:30
Post #331





Group: Members
Posts: 38
Joined: 26-May 02
Member No.: 2129



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.

This post has been edited by sneaker: Jan 16 2013, 02:32
Go to the top of the page
+Quote Post
nu774
post Jan 16 2013, 04:18
Post #332





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



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:
Attached File  qaac.zip ( 493.2K ) Number of downloads: 83
Go to the top of the page
+Quote Post
robertcollier4
post Jan 16 2013, 07:54
Post #333





Group: Members
Posts: 33
Joined: 25-November 12
Member No.: 104754



QUOTE (nu774 @ Jan 15 2013, 19:18) *
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:
Attached File  qaac.zip ( 493.2K ) Number of downloads: 83

@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. biggrin.gif 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.


This post has been edited by robertcollier4: Jan 16 2013, 08:22
Go to the top of the page
+Quote Post
nu774
post Jan 16 2013, 09:18
Post #334





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



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.
Go to the top of the page
+Quote Post
nu774
post Jan 16 2013, 09:27
Post #335





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (nu774 @ Jan 16 2013, 17:18) *
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.
Go to the top of the page
+Quote Post
robertcollier4
post Jan 16 2013, 10:37
Post #336





Group: Members
Posts: 33
Joined: 25-November 12
Member No.: 104754



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.

This post has been edited by robertcollier4: Jan 16 2013, 10:50
Go to the top of the page
+Quote Post
robertcollier4
post Jan 16 2013, 11:30
Post #337





Group: Members
Posts: 33
Joined: 25-November 12
Member No.: 104754



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.


This post has been edited by robertcollier4: Jan 16 2013, 11:34
Go to the top of the page
+Quote Post
nu774
post Jan 16 2013, 12:38
Post #338





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



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).
Go to the top of the page
+Quote Post
sluggy
post Jan 16 2013, 14:24
Post #339





Group: Members
Posts: 59
Joined: 22-June 12
Member No.: 100900



[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.
Go to the top of the page
+Quote Post
sneaker
post Jan 16 2013, 23:47
Post #340





Group: Members
Posts: 38
Joined: 26-May 02
Member No.: 2129



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.
Go to the top of the page
+Quote Post
gottogo99
post Jan 17 2013, 04:00
Post #341





Group: Members
Posts: 111
Joined: 13-April 07
Member No.: 42452



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.)
Go to the top of the page
+Quote Post
nu774
post Jan 17 2013, 05:29
Post #342





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (gottogo99 @ Jan 17 2013, 12:00) *
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.
Go to the top of the page
+Quote Post
robertcollier4
post Jan 17 2013, 09:32
Post #343





Group: Members
Posts: 33
Joined: 25-November 12
Member No.: 104754



QUOTE (gottogo99 @ Jan 16 2013, 19:00) *
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".

This post has been edited by robertcollier4: Jan 17 2013, 09:42
Go to the top of the page
+Quote Post
robertcollier4
post Jan 17 2013, 10:19
Post #344





Group: Members
Posts: 33
Joined: 25-November 12
Member No.: 104754



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

This post has been edited by robertcollier4: Jan 17 2013, 10:39
Go to the top of the page
+Quote Post
nu774
post Jan 17 2013, 10:54
Post #345





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



Thanks for reporting, I will look into it.
Go to the top of the page
+Quote Post
nu774
post Jan 17 2013, 11:40
Post #346





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



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
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
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.
Go to the top of the page
+Quote Post
Anakunda
post Jan 17 2013, 11:45
Post #347





Group: Members
Posts: 486
Joined: 24-November 08
Member No.: 63072



Should I understand this like qaac is breaking gapless playback?
I didnot encounter any length mismatches so far (using qaac via pipe from foobar)
Go to the top of the page
+Quote Post
nu774
post Jan 17 2013, 11:54
Post #348





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (Anakunda @ Jan 17 2013, 19:45) *
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.
Go to the top of the page
+Quote Post
Anakunda
post Jan 17 2013, 12:02
Post #349





Group: Members
Posts: 486
Joined: 24-November 08
Member No.: 63072



QUOTE (nu774 @ Jan 17 2013, 11:54) *
QUOTE (Anakunda @ Jan 17 2013, 19:45) *
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)
Go to the top of the page
+Quote Post
nu774
post Jan 17 2013, 12:29
Post #350





Group: Developer
Posts: 565
Joined: 22-November 10
From: Japan
Member No.: 85902



QUOTE (Anakunda @ Jan 17 2013, 20:02) *
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.
Go to the top of the page
+Quote Post

32 Pages V  « < 12 13 14 15 16 > » 
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 29th December 2014 - 17:25