[PATCH] High quality AAC encoder on Mac OS X

[danchr]

FAAC isn't a terribly good AAC coder. A test in 2004 found iTunes AAC to be significantly better than FAAC, and since then, I imagine the situation hasn't changed. Apple has continually developed their AAC codec, whereas FAAC has continually laid dormant



Below is a patch against HandBrake trunk, which introduces a Mac OS X-specific audio encoder on Mac OS X, which will transparently replace FAAC. I replaced HB_ACODEC_FAAC with HB_ACODEC_AAC to reflect this. Please note that I haven't completely cleaned up the patch; for instance, it contains portions to have the CLI build with Jam, useful when coding.

The patch is available here. SHA-256 sums:

Code: Select all

4cf0ea95c4d3c6673912b04499924009831aaaffce64670310828d959029cd1b  hb-maac.diff
e17b8d3f4c2d5a31ee1b8b92907a7ee82157364dfdce237ed16ca840b344dd40  hb-maac2.diff

EDIT: Second patch iteration.
EDIT: The link is dead.

[stmiller]

Maybe instead of replacing FAAC, have an option to use the iTunes encoder or FAAC?

I have found the exact opposite to be true, that FAAC is far superior to the iTunes AAC encoder. You can open an FAAC encoded file vs. an iTunes AAC encoded file in any spectral analysis viewer (such as this one http://www.baudline.com/ ) and see the difference yourself.

FAAC retains far more audio information vs. the comparable iTunes encoded AAC.

I just did some recent testing on this out of my own curiosity.

Here is FAAC ($ faac -q 150 -w file.wav) 1.3MB:



vs. comparable iTunes AAC, VBR: 1.0MB



Compare to the original 16bit PCM:

[saintdev]

I have found the exact opposite to be true, that FAAC is far superior to the iTunes AAC encoder. You can open an FAAC encoded file vs. an iTunes AAC encoded file in any spectral analysis viewer (such as this one http://www.baudline.com/ ) and see the difference yourself.

FAAC retains far more audio information vs. the comparable iTunes encoded AAC.

I just did some recent testing on this out of my own curiosity.

And have you done any subjective ABX testing? Every blind study that I've seen has FAAC rated very low compared to other AAC encoders. Especially iTunes, it's always at the top. Just because FAAC keeps more information doesn't mean it's keeping more useful information. Also you're really comparing apples to oranges here, as the iTunes AAC encoder has been shown to be really ABR when you select VBR. So if you really wanted to do a fair comparison you would need to use FAAC's ABR mode, instead of quality based.

@danchr: I do hope that you realize that we will NEVER include this patch in the HandBrake trunk. 1) QuickTime is not a GPL application, so it's against our license. 2) This is in no way cross platform (as you yourself state it's specific to Mac OS X).
Thank you for taking the time, however, to bring a HQ AAC encoder to the game.

[eddyg]

@danchr: I do hope that you realize that we will NEVER include this patch in the HandBrake trunk. 1) QuickTime is not a GPL application, so it's against our license. 2) This is in no way cross platform (as you yourself state it's specific to Mac OS X).
Thank you for taking the time, however, to bring a HQ AAC encoder to the game.

I think that not allowing the Core Audio encoder is not the same as including non GPL code. And that's because when you use Core Audio you are not linking in that library, you are simply linking against it. It must be in the OS for it to work. Therefore this is still no non GPL code in the HB image itself.

I see it the same as HB using the Mac GUI. It is also not GPL, but HB uses that.

Personally I'd like Core Audio to be an option as well as faac, when building an Apple binary. Faac can stay the default, but it is short sighted to limit access to an OS supplied library just because that library is not GPL.

Cheers, Ed.

[stmiller]

Also you're really comparing apples to oranges here, as the iTunes AAC encoder has been shown to be really ABR when you select VBR. So if you really wanted to do a fair comparison you would need to use FAAC's ABR mode, instead of quality based.

Ah! I see what you mean. Here is faac ABR:



Which is similar to that above iTunes one. But since iTunes doesn't have true VBR encoding, then faac or other encoders (Nero) would be a better option for VBR AAC.

I haven't done any blind tests; I have just been looking at what information is retained. It is curious that most all codecs filter drastically at 16k.

[danchr]

I haven't done any blind tests; I have just been looking at what information is retained. It is curious that most all codecs filter drastically at 16k.

Yes, they do that at lower quality levels. Probably because they can't retain the high frequencies anyway, or something. All the sophisticated coders do that; LAME and probably Ogg Vorbis do too. It's worth noting that when it comes to audio, only double-blind listening tests are useful for determining quality.

About the GPL argument; this is as GPL as the Cocoa frameworks, and the entire Windows operating system. Heck, not even the C runtimes and Mac OS X and Windows are GPL-compatibly licenced. I don't quite understand what the difference is? The GPL allows you to link against proprietary system libraries; otherwise, Handbrake could not exist.

I've tried to make the patch as unobtrusive as possible. If instead, I made it an option to use either QuickTime AAC or FAAC, would that be better?

[danchr]

I'll be on vacation the next week, so I won't be able to reply to posts. However, after that, I'll happily implement any suggested changes

[stmiller]

Yes, they do that at lower quality levels. Probably because they can't retain the high frequencies anyway, or something. All the sophisticated coders do that; LAME and probably Ogg Vorbis do too. It's worth noting that when it comes to audio, only double-blind listening tests are useful for determining quality.

FWIW: Ogg Vorbis does not filter drastically at 16k, nor does faac VBR. But LAME does, and iTunes MP3 and AAC both do. You can set filters in LAME to change this though.

Double-blind testing is helpful, though you can see as in this test people avoid the iTunes encoder for varying reasons:

http://www.hydrogenaudio.org/forums/ind ... c=36465but

With other tools you can actually compare the audio to the original, like on this page:

http://www.baudline.com/solutions/codec/index.html

Anyways, just wanted to say that you can analyze the actual signal and see distortion, accuracy of frequencies, etc. in a codec against the original audio.

[danchr]

FWIW: Ogg Vorbis does not filter drastically at 16k, nor does faac VBR. But LAME does, and iTunes MP3 and AAC both do. You can set filters in LAME to change this though.

Double-blind testing is helpful, though you can see as in this test people avoid the iTunes encoder for varying reasons:

http://www.hydrogenaudio.org/forums/ind ... opic=36465

Yes, iTunes doesn't feature a true VBR mode. Or rather, it doesn't feature the bitrate guruboolez chose to test. I would say that one individual finding that the QuickTime VBR offers too course settings hardly constitutes varying reasons…

With other tools you can actually compare the audio to the original, like on this page:a

http://www.baudline.com/solutions/codec/index.html

Anyways, just wanted to say that you can analyze the actual signal and see distortion, accuracy of frequencies, etc. in a codec against the original audio.

Yes, but that tells you nothing about the actual quality of the codec. The entire point of a coder is to throw away parts of audio which the human ear cannot hear. The only way tell that is to use double-blind listening tests. I used to follow the HA forums, and they were quite adamant on this issue.

BTW, I think it's worth pointing to this sentence in the test you link:

Some readers suggest me to include faac as competitor, but I felt as unfair to test an encoder which was probably not the state of the art of AAC format and to compare it to the most advanced implementation of other formats (MEGAMIX and LAME 3.97).

[stmiller]

BTW, I think it's worth pointing to this sentence in the test you link:

Some readers suggest me to include faac as competitor, but I felt as unfair to test an encoder which was probably not the state of the art of AAC format and to compare it to the most advanced implementation of other formats (MEGAMIX and LAME 3.97).

Yes. My point in showing you that link was his description of why the current iTunes AAC encoder is problematic. By 'state of the art' he is referring to the Nero AAC encoder. Not iTunes. See their AAC forum section for plenty of info on AAC encoding and Nero.

Yes, but that tells you nothing about the actual quality of the codec. The entire point of a coder is to throw away parts of audio which the human ear cannot hear.

And yes we all know how encoders work. My point is that you can see distortion, noise, and other problems in actually looking at the audio that results with different encoders using different spectral analysis software. If this doesn't concern you, then okay that is fine. I'm not disagreeing with you, just adding that there are tools to actually look at how well an encoder handles the actual audio data and the caliber of artifacts/noise/distortion, etc. that may (and do!) result in the encoding process.

I'd be glad to continue this discussion through private email, as this is getting OT from the HandBrake dev forum.

[danchr]

Yes. My point in showing you that link was his description of why the current iTunes AAC encoder is problematic. By 'state of the art' he is referring to the Nero AAC encoder. Not iTunes.

Well, whether Nero AAC or iTunes AAC is 'state of the art' may be debatable. It may even be that Nero AAC is significantly better than iTunes at high bitrates, but I haven't seen any evidence to suggest so. However, it is certain Nero AAC isn't available (yet) on Mac OS X, and also that there is sufficient evidence to state that QuickTime AAC offers superior quality to FAAC. For some people, FAAC may be better, but listening tests show that this is not the case for the general public.

I've made a new version of the patch available which offers the choice of FAAC or QuickTime AAC, but defaults to QuickTime. Please test.

[risck]

I've made a new version of the patch available which offers the choice of FAAC or QuickTime AAC, but defaults to QuickTime. Please test.

Personally given the choice between the two I would select the QT ACC over FAAC so I plan on giving this a shot, since I haven't looked yet does this have any hooks to the CLI?

[s55]

yeh, looks like it's got CLI tiein

[danchr]

yeh, looks like it's got CLI tiein

Indeed it does. I used HandBrakeCLI to test it, as it compiles faster. It's worth noting that the patch contains changes to make jam compile it on Mac OS X, and those changes probably would have to be reverted prior to inclusion in trunk.

HandBrakeCLI even mentions qtaac in it's help output.

[s55]

It's not going to be included in the trunk.

It's going to be left as a patch available for those feeling like trying it out.

[danchr]

It's not going to be included in the trunk.

Why not? It improves the quality of the encodes generated by HandBrake for the vast majority of Mac users. Is there any other way I could do it which would be fit for inclusion?

[s55]

Purely because its not cross platform. We are sticking to the same feature set for all platforms.

The patch is linked to from the wiki so anyone who really wishes to use it, can apply the patch to the svn and use it.

[danchr]

Purely because its not cross platform. We are sticking to the same feature set for all platforms.

That's sad. Fact is that there are no good AAC coders that are available on all platforms; QuickTime is only available on Mac OS X and Windows, and Nero Digital is only available on Windows and Linux.

It strikes me as sad to reject a patch on political grounds rather than technical.

[realityking]

Purely because its not cross platform. We are sticking to the same feature set for all platforms.

The patch is linked to from the wiki so anyone who really wishes to use it, can apply the patch to the svn and use it.

I am just asking out of curiosity:
If somebody would make the same thing for Windows would it then be considered cross platform or does it have to be available on every platform?

[s55]

would need to be available for all the platforms we support. (Including Linux)

[danchr]

would need to be available for all the platforms we support. (Including Linux)

I guess that leaves no option but maintaining a separate fork The question now is whether that's something I want to do…

[realityking]

would need to be available for all the platforms we support. (Including Linux)

I guess that leaves no option but maintaining a separate fork The question now is whether that's something I want to do…

Maybe you don't need to maintain a complete fork, but it would be nice if you could try to update your patch as needed to keep it working with current versions of HandBrake.

I would help you with non programming stuff (hosting for example) if you do plan fork since this is at least the second patch I like to use for me.

[Ritsuka]

As we all love cross-platform features parity in libhb, the truth is that after an year and half, there is no aac encoder on par with apple and nero ones yet (and not even par with lame and aoTuV).
So I think it would be a really nice addition to add apple's aac encoder as one of the usable encoder of HandBrake. At least on Mac OS X.

An updated patch:
- Does not replaces faac, but add ca_aac as a new aac encoder.
- Fixed a memory leak.
- Bit rate validation.
- The new encoder is enabled only on mac os x. So libhb still compiles without it on other platforms.

http://handbrake.fr/pastebin/pastebin.php?show=319

[nightstrm]

As we all love cross-platform features parity in libhb, the truth is that after an year and half, there is no aac encoder on par with apple and nero ones yet (and not even par with lame and aoTuV).
So I think it would be a really nice addition to add apple's aac encoder as one of the usable encoder of HandBrake. At least on Mac OS X.

An updated patch:
- Does not replaces faac, but add ca_aac as a new aac encoder.
- Fixed a memory leak.
- Bit rate validation.
- The new encoder is enabled only on mac os x. So libhb still compiles without it on other platforms.

http://handbrake.fr/pastebin/pastebin.php?show=319

Personally, I'd love for this to show up in SVN too... even if it is a hidden feature only accessible to those "in the know".

[jbrjake]

No one was denying that FAAC sucks, Ritsuka. The reason this was rejected last time is because HandBrake is not about shoving platform-specific features in the core library that make it give varying output on different platforms. It introduces complexity both to development and to support and betrays HandBrake's position as a truly cross-platform video transcoding solutions. We've finally got another interface that matches the MacGui feature for feature. I'm not sure it'd be a good thing to turn the other platforms into second class citizens again.