In What Format Should I Rip My Music?

[Edit: I just noticed that this is a very old thread, please understand that I wrote it thinking that Chris had written it today!] :-)<br />

<br />

Hey Chris.<br />

<br />

I have to take issue with your statement "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?"<br />

<br />

I believe this statement to be FUD, though I don't believe that you intend it as such. I offer this only to further the conversation.<br />

<br />

The problem is that discussion of file type reside entirely in the digital realm. I understand and have demonstrated to my own satisfaction that digital transmission variables have a disturbing-to-a-digital-guy affect upon sound quality. I state it that way because it took me a LONG time to observe this for myself because I simply couldn't believe that digital world concerns could have an analog effect beyond transcription errors, i.e. bitperfectness.<br />

<br />

Why? Let me put it this way: it's been decades since anything in the digital world has behaved this way! Digital transmission has matured through parallel, serial, modems, wired ethernet, wireless ethernet, Firewire, USB, and Thunderbolt. And since somewhere in the modem range, protocols have handled error detection and correction invisibly. In short, it's been decades since there's been a question as to whether what you put in one side comes out the other end.<br />

<br />

Given that, I find it incredibly unfortunate that it's taken the audio industry so long to arrive at this same point. I suppose it's related to the fact that pre-digital, the goal of an audio manufacturer was to pass the signal along as perfectly as possible. From that perspective, it's easy to see why it would seem reasonable to do things like take clocking information from the incoming bitstream.<br />

<br />

But from the digital perspective, doing so is unthinkable! Why? Because in the digital world, "bits are bits." And the purpose of cables are to move bits between components where they are processed.<br />

<br />

And it's that processing part that appears to me to have been missing in digital audio components. The processing is where the music needs to happen. Music is all about timing! That being the case, why in the world would anyone design an audio component in a way that was doomed to failure?<br />

<br />

I believe that we can state with 100% certainty that it's IMPOSSIBLE for there to be "unforeseen issues" with losslessly compressed audio files.<br />

<br />

Why? Because bits ARE bits and bits have only two possible states: a bit can be described as on or off, yes or know, true or false, etc. But a bit CANNOT be one of those AND early or late.<br />

<br />

Now someone might say "I can see it on an oscilloscope!", or "I can hear the deleterious effects of jitter!", and perhaps more to the point "I can hear the difference between WAV/AIFF/FLAC/ALAC!" And, unfortunately, I now find myself forced into agreement.<br />

<br />

These things DO make a difference!<br />

<br />

And that's where we've gone wrong, because that should never be true, damnit! :-(<br />

<br />

Why? Because if ANYTHING (jitter, file format, disk type, cable) short of a transcription error (failing to be bit perfect) in the digital transmission chain can affect the audio quality of a DAC, then the DAC has, I believe fundamentally failed its intended task!<br />

<br />

A DACs job is to turn bits into music. Since a bit can only have two states, they should NEVER be asked to carry timing information as well. Doing so fundamentally violates information theory! :-(<br />

<br />

The fact that bits are bits, when coupled with the fact that uncompressed files can be converted to losslessly compressed files and then converted back to identical uncompressed files mathematically proves that there can be no "unforeseen issues!"<br />

<br />

A = uncompressed file<br />

B = compressed version of A<br />

C = uncompressed version of B<br />

<br />

Transitive theory states:<br />

<br />

If A = B and B = C then A = C<br />

<br />

And that is why I have a problem with your statement.<br />

<br />

Can't we agree it's an entirely personal decision? To say anything else is, I believe, spreading misinformation.<br />

<br />

If all audio programs not only buffered the file into memory, but also uncompressed it while doing so before playback began, then it's unthinkable that file format could change the sound!<br />

<br />

I ask the authors of playback software to comment. For those apps that decompress-in-advance, do you or your users hear a difference between file formats? Surely the answer must be no!<br />

<br />

Finally, a request to the authors of applications that don't decompress-in-advance: please make this available as an option so the rest of us can judge for ourselves. :-)<br />

Small disclaimer, and I am sorry for it : I only read a few lines of your post. This jumped out :<br />

<br />

<cite>I ask the authors of playback software to comment. For those apps that decompress-in-advance, do you or your users hear a difference between file formats? Surely the answer must be no!</cite><br />

<br />

But the answer is yes. It even goes as far as while I (XXHighEnd) do my stinkin' best to prepare all in advance - let it rest - and to next let start Playback after any rest time to the wish of the user - it still makes a difference when ...<br />

<br />

The uncompressed files are copied to a RAMDisk for real playback from there<br />

<br />

vs<br />

<br />

The user copies those themselves to there.<br />

<br />

Mind you ... And this is pure memory playback.<br />

<br />

I myself do not say I perceive these kind of differences - I actually don't want to know. All I do know is that these things should be solved, which is what I effortlessly try (on behalf of users whom I highly trust - which is just everyone).<br />

<br />

I know what this is about (I think) but it is way hard to solve.<br />

<br />

Peter

Peter, when you say that the decompressed file is stored in a RAMDisk, in what format is the file?<br />

<br />

If you input a WAVE, AIFF, FLAC and ALAC containing identical audio, will the files in your RAMDisk be byte-for-byte identical?<br />

<br />

If so, please clarify: will the only difference between the files be the physical location of the memory cells holding the bits?<br />

<i>"I ask the authors of playback software to comment. For those apps that decompress-in-advance, do you or your users hear a difference between file formats? Surely the answer must be no!"</i><br />

<br />

You don't need to ask authors. <br />

There are posts in these forums where users are adamant that they hear differences in format when using an app that decodes, and decompresses where necessary, a complete file in advance of starting to play it. WAVE, AIFF, FLAC and ALAC are decoded to an identical Core Audio data buffer before play by Audirvana. I'm tempted to delete this post; the ground has been covered several times. I share your opinion of "no", but people hear what they hear and you'll struggle to convince them that they could be mistaken.<br />

<br />

<br />

<cite>Peter, when you say that the decompressed file is stored in a RAMDisk, in what format is the file?</cite><br />

<br />

Always WAV.<br />

<br />

<cite>If you input a WAVE, AIFF, FLAC and ALAC containing identical audio, will the files in your RAMDisk be byte-for-byte identical?</cite><br />

<br />

100%.<br />

<br />

<cite>If so, please clarify: will the only difference between the files be the physical location of the memory cells holding the bits?</cite><br />

<br />

Even that won't be different. Imagine a Dos Copy command, but now performed from code. This is not 100% so (it could, but I don't do it like that). Still there are many differences (impact on the OS) and it is about that.<br />

<br />

Btw and FYI :<br />

Since the program vs manual action in my view can be 100% mimiced towards the manual action (because of how XXHighEnd is setup) by letting the program perpare things - reboot - and then play, and *then* in my view no differences *can* be there, I suggested a couple of times to try this.<br />

I never received an answer to that, so or people never tried it, or were not able to perceive the difference anymore. And, as how we people tend to work, if we are not sure we better say nothing. Well, when it were about real valued comments.<br />

I must also say that around the time of these findings, the RAMDisk was shoveled out (because it really isn't better in the far end).<br />

<br />

Regards,<br />

Peter<br />

<br />

Peter, please comment on my interpretation of your account of RAMDisk playback...<br />

<br />

The input files of various formats containing identical audio samples were decoded to identical bits in identical memory cells of RAM in advance of play. In spite of that, the specific decoding process for a particular file format had an effect on the system which was propagated to, and was audibly manifest in, the following (in other words, not concurrent) play process.<br />

<br />

You suspect that the only way to negate this propagated effect on sound quality may be to reboot the system between the decode process and the play process, but you have no test results to verify that.<br />

<br />

"But the answer is yes."<br />

<br />

But, it really shouldn't be.<br />

<br />

I find this very, very disturbing.

Sorry that I had not noticed these other references.<br />

<br />

I have to say that I find this absolutely impossible from a technical standpoint.

Your universe is not crumbling. There is no evidence for this propagation effect. There's only the anecdotes of a tiny subset of audiophiles. They may be right. They may be wrong. Nothing to lose sleep over.<br />

<br />

We're dealing with people's perceptions in the absence of controlled trials; anything can be imagined and anything can be possible.<br />

<i>"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?"</i><br />

<br />

<br />

Hi tmornini - Thanks for your well thought out comments and for recognizing this article wasn't written today :~)<br />

<br />

Here's my reasoning for saying what I said. <br />

1. I see no reason to take a chance, no matter how minute, if one doesn't have to.<br />

2. When talking about unforeseen issues I am not specifically saying anything about the ability of a lossless file to be converted back and forth without losing bits. We've all done the comparisons converting files and checking the MD5 hash etc... There is no difference. My thinking is more about issues with lossless codecs. Apple Lossless is proprietary and has gone through several versions. The user is not notified about new versions or what the differences are. Third party developers must reverse engineer the conversion from ALAC to something else and to playback ALAC. I have already seen issues related to converting 24 bit ALAC files in third party apps. For the life of me I wish I could find the thread but I cannot at the moment. I'll continue my search. To me it's all about minimizing risk. I now my reasoning is not perfect and not for everybody. I'm simply explaining why I do what I do. I've also been using uncompressed FLAC a lot lately. I've been extremely happy and impressed with uncompressed FLAC and the support of FLAC in software and hardware from everyone except Apple.<br />

<br />

As I like to say, nobody is saving babies or killing puppies here. There are much larger fish to fry when it comes to impacting computer based audio. This article was written in response to many inquiries about file formats. I followed this article up with my ripping article that discusses some of this as well.<br />

<br />

http://www.computeraudiophile.com/content/Computer-Audiophile-CD-Ripping-Strategy-and-Methodology<br />

<br />

Thanks for your thoughts on the matter.<br />

<br />

I think we're going to need to agree to disagree. :-)<br />

<br />

Again, not with your decision, but with your reasoning.<br />

<br />

I do agree that an open codec is ideal, but I think it's absolutely unfair to suggest that the reason for choosing it to avoid future problems.<br />

<br />

I know for a fact, first hand, that open formats are no prophylactic from future problems. Remember what happened to GIF?<br />

<br />

My point here is that I agree that FLAC is the ideal format for archive, but it's not for technical reasons, but instead philosophical grounds. :-)<br />

<br />

I'm glad if we can agreed that there is zero risk *beyond the effort to convert to something else* in choosing a lossless compressed format. No chance of loss, no chance of irreversible quality issues; just(!) the irrefutable fact of ALAC's lack of transparency, which is enough, but doesn't qualify as a technical risk.<br />

<br />

With respect to CODEC quality issues, I think what you've written above qualifies as FUD as well. There is Apple's CODEC which is HIGHLY LIKELY to be well maintained (it's the basis for AirPlay which is looking increasingly like the de-facto standard for networked audio transmission) and an open source implementation available here:<br />

<br />

http://craz.net/programs/itunes/alac.html<br />

<br />

Note: I consider the fact that they added 24 bit support 2 years ago, and haven't updated it since to be a good sign that the code base is highly stable and bug free.<br />

<br />

I just cannot see a way to support the idea that ALAC will have quality issues in the future that are more significant than FLAC. Both are fixed formats that have little chance of change in the future. Both are ancient. Both have near universal support in player applications and perhaps most important, both have shown very few interoperability issues over the years.<br />

<br />

In any case, long live FLAC as the audiophile archival format of the present! :-)<br />

I get the concept that uncompressed (eg. AIFF) if nothing else, avoids any issues associated in playback associated with decompressing the file.<br />

<br />

I also get why people would choose to use FLAC uncompressed to get tagging advantages.<br />

<br />

What I don't get is even if the FLAC file is uncompressed, doesn't the software process the file? After all, when presented with the file the software will recognize it as FLAC and initiate whatever the standard FLAC processing is; no?<br />

<br />

If so, do you really avoid the processing step if it is in FLAC format?

Hi tmornini - I'm not trying to beat a dead horse with this one rather I'm pointing to some evidence as to why I don't like ALAC and why I think future problems are inevitable with such proprietary codecs. <br />

<br />

Please see this post -> http://www.computeraudiophile.com/content/New-ALAC-problem-not-affecting-playback-iTunes-Decibel-Fidelia-and-Audirvana<br />

<br />