What is the best compressed iTunes format?


First, let me state that I fully understand that an uncompressed format is far superior to a compressed on such as MP3. My current iPod is a 4GB unit, but I just had the battery replaced on my wife's old 30GB unit and plan to transfer my music that direction.

I generally use it for listening at work on Sennheiser earbud headphones that retailed for about $80 new so we're not talking HiFi. My only iPod connection currently, or planned, to my main stereo is via an Onkyo dock so I'm not getting the benefit of an external DAC so again we're not talking HiFi.

Knowing that I have somewhat limited space, what would you recommend for me to choose as the format for iTunes. I've never done anything beyond one of the lower compression MP3 options, is there something better?

Please provide a suggestion and why.

Thanks
mceljo
Way I understand ALAC is that it is 100% lossless, but runs a compression algorithm to reduce file size. Think a self executing zip file that automatically unzips itself in RAM every time you play it, while the disk copy remains compressed. FLAC, I think, is similar, but with a variable, user-selectable compression ratio (from 0 to more), whereas ALAC is the Apple version, which invariably means two things: compression ratio is fixed because Apple picks it for you and FLAC not supported on Apple. (And by "fixed" I mean not user-adjustable, I think the compression ratio on ALAC is very variable, just adjusted in secret by the Apple tech boffins and their sneaky algorithms depending on the nature of the track. Again, think zip files – depending on the nature of the file and density, it will be more or less compressable).

The only theoretically possible source of sonic difference between ALAC and an uncompressed lossless format (AIFF / WAV) is the processor burden of uncompressing the ALAC files every time you access them. Once upon a time, that may have mattered more, but with current processors I expect it really doesn't. (Although folks do still argue about it.)

Finally, the explanation for different bitrates on lossless files that has made the most sense to me is that all the bitrate represents is filesize divided by length of the track (kbps, kb/s, to be precise). So, if you compress a track, making the file size smaller, it will read as having a lower bitrate as against the same track uncompressed. But lossless / bit perfect is just that, compression or no, so the bitrate stat for a lossless track is really pretty much meaningless. Put differently, track density or complexity may well have an impact on the compression efficiency and ratio, so there's your source of variability, but all bitrate represents is that result (compressed file size) divided by length. Nothing to lose sleep over.

Flip side, when you pick a bit rate as the controlling factor for track compression – rather than anything to do with the track itself -- it’s kinda like the tail wagging the dog. You’ve imposed an arbitrary variable, mashed the track through it, and then discarded everything else so that your pre-determined kb/s = X equation comes out to equal X. What’s left is only what wasn’t lost, ie deleted, in order to make this arbitrary number (and hence the opposite of lossless). This, in turn, is I expect why “variable bit rate” makes sense, cause it gives the algorithms “discretion” (flexibility?) to take the nature and complexity of the track into account, from second to second adjusting bit rate in accordance with what is actually going on, instead of just hacking and slashing to make an arbitrary number – but in such a way to come out with an average “X” result to meet the predetermined outcome. (OK, that last one was pure guesswork.) So, for ALAC, bitrate is an arbitrary number, but a meaningless arbitrary number. While, for a loss-y format, bit rate is still an arbitrary number, but a fantastically meaningful one because it is what was chosen to determine how much of the original lossless file survived.
I'd say bitrate is not arbitrary on ALAC files. Rather a measure of 'complexity'. If what you mean by arbitrary is that you have no control over it, that's also true. But not in the sense that somebody just picked a number. ALAC would seem to end up about 30% to 35% reduced from the original.
Very complex, rapidly changing or 'dense' music will get a higher bitrate than sine waves. Maybe I'll test this, later today. I think you may be on to something with file size/length math. I'll look over some of the large number of songs I've got in ALAC and look for a pattern.

The idea behind lossy files...and this applies to photography, too, is to only discard the least significant data. That which couldn't be heard (seen?) anyway.
Of course, this doesn't work well, at least at higher compressions. In Photoshop, I have a choice of 10 or more 'levels' of compression. Using extreme enlarements of small parts of a picture, you can clearly see what changes. The changes are most readily apparent in more.....complex parts of an image. Big enlargements are hurt worse than small prints. Images for monitor use are nearly immune!

Yes, processer overhead makes sense. Again, using photoshop as an example, when I make a big change to a photo, It can take several seconds to process.

I just decided early on, after experimenting with FLAC, to change over to ALAC. It was more.....painless, for me. And I Tunes makes it easy to 'downconvert' to a much smaller but still listenable MP3-160 bitrate. Album art is more easily manged, at least for me. That, and the fact I can stream music wirelessly to my stereo is the icing on the cake. I only wish the Airport Express were better clocked.
Why compress. Use AIFF. It takes twice the space as ALAC, but who cares? Disk is cheap.

Steve N.
Empirical Audio
Well, the downside of having iTunes convert to AAC when syncing to the iPod is when you mess up it takes a long time to redo it. I was trying to replace my best CDs with the Apple Lossless files and didn't set things right. Now I have about a 24 hour delay allow it to sync everything in AAC again. I think I've got it figured out for next time.