Bug report:It seems that the "iTunSMPB" tag is written incorrectly for HE output. Instead of writing the correct delay value, it will always write the standard LC value (840).Haven't checked padding value yet.

Bug report:It seems that the "iTunSMPB" tag is written incorrectly for HE output. Instead of writing the correct delay value, it will always write the standard LC value (840).Haven't checked padding value yet.

As far as I know, iTunes is using exactly the same value including padding.How did you think it is incorrect?

Bug report:It seems that the "iTunSMPB" tag is written incorrectly for HE output. Instead of writing the correct delay value, it will always write the standard LC value (840).Haven't checked padding value yet.

As far as I know, iTunes is using exactly the same value including padding.How did you think it is incorrect?

I compared the value to the actual delay that I can see in Audacity after decoding to wav.For LC the value stored in the tag as delay is 840 which equals 2112 samples in decimal notation. The source file was 44.1 KHz.2112/44100Hz ~= 48msComparing the original source wav and the decoded wav I can see that this is correct.Now for HE qaac also writes 840, which would mean:2112/22050Hz ~= 96msBut comparing the files in Audacity I can see that the actual delay is 117ms

When I encode with NeroAacEnc it will correctly adapt the value to the output profile.

If you think it's problem of Apple encoder, you should report this to Apple.qaac is just using the value which obtained via CoreAudioToolbox API. Probably same for iTunes(leading/trailing frames of AudioConverterPrimeInfo).

In last July I helped the JRiver developers in adding support for iTunSMPB to their recently introduced new decoder: http://yabb.jriver.com/interact/index.php?topic=65076. Gapless HE and HE+PS decoding didn't initially work correctly because the doubled output sample rate was not taken into account. But this was a decoder issue, not an iTunSMPB tag issue. AFAIK, it is correct to write the tag values that work with the LC part. If a decoder creates the reconstructed higher sample rate output, it should adjust the values accordingly.

Could it be possible that the decoder uses the older Nero/FAAC gapless method (and does it correctly) if that data is present, but does not interpret iTunSMPB correctly if the format is HE-AAC?

I'm using the AviSynth plug-in ffmpegsource. It does not seem to read the iTunSMPB tag nor the old Nero info at all, thus is ideal for finding out the encoder delay. If it would just be an issue of not taking the halved sample rate into consideration, the delay should be off by a factor of two, which is not the case. (117ms / 2 != 96ms)

QuickTime player decodes it without leading zeros. Instead, zero padding is appended to the end. Whole length is same with avconv, and actual content is trimmed here, too. Probably it is already trimmed when it is encoded.

For a practical test, I created a short 44.1 kHz wav file. It contains 102400 samples of 8820 Hz sine wave.

I converted the sample to HE-AAC and LC-AAC with qaac. Then I decoded the resulting m4a files with foobar2000 and iTunes.

Foobar2000 produced accurate file durations for both decoded files (102400 samples), but the decoded HE sample is delayed by a bit over 20 ms.

iTunes didn't even get the durations right. The decoded LC file is 102312 samples and the decoded HE file is 103358. The latter contains a bit over 20 ms of some quieter stuff in the end (quieter by about -20 dB).

with --concat-cuesheet foobar2000 reads the chapters perfectly but itunes does not. does itunes not support chapters?

If I remember correctly, iTunes was ignoring ALAC chapter before.However, it looks like iTunes is now supporting chapter of ALAC in m4a.In my environment (iTunes 10.5.3.3), "chapter" menu appears when a file including chapter is being played.

If I remember correctly, iTunes was ignoring ALAC chapter before.However, it looks like iTunes is now supporting chapter of ALAC in m4a.In my environment (iTunes 10.5.3.3), "chapter" menu appears when a file including chapter is being played.

Would it be possible to disable normalization when downmixing? If not, could the option be added?

Thank you, nu, for this great tool.

When you want different gain for each channel, you might surely want to disable automatic normalization of matrix coefficients.Since automatic normalization of coefficients will be usually convenient, I will leave it as default and add another option.Thanks.

Also, it seems that the biggest dll file (icudt46.dll) contains only some data for ICU library. it is possible to compile 'dummy' icudt46.dll that doesn't contain any data. This version is sufficient for qaac encoding:icudt46_dummy.zip ( 2.01K )
Number of downloads: 248