0.10 RC1 produces lower quality "hissy" AAC audio
Forum rules
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
*******************************
Please be aware we are now using GitHub for issue tracking and feature requests.
- This section of the forum is now closed to new topics.
*******************************
0.10 RC1 produces lower quality "hissy" AAC audio
Hi team,
I've found that encoding a video using Handbrake CLI 0.10 RC1 produced lower-quality and slightly distorted AAC audio (the treble is a bit "hissy" and garbled), whereas the previous stable version produces great clean audio, even though both were instructed to use 44khz 96kbps.
Command used
HandBrakeCLI --input ____ --output ____ --encoder x264 --quality 23 --ab 96 --x264-profile main --decomb --strict-anamorphic --x264-preset slow --maxWidth 640 --arate 44.1 --optimize
Sample files
Original MP4
MP4 encoded with 0.9.9, has clear audio
MP4 encoded with 0.10 RC1 (SVN 6468, downloaded on 27 Oct 2014), has lower quality "hissy" audio
Screen log
https://dl.dropboxusercontent.com/u/991 ... encode.txt
I've found that encoding a video using Handbrake CLI 0.10 RC1 produced lower-quality and slightly distorted AAC audio (the treble is a bit "hissy" and garbled), whereas the previous stable version produces great clean audio, even though both were instructed to use 44khz 96kbps.
Command used
HandBrakeCLI --input ____ --output ____ --encoder x264 --quality 23 --ab 96 --x264-profile main --decomb --strict-anamorphic --x264-preset slow --maxWidth 640 --arate 44.1 --optimize
Sample files
Original MP4
MP4 encoded with 0.9.9, has clear audio
MP4 encoded with 0.10 RC1 (SVN 6468, downloaded on 27 Oct 2014), has lower quality "hissy" audio
Screen log
https://dl.dropboxusercontent.com/u/991 ... encode.txt
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
The audio is still pretty bad with default settings (160kbps):
HandBrakeCLI --input ____ --output ____ --encoder x264
HandBrakeCLI --input ____ --output ____ --encoder x264
-
- Veteran User
- Posts: 440
- Joined: Fri Mar 09, 2012 5:26 am
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
well since the source is already AAC, just use AAC passthrough...
second, handbrake removed faac (used in 0.9.9) and replaced it with avaac... which is hardly ever without distortion from my testing...
if you really want to re-encode the audio, you'd best use fdkaac
second, handbrake removed faac (used in 0.9.9) and replaced it with avaac... which is hardly ever without distortion from my testing...
if you really want to re-encode the audio, you'd best use fdkaac
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
This unfortunately is to be expected. The LibAV AAC encoder is pretty basic. It's not very good.
We also include the FDK AAC encoder as a stop-gap measure until the libav encoder improves. Sadly, this encoder conflicts with HandBrake's GPL license so it's not a long term solution. Unlike faac though, it's at least distributable. So we are essentially dual licensed at the moment
Our hands are unfortunately tied.
We also include the FDK AAC encoder as a stop-gap measure until the libav encoder improves. Sadly, this encoder conflicts with HandBrake's GPL license so it's not a long term solution. Unlike faac though, it's at least distributable. So we are essentially dual licensed at the moment
Our hands are unfortunately tied.
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
Would us installing a decent audio codec ourselves and handbrake enableing the options in the GUI to use it if it's present on the system be an option?
-
- Veteran User
- Posts: 2697
- Joined: Thu Jan 22, 2009 8:04 pm
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
That has been discussed, and the answer is "No."
SC
SC
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
external or internal makes no difference. We cant link to libraries that are not GPL compatible.
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
Forgive my ignorance I'm not familiar with the legal stuff. So there is no way around it and there is no decent aac encoder with relaxed enough licencing to work something out? Audacity has an option to download lame and ffmpeg from within the app but it sounds like a different situation.
Does the restriction apply globaly or just to certain countries, if there is even one country that it doesn't apply we can add it and enable the options after the user has confirmed their in said country by ticking a box or something.
Does the restriction apply globaly or just to certain countries, if there is even one country that it doesn't apply we can add it and enable the options after the user has confirmed their in said country by ticking a box or something.
- JohnAStebbins
- HandBrake Team
- Posts: 5726
- Joined: Sat Feb 09, 2008 7:21 pm
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
You are overthinking this, i.e. putting much more thought into it than we ever do
Just use fdk-aac, it's much better than ffmpeg aac and quite good by many accounts.
Just use fdk-aac, it's much better than ffmpeg aac and quite good by many accounts.
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
I do use fdk-aac, all the time, because LibAV is rubbish. However as we know fdk-aac can be a massive bottleneck, so I'm exploring the possibility of somehow still using a codec that is decent quality and doesn't bottleneck.
If you would like to help acheive that, put your brain in gear and step on the accelerator, after all, if you don't use it you lose it
Maybe we need to look at how other applications are doing it for inspiration. If it's not been thought about much there is most likely a better solution.
If you would like to help acheive that, put your brain in gear and step on the accelerator, after all, if you don't use it you lose it
Maybe we need to look at how other applications are doing it for inspiration. If it's not been thought about much there is most likely a better solution.
- JohnAStebbins
- HandBrake Team
- Posts: 5726
- Joined: Sat Feb 09, 2008 7:21 pm
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
I don't need (or appreciate) a lecture about how to use my time (which is donated free of charge and limited). But you are free to speculate all you like.
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
It wasn't a lecture it was encouragement, chill out. I'm investigating not speculating, thank you.
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
GPL is GPL. Doesn't matter where you are. Region is not an issue.Does the restriction apply globaly or just to certain countries, if there is even one country that it doesn't apply we can add it and enable the options after the user has confirmed their in said country by ticking a box or something.
We are not encoder developers. There is barely enough time to keep this project going never-mind start a new project developing a new encoder. Fact is there just isn't any great GPL-compatible AAC encoders out there. All the top encoders are commercial.
You should also bare in mind, if someone develops the AAC encoder in libav further, it'll probably get a lot slower. The only reason it's fast, is because it's not doing an awful lot. That's also why it's a bit flaky. It's not making good optimisation decisions. It's no different that x264 in that regard. You use ultrafast settings, it turns a lot of stuff off. It's fast but the quality is awful.
I generally just run slower x264 settings so I don't see bottlenecking. Take advantage of the better quality and lower filesizes
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
Thanks for the reply s55.
If there are no suitable alternatives then fair enough, if there are no other workarounds such as the one I mentioned that are workable then fair enough, just trying to explore the possibilities, if that has already been done then fair enough.
There seems to be a big gap in the market for a decent affordable AAC codec, maybe someone will make one one day.
That's what I thought, oh well.s55 wrote:GPL is GPL. Doesn't matter where you are. Region is not an issue.
I never said you were or you should start developing one. And please don't think I don't appreciate what goes into this because I do and frankly, it's a travesty that you don't have more volunteers to develop what is quite possibly the best and most popular encoding app in the world.s55 wrote:We are not encoder developers. There is barely enough time to keep this project going never-mind start a new project developing a new encoder. Fact is there just isn't any great GPL-compatible AAC encoders out there. All the top encoders are commercial.
If there are no suitable alternatives then fair enough, if there are no other workarounds such as the one I mentioned that are workable then fair enough, just trying to explore the possibilities, if that has already been done then fair enough.
But isn't the main reason FDK is slower is because of poor optimisation/efficiency? I thought it was mostly that rather the amount of decisions it's making.s55 wrote:You should also bare in mind, if someone develops the AAC encoder in libav further, it'll probably get a lot slower. The only reason it's fast, is because it's not doing an awful lot. That's also why it's a bit flaky. It's not making good optimisation decisions. It's no different that x264 in that regard. You use ultrafast settings, it turns a lot of stuff off. It's fast but the quality is awful.
Me too, there are times though that you don't need to and speed is more important. That's the beauty of x264, many options to fit a wide range of requirements.s55 wrote:I generally just run slower x264 settings so I don't see bottlenecking. Take advantage of the better quality and lower filesizes
There seems to be a big gap in the market for a decent affordable AAC codec, maybe someone will make one one day.
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
Depends on how well it's done. Apple's encoder is about as fast as libav AAC as it currently stands, while still being one of the top AAC encoderss55 wrote:You should also bare in mind, if someone develops the AAC encoder in libav further, it'll probably get a lot slower. The only reason it's fast, is because it's not doing an awful lot.
Edit: also, while I've never tried it myself, Fraunhofer's other AAC encoder is supposedly better and faster than FDK…
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
Sounds interesting Rodeo.
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
So how does one use FDK-AAC on the command line? None of these appear to work...
Code: Select all
--aencoder fdkaac
--aencoder fdk-aac
--aencoder fdk
-
- Veteran User
- Posts: 440
- Joined: Fri Mar 09, 2012 5:26 am
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
fdk_aac or fdk_haac if using HE-AAC
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
This appears to work thoughsimoneast wrote:So how does one use FDK-AAC on the command line? None of these appear to work...
Code: Select all
--aencoder fdkaac --aencoder fdk-aac --aencoder fdk
Code: Select all
HandBrakeCLI --help
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
Oh, thanks! I always refer to the CLI guide in the wiki (much more readable) but the wiki doesn't contain that info yet.
- JohnAStebbins
- HandBrake Team
- Posts: 5726
- Joined: Sat Feb 09, 2008 7:21 pm
Re: 0.10 RC1 produces lower quality "hissy" AAC audio
Ok, I updated that part of the wiki. But there is probably a ton more that needs fixing.