Article: In What Format Should I Rip My Music?

[soppman]

if you guys worry so much that the cpu works harder when using flac or alac and therefore for some reason couses jitter, why dont you try out an Atom cpu or via nano? even a busy one will draw much less power then a idle fancy intel duel core.

[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.

[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?

[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 />

[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).

[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.

[glt]

You convert them to wav right after the company disappears

[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 :~)

[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

[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.

[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.

[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 />

[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

[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 />

[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.

[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 />

[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 />

[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

[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 />

[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 />

[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.

[haiku1]

No one mentioning CBR vs VBR?<br />

Is it not worth it, Chris???<br />

<br />

Kind Regards

[ldolse]

Just found out something interesting, which probably means the recommendations for Mac vs. PC should be tweaked.<br />

<br />

Mac:<br />

- AIFF and iTunes - 'nuff said, gives you tagging, uncompressed lossless, and bit perfect<br />

- ALAC and iTunes - use it if you want to save space and don't feel there is any difference<br />

<br />

PC:<br />

- Tagged WAV and Mediamonkey - provides tag support, uncompressed lossless, and bit perfect<br />

       <cite>Requires that the WAVs are ripped/converted to using dbpoweramp, as that supports wav tagging</cite><br />

- FLAC if you want widespread application support for tags and don't care about uncompressed<br />

- AIFF is out because iTunes isn't bit perfect and nothing else supports AIFF tags<br />

<br />

<br />

Regarding VBR, All VBR is give you more bandwidth in more active/noisy areas by taking away bandwidth from quieter areas. It's still a lossy methodology. I think most of the people here prefer lossless, but if you can't hear a difference between that and a lossy format then by all means use what suits you.

[haiku1]

you know what you`re talking about?<br />

<br />

http://wiki.hydrogenaudio.org/index.php?title=Variable_Bitrate<br />

<br />

Hmmmmm.....

[ldolse]

Yes, that hydrogen audio definition is just a defining VBR from the opposite direction.<br />

<br />

To quote your link:<br />

<cite>Then the encoder tries to maintain the selected quality during the whole stream by choosing the optimal amount of data to represent each frame of audio.</cite><br />

<br />

It does that by choosing a reduced bitrate for quiet passages and a higher bitrate for louder, more dynamic passages, which is exactly what I described.<br />

<br />

All lossless is constant bitrate. Lossless compression uses a variety of compression methodologies to reduce the data, but the uncompressed bitrate remains the same.<br />

<br />

Variable bitrate is a lossy technique, and is used in a variety of lossy compression techniques. As stated before, quiet or nearly silent passages can be represented with less bits. Reducing the bits IS a form of loss, and the compression of the codecs themselves is an additional form of loss. The most extreme example of this is modern phone conversations over a variety of networks. Did you ever wonder why the other side of the line goes dead silent and you wonder if your buddy is still there? That's the VBR algorithm in the voice codecs deciding to reduce the bitrate to zero - i.e. real silence to save bandwidth over the voice transmissions.