Calling all audiophiles - Uncompressed or lossless?

[hifisteve]

Now I know that this might sound like a silly question, and for non-hifi nuts and computer experts it probably is, but this is addressed to people like me - very fussy about my music and not totally convinced that computers don't involve witchcraft...

If storage space were not an issue, would people actually sooner store their music totally uncompressed rather than use a 'lossless' codec?

I know people are going to say that lossless preserves all the data etc. but let me ask you this:

If someone invented a 'lossless' way of making food 'smaller' for storage by removing the water, would you rather eat an apparantly perfectly reconstituted or untouched version? I mean water is just water right? If you put it back where it came from is as good as before isn't it?...

I'm sure this is more of a psychological question but then we live in the world of 'vibration cones', 'green pen on CD edges' and 'deep freeze your CDs for better sound'

[Robin Bowes]

hifisteve wrote:
> If someone invented a 'lossless' way of making food 'smaller' for
> storage by removing the water, would you rather eat an apparantly
> perfectly reconstituted or untouched version? I mean water is just
> water right? If you put it back where it came from is as good as
> before isn't it?...

Let me give you a more appropriate analogy...

Would you rather store 1000 inflated balloons or 1000 pieces of rubber
which you could inflate when you needed them?

> I'm sure this is more of a psychological question but then we live in
> the world of 'vibration cones', 'green pen on CD edges' and 'deep
> freeze your CDs for better sound'

And you believe *everything* you read, do you?

R.

[mwphoto]

Hi,

Sounds like a reasonable question to me and it all comes down to belief. If you believe the result of compressing and uncompressing is the same as the original then there's no problem choosing the compressed version.

Now looking at your questions:

1) Why do I believe lossless compressions + decompression are 'perfect'. I didn't check the source code, I haven't actually compared before and after files. In fact the only check I have personally performed is that file sizes of the WAV before and after the process are the same. So why do I believe?

a) firstly it is claimed to work

b) I can hear no difference

c) there are ways to check the process is perfect even if I haven't performed them

d) I understand how to write my own test so I believe I could check myself

2) For food, why do I not believe?

a) no one has ever claimed it

b) I cannot conceive how it could work

c) I believe that the 'information' encoded in the water cannot be preserved (ie location and energy of the water molecules)

To take your analogy further, if someone could dehydrate a live mouse and then rehydrate the mouse back to a living active state I'd start to get much more comfortable about a ham sandwich!

Finally, here's some beliefs that I think you have that you might not even have considered. These are all perfectly sound beliefs, but for the most part that's all they are until you have done some personal testing. (I believe them too and I haven't tested them!)

1) storage media doesn't matter, you believe slim server would work if the files were read from Hard Disk, CD ROM, DVD, or memory stick.

2) The quality, grade and type of ethernet cabling do not make any difference.

3) The operating system does not make any difference, you get the same result if you server files from a Windows PC, a MAC, a linux box, or Symbian PalmOs

4) Conversion from ISO format to WAV doesn't matter (one lossless format to another). What is stored on an audio CD is NOT wav files.

5) Renaming you WAV files makes no difference - this has already changed the structure of the information encoded on the storage media

6) Wearing a yellow hat on Tuesday does not improve the sound.

I put in 6 deliberately simply to raise the point about why you believe it. I assume you have not done blind ABX tests with and without a yellow hat, yet you are able to be confident it makes no difference (as am I). So in summary, for IT we believe that lossless makes no difference because:

1) personal evidence gives no counter examples (we can't hear a difference and every test we have performed shows they are the same)

2) we have faith in the community that developed the tools

3) we believe we could independently test it if we chose to.


That's all a bit deep and philosophical and paraphrases a lots of philosphy of science. But it's interesting to question even deeply held beliefs once in a while.

Malcolm

[hifisteve]

I just wanted to put the point up for discussion.

All I wanted to know is whether all 'audiophiles' are convinced that lossless compression truely has no impact on sound quality.

I appreciate that the theory is sound but theory and reality are two different things. I mean Eienstein's theory shows that time is not constant and I'm sure that even the most scientificly minded people find that slight weird to get their heads around.

p.s. I've never gone in for any of the 'tweaking' I mentioned but there are plenty who have....

[hifisteve]

I just wanted to put the point up for discussion.

All I wanted to know is whether all 'audiophiles' are convinced that lossless compression truly has no impact on sound quality.

I appreciate that the theory is sound but theory and reality are two different things. I mean Einstein's theory shows that time is not constant and I'm sure that even the most scientifically minded people find that slight weird to get their heads around.

p.s. I've never gone in for any of the 'tweaking' I mentioned but there are plenty who have....

Sorry.

[mwphoto]

I just wanted to put the point up for discussion.

All I wanted to know is whether all 'audiophiles' are convinced that lossless compression truely has no impact on sound quality.


I know - it's a good question, I just wanted to raise the point that from both sides of the fence we each have 'beliefs' about what matters. We only disagree in some areas. The interesting thing about the difference is what causes it. For the most part in the audiophile world the killer feature is:

'I believe I can hear a difference'

and no amount of forum discussion will change that. The really interesting thing about this for me is:

1) can you tell a real difference?

2) do ypu just believe it is different (this can be tested in ABX tests)

and for me, I'm also curious as to why we believe we hear a difference if there isn't one.

Malcolm

[Robin Bowes]

mwphoto wrote:
> I know - it's a good question, I just wanted to raise the point that
> from both sides of the fence we each have 'beliefs' about what matters.
> We only disagree in some areas. The interesting thing about the
> difference is what causes it. For the most part in the audiophile world
> the killer feature is:
>
> 'I believe I can hear a difference'
>
> and no amount of forum discussion will change that. The really
> interesting thing about this for me is:
>
> 1) can you tell a real difference?
>
> 2) do ypu just believe it is different (this can be tested in ABX
> tests)
>
> and for me, I'm also curious as to why we believe we hear a difference
> if there isn't one.

In the case of lossless vs. uncompressed (I am thinking flac vs. wav
here), there can not be any difference - flac decodes to the exact same
bits that were used to create the compressed file.

There is a school of thought that says that the additional work done by
the CPU on the SB to decode flac natively can affect the audio output.
That may well be the case.

However, if you consider the case of flac decoded on the server vs. wav
files (i.e. both are streamed to the SB as wav files) then there can not
be any difference - the Squeezebox will receive *exactly* the same bits
in both cases. Indeed, it will not even know or care whether those bits
came from a wav file or from a flac file decoded on the fly.

R.
(with his "engineering" head on - not interested in the social aspects
of why audiophiles are weird today :) )

[mwphoto]

In the case of lossless vs. uncompressed (I am thinking flac vs. wav
here), there can not be any difference - flac decodes to the exact same
bits that were used to create the compressed file.



I agree, however I didn't make my point clear, sorry about that. I wasn't trying to talk about whether there is a difference, I was trying to get to the bottom of why we believe such a thing.

I think the point here is that

a) it makes logical sense and we believe in logic AND

b) it is confirmed by our listening experience.

For example lets say you tried a new encoding that I claim is lossless (MalcolmsLossLess MLL), and you found that every time you used it you could immediately tell the difference between MLL and WAV. What would you conclude? I expect you would come up with a number of thoughts:

1) the encoding is lossless, but the software has bugs and isn't executing the encoding/decoding properly

2) The encoding is faulty ie it's not lossless

and you would be more willing to believe 1 or 2 above than believe that the encoding is lossless and bug free. Essentially you have a stronger belief in lossless encoding sounding identical than you do in me and my software (and that's perfectly reasonable). All of these are essentially beliefs, until you do some testing on my software or algorithm you don't know which of 1 or 2 to believe but you would rather believe them than lossless could sound different. This makes perfect sense based on past experience as:

1) software often has bugs

2) complex algorithms can be misunderstood.

I hope I've added to the 'belief' debate, I didn't mean to suggest I believed that lossless could be somehow different (I use FLAC 100% and believe it is perfect - and I've written software to allow me to test it ABX)

Malcolm

[Pale Blue Ego]

It's easy enough to test the lossless "theory" using a hash algorithm.

http://en.wikipedia.org/wiki/Hash_function

Just as a text file doesn't change after being zipped and unzipped, neither will music bits change with lossless compression and decompression.

Losssless compression is essentially "shorthand". Instead of reading "zero, zero, zero, zero, zero, zero", the sequence is notated as "6 zeroes". This saves a little space, and when read back, produces the exact same number pattern.

On a more practical note, WAV files have no provision for metadata (tags). FLAC files do. Managing a collection without the benefit of tags is extremely cumbersome. I'd use FLAC for that reason alone, even if there was a detectable difference in sound quality. Thankfully, with FLAC I don't lose anything.

[ezkcdude]

I don't understand why this is still such an issue. (I suppose it's because new people always join the forum.) The FLAC code does not produce errors. Now, if you rip a WAV file with some errors, then of course, the FLAC file will also have errors. Obviously! So will the WAV file. If you're worried about the accuracy of ripping the WAV file, just use AccurateRip to verify the results. It boggles the mind that people keep insisting FLAC does not decode to the same PCM bitstream as WAV. If you question that, I suppose you've never used the ZIP format either.

[hifisteve]

That's exactly the kind of debate I was kind to kick off!

Probably worth pointing out that I don't really believe one way or the other, I've only just got my SB3 and I'm currently sitting uncomfortably on the fence trying to decide which format to encode all my CDs with.

Incidentally, having an engineering background I am inherently sceptical of 'tweakery' in general, which means that I'd essentially think that lossless compression with digital data would work perfectly well, especially as the 'shorthand' replacement of extra zeros was how I'd assumed it would work.

I just wondered if anyone had experienced differences (perceved or measured) between uncompressed and lossless.

Other than the obvious compatability issues, any views on whether there's any other advantages/disadvantages of using Apple
lossless rather than FLAC?

[radish]

First off, as a clarification, FLAC compression is somewhat more complex than simple RLE (the "6 zeros" approach mentioned earlier), but the basic concept is the same. Find a way of describing the signal which takes less space than simply writing it out in full. A more accurate model would be something like "it's a sine wave of amplitude x and frequency y with a couple of other bits stuck on". Not scientific but you get the idea! The format is specified here: http://flac.sourceforge.net/format.html.

Second, on the discussion of accuracy. The theory of FLAC is correct - it is lossless when implemented properly, it just has to be - it's mathmatically provable. So the only risk of loss is if there's a bug in the implementation of the encoder or decoder. This is perfectly possible, however I personally consider it unlikely. Why?

* The FLAC reference encoder and decoder are open source and thus freely examinable by anyone who cares to look.
* Audio fans are a picky bunch. If there was an audible problem someone would notice.
* Proving or disproving a problem is trivial - just compare the original wav and output from flac. I have done so, it takes less than a minute. If anyone ever said they could hear a difference I'd immediatly compare the files. You may even want to add it as an automated step in your ripping process if you're really concerned.

[CardinalFang]

Other than the obvious compatability issues, any views on whether there's any other advantages/disadvantages of using Apple lossless rather than FLAC?

Not really from an audio standpoint, they're about the same size and are both lossless. One of them is open source and the other requires quicktime to play it back. For me it was a convenience thing, Apple Lossless is easier for me because I can use iTunes to rip and manage my library. EAC may perhaps give a more accurate rip, but it's a pain to set up and manage the files and I couldn't hear a difference in the end.

I think the only argument you could put for an audible difference between lossless and uncompressed, assuming accuracy of the codecs which actually is pretty easy to verify, is that they place different electrical loads on the SB power supply due to the additional decoding or alternate circuitry being exercised.

However, the SB isn't a asynchronously clocked processing device, so the processor is always crunching code, and the same circuits are used irrespective of source data, so I can't see how there would be any elctrical differences. In the case of Apple Lossless, it's done on the server anyway, so absolutely no diference as far as the SB is concerned.

Paul

[dem]

Is there anyone here who refuses to deal with ZIP archives on the theory that what you get out might not be what you put in? Do you believe that your spreadsheets lose accuracy after they've been ZIPped? :-)

To test a beta release of FLAC, I once used it to encode 3,000 WAV files, then decoded them and did a byte-by-byte comparison with the original WAV files. Not a single byte was out of place.

I agree with Pale Blue Ego that being able to tag FLAC files is reason enough to choose FLAC over WAV.

[Kyle]

Is there anyone here who refuses to deal with ZIP archives on the theory that what you get out might not be what you put in? Do you believe that your spreadsheets lose accuracy after they've been ZIPped? :-)
I'm not sure the zip file analogy is valid here. If all of the sixes in your spreadsheet had one pixel out of place, chances are slim that anyone would notice. However, critical audio listening might indeed pick up such a minor discrepancy. That said, I believe that FLAC produces the same audio signal as WAV, and for me the bandwidth issue (I'm running wireless) makes it a no-brainer.

[pablolie]

...the only test that matters is: sit down, preferably with a glass of Peter Michael Les Pavots (I recommend the 2001), play music, close your eyes, and trust your instinct. If the sound and music vow you, why keep second-guessing whether something's wrong.

I always compare the the original CD sound, and if that comparison is favorable (not perfect), I am fine.

[aubuti]

I'm not sure the zip file analogy is valid here. If all of the sixes in your spreadsheet had one pixel out of place, chances are slim that anyone would notice. However, critical audio listening might indeed pick up such a minor discrepancy. That said, I believe that FLAC produces the same audio signal as WAV, and for me the bandwidth issue (I'm running wireless) makes it a no-brainer.
The validity of the zip analogy is that both zip and flac are lossless. So there won't be any pixels, decimal points, or anything else out of place.

[Cleve]

To play Devil's advocate for a moment (and I've been converting all my CDs to FLAC, so I'm not anti-FLAC)

Here's a review of the McIntosh MS300 music server. The MS300 would certainly seem potentially to outperform the Squeezebox in all possible parameters, especially our home-brew ripping/encoding on our PCs with EAC, Flac, Itunes, or whatever.... After all, the SB3 is $300 - and I'm using an old Gateway Athlon 650 as my ripper/encoder with freeware doing the tasks. The MS300 couldn't possibly make worse FLAC copies - in all likelyhood, superior.

http://ultimateavmag.com/mediaservers/1105mcintosh/index1.html

Yet on page two, the reviewer claims he can definitely hear a difference between FLAC and the original CD. He said the FLAC sounds duller, flater than the original CD. I guess I really need to make some FLACS and AIFF/WAV files and do some intense comparisons, to see if I can hear what this reviewer is hearing.

[dem]

Yet on page two, the reviewer claims he can definitely hear a difference between FLAC and the original CD.
Setting aside for a moment my belief that non-blind comparisons like this guy did are invalid...

FLAC's job is to make WAV files smaller. It doesn't rip the WAV files from the CD, and it doesn't convert WAV data to audio.

So even if this guy did hear differences, it's unlikely it had anything to do with FLAC.

Going back to my earlier analogy, you can't blame ZIP for someone else entering an incorrect formula in the spreadsheet.

[radish]

I'm not sure the zip file analogy is valid here. If all of the sixes in your spreadsheet had one pixel out of place, chances are slim that anyone would notice. However, critical audio listening might indeed pick up such a minor discrepancy. That said, I believe that FLAC produces the same audio signal as WAV, and for me the bandwidth issue (I'm running wireless) makes it a no-brainer.

Which makes no sense, as spreadsheets don't store pixels they store numbers. If a spreadsheet file got corrupted, even by a single bit, it (a) almost certainly wouldn't even load into the application and (b) would have numeric or formulaic errors. People would notice. It doesn't happen.

[radish]

The MS300 would certainly seem potentially to outperform the Squeezebox in all possible parameters, especially our home-brew ripping/encoding on our PCs with EAC, Flac, Itunes, or whatever.... After all, the SB3 is $300 - and I'm using an old Gateway Athlon 650 as my ripper/encoder with freeware doing the tasks.

Because cost is an indication of quality? Please.



The MS300 couldn't possibly make worse FLAC copies - in all likelyhood, superior.

Based on what? The fact that it costs money? The fact that it comes in a shiny box? This is an absurd argument. If you have a device which claims to use FLAC and which sounds different when playing them back versus the original CD it's BROKEN. I don't care how many millions of dollars it cost.

Personally I don't trust sealed black boxes unless I can verify they are working properly by my own experimentation. I trust a binary diff more than my ears and hugely more than some ripoff manufacturer's marketing department.

[JJZolx]

All I wanted to know is whether all 'audiophiles' are convinced that lossless compression truely has no impact on sound quality.
That's an easy one. No, all of them are not convinced.

Any other questions?

[Kyle]

Which makes no sense, as spreadsheets don't store pixels they store numbers. If a spreadsheet file got corrupted, even by a single bit, it (a) almost certainly wouldn't even load into the application and (b) would have numeric or formulaic errors. People would notice. It doesn't happen.
Shows how little I know about the way computers work.

[ezkcdude]

That's an easy one. No, all of them are not convinced.

Any other questions?

If 2+2=4 were an amplifier, then I'd upgrade it to 5 :)

[cvj]

Just curious - why is WMA Lossless not considered in this discussion - is it assumed to be inherently inferior to FLAC - or is it just an oversight?

[ezkcdude]

Just curious - why is WMA Lossless not considered in this discussion - is it assumed to be inherently inferior to FLAC - or is it just an oversight?

SqueezeBox Audiophile = 1 part Audiophile Geek + 1 part Computer Geek

Therefore, anything with "Windows" in it is inherently inferior.

[Pale Blue Ego]

Here's a review of the McIntosh MS300 music server.

Sounds like it makes a nifty $5100 boat anchor:

If you run out of disc space, you can't add another hard drive - you have to buy another $5100 component, LOL

There were dropouts playing directly from the HDD. What's that about? The drive can't serve up 800 kb/s cleanly?

You have to run ethernet to the playback location, or you won't get CD info lookup - even so, the lookup was inaccurate and incomplete, especially for classical discs.

The thing is useless without a video display. And if you use a modest LCD like a 15", you'd probably still have to walk over to it to read the small fonts.

The generic remote was cheesy and hard to use.

Beginning and end of some tracks were chopped off.

Recording of internet streams is purposely crippled.

FLACs created and served with it sounded worse than CDs.

BUT the reviewer said it makes for a fine-sounding CD player if you just want to play a CD from the tray. I dunno, this really struck me as funny.

Gee, for $5100, you could get your whole house wired for ethernet, buy 5 SB3s, a terabyte of storage with RAID on a high-end server, AND have Slim rip and tag a few thousand CDs for you.

[P Floding]

Now I know that this might sound like a silly question, and for non-hifi nuts and computer experts it probably is, but this is addressed to people like me - very fussy about my music and not totally convinced that computers don't involve witchcraft...

If storage space were not an issue, would people actually sooner store their music totally uncompressed rather than use a 'lossless' codec?

I know people are going to say that lossless preserves all the data etc. but let me ask you this:

If someone invented a 'lossless' way of making food 'smaller' for storage by removing the water, would you rather eat an apparantly perfectly reconstituted or untouched version? I mean water is just water right? If you put it back where it came from is as good as before isn't it?...

I'm sure this is more of a psychological question but then we live in the world of 'vibration cones', 'green pen on CD edges' and 'deep freeze your CDs for better sound'

A trollig effort, or some kind of bad joke?

Do you also believe your unzipped programs are not as good as the originals stored somewhere at the software firm's head office?

[JJZolx]

A trollig effort, or some kind of bad joke?
You don't have to look very hard in some of the other audiophile forums to find a significant number of people claiming that uncompressed WAV files sound better than FLAC when played on the Sqeezebox.

Also, there are still claims that firmware prior to that released after version 15 sounds superior to the latest firmware and the patch that was instituted to correct the volume adjustment errors.

Like anything else, let your own ears be the judge and use what you feel sounds better. I know what works for me.

[P Floding]

You don't have to look very hard in some of the other audiophile forums to find a significant number of people claiming that uncompressed WAV files sound better than FLAC when played on the Sqeezebox.

Also, there are still claims that firmware prior to that released after version 15 sounds superior to the latest firmware and the patch that was instituted to correct the volume adjustment errors.

Like anything else, let your own ears be the judge and use what you feel sounds better. I know what works for me.

"When played" is a totally different issue!
However, restoring FLAC to WAV, which can be done at any time offline, and will restore the same data as the WAV.

[tom permutt]

As far as the psychology is concerned, it may help not to use the word "compressed" in thinking about, say, FLAC vs. WAV. Rather, they are different representations of the same information. (Actually, as has been pointed out, FLAC has _more_ information, considering the tags.)

Would you rather the same number were represented as:

a. One thousand twenty-four
b. 1024
c. 10000000000 (base 2)
d. A thousand?

If you are writing a check, a and b, redundantly. In your check register, b, because that's the way you are accustomed to looking at it and to doing arithmetic; secondarily, because it is a little quicker to write and takes up less space, but you don't think of it as "compressed," do you? Inside your computer, a, b or c, you don't care, as long as it is output correctly; but in fact you get c. For certain purposes, d: rounded off, which corresponds to lossy compression.

Your analogy is not really a very useful one here, but I can't help noting that certain drugs are supplied with the water removed and have to be reconstituted for use because they are more stable that way. That is, you get something _more_ like the original by going through this "compression/decompression" cycle than by just letting the solution sit on the shelf. You could make this apply to audio formats if you wanted to: if you saved some redundant information (like a checksum) in the transformed file, it could reproduce the original _more_ faithfully than a bit-for-bit copy that might have or acquire errors in it.

[ezkcdude]

FLAC is a compression format. Compression just denotes the fact that the files are smaller in size, but says nothing about quality. What is more important to distinguish is lossy vs. lossless. FLAC is lossless compression, just like a zip file, as has been said too many times.

[tom permutt]

FLAC is a compression format. Compression just denotes the fact that the files are smaller in size, but says nothing about quality. What is more important to distinguish is lossy vs. lossless. FLAC is lossless compression, just like a zip file, as has been said too many times.
I think you missed my point. "Smaller" than what? You might almost equally well say that WAV is an "expansion format" because there is no canonical way to express numbers or sounds or voltages inside a computer.

[ezkcdude]

FLAC is smaller than WAV. Isn't that obvious? If you're going to be really anal about it, then any digital format is a compression of the orginal analog signal.

[opaqueice]

I agree with what people are saying here about lossless formats being, after all, lossless - but no one has addressed what seems to me to be the crucial question raised by the OP.

Suppose the SB and/or the server isn't able to do bit-accurate FLAC decompression in real time? For example, in any computer occasionally there will be an error due to a bad hard drive read or a RAM glitch or something. In normal asynchronous applications this gets caught by error checking and corrected. But here the decoding has to occur at least fast enough to keep up with the music. So isn't it theoretically possible that some errors could creep in due to this?

Let me be clear, I consider this very unlikely since it should be possible to decode FLAC files much faster than real time, thus leaving plenty of time for error corrections in the unlikely event one occurs. Also, such an uncorrected error would probably have a big effect on the sound, not a subtle one - unless the SB does some kind of interpolation after an error, as CD players do. But since FLAC files probably encode the data in a non-local (in time) way, this might be impossible.

[pfarrell]

opaqueice wrote:
> Suppose the SB and/or the server isn't able to do bit-accurate FLAC
> decompression in real time? For example, in any computer occasionally
> there will be an error due to a bad hard drive read or a RAM glitch or
> something. In normal asynchronous applications this gets caught by
> error checking and corrected. But here the decoding has to occur at
> least fast enough to keep up with the music. So isn't it theoretically
> possible that some errors could creep in due to this?

In theory, probably so.

But FLAC is specifically designed to be asymetrical. It takes lots
of computing power to compress, and is near trivial to decompress.
It was designed for low power (CPU brain power) and even low power
(milliwatt) devices like iPod kinds of things. It is
designed to be very fast to decompress.

So even a dumb microcontroller can decompress it.

A more likely problem is network errors, and here
FLAC being smaller is a win, as it can be retransmitted
on average once (total twice) and still be keeping up with music speed.
(whether that is real time, or if the master tapes are slow is a
separate issue.

> Let me be clear, I consider this very unlikely since it should be
> possible to decode FLAC files much faster than real time, thus leaving
> plenty of time for error corrections in the unlikely event one occurs.

Even retransmission.

> Also, such an uncorrected error would probably have a big effect on the
> sound, not a subtle one - unless the SB does some kind of interpolation
> after an error, as CD players do. But since FLAC files probably encode
> the data in a non-local (in time) way, this might be impossible.

This is correct. Both WAV (really PCM) and FLAC lack the fake out
interpolation logic that real CD players are required to have by the
RedBook spec. Depending on what the error is, it could be very bad
with either .wav or FLAC.

Of course, no self respecting audiophile would consider the gross
error covering done per the RedBook spec as being acceptable.

Most of your case is pretty esoteric and not unique to music.
Random cosmic rays do flip bits in memory. Not often, but it
is known to happen. Such a change could cause problems in
data, application code, or the OS itself. Most mortals
just ignore it as too rare to worry about.


--
Pat
http://www.pfarrell.com/music/slimserver/slimsoftware.html

[JJZolx]

I agree with what people are saying here about lossless formats being, after all, lossless - but no one has addressed what seems to me to be the crucial question raised by the OP.

Suppose the SB and/or the server isn't able to do bit-accurate FLAC decompression in real time? For example, in any computer occasionally there will be an error due to a bad hard drive read or a RAM glitch or something. In normal asynchronous applications this gets caught by error checking and corrected. But here the decoding has to occur at least fast enough to keep up with the music. So isn't it theoretically possible that some errors could creep in due to this?
Errors of a mathematical nature don't "creep in". If the processing is unable to keep up then you would either have dropouts or else errors/approximations would have to be _intentionally_ introduced.

For comparison, an SB or other device (such as a cheap $40 MP3 player), when playing back lossy streams such as MP3 has much more processing to do than when decoding Flac, due to the complexity of those other codecs. Flac is easy.

[radish]

If you want to hear what happens when a portion of the Slimserver/SB chain can't keep up, turn on your microwave. Wireless interference will block the transmission of data to the SB. Luckily it has a big buffer so unless the interference is very long term, no effect whatsoever will be heard. Eventually the buffer will drain, in which case the music will stop. The SB will not try to guess (like a CDP) and it won't degrade the quality, it will just stop. So you can be sure that if you can hear anything, it's the right thing.

[radish]

Shows how little I know about the way computers work.

An easy mistake to make if you are not involved in the field. Not knowing everything there is to know about computers is fine, we're all experts in our own fields. But seeing as SlimServer/Squeezebox is basically just a computer all the way up to the DAC or SPDIF driver, I really wish some people would start trusting those of us who do know about this stuff :)

[martintyler]

An easy mistake to make if you are not involved in the field. Not knowing everything there is to know about computers is fine, we're all experts in our own fields. But seeing as SlimServer/Squeezebox is basically just a computer all the way up to the DAC or SPDIF driver, I really wish some people would start trusting those of us who do know about this stuff :)

I dont think anyone should be trusting some of the comments here at all!

All this talk about zip files and bit for bit exact copies etc is all true, but its just a shame that most people seem to forget that you dont listen to bits, you listen to music. SB doesnt even output 'bits' out of its digital output - its a signal, not a perfect square wave. SPDIF is not perfect. How audible this is depends on your ears and your equipment.

I would put money on people not being able to hear the difference between wav and flac on an SB, but that doesnt mean that there isnt a difference (or at least couldnt be)

Having said that, I use flac, i find the main advantages over wav are the file size and the tagging. File size is not necessarily that important depending on your storage and network - but the tagging is useful, especially when it comes to compilations that need more info that you can easily represent with the path/file name.

[Phil Leigh]

Finally some sanity!
FLAC vs WAV are mathematically identical and neither the compression or decompression processes introduce "error" of any sort. If this wasn't true of any lossless compression regime, we'd all know about it - and how.
LL compression is used "on the wire" to minimise bandwidth utilisation. If it wasn't really, always, lossless every networked computer in the world would be spewing out garbage all of the time (I know some might believe that the Internet is in fact doing this...).

If ZIP files didn't unzip perfectly we'd all know about it - the world would be in uproar.

FLAC, ZIP etc just work in the same way that your calculator always ALWAYS says that 2+2 = 4.

With server-side FLAC decompression (and accurate rips in the first place), the only things that really count towards audible reproduction quality are the DAC onwards parts of the a chain. This assumes you buy into the "SB-side FLAC decode can be heard to be worse than server-side" argument - which I most certainly don't.

In fact, there are very good arguments that SB+reclocking DAC should sound better than any spinning disc transport, since there is a much greater chance of random timing and reading errors in real-time, one shot reading of small pits on a wobbly rotating disc with a wobbling laser and some dubious interpolation algorithms to cover problems.

[Patrick Dixon]

In fact, there are very good arguments that SB+reclocking DAC should sound better than any spinning disc transport, since there is a much greater chance of random timing and reading errors in real-time, one shot reading of small pits on a wobbly rotating disc with a wobbling laser and some dubious interpolation algorithms to cover problems.Agreed - although using an SPDIF or Toslink connection between the two doesn't strengthen the argument, IMV.

[Phil Leigh]

Agreed - although using an SPDIF or Toslink connection between the two doesn't strengthen the argument, IMV.
I agree - be nice not to have that...at the same time, keeping very good electrical isolation from any noisy upstream computers etc (my sb is wired)

Also I was specifically talking about CD transports (that would also have SPDIF etc) to the DAC...the best CDP's I have ever owned or heard were all single box players.

[Cleve]

Because cost is an indication of quality? Please.


Based on what? The fact that it costs money? The fact that it comes in a shiny box? This is an absurd argument. If you have a device which claims to use FLAC and which sounds different when playing them back versus the original CD it's BROKEN. I don't care how many millions of dollars it cost.

Personally I don't trust sealed black boxes unless I can verify they are working properly by my own experimentation. I trust a binary diff more than my ears and hugely more than some ripoff manufacturer's marketing department.


Now, now. You left out the part of my original post where I stated "Let me play Devil's Advocate".


I too suspect that there was a problem with the McIntosh - since a 300 Gb Maxtor hard drive shouldn't produce any "dropouts" reading at 140 Kb/sec - those drives are capable of read speeds of 40-50 megabytes/sec or better. I should inquire about it with Ron Cornelius at McIntosh to see if he knows any of the background- it was possibly a demo unit that had "made the rounds" so to speak.

We auditioned an MS300 at the Mac factory this summer - it's a wonderful unit - it's meant to be integrated with a Home Theatre setup - the user interface on a widescreen TV is beautiful. And the CD identification didn't have much trouble with providing proper cover art or album information. Some CDs just aren't in those online databases.

The SB3 basically does many of the same things that the McIntosh does - as long as the user is willing to understand and employ software technologies like EAC, FLAC, etc.

The nice thing about the McIntosh - there's not much of a "learning curve" involved - you just put the CD into it - push a button on the remote, and the entire CD is automatically encoded into FLAC in something like 6-7 minutes. And the McIntosh also interfaces with CD changers - so one can effortlessly copy multiple CDs at a time into FLAC.

The other cool feature - being integrated into the owner's home theatre/audio system one can also easily copy vinyl and other analog sources to FLAC.

And, you also get a high-quality CD transport with high-quality DACs with the Mac.

There are some disappointments with the McIntosh - I'm surprised that the factory doesn't provide for the easy addition of additional or larger hard drives. And another huge limitation - at least for someone like myself who listens to Shoutcast webradio daily - the unit will only play WMA stations. I shudder to think of any device locked into Windoze' proprietary codecs.

[opaqueice]

With server-side FLAC decompression (and accurate rips in the first place), the only things that really count towards audible reproduction quality are the DAC onwards parts of the a chain.


This is a nitpick (and doesn't really have to do with the original topic - FLAC versus WAV), but I don't think this is quite correct. I agree the FLAC should decode perfectly (almost always) in the sense that it produces the correct string of bits. However problems begin the moment those bits are converted into an isynchronous signal - for example because the clock isn't perfect, and because the output isn't a perfect square wave. That all occurs before the DAC.

It does seem to be true that the SB does a better job with this than all but very expensive CD transports.

[zooropa320]

The nice thing about the McIntosh - there's not much of a "learning curve" involved - you just put the CD into it - push a button on the remote, and the entire CD is automatically encoded into FLAC in something like 6-7 minutes. And the McIntosh also interfaces with CD changers - so one can effortlessly copy multiple CDs at a time into FLAC.


I'm not familiar with the software its using but I doubt its as good as EAC for making perfect rips. Average consumers want the CDs to rip as fast as possible. You only rip once but you play it many times so the speed of the rip is not as important as an error-free rip. If its ripping in 6-7 minutes I doubt its doing the equivalent of a secure mode rip in EAC.

I prefer open systems myself to ensure the highest quality possible even if the learning curve is steeper. It does cause me to wonder about the market for this unit as the average consumer won't pay the premium for a McIntosh and audiophile consumers are more savvy about how to create high quality rips (I assume) and would prefer an open storage solution rather than being constrained by the included hard drive capacity. Then there's the backup issue...

[Pale Blue Ego]

And it's not like using EAC for secure rips is a constant struggle. Spend 30 minutes setting it up right, and you're done. This McIntosh may not be able to do it at all.

[crooner]

The McIntosh is incredibly expensive for what you get. Take a look at the internal picture. The components appear to be standard fare: computer grade CD/DVD ROM drive and regular Maxtor hard drive. You are paying a premium for the McIntosh name, lighted glass faceplate and the assembly up in Binghamton.

[radish]

I agree the FLAC should decode perfectly (almost always)

No - always.


However problems begin the moment those bits are converted into an isynchronous signal - for example because the clock isn't perfect, and because the output isn't a perfect square wave. That all occurs before the DAC.

Let's see here. We're talking about transmitting data at a rate of something like 1.4mbit/s. That's nothing compared to what goes on inside you computer when it's sitting there doing nothing more than displaying a screensaver (for example, the HyperTransport bus in my PC runs at something like 87 gigabit/s without loss). If the Slim engineers can't get that speed working reliably then they should hang up their soldering irons. Not to mention the fact that the same issues (or non-issues) exist whether FLAC or WAV is being played, and in any device manipulating digital data - such as a CDP. If there _is_ a risk of pre-DAC data corruption, it exists equally in every transport.



It does seem to be true that the SB does a better job with this than all but very expensive CD transports.
The difference is in the non-solid state areas. A CDP has the tough job of reading the disc realiably. Compared to that, getting the bits to the DAC is trivial. The SB already has the (assumedly perfect) bitstream, hence why it can do such a good job.

[radish]

Now, now. You left out the part of my original post where I stated "Let me play Devil's Advocate".


My concern was not with the UI, or the industrial design or anything else. I'm sure the McIntosh is very easy and convenient to use, and I imagine it sounds pretty decent. My main objection was your assertion that:

"the SB3 is $300 - and I'm using an old Gateway Athlon 650 as my ripper/encoder with freeware doing the tasks. The MS300 couldn't possibly make worse FLAC copies - in all likelyhood, superior."

That's where you're equating cost with quality, and it's utterly wrong. Most of the best software I've ever used has been free, and much of the worst very expensive. While it might be really easy to rip a CD on this unit that's a worthless convenience if the resulting file sucks, and they don't give you any way to verify it doesn't.

[Pale Blue Ego]

Back to the original question, it might be interesting to get some audiophiles together for structured double-blind listening tests.

Take the same source WAV and try to detect any difference between:

1 - uncompressed WAV streamed to SB3

2 - FLAC decompressed by server to SB3

3 - FLAC streamed to SB3

[Phil Leigh]

[QUOTE=Pale Blue Ego]...get some audiophiles together for structured double-blind listening tests...

I'd find the results more interesting if the test used ordinary people.

I think Radish nailed the point about the digital stream. Compared to what's going on in a typical PC, getting the right bits in the right order at the right time to the DAC is hardly rocket science.

Most decent DACS buffer and reclock the stream anyway, by which time the only thing left of our precious FLAC files is the bit value and order...

[opaqueice]

I think Radish nailed the point about the digital stream. Compared to what's going on in a typical PC, getting the right bits in the right order at the right time to the DAC is hardly rocket science.


This really isn't about bits, or the fact that computer networks work at higher data rates - that precisely misses the point, actually. The issue arises because digital audio transmits data isynchronously, unlike a computer network. That makes things much trickier. If you don't believe this, an very good paper on the subject is here:

http://www.stereophile.com/reference/1093jitter/index.html

But (as I said before) this has nothing to do with the original topic anyway.

[Phil Leigh]

:o)

I think that getting the right bits in the right order at the right time into the DAC is the very essence of digital music reproduction. Get it wrong up to this point and the music is damaged.

Turning the numbers into music is where the real problems should start. With the SB and accurate rips, getting the right bits is basically fixed - but of course the timing is still an issue - that's why we should focus on the DAC and how it deals with inbound jtter (which admittedly is low with SB 2/3) and of course how well the recovered analogue signal is handled.


I wasn't talking about networks, I was talking about (for example) the m-board bus - and things have to happen pretty fast and pretty reliably there, with lots of square waves being interpreted very unambiguously.

My "at the right time" phrase was supposed to cover-off jitter.

Reading out of a buffer (with or without upsampling) using an independent clock right next to the DAC is going to lose most (maybe all?) of the inbound transport/spdif induced jitter - and if there is correlated jitter coming out of the transport, then the designer wants shooting (IMHO). Uncorrelated jitter is a different beast.

I'm not convinced that sending a bitstream to a DAC represents an isynchronous network. Surely the transmitter is blind to the receiver? If anything, it's a broadcast...


Anyway I think this is more interesting than trying to decide if any real person can hear any real difference between FLAC, WAV or server vs SB-side decoding. I know I can't - and more importantly - neither can my wife!.
YMMV

[kjg]

zooropa320 wrote:
> Cleve Wrote:
>
>> The nice thing about the McIntosh - there's not much of a "learning
>> curve" involved - you just put the CD into it - push a button on the
>> remote, and the entire CD is automatically encoded into FLAC in
>> something like 6-7 minutes. And the McIntosh also interfaces with CD
>> changers - so one can effortlessly copy multiple CDs at a time into
>> FLAC.
>>
>>
>
> I'm not familiar with the software its using but I doubt its as good as
> EAC for making perfect rips. Average consumers want the CDs to rip as
> fast as possible. You only rip once but you play it many times so the
> speed of the rip is not as important as an error-free rip. If its
> ripping in 6-7 minutes I doubt its doing the equivalent of a secure
> mode rip in EAC.
>
> I prefer open systems myself to ensure the highest quality possible
> even if the learning curve is steeper. It does cause me to wonder
> about the market for this unit as the average consumer won't pay the
> premium for a McIntosh and audiophile consumers are more savvy about
> how to create high quality rips (I assume) and would prefer an open
> storage solution rather than being constrained by the included hard
> drive capacity. Then there's the backup issue...
>

Just for reference, the Plextor PlexWriter drive with their proprietary
Plextools software rips at greater 20x, and employs and even wider array
of techniques for ensuring accurate rips than EAC. EAC is slow primarily
because the software is generalized to work across a broad range of
drives, and the speeds it achieves can be quite dependent on the drive
being used (e.g. I get about 5x rips with EAC using my Plextor drive,
but others with LG drives have claimed better than 16x with the same
configuration settings). There is nothing in the ripping process per se
that causes it to be extremely slow, and a proprietary hardware/software
package can rip quite a bit faster. A well designed music server product
should be able to provide extremely fast ripping given their ability to
choose the hardware/software combination.