• In What Format Should I Rip My Music?

    There are endless file formats to consider before ripping CDs. Some of the popular formats are WAV and AIFF (uncompressed), and FLAC, WMA, ALAC, APE, and WavPack (lossless compression). The decision about what format to use can be made by considering disk space and interoperability.
     

     


    Please note: I am certainly not the Minister of Information and these statements should be considered my opinion based upon my own knowledge, research, and experience.

     


    The quickest path to determine the correct format for your situation is this:

    1. Can you afford the disk space required to use uncompressed formats?
    a. If yes, my answer is AIFF.
    b. If no, proceed to number two.

    2. What operating system(s) are you gong to use?
    a. If Windows only my answer is FLAC.
    b. If Mac OS X only my answer is ALAC.
    c. If Windows and Mac OS X my answer is ALAC.

     

     



    Why These Formats?

    1. Uncompressed AIFF

    Uncompressed - Question number one is all about compressed versus uncompressed formats. If you can afford the disk space I see no reason to use a compressed format. Right now one terabyte is literally one-hundred dollars at NewEgg. Even with the current economic recession (Jan, 2009) this is reasonable. There is currently much debate about whether or not there is an audible difference between compressed and uncompressed formats. This fact alone is reason enough to avoid any type of compression. As with all other audiophile "dilemmas" this one is likely to go on for the foreseeable future. The whole issue can be avoided by selecting an uncompressed file format. In my opinion using compression means one has to rule out the possibility that compressed formats might later be found to have unforeseen issues that uncompressed formats do not have. Is it likely to happen? Absolutely not, but why take a chance you don't have to take even if it is minute?

    Almost everyone agrees that lossless compression is lossless. But what exactly does that mean? To many it means that lossless compressed files are exactly the same as uncompressed files from the time they are ripped to the time they hit the DAC during playback. In my opinion lossless files are lossless in terms of compressing them as a method of storage and transport. One can convert an uncompressed file to a lossless file and back again all day and night without any loss of data. The potential issue arises when compressed files must be uncompressed in real time during playback. In my opinion there is no reason to compress a file that must be uncompressed to be played back. One often used comparison is between data files being compressed with WinZip and audio files being compressed with a lossless codec. I think this is a good comparison, but it leads me to a different conclusion than many people who use the analogy. I too agree that a word document compressed with WinZip will be the same word document whether I zip it and unzip it one or one-hundred times. After all lossless is lossless. Here is where my opinion differs and it involves real time uncompressing of data/music. If you were to losslessly compress 20,000 word documents & spreadsheets (roughly the same as compressing 2000 albums with 10 tracks each). It is very likely you would experience some hiccups upon opening the files every once in a while. The data certainly won't change without some kind of corruption, but it's very likely your computer will "stutter" a few times opening thousands of zipped documents and spreadsheets. Unzipping a document is one of the easiest tasks a computer is capable of doing. This is similar to playing music as it too is rather simple for a computer to handle. I look at it this way. Audiophiles often spend thousands of dollars for an extra .01% improvement in their system. So, I see know reason to use any compression at all. It's all about managing risk. Uncompressed AIFF and WAV eliminate the risk of decompression errors in real-time. Granted the chances of hearing something wrong with a compressed file are minuscule or arguably nonexistent, but audiophiles are into reducing minuscule risks.

    Format longevity is another reason I elect to avoid compression. Uncompressed formats have been around for decades and I'm betting they'll be supported for the foreseeable future. WAV was developed for Windows 3.1 around 1991 by IBM and Microsoft. AIFF was developed for the most part by Apple in 1988. Compressed formats haven't been used for nearly as long. FLAC was first used byXiphophorus in 2003 while Apple Lossless was first introduced on April 28, 2004. The comparative youthfulness of compressed formats is certainly no indication of their validity or performance. Rather "newer" technologies tend to have many competitors that lead to format wars. This can lead to one, two, or many formats eventually winning out. In the music server world this means that since applications only support a limited number of formats there will be certain compression schemes dropped or added by applications sometime in the near future. Another argument can be made against uncompressed formats because they are getting long in the tooth. This is certainly a concern, but not one I lose sleep over. Dropping AIFF and/or WAV support by any application doesn't seem likely. Supporting these uncompressed formats has been done "forever" and does not require a company to reinvent the wheel to continue supporting them.

    AIFF - The two popular uncompressed formats are WAV and AIFF. I use AIFF because it natively supports embedded meta-data tagging and album art. WAV files in general don't have embedded meta-data or album art. In addition WAV files can be limited in size to between two and four GB. This may not seem like a real world limitation but 24/192 music can easily reach this limitation. Sonically I've never heard of anyone identifying differences between WAV and AIFF.

     

     



    2. Lossless Compressed FLAC and ALAC



    Windows - Lossless Compressed FLAC

    For Windows users who either cannot afford enough disk space or elect not to purchase enough disk space for uncompressed music I recommend FLAC. Free Lossless Audio Codec is the best lossless compression option on the Windows platform for a few reasons. FLAC supports excellent meta-data tagging and album art. I recommend FLAC over Windows Media Lossless (WMA) because FLAC is open source and the most widely supported lossless codec. FLAC can be used with MediaMonkey or other popular players that allow bypassing the dreaded Windows KMixer. Windows Media Player does not have native support for FLAC, but I don't consider Windows Media Player to be a true audiophile application.



    Mac OS X - Apple Lossless Audio Codec (ALAC)

    iTunes is the gold standard playback application on Mac OS X. Unfortunately iTunes does not support FLAC natively and the enabling plugins / applications like Fluke are less than flawless. I personally don't use Fluke as I find it a bigger headache than it's worth. Thus ALAC is my recommended lossless compression scheme for OS X. Full meta-data tagging support and album art. Since it was developed by Apple themselves there are very few issues with ALAC. File sizes are reduced between 40% and 60%. This also helps people synchronizing iPods with little available space. Whenever the Apple Airport Express is used to stream music all files are actually converted to ALAC in the process. So, starting with ALAC may be a good thing in this situation.

     

    Windows and Mac OS X Interoperability

    Audiophiles that require interoperability between Mac OS X and Windows platforms have more options by selecting ALAC. As I said earlier playing FLAC on Mac is a non-starter for me. Playing ALAC on a PC is much easier. Applications such as JRiver and WinAmp support ALAC. While the files will play on these Windows applications there are issues with meta-data tagging. Cross platform interoperability without issues is still very elusive. Even cross application interoperability is currently less than good.

     

     


    Closing Words

    As I made clear in this article I am definitely not proposing the one and only file format, but my preference is for uncompressed AIFF files. This is my recommendation for many reasons, among them avoidance of ambiguity, reduction of risk, and format longevity. In addition, this whole discussion may be moot when multi-terabyte drives are twenty-five dollars. When disk space is no longer a concern data compression is no longer a concern in my opinion. If I had my wish I would select a file format somewhere between AIFF and FLAC. Uncompressed AIFF as open source as FLAC would be pretty nice. Even though lossless compression is not my favorite thing I clearly understand that it works fabulous for a large percentage of music lovers. Whatever works for you is OK with me. There is no right or wrong answer. If you're on the fence over what format to select you're in luck. Trying AIFF, FLAC, and ALAC is totally free and allows you to decide for yourself. In an industry where one can't walk into retail store without dropping a couple grand there is something to be said about a free exercise involving high-end audio anything.

     

     
    Comments 114 Comments
    1. The Computer Audiophile's Avatar
      The Computer Audiophile -
      soppman - Welcome to Computer Audiophile. I appreciate your involvement in the site but I'm not following your logic on this comment. The article does not mention anything about CPU utilization or jitter. Plus, if this was a worry to someone and they switched to an Atom or Via Nano my guess is CPU utilization would go much higher because the ability of these CPUs is reduced significantly from a Core 2 Duo or Xeon.<br />
      <br />
      Anyway, welcome to the site I hope to see you here often.
    1. zachmattheus's Avatar
      zachmattheus -
      Why not AAC? Right now I am using only the internal HD of my iMac and don't want to run out of room just yet. Perhaps in the future I will upgrade to an external or server but not yet. Also, what do you do with all the music you've already imported or downloaded and is AAC?
    1. The Computer Audiophile's Avatar
      The Computer Audiophile -
      Hi zachmattheus - Good question. I don't recommend AAC because it is a lossy compression scheme. When I rip CDs I want an exact copy of the original music containing all the bits and bytes. AAC throws away some bits and bytes to achieve smaller file sizes. In my opinion there is no upgrade path for your current AAC files. You can't reconstruct the data that has been tossed out as part of the data compression process with AAC. In other words you can't get something from nothing.<br />
      <br />
    1. glt's Avatar
      glt -
      If you use airport express, then it MAY be better to use ALAC since this is the native format for the Airport Express (at least in the old days).
    1. 6sigma's Avatar
      6sigma -
      Chris:<br />
      <br />
      Very informative article.<br />
      <br />
      I bit my tongue a couple of times before posting this question, but I think it's valid and rational. It does, however, carry with it the risk of a "religious" war. That said...<br />
      <br />
      What is your view of the future of the AIFF format <strong><em>IF</em></strong> something were to happen to Apple as a company? With hardly a 10% market share of the computer industry, does their 80%+ share of the portable music device business insure AIFF's future?<br />
      <br />
      I'm not thinking about the next 36 months. I'm trying to look 10 or more years down the road - nearly always impossible to do in tech. <em>However, there were people who thought we'd <strong>always</strong> have slide rules, Wang word processors, DEC minis, 5.25" diskettes and eight-track cartridges.</em><br />
      <br />
      Thanks again for an outstanding site.
    1. glt's Avatar
      glt -
      You convert them to wav right after the company disappears
    1. The Computer Audiophile's Avatar
      The Computer Audiophile -
      Hi 6sigma - Thanks for the post. Based on your forum name (6sigma) I wouldn't expect anything less than a (far) forward looking question. Rumors of Apple's demise have been greatly exaggerated for decades. I realize you did not suggest Apple is going to disappear, especially with your <b>bold IF</b> but I thought I'd add that sentence in here for a little background perspective. If something happens to Apple my guess is that support for AIFF would continue for quite a while. AIFF has some market share in the pro audio world. This would help push for continued support of the format. On the other hand, as suggested rather bluntly above, one can always convert to another uncompressed format. This would be an absolute mess for large libraries in terms of tagging. Months of librarian type work would be required.<br />
      <br />
      I wish there was an easy answer to all of this, but then again this site would be rather boring if that was the case :~)
    1. Monk's Avatar
      Monk -
      Chris,<br />
      <br />
      I'd just like to caution your suggestion for .AIFF as cross-platform. As some of us have recently discovered, PC friendly player applications don't support .AIFF fully.<br />
      <br />
      Dave
    1. 6sigma's Avatar
      6sigma -
      The clarification of what <em>might</em> be required to convert from AIFF to WAV is really helpful. For big collections that have not yet been ripped, these are non-trivial matters. They may not be show-stoppers, but they certainly aren't to be ignored.<br />
      <br />
      I share your belief that AIFF has enough momentum to continue forward without Apple should such a need arise. Thanks to everyone offering comments.
    1. The Computer Audiophile's Avatar
      The Computer Audiophile -
      Hi Dave - I consider AIFF to be the best choice between the two popular uncompressed formats. Unfortunately there is no silver bullet.
    1. audiozorro's Avatar
      audiozorro -
      I think we will have the AIFF, WAV, and FLAC audio file formats for the foreseeable future. We have had AIFF since 1988, WAV since 1991, and FLAC since 2003. These audio formats are so deeply entrenched and supported they’re not going anywhere. Some of the lossy audio formats such as MP3 may also be around for just as long since fast digital transmission and humongous storage capacities will always have advantages.<br />
      <br />
      The better solution is not necessarily for consumers to choose AIFF or FLAC, but for hardware and software vendors to fully support both these formats. Sorry for my ranting again, but manufacturers and vendors should do their best to satisfy customer needs and desires. Apple has the financial resources and technical talent to provide an updated iTunes that supports FLAC, even if they choose not to offer the enhanced version for free.<br />
    1. phunge's Avatar
      phunge -
      Several years ago, I asked myself this very question before undertaking the task of ripping my existing CD library. After much research, I decided to rip all of my music to single-file .WAV with cuesheets (see here for a description: http://wiki.hydrogenaudio.org/index.php?title=EAC_and_Cue_Sheets )<br />
      <br />
      My reasoning was:<br />
      1. Longevity<br />
      .wav is a simple, well documented standard that basically just represents the raw audio samples as recorded on the CD. You can also use the cuesheet and .wav file to burn a replacement cd if required that will be an exact copy of the original making it the ideal archive format.<br />
      <br />
      2. Simplicity<br />
      Lossless compression adds a lot of complexity and overhead. Being a programmer, I never quite trusted the encryption and decryption routines, or liked having to rely on someone else's library<br />
      <br />
      3. Accuracy (most important)<br />
      One of the tenets of audiophilia is reproducing as closely as possible the sound of the original recording. For any serious computer-based playback system, in my opinion you have to start with accurately ripped source files.<br />
      <br />
      When splitting the CD into a separate file for each track, you have to decide how to handle the gaps. (see http://users.fulladsl.be/spb2267/gapscue/gapscue.htm) By ripping to a single file, you don't have to worry about the gaps, the cuesheet is used by the player to determine where you are. Playing back from a single file aslo avoids the problem of gapless playback http://en.wikipedia.org/wiki/Gapless_playback (though most software programs have now fixed this problem internally)<br />
      <br />
      Foobar2000 supports playing back these files, but I've never been a big fan, so I wrote my own media player program that exclusively plays back media files recorded as single-file .WAV + Cuesheet. Being an audiophile, my focus was on accuracy. The program mounts the single large .wav file, and reads ahead to fill a memory buffer with audio samples. A separate high-priority thread then takes the audio samples from memory and renders them to the audio device (Ideally to a high-quality external DAC via USB who's drivers bypass the dreaded Kmixer in WinXP). By writing my own software, I felt confident that the audio samples were being passed directly to the audio device without any modification of any kind. During playback, the software periodically polls the audio device to determine which sample is currently being played, and then does a look-up to the cuesheet to determine the exact location of playback. Because the file is not split, during playback of a pre-gap, it knows exactly which track is being played, and the fact that we are in the pre-gap is displayed by counting down from a negative position to the position of index 01. In my opinion, this most closely resembles not only how a CD player works, but also the experience of playing an album. I tend to think of my music collection as a collection of albums, not a loose collection of tracks. The player represents my library in this way I.E. I select an album to 'load' into the software transport (load the .cue sheet and open the .wav file for i/o). The player transitions seamlessly from track to track, because it's really just playing back one large track. Skipping is accomplished by determining the location of index 0, and seeking to that position in the file. Because of the memory buffering scheme, Disk I/O does not negatively affect playback. <br />
      <br />
      Simple and effective. As any anal (borderline OCD) audiophile would insist upon
    1. arin's Avatar
      arin -
      Hi Chris,<br />
      I share most of your views and I do believe that aiff, if you have enough space, should be a better choice.<br />
      In the pro-audio field everyone I know use aiff, apart from some people on the Window platform who use WAV for practical reasons...and they don't care about tags and things like that!<br />
      <br />
      BUT, just for the record, I made another test about ALAC and aiff playback: I'm currently very fond of one of my new toys, the Wadia 170iTransport and as I recently read two reviews where people wrote to hear differences between an ALAC file and an aiff one, I decided to proceed to record the digital output of the Wadia directly into LogicPro.<br />
      I tried the test several times with different kind of music ripped both in ALAC and aiff and then went on to compare the two formats using the inverted phase system: in every single case the files I got from my "humble" iPod into Logic were identical, bit by bit.<br />
      <br />
      So as someone told in another forum on CA: if an humble iPod can do it, why a PPC or an Intel processor shouldn't?<br />
      <br />
      This is not meant to begin a "format war" debate again, this is just food for thoughts...<br />
      <br />
      Ciao!<br />
      Arin<br />
    1. The Computer Audiophile's Avatar
      The Computer Audiophile -
      Hi Arin - Your test mirrors pretty much what I wrote in the article. I also agree that almost any computer can handle this decompression in real time. I'm just on the side of reducing the possibilities of errors however small it may be.<br />
      <br />
      Thanks for comments.
    1. ldolse's Avatar
      ldolse -
      The biggest issue with the uncompressed formats is a major lack of tagging support across most applications on both platforms, iTunes being the exception for AIFF. I'm still looking for other apps with AIFF or WAV tag support, so my search isn't over.<br />
      <br />
      I can definitely see how decompression can affect jitter and accuracy (let's not turn that into a debate, I'm happy to disagree with those who disagree), so I'm a fan of playing back uncompressed PCM data. The one option that allows you to use a compressed formats in an uncompressed fashion are some of the memory based players. These basically decompress the data into memory before playing (possibly applying SRC at that time), and then play back the uncompressed data directly from RAM. That said, the only two memory players I know of are cPlay and XXHighend. Unfortunately I think both of those programs are still pretty immature, neither support tags and overall are pretty limited compared to the popular playback tools. <br />
      <br />
      I think the whole CUE file option is interesting, but I think that forcing computers into an album only mode kills many of the benefits of computer based audio in the first place. That approach doesn't lend itself to simple playlist management, shuffling, etc...<br />
    1. PeterSt's Avatar
      PeterSt -
      <cite>I think the whole CUE file option is interesting, but I think that forcing computers into an album only mode kills many of the benefits of computer based audio in the first place. That approach doesn't lend itself to simple playlist management, shuffling, etc...</cite><br />
      <br />
      For a number of reasons wrong arguments are being used (kindish).<br />
      First of all the explanation of phunge on the "why's" to do so, don't have much ground if other means can do just the same. Thus, XXHighEnd does a. exactly what phunge describes (like cPlay does btw) but b. can do that in the exact same fasion for separate tracks. -> Once playback is going on for separate tracks, the audio engine doesn't know anymore about separate tracks and it just comes down to the exact same. Including "gapless" virtues that is.<br />
      <br />
      Then Idolse, what you describe also is true, but then for those cases this would not be suported. Thus, for XXHE counts, whether Cue Files or not, internally (at shuffling, anything) the individual Cue File tracks are retrieved virtually and all can be treated as if those individual tracks really existed (and this is not what cPlay does I think).<br />
      <br />
      Just the above "functionalities" consume all of the development time at being a "memory player"; Whatever it is you do, it is a 100 times more complicated, for sure if the Cue File stuff is supported also.<br />
      It indeed *is* all for a good reason, because, yes, a.o. it becomes sheer impossible to be bothered by any decompression negatives. And, it *is* true that you can hear that, because the capacity it takes influences sound (when done in real time).<br />
      <br />
      Chris, personally I don't think the arguments of "it may give hiccups" or "you'll never know whether the decompression is 100%" are real good ones. I mean, the first just shouldn't happen in a decently setup system, and the second is just about data, and if we don't trust that, let's forget about computing.<br />
      But since the first might not be under good control for everyone, YMMV here.<br />
      <br />
      Peter<br />
      <br />
    1. PeterSt's Avatar
      PeterSt -
      Chris,<br />
      <br />
      You may not be aware of it, but since AIFF is not supported natively by Windows a similar conversion has to take place as any decompression conversion. The resources needed are about equal, with my personal conclusion that when you have the opinion to better not use FLAC (etc.) because of negatives like possible hiccups, one should better not use AIFF on a Windows PC just the same.<br />
      <br />
      In the end *my* opinion is that these things just don't matter BUT ... they do when done in real time. So, once you use a player that has to convert these things in real tim (better : on the fly), it is better to avoid them.<br />
      This would mean using AIFF on a Mac and WAV on a PC.<br />
      This is not to change your own conclusion, but to put it in some context.<br />
      <br />
      Then, if I may say so, the subject should be not as "hot" or deterministic for the future as it now seems to be. I mean, once you have chosen a lossless format, means to convert to another format exist all over, and at the moment you want to change, just convert.<br />
      <br />
      Just convert ? this is not completely true, because it may take vast manual effort to convert all your albums, because most of the tools can't do it in one go (which is not related to the ability of batch processing, but to being able to recursively treat (find) all the folders).<br />
      <br />
      My 2c, Peter
    1. PeterSt's Avatar
      PeterSt -
      <cite>The biggest issue with the uncompressed formats is a major lack of tagging support across most applications on both platforms</cite><br />
      <br />
      Yes, this is true of course. But allow me to put this into some real life context; The sad, sad project of developing a player ...<br />
      <br />
      First thing to recoginze is that when we talk about the internal support of audio playback (might it be MS with Direct Sound or Apple with ITunes) many many things arre arranged in there. A developer could call some function, and audio starts playing;<br />
      The many people developing that inherent audio support thought of <br />
      a. as much as possible to support;<br />
      b. as much as possible to get customers which souldn't dive off to another platform once they are there.<br />
      <br />
      Both are contradictional.<br />
      Now let's see what factors are in the equation, and what a developer starting right from the ground has take into account (and on a side note, I know, because I did so) :<br />
      <br />
      - Sample rates, like 44.1, 48, 88.2, 96, 176.4, 192, 352.8 (and possibly 384).<br />
      <br />
      - Bit depths of 16 vs. 24 at each of these sample rates. Note that 16 counts for each, because of DACs not supporting more, while they do support 192 sometimes.<br />
      Note that in most cases 24 bits comes down to 32 because DACs or other means won't accept 24.<br />
      <br />
      - The native forms in which above appear. This may be WAV/AIFF (these are not the same).<br />
      <br />
      - The compressed form in which above appear. Think of MP3, FLAC, ALAC, etc. etc. etc.;<br />
      <br />
      - The means of tagging applied, which may differ for one form, like MP3. There are *no* standards here (in practice !!).<br />
      <br />
      - The means of tagging applied into standards not allowing that. Example : WAV.<br />
      <br />
      - The means of tagging by itself conformed to standards, but the standards may change throuhgout time. Example : FLAC.<br />
      <br />
      - The means of ripping. Example : WMP outputs WAV, but the WAV header (outside tagging) is 2 bytes longer than the standard.<br />
      <br />
      - The means of recording. Example (more and more occurring these days obviously) : 2L. They might not know it themselves, but they apply the WAV standard wrongly.<br />
      <br />
      - The means of tagging. Oh yes, this is another one, because dedicated tagging software exists in many forms, and don't forget a rip by Winamp can be tagged by Foobar.<br />
      <br />
      - The means of physical representation. This is <br />
      a. Cue Files with one large track<br />
      b. Separate tracks, but a Cue File listing the individual track sequence.<br />
      This is used by some ripping software, that not including the track number in the track name, but the player going along with it using the .cue file to properly sort the tracks. Without this, the tracks will list in alphabetical sequence.<br />
      <br />
      Above dimensions (maybe I forgot one or two) have an impact on already one very important thing you might not think of : the length of the music data and where it actually starts;<br />
      When all of the above dimensions influence (the sample rates and bit depths the least btw), the developer must take this into account.<br />
      <br />
      Example : A rip by WMP, some nice tag data added, turned into a Cue File, in a nice FLACed form.<br />
      <br />
      Now to my point : As a developer it can take you a life time to sort out the track starts and lengths for all the numerous combinations only. I mean, go Google and find out how WMP arranges this all. Do the same for Monkey, ITunes, dbPowerAmp, WinAmp etc. Only with luck you will find it, *if* available at all.<br />
      FLAC has nice documentation on it (which is logic), and EAC doesn't need it because it is normal WAV, and WAV has documentation on it (logic again). But already for FLAC it may take you a week to understand and get it all in. Remember, including the documentation.<br />
      <br />
      On a sidenote, it is not sufficient to find the start of the track and let it run to the end, because crazys exist adding tag data at the end of the file. Not nice for your speakers when not recognized as such.<br />
      <br />
      <strong>The real point</strong> is, when it is already so difficult to find out the track start and length, just forget about the tag data. Tag data can exist in an infinite number of forms, and what does not exist today, will tomorrow.<br />
      <br />
      The problem emerges by means of self supporting software. Think of ITunes as an example;<br />
      Standards for the tagging don't exist anyway (at some high-level MP3, yes), so when ITunes allows you to rip, tag *and* playback, why not do as you like, and put in there what you can recognize yourself. What's the problem ?!<br />
      Well, not much, until you hop to another player of course.<br />
      <br />
      So, as a real life example you can trust me that when I (or XXHE) just got around supporting all those combinations mentioned above (meaning, for any ripping means, for any tagging means but for a few formats only (WAV, FLAC, AIF(F), MP3) and related to the track start/length only, I will probably never start thinking about supporting all those crazy means of tagging. It would take me another year, and when done I can start again because a next version of ITunes started to support video for tag data. Whatever.<br />
      The only thing feaseable is make something my own. This may take a few weeks only ...<br />
      <br />
      So now you know why these difficutlties amongst players (and platforms) exist. :-)<br />
      Peter<br />
    1. audiozorro's Avatar
      audiozorro -
      I haven’t thoroughly reviewed the state of audiophile music downloads, but it seems to me that few if any vendors offer ALAC music downloads. ALAC, also known as Apple Lossless, doesn’t even seem to be available from Apple’s own iTunes music store.<br />
      <br />
      I know I must be missing something, but I can’t see why I would ever want ALAC. So long as the major of vendors offer high rez digital downloads or discs with AIFF, FLAC, or WAV audio files, those are the only formats I wish to consider. My preference for new digital music is not to rip physical discs but to get the digital audio files directly from the vendor in one of those formats.<br />
    1. ldolse's Avatar
      ldolse -
      Peter, more or less agree with you on a lot of your points. There are standards for tagging though, and I'm hooked on the concept of database type access that goes way beyond filesystem constraints.<br />
      <br />
      That said, I'm looking for the best of both worlds - killer UI and first class playback. I think you're doing great from the playback side, but as you yourself stated it would take an incredible amount of work to get a complete front end working on your own. <br />
      <br />
      My dream option would be for someone like yourself or cics to leverage an open source project like XBMC for the tag based database front end, etc, and just use a memory based player as just that, the back end engine. This isn't that far outside the realm of possibility, as XBMC already supports calling a third party player, alternatively you could just rip out the paplayer portion they currently use and replace it with your own. I don't think cplay could really support something like this the way it functions today, but with XXhighend this might not be that farfetched an option.