[Kuyt]

Out of all the music I've seen online, I only have one album that's ripped in .WAV. After all, it is a lossless format right? Does it not perform better than other lossless formats, like FLAC and APE? Yet most players support it.

 

[Gurck]

Lossless is lossless, any lossless codec produces an identical output to wav, but is compressed to save space and provides tagging support. Good players like foobar can play just about anything natively and have plugins for the blue-moon codec they don't support out of the box, and portable players can mostly do the same or be rockboxed if not - so there's no reason to have wavs.

 

[wavoman]

Quote:

Originally Posted by Gurck /img/forum/go_quote.gif Lossless is lossless, any lossless codec produces an identical output to wav...

True in practice. In theory, compressed lossless has to be uncompressed in real-time as the music plays, with no chance to back-up and re-try, so one can easily imagine a very limited type of processor that could play back uncompressed lossless but would stumble on compressed lossless, especially when confronted with a disk-read error, and a codec that took this in stride, pushed on, and produced slightly the wrong bitstream via interpolation (or a hiccup in the music).

Just a theoretical note. I always say "in practice, lossless compressed play back perfectly".

 

[Planar_head]

Quote:

Originally Posted by wavoman /img/forum/go_quote.gif True in practice. In theory, compressed lossless has to be uncompressed in real-time as the music plays, with no chance to back-up and re-try, so one can easily imagine a very limited type of processor that could play back uncompressed lossless but would stumble on compressed lossless, especially when confronted with a disk-read error, and a codec that took this in stride, pushed on, and produced slightly the wrong bitstream via interpolation (or a hiccup in the music). Just a theoretical note. I always say "in practice, lossless compressed play back perfectly".

There are players that decompress the music before playing and store it in RAM.

I don't like .wav because I can't tag it, and I hate not knowing what song I may be choosing.

 

[wavoman]

Quote:

Originally Posted by Planar_head /img/forum/go_quote.gif There are players that decompress the music before playing and store it in RAM...

Yea, buffering is the answer ... but I was hypothesizing this terribly limited piece of hardware, so buffering in RAM is out (by definition). Buffering is great protection against a hard-drive re-read due to motion, etc.

Why did I bother to post this nonsense? 'Cause people always say "bits are bits" re file formats, cable transmission, etc. And that's just not true -- playing music has a hard real-time constraint, so it's "bits AND timing", not just bits. This is why not all digital cables are equal, 'cause otherwise they would be. It is also not clear what timing errors are actually audible -- probably very few. But why take a chance? I, in fact, use WAVs -- to answer the OPs question -- and decent cables -- but that's 'cause I feel no shortage of disk space (I do feel a shortage of money so my digital cables are decent but not those super-costly ones, which I don't think could possibly make a difference, but who knows?). If I did run short of space I would use FLAC of course. And I don't really tag deeply, just make simple playlists, so a nice compound file title is good enough for me.

 

[Planar_head]

I agree in every which way, that digital is not "perfect", and may never be, simply because timing is crucial in getting a good digital signal.

There is so much gibber about .wav vs. .flac, optical vs. electrical, player1 vs. player2... Honestly, it takes ears, not common sense (wow, thats a first) to figure out why something sounds better than something else.

Just choose what you want, and roll with it. I had .wav files before, but I couldn't hear the difference between one format or another. So I just went with .flac because I am a psycho about tagging things.

EDIT: Didn't mean to stir up trouble and high water.

Lossless should sound like lossless, that's that. Really, if something in the player makes .wavs sound better than another lossless file, then use .wavs.

 

[TheMarchingMule]

Woah, okay. Stop. Before we get another stupid thread of "WAV sounds better than FLAC" or whatnot, it's not possible. Unless the decoder is fubar'd, then no matter what lossless compresion is used, it should all sound the same.

Back on the lovely topic, .WAV is barely used because it's too big (APE, FLAC, ALAC, etc.), not open source (FLAC), and it's not optimized for portable players (ALAC).

 

[grawk]

in theory the wav will sound just like the decompressed lossless file, but since there are processing cycles involved, it's certainly possible that there are mistakes made in the name of expedience, or samples dropped, or gaps, etc. Just because it's possible to derive a perfect extraction from a flac or alac etc file, doesn't mean you always get that.

WAV is a poor choice because, as others have said, there's no native tagging.

 

[LnxPrgr3]

Quote:

Originally Posted by grawk /img/forum/go_quote.gif in theory the wav will sound just like the decompressed lossless file, but since there are processing cycles involved, it's certainly possible that there are mistakes made in the name of expedience, or samples dropped, or gaps, etc.

Is anyone's computer here seriously that slow? FLAC isn't all that intense...

Consider this -- WAV, because of its size, means increased demand on your hard drive. This can lead to dropouts as well, if there's IO besides reading the file you're playing.

 

[wavoman]

We all appear to agree. No warnings needed. But Mule, the operative word in your post is "should", as in "should sound the same". And does in the real world. But, in theory only, if there are mistakes in the decompression due to timing errors caused by disk re-reads, or other reasons, then it doesn't have to.

Grawk put this even better than I did.

So you can't say "it's not possible", 'cause it is possible. I know you know this, but you will confuse others. It doesn't happen with today's fast processors, but it is possible and not even hard to imagine.

Can food spoil in your fridge if the power stays on ? Sure ... the compressor might go with no notice while you are away. This happened in the '50's. I don't think it ever happens today, our appliances are way better. Have never heard even one person complain about this in 50 years. But it happened to my parents in 1958 (with a fridge build in 1949).

 

[grawk]

people use all kinds of devices for playback, and not all of them are speed demons. Some of those devices have trouble playing back various formats. Pick the one that has the compromises you prefer.

 

[wavoman]

Quote:

Originally Posted by LnxPrgr3 /img/forum/go_quote.gif Is anyone's computer here seriously that slow? FLAC isn't all that intense... Consider this -- WAV, because of its size, means increased demand on your hard drive. This can lead to dropouts as well, if there's IO besides reading the file you're playing.

I was thinking of a lame (bad pun) PMP, not a computer.

Reading a larger file is probably less computationally intense than de-compressing a smaller one, but if disk errors are numerous then your point is well taken. The wav could produce more bit errors than the FLAC I suppose, but a 1-bit disk read error in a wav causes a 1-bit error in the bitstream sent to the DAC, but a 1-bit disk read error in a FLAC causes a multi-bit error in the bitstream (the decompression will incorrectly set a number of neighboring bits).

Interesting, didn't really focus on the "extra reads needed" issue. We have to tradeoff disk I/O performance against CPU ... I still vote for FLAC being more likely to error. Still this is theory only. But fun! I guess not for M Mule.

Added: if I decode your head-fi handle correctly, LnxPrgr3, we should have a conversation about disk read errors in both ext2 and ext3 directly after a write, even when flushing everything. Now that's a topic! I have had correspondence with Tweedie on this -- it happens. Amazing. The SCSI controller firmware incorrectly reports back to the kernel the true state of the flush (the controller manufacturers are trying to win government contracts awarded via speed benchmarks).

 

[Ruahrc]

Except that I don't believe that there is any audio playback device or method in use today that does not have some kind of buffering involved. I would love to hear of it if you know of one. Thus your fears of real-time uncorrectable errors are IMO nullified by the fact that any digital playback system DOES have buffering- designed in specifically to circumvent the types of errors you mention!

And like was mentioned earlier the fact that WAVs are equally susceptible to (or potentially even moreso) these same I/O or processing errors, given that the amounts of data being transferred are greater with WAV than FLAC. By that logic, we should be using the lowest bitrates possible to minimize the chance of these unrecoverable errors...

And there's always the practical matter of WAVs being much larger than FLAC or other lossless formats, and the lack of tagging make it a poor choice to rip audio.

 

[LnxPrgr3]

Quote:

Originally Posted by wavoman /img/forum/go_quote.gif I was thinking of a lame (bad pun) PMP, not a computer.

Good point -- portable devices are an entirely different world. Quote:

Originally Posted by wavoman /img/forum/go_quote.gif The wav could produce more bit errors than the FLAC I suppose...

For that matter, on the wrong hardware, even the WAV could sound worse than a well-encoded MP3, if the device is not so good at scheduling disk reads. My Rio Volt could sound better with compressed music than it did with the original CD, thanks to a very poorly implemented anti-skip for audio CDs.

My Zen Touch has a cool bug decoding WMA -- every so often, it will chirp. If you play the song again, it won't happen in the same place, and may not happen at all. Thankfully, no such thing happens with MP3.

Now I carry around a laptop. It handles WAV and lossless fine

Quote:

Originally Posted by wavoman /img/forum/go_quote.gif Added: if I decode your head-fi handle correctly, LnxPrgr3, we should have a conversation about disk read errors in both ext2 and ext3 directly after a write, even when flushing everything. Now that's a topic! I have had correspondence with Tweedie on this -- it happens. Amazing. The SCSI controller firmware incorrectly reports back to the kernel the true state of the flush (the controller manufacturers are trying to win government contracts awarded via speed benchmarks).

Wow -- thankfully, I can't say I've run into that. Thanks for the reminder that hardware's not always trustworthy, nor are the manufacturers

 

[wavoman]

Ruahrc -- I Agree! Other posters said it too -- buffering solves the problem.

I made no claims about any real-world devices! I said over and over that this was theory only. (Did you actually read my posts, or just the first line?).

Back to theory -- of course you have to balance "number of bits read" with "processing on those bits after reading" ... as I said in my post. Shorter compressed files may be more compute intensive than longer uncompressed ones. It all depends.

Of course your reducto-ad-absurdem about low bit rates is a faulty argument, and nothing I wrote in any way implied you could or should try to make the files small by dropping the bit rate -- but you knew that and were just having fun. The tradeoff is .. oh heck, what you said about low bit rates is so stupid (and, as I said, you know it!) that I won't bother explaining the fallacy.

Food A is better for you than Food B because it has less fat (but the same calories) ... oh, let's be even more healthy and eat nothing at all, then we have no fat. Starve to death. Some logic.

One last time, as I have said before. We all agree. No bits are dropped in the real world. Buffering solves most processing problems.

If you care about space, don't use wavs. If you care about tags inside music files, don't use wavs.

I don't care about either, and I don't care either if you care about both.

To turn a phrase.

You do what you want. I have all the disk I need. And the filenames carry the artist and title ... and every player displays the filename ... this is all I want. You tag your library, and I'll remember not to randomly rename my files. We'll both be happy.