What is currently the best aac encoder? In doom9's forum somebody said it would be nero. Also fhg is said to be the best but it isn't available anywhere. What encoder would be the best option to encode my music to aac?

Nero or Psytel AACenc.

Sometimes Psytel performs better than Nero, but Nero is usually twice as faster for only a little less (probably barely noticeable) quality.

QuickTime is very good, according to some tests, but it lacks VBR, what makes it a poor contender.

Regards;

Roberto.

Liquid Audio?

Liquid audio is old, and based on FhG commercial AAC encoder.

Your only choice to get up-to-date Professional FhG AAC is using Sorenson Squeeze v3 or newer.

BTW: For those interested, Squeeze v3.5 still is limited to 128kbps AAC. No VBR either.

If you planned to update it, save yourself some time and bandwidth and don't download. It's only update is the inclusion of MainConcept MPEG1 and MPEG2 encoder - that are shitty, BTW.

Regards;

Roberto.

According to Guru's test
This encoder is even worse than psytel IIRC

Hrm... you read Guruboolez test in some wrong fashion.

Average scores of encoders (considering all tests):

QuickTime: 4.142
Ahead: 2.621
Psytel: 2.753
Sorenson: 3.384

The scores range from 1.0 to 5.0

Only encoder which doesn't have a new version either coming very soon (or new version already out) at the time of Guru's testing, is Psytel. The race for the better quality is now just beginning, and I'd expect probably new competitors coming outside Ahead, Dolby,FhG -block also..

So don't make any final conclusions yet, because the race was just started..

I figured out that Nero 5.5.10.28 has the AAC encoder dating from February 2003 (old) - and this will be updated in the next revision.

We should organize some serious listening tests for AAC encoders since iPod and iTunes generated a lot of interest into MP4 .

Does anyone know on which encoder Apples' product is based? Or is it a new development from Apple?
If anyone knows where Dolby's and FhG's encoders are used, I am interessted in this too ;-)

YES!!

I'm agree, too...
But I want test the new revision of your codec, Ivan.

There are some thing to note in my results.
PsyTEL & Ahead Nero aac/mp4 codec can't avoid some watery/metallic cymbals. This is really annoying on some popular music (the Red Hot Chili Peppers for exemple is constantly covered by cymbals). MP3/lame suffers in the same way at the same bitrate range. Quicktime codec is really clean in comparison. If my own Quicktime rating is between 4 and 5, it's mainly because I can't hear something irritating (contrary to Nero codec), but just a small lack in high frequency (on cymbal, again...), detectable on a direct comparison with the original file.

Note that curiously, I was able to differenciate Ahead/PsyTEL and Quictime on the lowpassing effect. It was really surprising, because these values seems to be very close. Sorenson is cutting under 16000 hertz : sound is less rich as Quicktime and Nero codec.

I'll make sure that the latest version is out in the next release of NERO - new version should also be 30% or more faster than the old one.

I agree that some serious testing of current AAC codecs is needed. Though a few questions remain unclear:
1. What bitrate(-range) should be tested on what kind of samples?
2. Who'd be willing to prepare/conclude/analyze a test like ff123's infamous 64kbps test?
3. Who'd be willing to actively participate in such a test?

Apple is using Dolby's encoder (Dolby Consumer Encoder)

Sorenson is using FhG's Pro encoder (slow one)

Nero is using Ahead's encoder


Also, there are few versions of these encoders - so it is really becoming interesting

as aac is getting more and more interesting for the dvd encoding people (doom9, etc...) it would be great to have 96kbs and 64kbs included and also sample(s) with people talking/speech (like in movies)...

Non-irritating (I prefer that term than transparency) encodings are interesting me a lot (for portable listening). I'm quite sure that 96 kbps and below are not enough for that performance (at least, for me). By non-irritating, I have in mind : no annoying artifacts, as audible distorsions, metallic coloration or consequent pre-echo. 16 Khz lowpassing isn't an issue for me, on a portable : electronic and headphone are rarely good enough. 128 kbps seems to be a very good compromise, especially for flash-memory players.


Why infamous ? I find it very interesting, with 12 different non-absolute-killer samples, and a lot of tester.

Thank you, Ivan.

Regards,
David

I would, no problem. I have the necessary time and I have the encoders. :B

But I would need some instructions from ff123, since I never did anything like this before. (although I had been collecting vocodecs hoping to prepare a listening test when Speex 1.0 got released. Never got around to doing it anyway - too few people care about speech coding)

This should be the minimum standard. I'd like something that is at least as good as lame --aps.

I'm sure you could get plenty of volunteers on the speex-dev list. Having formal listening tests for Speex would be cool.

Where is that located?



Well, my idea is test it against, at least, Acelp.net (used in WMA and Real Audio), g729 and MPEG4's CELP. I also have codecs for VoxWare, Quallcomm PureVoice, g711 (a/mu-law), GSM 6.10 and DSP TrueSpeech. Any comments on that?

My biggest problem here is that we won't have consistent bitrates, or frequencies. g729, for instance, is limited to 16kHz, 8 bits and 8kbps (the implementation I have, at least). Now, Acelp.net has a 8.5kbps setting - but it's limited to 8kHz. And so goes...

I would also need more samples - I only have a BBC sample of some news report.

Finally, I would need ff123's instructions.

Regards;

Roberto.

Didn't someone pick up the work on the FAAC encoder? It would be convenient with a small, free (!?) AAC encoder with good quality (who wouldn't?). Personally I think tests should be performed on files around 150 kbps. They should come out as good as LAME aps (i.e. transparent most of the time)

I agree with digitaldictator so far as a free AAC encoder that is being developed would be appreciated by many and open up AAC for people who don't like spending money.

Is FAAC still being developed? The last entry to the changelog on FAAC was by menno on 26/10/2001. So I'm guessing that development has stopped or something. Can anyone (Roberto or Menno or someone) offer any clarification on the status of the faac project?

Thanks

Faac is being heavily worked on by a guy nicknamed Knik. If you want to know what he has been doing to the encoder, visit the audiocoding.com forum.

Speed and quality increased very significantly the last few months.

So, let me give a quick overview what has to be done for the AAC encoder test (Someone should probably split the part about the speech codecs into the appropriate section):

1. Bitrate
Should it focus around 'consumer' (128 kbps - used by Apple) bitrates or the transparent/audiophile bitrates (>160kbps)?

2. Samples
I'd like to see a similiar selection of samples as in ff123's 64kbps test with probably one or two problem samples mixed into it.

3. Codecs
What codecs/encoders should be included? Should LAME/Vorbis be included as a reference for 'current'/alternative technology?

dev0

Thank you very much Roberto.

I would love to see how the AAC encoders do against LAME APS. Its basically the standard because before the new ipods, it was basically the only high quality option for people with portables.

Also, lets avoid <128. 95% of people interested in this comparison either have little interest in portables or a 10GB+ ipod. With this in mind lowbitrate tests are somewhat assinine.

aac is getting more and more interesting for the divx/xvid encoding scene and for this kind of people it would be very interesting to see bitrate tests around 96kbs (or even lower with aac+)

If such a test is carried out, I think it should have to parts: One of ~128kbps and one of ~192kbps. LAME 128kbps ABR and preset standard could be used as a reference, so people know if the improvement is worth switching.

I also believe that FAAC should be part of the test - I find that it gives quite good quality at 180-200kbps. If nothing else, FAAC should be part of it to show that they are taken seriously, and to let them know how well they are doing. Anyway, it's the only VBR encoder for mac, and the only encoder for everything other than mac and windows.

Anyway, about the ripping crowd - they shouldn't be taken too seriously. If they really knew what they were doing, they'd be using higher quality audio and always 44,1kHz. The video won't benifit much from an extra 100kb/s if it's already at 1Mb/s, and 48kHz doesn't really improve quality - at least not at 128kbps and less.

1) thanks that you take us so serious (everybody lives in his own tiny world )
2) higher audio bitrate means lower video bitrate and 100kbs more audio means a lot when the video bitrate was originaly 650kbs (if you aim to put a dvd on 1cd)!!!
3) many people already use 44.1khz, but some believe that this can cause sync-problems with the video for some reasons...
4) movie soundtracks are not like music clips cause there is a lot of speech, which means you dont need that much bitrate...
5) but if the audio-nuts dont want to support the video-nuts (), the video nuts will have to do their own tests and i am sure they will. 64kbs with aac+ would be great

You could do some simple math and figure out how much you have to scale the movie to make it look good in the new bandwidth requirements.

It won't lead to synch issues unless they are using buggy software. Resampling, when done properly doesn't alter duration or lead to noticable quality losses. It also has the disadvantage that many older computers - like mine - don't play 48kHz and thus have to downsample the audio using valuable CPU resources which could have been used for decoding video or post-processing it. Anyway, it's just as likely that there will be bugs on the decoder end, and that this downsampling will lead to bad synch.

Actually, in many cases, movie soundtracks are much more tuned for just the right experience than most music is. It is true that there are large portions in many movies which are easily compressed, but there can also be problematic portions here and there (explosions, music, etc.). That's why VBR suits it very well, and you will find that LAME r3mix or alt-preset standard will give ~140kbps or ~160kbps on most movies - and be almost transperant. This isn't all that much more than 96kbps, and if you insist on using a low bitrate - use VBR instead of ABR or CBR. The only problem with VBR is that you have to encode it before the video to find out how much space you have left.

If the problem was making a movie fit on one CD, wouldn't it be better to use the enhanced coding efficiency to improve quality rather than continue to rape the soundtrack?

EDIT: You can find some tips on how to get best quality/file size here. It's pretty MEncoder/FFmpeg specific, but it still is quite useful.

It is exactly the opposite reason that I leave sample rates at 48khz... modern (last 5 years ) sound cards will upsample all audio to 48kHz for output. AC97 rules the day. To downsample, even with SSRC, only to have it upsample on-the-fly (in a buggy fashion, with my sblive), doesn't make any sense.

-Chez

you can be sure that even "some simple math" cannot replace the quality loss you get in the video when you have 100kbs less to use...


yup (btw you always encode the audio before encoding the video to make it possible to reach exactly 700mb)


you can be sure that everybody who knows the stuff will always use "enhanced coding efficiency" to reach the best quality possible in any case

i wouldnt say that i am raping the soundtrack when i use 96kbs vorbis (but perhaps i have better eyes than ears )
if ogg vorbis at 96kbs sounds similar to lame at 128kbs (which is the lowest i would go with .mp3) why not using vorbis? and if aac at 96 sounds better than vorbis at that bitrate why not using aac?
of course the situation looks very different if you have lots of bitrate (2cd encodes..) but on 1 cd...

but nobody can be forced to include the 96kbs bitrate in his test so...

If you're already pushing the audio codec to it's limits, adding more data won't improve the situation. At 128kbps and less, all audio codecs cut off high frequencies, and thus you lose the main benifit of 48kHz audio. Anyway, 44,1kHz is what CDs and most games use - a soundcard incapable of handling it is IMHO defective.

(BTW, what's AC97 and SSRC?)


By simple math, I meant that you do the math and figure out what the optimal resolution is for the lowered bitrate. It's true, though, that if you go for a bitrate of 650kbps, it'll be hard to make the video look good even at 512x288, so naturally, there isn't much space for the audio. I would consider that too low a bitrate for high quality material. It's possible to minimise the quality loss in many ways.

I haven't heard enough of Ogg Vorbis to know whether 96kbps is any good. Even if it sounds as good as 128kbps MP3, I'd say that isn't enough. On movies, the "sound picture" is often as important as the actual pictures.

Anyway, this is getting very much off topic, and I think it's time to end this discussion.

Calm down, people...

I'm still looking into conductiong these listening tests. I have been reading ff123's page lately to find out how he conducts his, and I plan to start soon.

ATM, I wouldn't touch bitrates lower than 128kbps, at least not before AAC+ is released. Makes no sense, since I would have to redo these low bitrate tests after it's released.

128kbps seems to be a sweet spot. First, because Apple uses this bitrate for it's electronic music distribution. It would help us evaluate how their files supposedly sound.
Second, because Sorenson Squeeze (FhG Pro) only encodes up to 128kbps. :-/

I'm still thinking about what encoders I'll use, and how. QuickTime, Squeeze, FAAC, Psytel and Nero would surely be used, but I still wonder if I should use VBR when possible (since some encoders don't allow that, what could make things unfair), or not. I would probably also add Vorbis GT3, so that people can compare.

I may also need some Macintosh user (danchr? ) encoding the samples with latest QuickTime for me, since the version with updated AAC encoding routines hasn't arrived on Windows yet.

I'm also thinking about 10 or 12 samples, 2 of them would be problem cases, the rest would be a mix of musical styles.

Any comments? Any idea would be very welcome.

Regards;

Roberto.

I would be mainly interested in how the next Nero codec (after 5.5.10.28, at the extreme::high and the normal::high VBR settings) does against lame 3.90.3 --a-p s.
Quicktime Pro would have to use 160/192k CBR for that (not that I would ever use it). Dunno about the other encoders (FAAC, Psytel)... use VBR when possible, otherwise 160/192 CBR

EDIT: oh I forgot, when this already done one could as well throw in MPC -q5 and ogg -q6 to get a real nice comparison

I plan to do a higher bitrate test later, but ATM I would like to stay with 128, for the reasons I mentioned above.

Besides, at such high bitrates, many tunes start becoming transparent. It would make comparision difficult, except for the golden eared fellas.

First of all, you should be aware the FAAC doesn't support CBR currently - it's mainly VBR with an ABR mode added recently.

I'd be that mac user - send me the samples (you can email them if you want) or tell me where to get them, and I'll encode

I'd suggest one 128kbps CBR/ABR test and a ~190kbps ABR/VBR test (and in QT's case, CBR). This seems to be what most people go for anyway, and it'd be nice to have LAME 128 ABR and alt-preset standard as references. This way you could have two questions to be answered: "What is the best AAC coder?" and "Is AAC ready to take over from MP3 and/or Ogg Vorbis?"

BTW, shouldn't it be MPEG-4 AAC? It would also be a good idea to pass any MP4s/M4As through QuickTime - iTunes doesn't like them created by mp4creator.

Well, Psytel never supported CBR either. It's ABR being called CBR. >_<



Great. Thanks.



Yeah, probably I can add a Lame encoding as well. Must consider how much space the samples package would take, as well. Don't want to kill anybody's bandwidth. And the high bitrate test would happen some time later, at least, since I don't want to overload people with a daily listening test.



What do you mean?

Well, as long as I can decode them with FAAD (the samples would be distributed in FLAC and probably MAC format), it's OK.

Well, since ABR is CBR, only better, I figure that's OK


Cool. I've been testing FAAC again today, and I must say that I find it pretty good at 128kbps and up.

I would suggest distributing them as MP4 (with the extension m4a) and MP3 as well. Most mac users don't know how to decode lossless formats, but have QuickTime and/or iTunes at hand. (As long as it's MPEG-4 AAC and not MPEG-2 AAC, that's good enough.)

Anyway, the problems iTunes had with mp4creator have been solved in iTunes 4.0.1.

But then it wouldn't be a double blind test.

At least, not if I use Vorbis and MP3.

If I only use AAC, then it would be no problem, since it's very hard to tell the file from an encoder to the other by looking at it (you must know about fingerprints and whatnot)

True. Then there's only either Wave or AIFF. FLAC is playable on macs, but only from the command line, so most users wouldn't know how to do it. It might be nice for the Linux crowd, though. A solution would be to compress the raw sound files with BZip2, GZip or StuffIt. Personally, I prefer BZip2 - it's the best open source compressor, and can be handled both graphically and in the command line on Mac OS X - I guess the same goes for other systems.

If you want to oppose 4 or 5 aac codecs in a same (blind) test, don't oppose them to another format (especially Vorbis, easy to recognise).
I suggest you to perform two tests :

• AAC TEST, with only AAC encoding. This test will conclude what aac codec is able to be the best challenger against other audio formats.

• 128 LISTENING TEST : with the previous winner, opposed to mpc/mp3/atrac3/wma9 at ~130 kbps.

Good idea.

I think the best bet would be compress the files in bzip2 for everybody, and APE for those that can decompress it (it would help me save some bandwidth)

But, then again, MAC users wouldn't be able to perform an ABC/HR test, since ff123's tool is Windows only.

Great idea!

Soon, I'll start a thread asking for samples donation.

Or do you guys think I can use ff123's 64kbps test ones?

I like the ff123's 64kbps test set of samples. I'm not sure it's worth it to build a new set, though maybe one/few extreme samples should be included for the 128kbps test, and maybe remove some samples which are unlikely to give any bigger differences at 128kbps (at least maybe the BachS-sample)

I'm agree with JohnV. For the BachS sample, I suggest this new one :
http://membres.lycos.fr/guruboolez/BWV1011.flac

Same composer (Johann Sebastian Bach), same composition (6 Suites per violoncello solo senza basso), same instrument (cello), but other artist (Ophélie Gaillard) and sound engineer (Nicolas Bartholomée).

I used this sample, crisp and detailed cello, for comparison with lame ~130 & atrac3 132 kbps comparison. It's not a killer sample, but it wasn't too difficult to hear difference with atrac3 (NetMD SonicStage encoding) and with less evidence with mp3. I think it's a good sample for replacement, if we want to stay in the same category of music.

Wouldn't it be better to use FLAC for lossless? It's probably just as good and it works on Darwin (Mac OS X), Linux and most other UNIX-based systems too.

About ABC/HR, I'm not quite sure what it is, but it's true that there aren't any audio comparison tools for Mac OS X. I'll see if that ABC/HR is easily converted to Mac OS X.

Well, you complained about FLAC yourself. :B

"FLAC is playable on macs, but only from the command line, so most users wouldn't know how to do it. It might be nice for the Linux crowd, though. A solution would be to compress the raw sound files with BZip2, GZip or StuffIt."



that would be really cool.

Here's ff123's ABC/HR page:
http://www.ff123.net/abchr/abchr.html

Sources are available there.

Yeah, but you talk about using APE for lossless anyway And FLAC is still usable by expert mac users and Linux users. Even though I have the MAC sources and I got it to compile, it isn't as widespread as FLAC. Anyway, BZip2ed Wave should be good enough for most people.


Yeah, I downloaded them yesterday, but I haven't looked at them yet. I have an exam coming up on the 12th, and I won't do it before then. I can't guarantee I'll do it after that, but I'll try.