AIFF or Apple Lossless

[poop]

Well Markr, I haven't heard for myself what you describe, but I'm not trying to say it doesn't exist; it well may. It's something at least that while we both have different experiences listening to these files, we both want the same outcome: Music that sounds fantastic, and a little evidence as to why it could sound better...

 

I think our two comments have brought up one of the most important points in this seemingly endless debate; important in that it might be a good starting point that the majority might at least be able to agree on or accept (even if like me, they haven't heard it for themselves). Some seem to suggest that certain codecs or file types are flawed (in this case, ALAC). Others seem to suggest (as I believe you have if I understand you correctly), that there is nothing "wrong with the losslessly compressed file", it is the "the act of playing the file back" that some how changes it. In other words (generalised), if you encode a file to ALAC, change it back to WAV, then make it AIFF, it's the same information throughout the whole process, presented in a slightly different format each time.

 

I guess my point is that there seem to be two debates in the audio world when this discussion arises, and both debates always seem to get confused into the same discussion. The first says: encoding to ALAC is bad because the information stored in that file is not a true and accurate version of the original file. The second debate is more along the lines of: the actual encoding of a file to ALAC is fine, you're just using a compression algorithm, but when you play that file back, it won't always sound the same as the WAV or AIFF version of that file for some reason (the reason being up for debate).

 

So what is the debate here? Is it a combination of both? Can we please at least try to be clear on exactly where the problem supposedly lies? Does everyone here agree that ripping a file from CD to ALAC, then transcoding that same file to AIFF will give you the same result as ripping the CD straight to AIFF?

 

[John]

Yes, agreed (your last statement).

 

I never heard an alternative view. It does not matter how many iterations you go through; the file will be the same. (Try zipping and unzipping an msWord document. None of your spelling will change. Same process.)

 

- John.

 

[poop]

I have heard alternate views, many times, on many various audiophile based sites.

 

If we all agree on this point as you have described it, at least we are all 'on the same page' regarding the accuracy of the file or information being compressed. In other words; this change in what some people hear between different file formats is potentially not due to the encoding at all, or indeed the file format.

 

[HarryHWombat]

Nice post, poo! Of course your statement is true. I like this approach but would suggest that before the hypotheses you outlined you would need agreement on the following: "All other things being equal two identical same format files produce exactly the same sound". Amazing how many audiophiles refuse to sign up to this and if they hear a difference between files produced by different rippers refuse to check whether the files are different and how. The corollary of the statement is, of course: "Allother things being equal if two same format files sound different then the files are different"

 

[BEEMB]

 

I guess I'm talking different formats here, but take a look at this:

AAC is not lossless. So guess we're talking ALAC above are we ?

 

http://www.computeraudiophile.com/content/Scientific-comparison-audio-formats

 

Link to the stereophile test comparing MP3, AAC and uncompressed.

 

Summary: 128kbs MP3 can be good, but not uncompressed, 128kbs AAC better, 320kbs AAC is measurably not as good as uncompressed but audible differences may or may not exist.

 

Hard disk space is so cheap ... just rip it uncompressed.

Unless you have 1000's of CDs.

 

 

[Wavelength]

Larry,

 

Basically it has been found that it does not matter what type of computer or operating systems. Flat PCM files like WAV and AIFF will always sound better than Lossless files (FLAC, ALAC=Apple Lossless, etc...).

 

Why? I don't know it really does not make any sense. We have tested the file integrity and they all match up, but there is a difference when you hear it.

 

The good news is that you don't have to rip all the files again. The Lossless as I said are bit copies and can be converted to AIFF without loss of integrity.

 

I am working on a test bed to determine bit accuracy at several levels as well as sonics using some testing files I create and will post some results when they are finished. Problem is I have never been busier and testing like this can take weeks worth of time.

 

I did some THD measurements and most of them were only a few percentages different than their Lossless companions. But the levels were so low that I don't think that is an aspect of what we are hearing.

 

Thanks

Gordon

 

[WoodsDweller]

Even then, since it's about 4 cents of HDD space per CD.

 

The only exceptions I can think of would be if you are using SSD (solid-state drive), which is still very expensive, and the 30% or so less space with lossless compression would amount to a few hundred dollars of SSD

 

[markr]

Poo asks: "Can we please at least try to be clear on exactly where the problem supposedly lies? Does everyone here agree that ripping a file from CD to ALAC, then transcoding that same file to AIFF will give you the same result as ripping the CD straight to AIFF?

 

YES! I agree.

 

[WoodsDweller]

When you are writing code for a lossless compression, the easiest test you can make is that it restores an identical file. You won't release it until it does that. Your automated regression tests will check for that, and if there is a bug in a release that breaks it, it will be caught and fixed before it makes it to the field. In our universe of things to worry about, that just isn't one of them.

 

[Abstraction]

The collection--or more precisely a little more than half of it-- was ripped in wav, not a lossless format.

 

I started in computer audio when I got my first Ipod--some years ago. I thought--wow--I want this kind of access to my collection on the big system. It didn't occur to me that there was a community of people who could help me. So the files I had were ripped with various software and sometimes on a dubious drive. The metadata was an impossible mess. Helpful people on this board suggested ways I might clean it up, but nothing worked.

 

It was a task, but it's all in a.i.f. now. It sounds great. Album covers pop up on the screen. Etc. It seemed the only way to be sure of what I had. I have it twice backed up.

 

I do use apple lossless on my Ipod.

 

It does seem that there begins to a consensus that wav and a.i.f. sound better than lossless formats, and we do not have a way to measure what we are hearing. That would be quite a step.

Don

 

[glt]

I think some of the observations from the more credible people (like Gordon) should be kept in a "Truth section". So busy people like me :-) can go straight to the truth. So lossless is lossless is lossless. And the difference between lossless and uncompressed cannot be attributed by the data. And Gordon will publish his results in due time :-)

 

[audioengr]

I have had enough customers report a difference that I believe them.

 

How can this be?

 

Easy. The real-time performance of the ALAC CODEC is different than the static performance. The difference may just be jitter, however, and not detectable with data compares etc. The differences may also be in the control info, not the data.

 

Data compares dont tell the whole story. Been there, done that.

 

If your particular system has high sibilance, you may not hear any difference.

 

I recommend using AIFF. The only downside is that it evidently does not support album art.

 

Steve N.

Empirical Audio

 

[audioengr]

Gordon - what does it look like on a spectrum analyzer? Are there obvious differences?

 

I think the big problem here is transient versus steady-state. It is easy to examine the harmonics and noise of a steady-state signal on a Spectrum analyzer. But this is not music. Music is much more complicated, more transient.

 

Its like you need to capture a particular musical point in time or a short passage and compare these. Very difficult, if not impossible IMO.

 

Steve N.

 

[flatmap]

Markr, so something like this:

 

Open iTunes.

Open Activity Monitor and get iTunes process id

Open Terminal window.

Type "renice -1 -p " into Terminal

 

Does that sound right?

 

Is there some way to see what priority a process is currently running at? At the bottom of the renice man page it said "SEE ALSO nice(1), rtprio(1), getpriority(2), setpriority(2)"

 

I tried doing "man getpriority" but the response is that there is no manual entry for getpriority.

 

[markr]

Hi flatmap. I don't have direct experience at 'renice-ing'. Things are running just as I like them now. But I know this much: You are going the right direction by using the "-" before the priority variable ("1" in this case). Your example should read "renice -1 xxx -p" where "xxx" is the process number of iTunes (mine is showing up as process 713 right now). The documents online for the renice command, http://www.opengroup.org/onlinepubs/007908799/xcu/renice.html , state that the "-p" is not necessary, and therefore would not have to be added. It is also stated that the consequence of errors while using this command are to return the system to its default setting - that can't be bad. This brings me to the last part of your question. The default setting for processes is priority "0". That should be what every process is set to, until the user of the process changes that. As for being able to single out a process and see what its priority is without 'assuming' zero, I don't see it yet but I'm looking..... This might be it: http://www.opengroup.org/onlinepubs/000095399/functions/getpriority.html .

 

Meanwhile keep in mind that UNIX is a multitasking/multithreading OS, so as I read somewhere:

"...But there's NOT an absolute rule that runnables are started and run without limit in the order "least nice first" - there has to be some sharing and although the higher priority processes will be kept waiting far less, they will be kept waiting on occasions."

- So this renice command may do nothing for you, or maybe not what you want it to do. What you want to do is to avoid having to transcode all of your lossless files back to uncompressed files, right? If that is it, please let us know how renice works for you. I run uncompressed files almost exclusively - even on my iPod, but am curious nevertheless. Not curious enough to spend time experimenting with it though

 

regards,

markr

 

[davidR]

As others have said, hard drive space is so cheap these days (not SSD). Out of all the many variables already present in computer audio why not eliminate one that could possibly compromise sonic fidelity? Just my thoughts.

 

[The Computer Audiophile]

Hi DavidR - My thoughts exactly.

 

[flatmap]

Thanks, markr, very helpful!

 

I get what you're saying about renice not being the ultimate approach here since the priority setting is not the absolute consideration; higher priority processes (less nice processes) will just be kept waiting less than otherwise. So this is no substitute for an optimized real-time application and it may have no audible effect.

 

Keeping along this line of thought, however, it would seem that one wants to 1.) renice iTunes to -1, 2.) don't start any other applications (hey you! no surfing the internet while the music is playing!) and 3.) kill all nonessential background processes such as the scheduler for backup, Palm desktop background, growl helper, whatever.

 

Ah, OK, just tried out "renice -1 2076" where the 2076 is the process id for my currently running iTunes process as given by Activity Monitor. I got an error message back, however, saying "setpriority: Permission denied". So alright, even though I'm logged in as admin, I don't have privilege to run this. Apparently my admin privilege within Finder doesn't automatically carry over into my terminal (bash) session. The bash shell doesn't acknowledge me as root? I'm hurt.

 

Well there's always something with computers. Next step is to figure out how to login as root, I think. And then try to renice.

 

markr, on your last point, once I realized that my copy of Symphonie Fantastique was never going to sound acceptable as ALAC, I bit the bullet and converted everything to AIFF. Frankly I don't know if I needed to do this for all of my ALAC files, but I decided to go all the way. In any event, I'm just fiddling around with this since I'm off from work this week.

 

[markr]

That is why I use uncompressed files almost exclusively as well. .....Well, OK I started using nothing but uncompressed because I have been known to edit and/or loop audio for my own nefarious purposes, and it works much more satisfactorily with the original flat file or portion of the original file. It became habit for me before hard drives were as inexpensive as they are now. I solved the affordability issue back then by using Syquest and Zip drives for storage, swapping files I was working on back and forth to the 2nd system hard drive for editing speed purposes. Heck, I don't think MP3, never mind lossless was even commercially/publicly available at the time I started doing this. Memories.....

 

But flatmap is tinkering now, don't stop him! He's having fun. ;^)

 

- markr

 

 

 

 

[markr]

... flatpack! Your liable to be restarting a controversy: "once I realized that my copy of Symphonie Fantastique was never going to sound acceptable as ALAC, I bit the bullet and converted everything to AIFF.". LOL - I do find some lossless files to sound just great to me. It's just that I had enough misses with the codec's performance to make me leery of using it for my main library. It seems totally bulletproof as a storage or delivery (dowload) medium however.....

 

I was kind of hoping that you were just experimenting now and had decided to transcode everything to AIF, but that isn't what your post had said and I didn't want to tell you what to do. Besides, it would be nice if a way could be figured out to get lossless to be more consistent upon playback. I like to tinker too, but my tinkering is usually directed towards writing a tune on the keyboard or tweaking my softsynths and samplers in Reason, http://www.propellerheads.se/products/reason/index.cfm?fuseaction=get_article&article=what-is-it , to sound (even) more like the analog instruments of yesteryear.

 

Speaking of work - I'm supposed to be looking for more companies to drop my resume' off to right now.

 

Happy 'fiddling'.

-markr

 

[BEEMB]

Maybe I should read threads before I post in future - I've gotta get out of my skimming over things habit!

My link to stereophile above was useless as it compare lossy files to uncompressed. Sorry for wasting anybodies time.

 

But, quickly referring back to that article ..

 

It states that a 320kbs AAC can be measured to be inferior to uncompressed. But, sometimes it may not be audible.

 

So, bearing in mind that was a lossless AAC file, surely with ALAC it must be almost impossible in a blind test to detect differences.

 

I completely understand where some people are coming from regarding the decoding process, real time and all other items mentioned above. I'm just haing tough time accepting some of it having tried some of my own tests.

 

Or just be done with it and, as posted multiple numbers of times within these forum walls, rip ALL your music to AIFF or WAV and be done with it. Then you know for sure you're getting optimum quality.

 

There is no way to blind test this is there? I was going to volunteer to setup some files for you to all compare - see who can guess which is which, but of course, an ALAC file converts back to a WAV/AIFF with no loss of data.

 

Is there a way around that ?

 

Matt.

 

 

[flatmap]

Matt, I don't really know anything about the internals of the decoding process. I guess the way I'm thinking about it is that when the codec runs (as a decoder), it creates an output stream to your sound card and it is this output stream that must be different from the unpacked static file.

 

I think the way we want it to work is for the player software to unpack the lossless file in .aif or .wav format into a buffer -- and then have the player create the output stream from there. Then I think we'd be in good shape. (!) However there would be a delay from the time you click "play" until the sound actually starts. So the designers may have decided that this was not user friendly. And maybe only the audio fringe elements would care anyway -- they may have been thinking. :-)

 

So, in trying to say this clearly, I don't think any change is needed in the ALAC format. I think we want improved playback software.

 

But yes, I bet there are plenty of ALAC files where I wouldn't notice a difference even with the current player technology. I listen most critically to classical music and that's where I'm least tolerant to any perceived aberrance. Probably I over reacted in converting everything to AIFF -- but now I don't have to worry about it. And as others have mentioned, the cost per gigabyte is no longer an obstacle.

 

[markr]

Hi Matt,

 

No. I don't think so. I believe that is part of what Steve was trying to express in his post(s) above about comparing the two: "..Its like you need to capture a particular musical point in time or a short passage and compare these. Very difficult, if not impossible...". But then of course, he was talking about measuring a difference - not hearing one. I think that it is already established that many people's *opinion* is that they can hear a difference between (some) uncompressed and flat audio files. Subjective though that may be, *some* experts agree. Like Gordon said in an earlier post in this thread: "..It really doesn't make any sense..", but he & his team hear it too (my inference from reading that post - he uses the word "we"). I'm sure the MOST frustrated folks around this question are the ones that have the capability to measure audio, but no techniques are yet available for this particular anomaly.

 

markr

 

 

 

[poop]

I don't think any change is needed in the ALAC format. I think we want improved playback software.

 

Not that I'm any sort of expert, but yes flatmap, I would have to agree with what you suggest here. Essentially, if we all agree that the ALAC file itself is fine, it is down to the process being used to play it back.

 

[WoodsDweller]

New hypothesis.

 

Lossless compression is not guaranteed to work on a particular data set. Take some data, compress it losslessly, re-compress it, again, again, eventually it will stop shrinking, or even grow again as the bookkeeping information required exceeds the compression achieved.

 

Even if you are applying an algorithm uniformly across a file, the amount of compression you achieve in each chunk of the file will not be uniform. Some chunks might see good compression, others will be nearly uncompressed.

 

I can see various things that could result in the time taken to decode, say, each 1000 samples not being uniform. Not that they are particularly slow, it's all very fast, but that the number of CPU cycles per 1000 samples might not be uniform.

 

In the absence of proper buffering in the drivers (which I believe would just fix this), you could see subtle timing differences across different parts of the file. Could these be audible?

 

An uncompressed file would still have all the issues of running in a non-real-time OS, but it would be absolutely uniform in this regard.

 

A similar situation would arise with variable bit rate lossy files, but a) there is a substantial quality improvement with variable bit rate since it discards less information, which might tend to mask this effect and b) it's a crappy lossy file in the first place, and any problems would be attributed to that.