AIFF or Apple Lossless

[cfmsp]

 

 

"I use a £10 5m pro-spec no-name IEEE1394 cable, or standard £10 5m pro-spec no-name spdif opt, or an Airport Express."

 

What differences, if any, do you find between the Firewire, Toslink and AE variations into the Fireface?

 

Presumably, you're using Toslink with mini adapter from the AE?

 

cheers,

clay

 

 

 

 

 

[tfarney]

"Marketing? I don't think that a career in formalised artifice really helps the debate."

 

Long before we mix our cauldrons full of bubbling ooz and hoist the deceptions of our "formalized artifice" upon the gullible and unsuspecting public, forcing them to purchase that which they neither need nor want (we're all warlocks, you know), we marketers do quite a bit of research. It mostly has to do with attitudes, desires and emotional motivators. We do this because we are about to spend millions of dollars of our client's money, and unlike some audiophiles, they typically expect to actually get some verifiable, measurable performance from their expenditure. After a few decades of testing, marketing, succeeding, failing, testing, marketing, measuring...you develop a pretty good feel for how people are motivated and how much they're willing to believe (and deny) to maintain their inner image of themselves. And audiophiles are among the most extreme examples I've seen in those decades.

 

But pay no attention to us. We just deal in formalized artifice.

 

Tim

 

 

 

[jcbrum]

Hi Clay, No significant differences, they're all superb, and yes.

regards, jcbrum.

 

[flacphile]

I know this isn't a true test but I just wanted people to know there's NO difference in audio quality from a AIFF to a ALAC or FLAC.

 

I did a test where I listen to an AIFF file prior to compressing the file in a RAR format. I then got the audio and file properties from the uncompressed file as you can see below, Then compressed the file with WinRAR and got the file properties from the RAR file as that's the only information I could get as you can see the file size is smaller than when the file is uncompressed (no kidding). I then uncompressed the file and got the audio and file properties as you can see nothing changes. I compared the uncompressed file and the uncompressed RAR file...I could not here any difference after listening and comparing for around 20 minutes.

 

So my point here is there's no audio quality difference when the file is decoding on the fly or not decoding on the fly. The audio quality is still the same. So when people on this forum say I can hear the difference etc. etc. it must be in your imagination or you want to believe the AIFF/WAV file sounds better because it’s uncompressed format and your mind is saying uncompressed is better than compressed.

 

A true test is going to be where you should get your friend to play three files one in AIFF format and the other two in ALAC and FLAC format. Let your friend know which format you think sounds better (In this case AIFF) and without looking get your friend to play the three formats, after listening the songs then pick which one you think is the better sounding format, I bet you will pick the format that you didn’t expect or can't decide because they all sound the same. You might have to do it a few times. Let us know how you go!!

 

[uncompressed]

 

Carl Riseley - This Guy's In Love With You ripped with dbpoweramp converter in secure mode

Fie Properties: Size 44.9MB (47,119,618 bytes)

Audio Properties:

Artist Carl Riseley

Title This Guy's In Love With You

Album The Rise

Track 08/12

Disc 1

Genre Swing

Year 2008

Rating

Composer

Size 44.93 MB (0% Compressed)

Original Size 44.93 MB

Length 4 minutes 27 seconds

Channels 2 (stereo)

Sample Rate 44.1 KHz{CR}

Sample Size 16 bit

Bit Rate 1,411 kbps

Encoder

Encoder Settings NONE (no compression)

Audio Quality CD (Lossless)

Contains ID Tag [iTunes ID3]

Channel Mapping Left, Right

File 08 Carl Riseley - This Guy's In Love With You

Type AIFF [.aif]

Length 267360

 

[Compressed with WinRAR]

 

Carl Riseley - This Guy's In Love With You ripped with dbpoweramp converter in secure mode

Compressed file with WinRar

Fie Properties: 29.1MB (30,527,287 bytes)

 

[uncompressed RAR file]

 

File Properties: 44.9MB (47,119,618 bytes) (Same file size when file is uncompressed)

Audio Properties:

Artist Carl Riseley

Title This Guy's In Love With You

Album The Rise

Track 08/12

Disc 1

Genre Swing

Year 2008

Rating

Composer

Size 44.93 MB (0% Compressed)

Original Size 44.93 MB

Length 4 minutes 27 seconds

Channels 2 (stereo)

Sample Rate 44.1 KHz{CR}

Sample Size 16 bit

Bit Rate 1,411 kbps

Encoder

Encoder Settings NONE (no compression)

Audio Quality CD (Lossless)

Contains ID Tag [iTunes ID3]

Channel Mapping Left, Right

File 08 Carl Riseley - This Guy's In Love With You

Type AIFF [.aif]

Length 267360

 

[arin]

Hi Everybody!

I think many of you already know the test most pro-audio people do to determine if two audio files are exactly the same and that means they sound exactly the same: import the two audio file in a professional multi-track sequencer (in my case Logic), align them exactly (and that means at the sample level), set the volume of the two audio files at the same level, invert the phase of one of the files (using a simple plug-in that does nothing else to the signal), play the files and then measure what's coming out of the master output.

If you get nothing down to -144db (for 24bit audio files) or -96db (for 16bit audio files), the files ARE and SOUND exactly the same. That's because a simple law of nature says that if you sum two identical signals inverting the phase of one of them, you get null as they cancel each other.

Should you get clicks or pops or worse, if you could hear part of the sound, obviously the files are not the same.

 

I did several of these tests comparing AIFF, WAV, and ALAC prior deciding to rip my 5300 CDs in Apple Lossless.

 

By that I don't mean to bias anyone and if you prefer AIFF or WAV to ALAC or FLAC there's absolutely nothing wrong with that by me.

 

I just wanted to share my humble experience.

 

Ciao

Arin

 

[Lord Chaos]

My computer audio adventure started on a PC, for a variety of reasons. Most of them have to do with opportunity and accident. Later on I switched to a Mac, mainly because the PC was unreliable.

 

When I first turned to the Mac I was dismayed to find that Itunes no longer supported ripping to AIFF, just some lossless format. Well, I'd gotten used to that with Windows Lossless, which was the reason I had to re-rip all the 1,000 CDs I'd done on the PC. So, I re-ripped all of them. To my ears--connected to the computer with a Benchmark DAC1 USB and Denon AH-D7000 headphones--the music is just that: music.

 

My question is this: how much "extra" work must a computer do in order to play back a lossless file? It has to reconstruct the disk file anyway in order to get the bits out the USB port, and I don't notice any lag. I tell Itunes to play Philip Aaberg's "That Train" and I'm immediately going on a ride through Montana. The computer (Powerbook G4) doesn't even get extra warm.

 

I've heard the argument that decoding lossless files is an issue. Maybe it is, but if so it's at a level I can't hear... and refuse to worry about. And I just use the USB cable that came with the DAC1.

 

[1975DCS]

Isn't one of the benefits of AIFF or Apple Losless over FLAC that iTunes can burn red book CD's without having to convert them to WAV first?

 

Ps. I have to say there is some rubbisch over the internet: I've red somewhere that iTunes would convert the AIFF file to MP3 before burning a ".CDA" red book audio CD, meaning the CD would be a pumped up MP3... I can hardly believe such a thing! Why on earth would Apple want the lossless music to be lossy before making a "lossless" CD? I do give Apple more credit and believe iTunes is better than that! This sort of information (99,9999% that it is false in this case) makes me septical about thing I read on the Internet...

 

[1975DCS]

The only thing I think is to bad with AIFF is that MP3Tag from www.mp3tag.de doesn't work and i think that is a very easy program for batch conversion, splitting artist and title with " - " in the filename (or other if preffered). Apple Lossless seems to be working, altough no time and bitrate is given.

 

[mpmct]

If mega-monolith Apple released a codec named 'Apple Lossless',

and then had 'any-major-dude' decode it someday in his garage

as anything less than 'lossless' ... the legal fees would hardly

be worth the exercise for Apple. Yes?

 

Save an AIFF file to Apple Lossless, then click it, to revert to an AIFF.

Compare to the AIFF file that has not been compressed, bit for bit.

You will find perfect bits, un-'Zipped', aka: Lossless.

Still won't guarantee good *music*, but that's another subject. :-)

 

 

 

[mdunjic]

Hello

not sure why you said that iTunes doesn't rip the CDs to AIFF anymore.

 

iTunes continues to support ripping the original CDs into AIFF format. It did, is, and always will ...

 

Off course that may not be the default set right out of the box when iTunes is installed...

 

Go to preferences and change the ripping format. That's all you need to do.

 

Hope this clarifies...

 

[BEEMB]

 

Correct RE AIFF ..

.

Your response made me read the thread as far as Lizard saying that Mac's were inferior.

And Ashley responding about how superior Mac's are.

 

Both incorrect of course with the truth being somewhere in between.

 

 

[WoodsDweller]

Lossless is lossless. If there is any audible distinction between playback of a lossless compressed and a lossless uncompressed, it's a bug in the playback software. The time it takes to expand the compressed data is trivial, and BTW dwarfed by the time it would take to read the extra data from the hard drive. Audio is VERY undemanding of current-generation computer hardware.

 

Yes, you should absolutely use some lossless format for your rips. The choice is up to you, you should consider the format's support for tags, platform support, application support, DRM evil, and openness (versus proprietary). If you want to change lossless formats later, you can simply do a (perfect) conversion.

 

Compression or not is really not an issue in terms of disk space. I got an email special yesterday for a 1.5 terrabyte HDD for $120, big enough for around 3000 CDs in wav. A lossless compression of audio will give you in the neighborhood of 30% compression. So the disk space cost drops from 4 cents per CD to 3 cents. It's up to you if you consider that a major criteria.

 

[The Computer Audiophile]

"Lossless is lossless. If there is any audible distinction between playback of a lossless compressed and a lossless uncompressed, it's a bug in the playback software. The time it takes to expand the compressed data is trivial, and BTW dwarfed by the time it would take to read the extra data from the hard drive. Audio is VERY undemanding of current-generation computer hardware."

 

Hi WoodsDweller - I don't agree with your above statement. I'm not trying to start a flame throwing thread here, just relaying the information I have.

 

I know of some very knowledgeable engineers who have measured differences between Apple Lossless files and AIFF files. They measured the files, once a sonic difference was heard in an A/B comparison, in the first attempt to quantify the difference. The measurements were carried out on several computers with some of the best test equipment available. I'll try to get one of these people to post in this thread so it doesn't look like I am making things up :~) Please keep in mind that the goal of the engineers I know was to explain the sonic differences they heard between lossless compressed files and uncompressed files. No agenda is being pursued. They are just asking why and trying to show a measurable & repeatable reason.

 

I have yet to see anyone claim that a computer can't uncompress a music file fast enough or anything that relates to speed of decompression. I believe the common theories are more related to the decompression of music in real time and decompression errors, not a lack of computing power.

 

 

 

[WoodsDweller]

In other words, bugs.

 

EDIT: having said that, I store everything uncompressed...

 

[jcbrum]

quote - "I know of some very knowledgeable engineers who have measured differences between Apple Lossless files and AIFF files. They measured the files, once a sonic difference was heard in an A/B comparison, " - endquote.

 

This is baloney. The only difference between alac and aiff lies in the way the info is stored on the hdd. it's just a more efficient way of using the disk space. The sonic information is identical and fully created before presentation to the dac. A bit perfect aiff is easily created from an alac.

 

There is no sonic difference in any test, including abx.

 

JCBrum.

 

[Abstraction]

and the data is the data.

 

I hear a difference. My wife, who probably hears better than I do, hears a difference.

 

I just re-ripped my CD collection, nearly a terabyte. Why not a.i.f.?

 

Hard drives are cheap.

Don

 

 

 

 

 

[baxtus]

I do not usually like to be too adamant about things subjective, but in the case of AIFF versus Apple Lossless, I chose to encode my entire library in AIFF based only on what I heard. I cannot explain the reasons, the engineering, the science, but I do know that the AIFF playback has a certain effortlessness and ease on long term listening that is absent in comparison with the compressed file. I also have found over the years that short term, comparative, listening tests can be quite misleading and a similar experience to having your eyes checked at the optometrist in preparation for glasses. Constant switching between lenses for short periods of time in quick succession can be quite confusing and mistakes in the final choice of lens is more likely.

 

There are many things in life that cannot be explained by scientific testing. One of the reasons for this is that for many phenomena, we just do not have the sophistication or correct approach in either our tests or our testing environments.

 

Thank goodness for this open environment here at "Computer Audiophile" where we can post our personal opinions and experiences without fear of being "mistreated".

 

Thank you Chris for beginning, and maintaining this site and forum.

 

 

[The Computer Audiophile]

Oh great, part of the AVI advertising / marketing team has appeared again to call any real engineering attempt at improving sound "baloney." JCBrum I don't think anyone around here can take you serious after your threatened lawsuit and attempt to get me to allow Ashley back on the site ( http://www.computeraudiophile.com/content/It-all-sounds-same#comment-15554 )

 

I guess when engineers show me the measurements I tend to believe the measurements and not someone who acts rather sophomoric and disregards all engineering that he doesn't understand. By JCBrum.

 

Now the thread can get back to a real discussion where we can discuss this issue even thought we may not all agree.

 

WoodsDweller - I hear what your saying but I really don't think its a bug ( http://en.wikipedia.org/wiki/Software_bug ) For example when opening a compressed / zipped word document once in a while there is a hiccup. I wouldn't call the hiccup a big rather it's just something that happens because we're using PCs with many things going on. I'm guessing your still not going to buy this approach and I'm totally cool with that. I just like discussing the topic. As long as everyone is cool with each other we can all gain something.

 

[WoodsDweller]

I commend your stamina!

 

If it is already in a lossless format, and you want it in another lossless format, there is no reason to re-rip, you can just convert. It shouldn't take more than a few hours of CPU time. Seriously, there aren't any evil spirits in there. Take an uncompressed lossless, convert it to a compressed lossless, convert it back again. Diff the files. You get the same result, every time. Check every file in your terabyte. Identical files. If you get one bit different in your terabyte, there's a bug in the software used, and it needs to be fixed.

 

If you prefer uncompressed, (and I use it myself), by all means use it. Disk space is really, really cheap.

 

Do what makes you happy!

 

[The Computer Audiophile]

"Do what makes you happy!"

 

Ah, now we're talking. Back to enjoying this wonderful hobby whether it's 8 bit lossy compressed or 24/192 DDP files from the mastering house! As Cheryl Crow says, "If it make you happy, it can't be that bad.'

 

[flatmap]

It's true that a lossless file contains all the information as the original uncompressed file. So if you decide to rip to lossless, you should feel confident that you can always convert to an uncompressed format in the future if you need to. I recommend that you take some music you like and rip it both to lossless compressed and uncompressed formats. Listen and decide if there are any meaningful differences. If not , then you're good to go!

 

I originally ripped to lossless, but found that some music (mostly big orchestral works) just were not interesting to listen to (compared to similar versions on LP). Well sure, I guess that's no surprise. I thought this was the limitation of my dac, my computer, or simply the character of the digital file versus the analog format I was most used to.

 

Then at some point -- probably after reading postings here :-) -- I decided to convert some of these tracks to AIFF. Big difference. These orchestral works -- well they're still not what I get from vinyl -- became something worth listening to. They became enjoyable.

 

I was scratching my head over this, but the difference was considerable. These were all works that I was used to simply skipping when they came up during my evening Berlioz-a-thon, Wagner-a-thon, etc. Now I looked forward to hearing them. So something was going on. I am using an older computer and so maybe that accounts for the most of it.

 

However as I've thought more about it, what I think is going on -- and what others have said better -- is that the 'unpacking software' that decompresses the file is not keeping up with the downstream needs for audio reproduction. Let me see if I can explain my line of thought.

 

Certainly the software renders a completed file that is exactly like the original, I don't doubt it a moment. But as this code is performing the conversion it -- equally certainly -- depends on communicating with the computer's operating system (and then components of the operating system are addressing various components of the computer hardware itself) to do what it needs to do. But in some cases, at the whim of the operating system, the high level playback software will have to wait. Stacks will have to emptied, open streams will have to be closed, scheduled garbage collections will have stand aside. Et cetera. There are lot's of things going on inside a computer and the music player is just one of them.

 

So to be really good, as real time code, the software will have to increasingly address the hardware directly. Further, and more elusive, the programmers will have to have an extremely complete understanding of what the hardware does, what it expects, and how it performs. Much of the detail of how this all fits together is insufficiently documented and the truly excellent software developer will have to discover this himself by carefully thought-out testing on the particular machine in question. And what he learns about one platform will not entirely (or even mostly) carry over to another.

 

Worse, if you look at something like iTunes, it is a code set that must run on both motorola and intel cpu chips. And for each version of these cpu's, different choices were made i about the system hardware and software architecture. (Even my G4 iBook has lot's of differences in its hardware compared to my G4 Cube, even though they both have G4 series processors.)

 

But here's the deal, if iTunes runs really well on one hardware configuration, you can almost be guaranteed it is going to perform less well on other configurations. I'm sure they do their best, but the product does have to ship -- and so there are compromises that can be reasonably expected to affect real-time performance. Consequently the finished code, even if it is lexically the same at the high level (e.g. as C code), will not result in the same sequence of states, from platform to platform, as it executes. Really, you mightn't get the same sequence of total machine states from one time to the next with the same input file -- as the operating system will be up to its own tricks on its own schedule.

 

Sorry to go on so long. Anyway, IMO, the bottom line is that you should do a comparison for yourself, using your computer and your music, and then rip accordingly.

 

 

[WoodsDweller]

I wonder if we may be closing in on something.

 

Neither Windows, nor OS X, nor Linux are real-time OSes. They do absolutely nothing real-time. There is some work being done to try to make a real-time kernel mod for Linux, but I don't think they are having much luck. There are real-time OSes out there (like QNX), but they aren't in general desktop use. I've never worked in a real-time OS, but I think you need to design it in from the ground up. It's not a feature you bolt on, it's your first design decision.

 

The best you can do is set a timer interrupt and service it as quickly as possible. The timers themselves are pretty reliable, but you have to have a high process priority since you are running in user mode, and you need to do a context switch back into privileged mode, which takes time. However, the drivers should be running in privileged mode (I think even Windows does that).

 

The drivers should be buffering inputs and using a timer interrupt to release a sample to the audio interface every bazillion clock cycles.

 

As a working hypothesis, I'm wondering if you all aren't experiencing a driver issue (i.e. a bug), or maybe something specific about the way OS X drivers are written. A bug in a single driver would show up in listening tests using equipment using that specific driver, but maybe there is something more general.

 

Those of you who think you can detect this, try setting your player software priority as high as possible. I have absolutely no idea how to do this in OS X, but it's a Unix variant, so there should be a way.

 

Has anyone experienced this issue with FLAC vs. WAV on a non-Apple platform?

 

[markr]

I too am of the opinion that the capability and efficiency of software lags quite far behind that of the hardware it runs on. You also correctly point out that there are many different types of hardware that this software has to run on effectively. This is an often neglected point that you nailed right on the head.

 

I think that the best performing software is the software that is (correctly) coded in a low level language rather than a high level one. Of course this isn't really economically feasible, as there would have to be a different version of the program for every different type of hardware, and there are SO many now. We are kind of stuck with the high level compilers and interpreters.

 

LL language: http://en.wikipedia.org/wiki/Low-level_programming_language

HL language: http://en.wikipedia.org/wiki/High-level_programming_language - see 'abstraction penalty' here.

 

Good one!

 

markr

There are 10 types of people: those who understand binary and those who don't.

 

[poop]

From WoodsDweller above: "If it is already in a lossless format, and you want it in another lossless format, there is no reason to re-rip"

 

Surely if there is 'something wrong' with Apple Lossless as mentioned above, and AIFF is the way to go to avoid those problems, re-encoding is not going to solve anything! You would just be transferring whatever 'error' is in the original ALAC file into a new AIFF file... To get a rip to AIFF without the error, surely you would have to rip from the original media?

 

The only way I can see re-encoding working is if the fault is not in the encoding, but the decoding of the ALAC file on playback. Would sure be nice if that was the problem so it's an easy fix and you can all get over it

 

Either way my ALAC files sound excellent to me. Don't get me wrong, once someone has evidence, even just one tiny little scrap of something believable that a mere mortal can test themselves (perish the thought), then I'm sure I'll start to hear it too... It just frustrates me how long these damn theoretical 'debates' about compression formats have to drag on for! FOR GODS SAKE CAN ONE OF THESE BRILLIANT ENGINEERS SHOW ME SOME REAL F*C*I*G DATA JUST ONCE!!! ONCE!?!?!!!!! Not some pretty pie chart, not an abstract story about 'what I heard', not something posing to be 'proof', some actual INFORMATION, DATA or EVIDENCE!?

 

Go on, seriously, give it a go... why not?

 

 

 

[markr]

I don't think anyone here is saying that there is anything wrong with the losslessly compressed file here. What they are saying (and I've heard the difference too) is that the act of playing the file back (sometimes) isn't quite the same as playing an uncompressed file. The files that I've heard differences on have re-encoded back to AIFF flawlessly though; then play back without the 'problem' I'd heard before. I'd have to agree with WoodsDweller (or was that flatmap?) on that.

 

I do have to say here that I do not hear this issue on all lossless files upon playback, just some of them. I have also been able to sort of repair what deficiencies I've heard on these lossless files by increasing the latency setting in Play (the app I use to listen to lossless - FLAC- on the Mac). I don't do ALAC, so cannot speak (give my opinion) directly to that particular lossless file type.

 

I do admit that I am quite at a loss to explain this aural phenomenon. It just doesn't make complete sense to me. Nevertheless, I do hear it. Therefore I too would love to have "ONE OF THESE BRILLIANT ENGINEERS SHOW ME SOME REAL F*C*I*G DATA JUST ONCE!!! ONCE!?!?!!!!!". Hopefully that will be forthcoming.

 

EDIT: To answer WoodsDweller's question about prioritizing the CPU for certain applications on OS X - in attempt to get iTunes to give more priority time to play back ALAC better, The command line command "renice" is the one to use. There are some applications out there that will help do this for you, but I don't see any that are OS X 10.5-specific. You can find out more about the renice command by opening the 'Terminal' in the Utilities folder and typing "man renice" at the prompt. Not really for the faint at heart though.

 

regards,

markr