for the same size, 192mp3 vs 192 aac for example, which file sounds closest to the original source file? If distortions from the original are present, What are they for both formats? Does either have a particular sound signature?

Which one sounds closer to the original? Can't tell without listening.

Each (lossy) audio encoder has its own (lossy) psychoacoustic model, which implies more bits on such and such frequency, etc, therefore a different sound. Which sounds "closer" to original is relative, to your hearing, and to the encoder, therefore. But, the AAC format is a newer standard, and therefore has more potential, after as many years in developpement as the MP3 standard. If you're encoding music for an Ipod, I'd suggest AAC.

In theory, 192kbps AAC would have an advantage over 192kbps MP3 in terms of pre-echo, or the smearing of very sharp sounds or transients. In practice, though, I've found only a few killer samples at this bitrate where AAC clearly sounds "sharper" than MP3 (castanets being one of them). For most everyday listening, I doubt there would be much of a difference, if any at all. AAC's promise is in the medium bitrate range (96-128kbps) where it has the tools to perform better than MP3 (which quickly deteriorates <128kbps). At 192kbps, the differences between modern codecs are generally slight, if even perceptible on well-tuned encoders. That's why I've stuck with LAME and --preset standard: it sounds great AND works with all my devices, unlike AAC or Vorbis.

Reason why I posted this thread is that I might get an IPOD and maybe an apple mini for encoding and internet purposes. If I can't use EAC and Lame with an apple, I'm going to be screwed if I don't have a good satisfying encoder

You can use LAME with a mac--slow as hell, though...

http://blacktree.com/apps/iTunes-LAME/

Here is a nice write-up that compares MP3 and AAC:
http://members.chello.nl/~m.heijligers/ipo...ompression.html

Get a windows emulator. VMware or VirtualPC...

I think this post is full of shiat...

I agree. bullshit to itunes encoder being better than lame at 192kbps vbr, and big bullshit at 128 lame vbr being same size as 192 vbr...

^10000000

That sort of crap doesn't fly here.

Edit: I don't mean that as an attack on STL personally, just his link.

Wow, tough crowd...

It was pointed out to me that the way he used the -b setting on LAME he really crippled VBR so that might explain some of his impressions. His subjective comments aside, he did supply me with a useful "overview of encodings" link. The info it points to isn't written from an audiophile perspective and it's a bit dated, but overall it is still very informative. I also like the stuff he did under "Learn about encoder artifacts".

I don't see how that could be faster than a native PowerPC compile. I doubt VMWare can emulate x86 on PowerPC, anyway.

Now while I agree that the "test" would hardly stand up to serious critism, just calling it "full of shit" is hardly constructive, nor does it add anything.

Donunus, you can look at this thread:
http://www.hydrogenaudio.org/forums/index....showtopic=36465
The only complex blind listening test at 180 kbs for a long time.
As you can see, at least on classical music, AAC performed worse than MP3, Vorbis & MPC.

1) Only 1 listener, so entirely unrepresentative.
2) The used AAC encoders suck (for classical).

1. One is better than zero
2. Of course, everybody can see it

My point was that others would do a lot better. It's not an AAC problem.

for example?

To the end user that doesn't matter. The format is as good as the tools used to create it. But I take it you mean that some other tool than Nero would be better and more representative of the true quality of AAC? Apple's Quicktime?

Well duh

The public Nero AAC sucks for these kind of samples (let's not even talk about FAAC here...). That doesn't mean AAC sucks on them. I would expect most AAC encoders to do better (including current development Nero AAC).