AAC Put To The Test

technology is sexy writes "Following the increasing popularity of AAC in online music stores and the growing amount of implementations in software and hardware, the format is now being put to the test. How well does Apple's implementation fare against Ahead Nero, Sorenson or the Open Source FAAC at the popular bitrate of 128kbps? Find out for yourself and help by submitting the results. You can find instructions on how to participate here. The best AAC codec gets to face MP3, MP3Pro, Vorbis, MusePack and WMA in the next test. Previous test results at 64kbps can be found here."

Comments

i prefer just to steal the music

[Anonymous Coward]

this makes the format rather irrelevant.

Re:i prefer just to steal the music

[PhoenixK7]

There's nothing inherent in AAC that makes it DRM friendly. Its the quicktime wrapper thats DRM friendly. It would not be difficult to slap some form of DRM on MP3s, you just wouldn't get that many users because none of the MP3 players would support it out-of-the-box. People want to be able to fire up their winamp (or *shudder* realplayer, wmp, etc) and play the files without hassal. SInce iTunes is the most popular mac audio player, its much easier to add DRM to a format that hasn't been used much. Players will implement fairplay and authorize tracks. Apple could have done the same damn thing with MP3s, called them something other tham mp3s and it would have worked perfectly fine.

AAC _is_ technically superior to MP3. The problem is we've had around 10 years now to refine and perfect our MP3 encoders while free/cheap AAC encoders are just coming onto the market. Give it time, once it reaches its prime it will provide quality that I'm sure will undeniably rival MP3.

crap in, crap out

[larry bagina]

just remember, every codec depends on the quality of what it is encoding. I haven't heard any AAC encoded music myself (i use uncompressed wav or 256khz mp3 myself), but Apple allegedly uses the master recordings to encode their files.

Most mp3s or oggs you find out there are from someone's CD-Rom drive, who knows how the disc looked, or how much jitter there was. I have heard stories of people downloading songs to find a skip or two in the middle, or been an amalgam of two different files accidently spliced together.

I'd hazard a guess that most people that encode with ogg-vorbis do a better ripping and encoding job, though.

Re:crap in, crap out

[jpt.d]

256khz mp3? That is amazing, I only ever use 44khz

Re:crap in, crap out

[larry bagina]

Cdparanois uses the term "frame jitter" for block skewing. Out of respect for them, i use their terminology.

This is what the cdparanoia faq has to say about ripping...

I can play audio CDs perfectly; why is reading the CD into a file so difficult and prone to errors? It's just the same thing.

Unfortunately, it isn't that easy. The audio CD is not a random access format. It can only be played from some starting point in sequence until it is done, like a vinyl LP. Unlike a data CD, there are no synchronization or positioning headers in the audio data (a CD, audio or data, uses 2352 byte sectors. In a data CD, 304 bytes of each sector is used for header, sync and error correction. An audio CD uses all 2352 bytes for data). The audio CD *does* have a continuous fragmented subchannel, but this is only good for seeking +/-1 second (or 75 sectors or ~176kB) of the desired area, as per the SCSI spec.

When the CD is being played as audio, it is not only moving at 1x, the drive is keeping the media data rate (the spin speed) exactly locked to playback speed. Pick up a portable CD player while it's playing and rotate it 90 degrees. Chances are it will skip; you disturbed this delicate balance. In addition, a player is never distracted from what it's doing... it has nothing else taking up its time. Now add a non-realtime, (relatively) high-latency, multitasking kernel into the mess; it's like picking up the player and constantly shaking it.

CDROM drives generally assume that any sort of DAE will be linear and throw a readahead buffer at the task. However, the OS is reading the data as broken up, seperated read requests. The drive is doing readahead buffering and attempting to store additional data as it comes in off media while it waits for the OS to get around to reading previous blocks. Seeing as how, at 36x, data is coming in at 6.2MB/second, and each read is only 13 sectors or ~30k (due to DMA restrictions), one has to get off 208 read requests a second, minimum without any interruption, to avoid skipping. A single swap to disc or flush of filesystem cache by the OS will generally result in loss of streaming, assuming the drive is working flawlessly. Oh, and virtually no PC on earth has that kind of I/O throughput; a Sun Enterprise server might, but a PC does not. Most don't come within a factor of five, assuming perfect realtime behavior.

To keep piling on the difficulties, faster drives are often prone to vibration and alignment problems; some are total fiascos. They lose streaming *constantly* even without being interrupted. Philips determined 15 years ago that the CD could only be spun up to 50-60x until the physical CD (made of polycarbonate) would deform from centripetal force badly enough to become unreadable. Today's players are pushing physics to the limit. Few do so terribly reliably.

Note that CD 'playback speed' is an excellent example of advertisers making numbers lie for them. A 36x cdrom is generally not spinning at 36x a normal drive's speed. As a 1x drive is adjusting velocity depending on the access's distance from the hub, a 36x drive is probably using a constant angular velocity across the whole surface such that it gets 36x max at the edge. Thus it's actually spinning slower, assuming the '36x' isn't a complete lie, as it is on some drives.

Because audio discs have no headers in the data to assist in picking up where things got lost, most drives will just guess.

This doesn't even *begin* to get into stupid firmware bugs. Even Plextors have occasionally had DAE bugs (although in every case, Plextor has fixed the bug *and* replaced/repaired drives for free). Cheaper drives are often complete basket cases.

Rant Update (for those in the know):

Several folks, through personal mail and on Usenet, have pointed out that audio discs do place absolute positioning information for (at least) nine out of every ten sectors into the Q subchannel, and that my original stateme

Re:crap in, crap out

[Guppy06]

"I'd hazard a guess that most people that encode with ogg-vorbis do a better ripping and encoding job, though."

Only because right now you'd have to know a thing or two about the intricacies of digital music to have ever heard the phrase "ogg vorbis." If a big on-line music player were to standardize on this format instead of MP3 and it too becomes the common man's format, you can be sure the quality of ogg files will go down just as well.

DVDA

[Graspee_Leemoor]

I prefer DVDA.

What hyphen?

graspee

Re:Isn't AAC used for its DRM features?

[Anonymous Coward]

You mean the DRM features that allow me to rip my own CD's to AAC and copy the resultant files to any and all computers or players (that understand them) and play them back?

Or how about the DRM feature that allows me to export bought AAC's to aiff and then convert them to MP3/OGG/AAC/.wav/.au etc and do with them what I please?

True, Apple's TMS is selling AAC's that have a DRM-like "inconvenience protection" on them but it's not _inherent_ to the AAC format, nor does it affect the sound quality vs. file size questions.

(In any case, we _should_ be cheering for any company that's actually trying to give us quite reasonably limited freedom with copyrighted material, while satisfying the RIAA/MPAA etc.)

Don't take 64 Kbps AAC results seriously

[benwaggoner]

I note that in the 64 Kbps test, they used the AAC-LC encoder from QuickTime 6.0. This was a pretty darn lousy one, lacking any ability to specify a sample rate at a given data rate, and had poor quality. The current version of QuickTime 6.3 (for Windows and MacOS X), has a much improved, more flexible AAC-LC encoder, so if they did that test today AAC would likely rank higher.

If using the Apple encoder, encode in "Better" mode with 16-bit source, and in "Best" mode with source that's more than 16-bits per sample (and hence isn't a CD rip). Support for mastering from 24-bit when running in "Best" is one of the reasons why the AAC-LC files as part of iTunes sound so good.

Pfffft...

[Squirrel of Doom]

In the Billy and the Boingers' "U Stink But I Luv U" encoding test, the OOP-AAC compression scheme won by a wide margin.

Re:Sigh. When will people RTFA and get a clue?

[Anonymous Coward]

First, read this:

http://www.ff123.net/abchr/abchr.html

This describes the program and testing methodology used here, which, btw, is based on widely accepted perceptual testing conventions. And yes, by the scientific community. These are the same techniques used by the scientists that do the research and development on these formats. Please note the references at the bottom of the page.

1. Wrong, the MP4 files are already encoded and created for the user, stored in the .zip files.
2. Wrong, the Hidden Reference (ABC/*HR*, please read the page at the first link), ensures that if the user honestly cannot tell the difference but thinks that one exists (placebo), and rates the original lower than one of the encoded versions, that their results are discarded.
3. This is where the statistics come in. With enough listeners, the "noise" gets weeded out of relevant results. Most past tests using this methodology have been shown to provide highly relevant and fairly uniform results when all the data is factored together.

An open call to the masses is the only way to measure the perception of the masses, and if the test is performed properly (which it is in this case), then it *is* scientific.

Next time, please read up a little more on what is happening before jumping to all sorts of incorrect conclusions.

Sounds Better != High Fidelity

[Josuah]

This experiment is really designed to test which codec overall sounds better to the average user, for an arbitrary and inconsistent range of hardware setups, acoustic environments, and listening preferences (e.g. do I pay more attention to the primary beat or to the background harmony). I wouldn't place any value on this test other than to choose which codec I might choose if I wanted to please the ignorant consumer (a valid market, of course!). It does nothing to address how accurately a codec reproduces the artist's original sound.

I'll put a lot more stock in the Report on the MPEG-2 AAC Stereo Verification Tests put together by David Meares (BBC), Kaoru Watanabe (NHK), Eric Scheirer (MIT Media Labs) for the ISO. And the other MPEG Audio Public Documents.

I care.

[crapulent]

I care because I have not fallen for the "golden ears" fallacy. To me, 192kbps ABR lame-encoded sounds exactly like the original. I don't have super expensive speakers attached to the computer, nor do I have a fancy sound card (Creative Live 5.1.) Storing music losslessly is a waste of space to me. Sometimes I like to share music files and it's a heck of a lot easier and others are a heck of a lot more interested in trading compressed music compared to lossless files. And I can put a heck of a lot more of them on a CDR. And should I wish to listem to them in my MP3 player with limited memory, I'm sure as hell not going to use a lossless format.

If YOU want to use up your hard drive space, internet bandwidth, and blank media with huge lossless encoded files, feel free. But don't get all smug and proclaim to not have any idea why anyone would not want to waste their resources.

Oh, and I'm not going to touch that "mathematically lossless" crap, others have covered that already.

Apple vs. punk rock ethic

[switcha]

for a company who sold one of their first computers for $666 dollars, I'd imagine some of the bands are very disappointed in them using such a good codec.

I mean, damn them! Nirvana didn't pay $606.17 to record Bleach so that some Corporate Asswipe could make a high fidelty copy of it!

The Ramones would be very peeved to find all the work they put into keeping most songs to three, dingy, distorted chords, ripped to a high fidelty format.