Computer Audio

I'll second the re-ripping with dbpoweramp. If you can put up with the inconvenience, ripping tracks to .wav files will yield the best sound quality results. You may lost some tags and album art though.

Steve N.
Empirical Audio

"You may lost some tags and album art though."

You will loose A LOT of that with .wav.

I just converted my entire library over to FLAC finally after years of .wav.

Can't honestly say one sound categorically better than the other. Both sound very good, though I have not done careful a/b comparisons.

Steve, DBpoweramp can supposedly create and confirm perfect rips or not with any format, right?

Any good reason why .wav is really better sounding than .flac? Assuming the playback is doing its job correctly in both cases, of course.

I stuck with .wav for years just to be safe, but gotta say I am not missing it now that I have jumped ship.

I still have my original .wav files. I am almost ready to forget about them and delete them.

So now would be a good time to convince me I should keep them. :^)

Yes, DBpoweramp compares to Accurate Rip if this is enabled.

I have done FLAC, AIFF and ALAC to .wav comparisons at shows for probably 7 years now. Its easy to hear the compression effect of these, even on a show system. Why do they do this? I can only speculate. Maybe has to do with the offset or floating point rounding. Maybe has to do with erroneous behavior when the CODEC is running real-time.

Every time I play FLAC, AIFF or ALAC files, I notice a "tunnel" effect. This is kind of like compression. Makes the sound stage narrower. I only have .wav on my server and that is all I play at shows.

There is one exception. The Antipodes server playing FLAC and .wav files sounds identical from what I can tell. There is a lot of custom software running on Linux there.

You don't need to keep the .wav files. You can always create the .wav back from them.

Steve N.
Empirical Audio

"Maybe has to do with the offset or floating point rounding. Maybe has to do with erroneous behavior when the CODEC is running real-time."

Maybe if resmpling is done in teh process, but not for a straight format conversion. If it happens in that case its more likely a result of the CODEC. I can't see how reformatting done right with no recalculations involved would make a difference alone.

I'm saying this from the perspective of one who has written image resampling and reformatting programs professionally in past years for high precision military applications. The same principles would apply to digital audio as well I am fairly certain.

Of course, as always, the devil is in the details. If that's what you heard, there is probably a reason, but I would see no basis to place the blame on the format itself.