Yeah, that's a pretty useless test. An "empty" song with one vocal and one instrument (I'm not talking about Billie Jean, I'm just stating a metric) wouldn't sound that wrong at a low bitrate. However, if you use a song with several distinct instruments, spanning high trebles and deep, smooth bass, and add in a clear voice, 48kbps will totally fall apart.
Basically, if you have content with detail & range at the same time, you require a higher bitrate. As far as how good it sounds, well, if the music requires a higher bitrate, it'll sound bad no matter what. If a codec is designed to make low bitrates sound "pleasing" vs. "accurate when possible," well, people might like the fact that it sounds pleasing. I don't know if AAC is designed to sound just pleasing at low bitrates, but it's not a bad idea since it can't sound accurate anyway.
It's like vinyl. People like vinyl because the process of converting vinyl waveforms to play on speakers is pretty easy, and purely analog. If you're going to listen to a CD with high quality speakers, you absolutely must have a great digital-to-audio converter somewhere in the chain. With an ordinary DAC, good speakers will just make the music sound very "discrete" and digital (cheap speakers won't reproduce that level of detail, but will probably sound better playing records than they do playing CDs).
The ribbon system allows for the logical grouping of actions by function. This allows for a more intuitive interface for the standard user
Actually no. I've learned that there are two kinds of people in the world, problem solvers/designers, and those who follow. Those who follow don't think "logically," they are perfectly happy to spend time searching, or waiting for something to happen. If you give them options and possibilities to think about, they don't follow the same "logic" designers do, kind of like children.
If Apple did it right, then I'm pretty sure one can programmatically change the per-file association. Or probably even with the AppleScript.
No, they didn't do it right, they just chopped the functionality out. This is determined by the launch services database and the LaunchServices framework. The only thing you can use to "set" something using LaunchServices is the function LSSetItemAttribute, which only supports kLSItemQuarantineProperties. There's also stuff like LSSetExtensionHidden, but they didn't add anything for this.
There is no way to programatically influence what application a file should open in when running on Snow Leopard, and there was before. This is a significant loss of functionality. Text files are a great example of this; if I have a set of text files (or even XML) files that I like to create using with BBEdit because of BBEdit's feature set, I want to open them in BBEdit again. I don't want to save one, open an info window in the Finder, and select BBEdit from the popup menu, that's just stupid.
If I'm saving PDF compatible files in Illustrator with a
There are only two ways to set a file type in OS X: using a file extension (which is stupid, but supports the lowest common denominator) or HFS+ meta data (which is actually a good idea, because it's file meta data). There's no new extended attribute where you can set a UTI or other attribute that influences launch services other than quarantine (if you happen to find one, run to the top of a very large hill and yell loudly, preferably screaming the name of the attribute; then put a recording of it on YouTube).
Ideally, you'd have more file-system metadata to determine this kind of behaviour, but the "change" popup in the Get Info window only modifies the
That's probably one of my biggest gripes. I was trying to restore a corrupted config directory for Aptana Studio (Eclipse), and I had to open it from the command line.
Well, if you knew the name of it you could have just done View > Go to Folder (Command-Shift-G), and typed (for example) ~/.subversion.
Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky
