Recently i've learned to prefer FAAC v1.24.1 (from rarewares.org) for my aac (ipod) encodes and was looking to see if there was any new development from that front, esp since Itunes v5/QT 7 but was disapointed when their latest snapshot was from 10-18-2004.

Has development stopped ... should i switch to nero for my transcode? i've noticed that even nero w/preset portable is avg ~135 kbps. FAAC -q100 was avg ~120 which is what i was hoping for my ipods.

anyone have any suggestions?

If consistent high quality is what you're after, I think iTunes is the best choice. One thing's for sure, it'll take a while before FAAC ever catches up with iTunes/Nero..

All of the audio tests point to iTunes as being the best AAC encoder out there even when comparing iTunes CBR to Nero/FAAC VBR files. I think that QuickTime 7 even improves upon the quality of AAC encoded files, just from recent tests I have seen on the net.

Hmmm the reason i dont use ItunesEncode w/my transcode is becuz i cant seem to have it just transcode my files w/out adding it to Itunes. I tried -d and stuff but it still copies the m4a file to my Itunes. (Not in program but in my c:\~)

Not stopped, but slowed down quite a bit. Nero AG hired away the most talented coders working on the project for their AAC encoder. At least they still get time to work on FAAD.

That's actually false. Menno works on the decoder, Ivan never worked on FAAC, and knik (who did most recent FAAC development) never worked for us.

I don't really understand why noone works on FAAC, especially as it's trivial to improve it at this point. People who do free stuff prefer Vorbis perhaps?

it is truely in an sad state of development

we need to get people working on mp3 into aac (faac) or something more productive. how much better can lame get?


later

I don't think there's a limit how much Lame can be improved. There's always something that can be done.

There is a limit to the quality the MP3 format can provide at a given bitrate. Sure you can always improve an MP3 encoder, but the steps would in theory be getting smaller and smaller, where the same amount of work on faac would yield much more improvement.

In theory.

i agree with that statement, mp3 vs aac are like a generation apart right? even w/improvements and such aac techically is superior to mp3. Even wehn the first aac codecs came out my friends said that aac128 sounded similiar to mp3192.

But we now all know thats not true, don't we?

The only way to prove AAC is a better standard than MP3 is developing an AAC codec that is significantly better than any MP3 codec at any given bit rate. Correct me if I'm wrong, but this is not been done yet besides on the (very) low bit rate area (and perhaps for multichannel).

Theoretical (technological) superiority doesn't (or shouldn't) mean a damn thing to anyone.

This I don't understand. The statement was about technical superiority. AAC is definetely technically superior to MP3.

"developing an AAC codec that is significantly better than any MP3 codec at any given bit rate" is impossible, because how are you going to improve upon LAME MP3 CB320kbps?

AAC's superiority is particularly pronounced at lower bitrates (and I'm still discounting HE-AAC now).

The thread is about where to put development effort. For that purpose, technical superiority matters much more than current performance, because the goal is exactly to make such a better encoder.

Very simple, make an AAC encoder that gives the same quality at half the bitrate or 75% of it or at least something that gives me some space savings.

I would be willing to accept a bet that the best AAC encoder beats or equals LAME CBR 320kbps with AAC CBR 240kbps (75%)

Yes... equals ok... beats... hmmm...

But LAME CBR 320 was maybe not the best example...

You said "at any bitrate". AAC is already superior at low bitrates and you excluded that. Now high bitrates don't count either.

I don't think you have much of a point left.

I think you misunderstand my point. AAC encoders do not greatly diminish the bit rate needed for transparancy compared to Lame MP3 (correct me if I'm wrong). The only improvement is seen on low bit rates.

Saying AAC 240 kbps is the same as MP3 320 kbps is the same as saying AAC 240 kbps is the same as Lame --aps (for most people). You can't call that a real gain cause 320 kbps mp3 is generally overkill.

Yeah,you are probably right,stephanV. Bur what about AAC on 128 or 192 kbps,what is the situation on this bitrates.

I assume that AAC can beat MP3 at this bitrates.

That's a statement that is QUITE a bit more limited than your original one.

Yes

i agree too...

that's why i started this subject, wondering on the development of the open source codec.

Do you just want to win this argument or something Garf? If he says "ok fine you are right and I am wrong" can we then discuss this further? Cause it seems you are just hankering to be right about something.

Same feeling...



And I'm expecting to see u giving out anything to prove this.

I'm sorry but it is not. In my first post I never denied that AAC did better on lower bit rates, I merely said that it is not superior on the whole range of bit rates. What you did was single out an example on the upper end of bit rates and said that AAC can't possibly do better than that (which you then contradicted as you said afterwards that AAC 240 kbps would possibly be better, so what is it now anyway?); as if I were saying AAC should give better quality than LAME --api.

Now you can give unfounded statements about AAC CBR 240 kbps being equal or better than LAME 320 kbps, but that is completely beside the point, cause like I said, 320 kbps is generally overkill, so you can say the same for LAME at lower bit rates as well (at least the equal part). Since you did not correct me on my statement that AAC does not greatly diminish the needed bit rates for transparency, you have already acknowledged that AAC is not superior, but that it is just better at lower bit rates.

This is pretty much the gist of the matter: how you define "superior". I've been trying to show you that your definition is both silly (because you require superiority all over and not in some aspects) and inconsistent (because in some bitrate areas you can't really improve, and in some AAC already is better).

The fact that you already had to qualify it to start with, and then add some more qualifications when the flaws were pointed out to you, shows that's it's leaking all over.

I basically gather that you want AAC to provide LAME APS quality at like 128 or 160kbps. Well, that's a fine wish, but the fact that AAC may not attain that does not mean it is not a superior codec!

No contradiction:

On some pathological clips MP3 at 320kbps will/might have problems that AAC at 240kbps doesn't, becaused of the technical inferiority of MP3 compared to AAC. But it will drown out in the statistical noise and you won't be able to reach a hard "is better" conclusion.

It would need a valid test set up where listeners compare 320kbps MP3 versus 240kbps AAC. The hypothesis would then be that we were not able to conclude with statistical significance that either codec is worse than the other.

That is such a gigantic waste of time that I wouldn't do it just for the sake of this argument, hence I said "bet". But I doubt stephanV wants to argue this specific point further, because I agree with him it's irrelevant to the point.

As far as the original point goes, which was FAAC development, I want to point out the results of roberto's test:

First one:
http://www.rjamorim.com/test/128extension/plot12z.png

Second one:
http://www.rjamorim.com/test/multiformat128/plot18z.png

Vorbis and LAME were actively improved, the other codecs not. It's obvious that development effort is decisive in the codec's performance.

Improving FAAC is both much easier (less horrible code, much more simple things to do) and has more room for progress. That's why it's so sad noone is doing it.

I like your strong, solid logical argumentation against my obviously false statements.

I totally agree. Can't we sweet-talk Aoyumi (or someone) to take on FAAC? IIRC, FAAC doesn't even have a psy-model?

I'm planning to create FAAC branch future winter. The plans is to add SBR/PS part (from 3GPP reference encoder). If You point me what i can do for AAC-LC quality improvement (I'm newbie in audio comperrsion) i will try to improve it

Carefull with the licensing

As pointed out, a working psymodel would help. There are also many trivial speed optimizations that can be done.

How do You think, is it possible to merge psymodel from LAME project?

... or from Vorbis? Or even Musepack?? But I don't know squat about coding so I'd best keep my mouth shut.

It depends on what you understand as PsychoAcoustic Model. The PAM of the human ear depends on the subject, but there is already a "worst case" model valid for most of us. In that sense the PAM of an ACC encoder should be same as Vorbis' or MP3's one.

The problem is how to implement a PAM Engine. This PAM Engine configures the different parameters of the encoder blocks depending on the signal and other external parameters (rate, BW...). Vorbis, MP3 and AAC have different blocks, those blocks have different parameters that affect differently to the psychoacoustic response in terms of noise shaping, noise masking, frecuency accuracy or time accuracy. In this sense, the PAM Engine of Vorbis or LAME can hardly be adapted to AAC encoding.

Regards,
Oki

exactly why i wanted to know what was the status of faac. :-/ seemed to have potential and then i looked @ the build date and its been like over a year, w/the cvs snapshot being almost a year old also.

eh i guess i might just have to resort to QT/ITunes

That is truly a pity. QT/Itunes are good but it'd be nice to have a dandy little stand alone application instead of those hogs. Just my oppinion.

edit: I guess we still_have_FAAC but it's not as good as QT/ITunes

Make sure you have the latest (last) version of iTunesEncode. You'll find it on rarewares. Some earlier versions had a bug that caused what you're saying here.

With MP3, commercial encoders were well developed compared to the free ones for quite some time. I suppose faac will see more interest (= development) when aac gets bigger.

Untill that time, one could argue interest is simply too low for a viable open source project.

And please, let Aoyumi work on Vorbis. And lobby for Vorbis on portables instead

You're right, when the time is right, FAAC might pick up speed again. But I'd rather see that sooner than later, and if I could make Aoyumi switch over and tune FAAC instead of the Vorbis encoder, I'd do it in a heart beat.

I agree. Vorbis went through a similar stage where no-one was actively developing it (and many were hoping someone like Frank Klemm would switch to vorbis development, for heaven's sake ). Now we are lucky to have Aoyumi and no-one is going to take him away from us (though of course, it's Aoyumi's own decision) Besides,developers will find vorbis development to be less restricted in terms of releasing binaries of their experimental coders.

On the topic of faac's psymodel (or lack of one), I remember being chastised by someone at doom9 about my statement that faac had no psychoacoustic model and that I was making statements without listening tests I pointed to various statements made by Gabriel here about faac's lack of a psymodel and also faac's placing in the 128 kbps tests. This particular doom9 member then pointed out an faac source file that had 'psy' in the filename (at casual glance, it only contained some block switching stuff, but no noise or tonal masking, ATH, etc.) and said that the faac tested in the 128 kbps test was without TNS, which would have improved the quality. Funny thing is, this member didn't provide any listening tests to verify that faac+TNS would've sounded better.

So just to get the facts straight here, can someone please tell me precisely whether faac contains a psymodel or not. I know it's been mentioned a few times already, but an official reply would be nice.

FAAC does not have a psymodel. The only thing in the psykni.c file is block switching detection. Now you can argue that is also a psymodel, but I don't think just that is what most people will consider a "psymodel".

It originally had the ISO one, until someone figured out that one was so bad that it worked better without it.

TNS in FAAC is buggy and worses quality sometimes. I don't know any definite result whether it should be on or not.

Ohh, it MUST have been Hans-Jürgen!



I used the default settings, as I'm not crazy enough to go around tweaking encoders for my tests unless the tweaking is explictly approved by the developer. And, as it turns out, to this day, TNS is disabled by default in FAAC.

I have never been interested in FAAC because its performance is very bad and I have not even read a single line of code of this encoder. But according to what I am reading here, all I can say is WoW!

TNS is one of the State of the Art tools of AAC. It removes most of pre-echo artifacts and can be very effective if it is properly coordinated with a good block size predictor. TNS makes AAC a lot more effective than MP3 at all bit rates. If TNS is not used then the quality at a given bit rate is dramatically reduced.

TNS is not always a good choice, but a good PAM engine should properly evaluate if TNS is effective or not in a given block taking into account not only the spectral values but also the time samples. Implementing this into FAAC would improve the codec efficiency in terms of quality.

Regards,
Oki

I'm not sure I agree with you there. I wouldn't put it as "very bad". The last FAAC version performed quite well in the last test. The gap to Nero and QT has (for sure) widened since then, since the development has (temporarily?) come to a halt.

IMO, Knik did a wonderful job with FAAC, making it much faster and much better compared to the encoder's state when he first grabbed it (version 1.5, IIRC)

Unfortunately, for a series of reasons not worthy of being discussed here, he decided to abandon development at version 1.24.

Now, we are all awaiting the arrival of a new coder interested in developing it further...

Maybe my quality requirements are too high, that is subjective of course, but an AAC encoder without TNS and PAM engine is not a good one and its performance can not be acceptable for the potential of the AAC codec. The last FAAC version performed quite well in some tests just because of the quality of the AAC codec itself. Even with a mediocre implementation its performance is not that bad. In theory AAC can offer a much higher quality @ the same bit rate.

Regards,
Oki

Unfortunately it is a hard software engineering truth that

http://www.rjamorim.com/test/aac128v2/plot12z.png

simple code with few bugs still vastly outperforms "better" but more buggy code.

True. Nothing else explains FAAC slightly outperforming (or, more precisely, getting tied to) Compaact! and CodingTechnologies' encoders (CT's is reportedly FhG's consumer encoder)

Any plans for an aac128v3? FAAC may be at a stand-still, but it'd be interesting to see how much the others have progressed this past year.