QAAC: discussion, questions, feature requests, etc., [originally a thread for a feature request] Options

[Bostedclog]

Before I decide to encode all of my music to qaac .Does anyone know if there will be any significant improvements in the near future regarding sound quality.Many thanks..

Sound quality is of course the same as files generated with Quicktime/iTunes directly, since qaac interfaces Apple's encoders. So you should bug Apple about their encoders if you deem them too bad. At relatively low bitrates, Quicktime was recently found to produce the highest quality AAC encodes, though.

I dont know whether my question came across wrong but I think the qtaac/qaac encoders are brilliant .I as just wondering if any big changes are expected if not Ill start encoding 11,000 tracks.

[LigH]

Sounds a bit like sending a letter praising the powerful engine and easily shifting gearbox to the manufacturers of the car chassis.

The author of qaac is not responsible for the quality of the AAC encoder developed for Apple QuickTime. He "only" gave you the ability to use it without the QuickTime Player application.

But I'd like to thank him a lot for this essential job, because it is a prerequisite to use it with different user interfaces.

This post has been edited by LigH: Jan 3 2012, 11:49

[sneaker]

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.

This post has been edited by sneaker: Feb 6 2012, 11:55

[nu774]

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?

[sneaker]

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 ~= 48ms
Comparing 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 ~= 96ms
But 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.

This post has been edited by sneaker: Feb 6 2012, 12:53

[nu774]

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


This post has been edited by nu774: Feb 6 2012, 13:18

[sneaker]

Sorry, I don't know what part of the work is Apple's and what is yours.

Can anyone with iTunes confirm that it has the same problem?

Another suggestion:
As the iTunes value is wrong, just write your own value. It is always fixed, isn't it? 117ms would equal "A14", roughly.

This post has been edited by sneaker: Feb 6 2012, 13:45

[Alex B]

This iTunes/QT HE issue is interesting.

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.

Though, I had earlier created a set of useful sample files: http://yabb.jriver.com/interact/index.php?...22862#msg422862 . In that package my iTunes encoded HE-AAC files indeed had incorrect iTunSMPB tags. I discovered that an early version of iTunes 10 didn't do this right:

From: http://yabb.jriver.com/interact/index.php?...23115#msg423115

FYI, I just noticed that the ITUNSMPB tag values in my "iTunes HE-AAC (SBR)" sample files are slightly off. This was caused by a buggy iTunes version (an early v.10 build).

I just installed the latest iTunes version (10.2.1.1) and the bug seems to be fixed. It produces values that are identical to the Nero and QuickTime values.

For encoding the "QuickTime LC-AAC" set I used the qaac frontend and it created correct ITUNSMPB tags.

So, if you are considering adding gapless support, don't use the "iTunes HE-AAC (SBR)" file set for testing the behavior.

This post has been edited by Alex B: Feb 6 2012, 18:20

[Alex B]

sneaker,

What decoder did you use?

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?

[sneaker]

sneaker,

What decoder did you use?

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)

[nu774]

I confirmed your findings with avconv.
Also found:

1. Actual content seems trimmed by 20ms or so.
2. 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.

When iTunSMPB says:

2112 + A + T (A: length of input, T: length of trailing zero)

Actually it looks like:

L + A' + T (L: actual leading delay, A': length of encoded samples, T: length of trailing zero)

where:

L ≒ 2580, A' = A - (L - 2112)

Note:

2580/22050 ≒ 0.117
(2580-2112)/22050 ≒ 0.02

I sent PM to squo asking about this.

Attached File(s)

 t.zip ( 5.43K ) Number of downloads: 63

 

[Alex B]

Something is definitely not right.

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

I'll upload the samples and add a link here.

EDIT

The sample package is available here: http://www.hydrogenaudio.org/forums/index....st&p=785135

This post has been edited by Alex B: Feb 7 2012, 16:06

[sneaker]

[/list]When iTunSMPB says:

2112 + A + T (A: length of input, T: length of trailing zero)

Actually it looks like:

L + A' + T (L: actual leading delay, A': length of encoded samples, T: length of trailing zero)

where:

L ≒ 2580, A' = A - (L - 2112)

Note:

Did you swap A and T, i.e. shouldn't iTunSMPB be L + T + A(')? At least that seems to be correct in the case of LC.

[nu774]

Did you swap A and T, i.e. shouldn't iTunSMPB be L + T + A(')? At least that seems to be correct in the case of LC.

Yes, as for iTunSMPB your order is correct. I described here in the order which appear in the actual audio stream.
Might have been misleading.

[Xenion]

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

[nu774]

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.

[Xenion]

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.

hm with aacs it works but not with alacs here (iTunes 10.5.3.3)

[yuker]

I've created tool for using "qaac" without installing QuickTime.
http://www.mediafire.com/?kk96ytd933bf119

[nu774]

Is this stripped version of lvqcl's package?
Eh, I see, that was on megaupload (and is already lost).

[Soulvomit]

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

Thank you, nu, for this great tool.

This post has been edited by Soulvomit: Feb 23 2012, 01:24

[nu774]

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.

[lvqcl]

Is this stripped version of lvqcl's package?

My version uses 7z.exe (and 7z.dll) for unpacking and yuker's uses 7za.exe and system32\msiexec.exe (interesting idea).

Eh, I see, that was on megaupload (and is already lost).

Reuploaded here:  makeportable.zip ( 674bytes ) Number of downloads: 209


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: 150

[Boulder]

I'm getting this error with qaac v1.31:

ERROR: libmp4v2: mp4v2::impl::MP4File::WriteBytes: write failed: errno: 28 (..\..\mp4v2\src\mp4file_io.cpp,163)

What does it mean? I was trying to encode a 5.1-channel DTS-HD MA track to 5.1-channel AAC using this command line:

eac3to.exe d:redline.dts stdout.wav | qaac.exe -i -N -V 82 --verbose --tmpdir d:\ - -o f:redline_audio.m4a

The error occurs always at the exact same spot.

By the way, qaac says that it's version 1.30.

[nu774]

ERROR: libmp4v2: mp4v2::impl::MP4File::WriteBytes: write failed: errno: 28 (..\..\mp4v2\src\mp4file_io.cpp,163)

What does it mean?

errno 28 means ENOSPC (No space left on device).

By the way, qaac says that it's version 1.30.

Thanks, updated files.

[Boulder]

Weird, there is enough space on drive F..or does it actually run out of space on drive D (tmpdir)?

This post has been edited by Boulder: Feb 26 2012, 18:37