PDA

View Full Version : Flac or not, that is the question



pfarrell
2005-07-19, 16:15
On Tue, 2005-07-19 at 17:44 -0500, Mitch Harding wrote:
>On 7/19/05, Timbo <Timbo.1sfugb (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> >
> > Hi there - I hear what you say and agree that if space is an issue
> > (or bandwidth if you are wireless) then FLAC certainly adds
> > up to a good idea - but - in my case, in my system, with
> > my ears, I don't *hear* EXACTLY the same quality (and I
> > am not alone) - when it comes to audio quality a
> > few extra quid spent on more HD space (under 70 for a 250gb
> > HD!) is not an issue here.
> >
> > Who knows the exact reason why I can hear the difference between WAV
> > and FLAC, I certainly don't, but it doesn't worry me or cause me
> > > anxiety.

> As of your last post, I don't recall a true blind test having been
> conducted. Have you had the chance to do that yet?

I don't understand this response at all.
Separate from the whole "is blind testing useful?" argument,
if Timbo says it is worth a tiny amount of money (under $100 or
(under 70)) then it is worth it to him. Being an audiophile means
you get to obsess about sonic quality or spend more money
than normal people consider appropriate on changes that seem
without justification.

Not only are disks becoming free, but CPU and bandwidth are
getting cheaper and faster on almost a daily basis.

Whatever it takes to enjoy the music


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

Mitch Harding
2005-07-19, 16:27
I don't really care how he stores his music. But I do not absolutely
rule out the possibility of a sonic difference here. I can see no
reason why there would be one, but stranger things have happened. I
believe that FLAC preserves the data just fine, but it is not outside
the realm of imagination that some strange confluence of forces could
result in the sonic difference he perceives.

However, without a true blind test being conducted, it seems more
likely to me to be a placebo effect.

The reason I am concerned is because I want to know if there is such a
difference here. I don't care how he ends up storing his files, I
just want to know if there's a real difference here or not.

On 7/19/05, Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
> On Tue, 2005-07-19 at 17:44 -0500, Mitch Harding wrote:
> >On 7/19/05, Timbo <Timbo.1sfugb (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> > >
> > > Hi there - I hear what you say and agree that if space is an issue
> > > (or bandwidth if you are wireless) then FLAC certainly adds
> > > up to a good idea - but - in my case, in my system, with
> > > my ears, I don't *hear* EXACTLY the same quality (and I
> > > am not alone) - when it comes to audio quality a
> > > few extra quid spent on more HD space (under 70 for a 250gb
> > > HD!) is not an issue here.
> > >
> > > Who knows the exact reason why I can hear the difference between WAV
> > > and FLAC, I certainly don't, but it doesn't worry me or cause me
> > > > anxiety.
>
> > As of your last post, I don't recall a true blind test having been
> > conducted. Have you had the chance to do that yet?
>
> I don't understand this response at all.
> Separate from the whole "is blind testing useful?" argument,
> if Timbo says it is worth a tiny amount of money (under $100 or
> (under 70)) then it is worth it to him. Being an audiophile means
> you get to obsess about sonic quality or spend more money
> than normal people consider appropriate on changes that seem
> without justification.
>
> Not only are disks becoming free, but CPU and bandwidth are
> getting cheaper and faster on almost a daily basis.
>
> Whatever it takes to enjoy the music
>
>
> --
> Pat
> http://www.pfarrell.com/music/slimserver/slimsoftware.html
>
>
>

pfarrell
2005-07-19, 17:02
On Tue, 2005-07-19 at 18:27 -0500, Mitch Harding wrote:
> However, without a true blind test being conducted, it seems more
> likely to me to be a placebo effect.

Have you read up on the "value" of blind testing?

> The reason I am concerned is because I want to know if there is such a
> difference here. I don't care how he ends up storing his files, I
> just want to know if there's a real difference here or not.

So, what is preventing you from doing your own tests? blind or not?

There was a similar argument in the late 70s, saying that all amps
sound alike if they had the same power and basic measurements.
The concept of "audiophiles" and all of high end grew out of
people that say this is wrong, that different amps sound different.

Rather than asking/telling timbo, do your own test.
You might even get some real science if ten people
do the same test and 7 out of 10 can tell.
or even if 2 out of 10 can't tell


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

DrNic
2005-07-25, 12:16
Have you read up on the "value" of blind testing?


Not sure what you are getting at with this statement. If it is purely aimed at blind testing in audio then there may be a different answer (please let me know what it is), but I would categorically state that double blind testing is the only method of true unbiased testing in all fields of "science". But that may be the rub - we already know that music reproduction only partly falls within the realm of science, don't we!!

Nic

gdg
2005-07-27, 17:24
I read from someone over at AudioAsylum that, while in a perfect world FLAC is 100% accurate, in reality one runs a <b>very</b> slight risk of audio degradation in the "uncompressing" process. I guess the more "processing that gets done the more chance there is for error.

Jacob Potter
2005-07-27, 17:32
On 7/27/05, gdg <gdg.1susvn (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> I read from someone over at AudioAsylum that, while in a perfect world
> FLAC is 100% accurate, in reality one runs a <b>very</b> slight risk of
> audio degradation in the "uncompressing" process. I guess the more
> "processing that gets done the more chance there is for error.

Not really. FLAC has checksums on the data - if there was an error by
some astronomically large chance, it would be caught by the decoder.

Besides the fact that a computer that was getting random bit changes
would be horribly unstable no matter what it was doing.

- Jacob

Robin Bowes
2005-07-28, 01:55
gdg wrote:
> I read from someone over at AudioAsylum that, while in a perfect world
> FLAC is 100% accurate, in reality one runs a <b>very</b> slight risk of
> audio degradation in the "uncompressing" process. I guess the more
> "processing that gets done the more chance there is for error.

Rubbish.

Flac is lossless and uses checksums to verify that the decoded audio is
correct.

R.

pfarrell
2005-07-28, 08:23
On Wed, 2005-07-27 at 17:24 -0700, gdg wrote:
> I read from someone over at AudioAsylum that, while in a perfect world
> FLAC is 100% accurate, in reality one runs a <b>very</b> slight risk of
> audio degradation in the "uncompressing" process.

This tells me that one shouldn't bother to read AudioAsylum.

Lossless means that the data is preserved.

It is trivial to test that a lossless process is correct,
compress and uncompress and then bit compare.

Similarly, if you hear that Lossless WMA is different (more or less
accurate ) from lossless AAC is different from MLP is different from
flac, it is pure BS. The speeds, DRMs, platforms supported, etc.
are different, but being lossless is like being pregant.
You are or you are not. There are no degrees.

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

Andrew L. Weekes
2005-07-28, 08:35
I'm not stating either side is right here, but there ARE perfectly valid engineering reasons why lossless compression and uncompressed playback could sound slightly different.

The workload on the CPU is likely to be different in each case and this could have a directly correllatable effect on the PSU for the CPU section of the Squeezebox.

Since that CPU load is on the same PSU's that power the clock circuitry, it's entirely possible it could affect the sound.

Again I'm not saying it does, or doesn't, but it's entirely possible through logical and genuine engineering analysis for it to do so.

It's not uncommon for many high end audio products to use the lowest power CPU / uP sections they can get away with AND then put them to sleep when not required, for this very reason, since PSU and EMC interactions can have very obvious sonic effects. Some products have an optional and entirely isolated and remote PSU for the digital sections too, with very large improvements in sonic performance as a result of seperating the current flows.

Andy.

seanadams
2005-07-28, 08:40
being lossless is like being pregant.
You are or you are not. There are no degrees.

http://www.cnn.com/US/9901/01/octuplets/

So, are you sure some ultra-ultra-lossless compression is not possible? :)

pfarrell
2005-07-28, 09:16
On Thu, 2005-07-28 at 08:35 -0700, Andrew L.Weekes wrote:
> I'm not stating either side is right here, but there ARE perfectly valid
> engineering reasons why lossless compression and uncompressed playback
> -could- sound slightly different.

Throw in enough "possibly" and "theoretically" and I'm with you.

In practice, you would have to balance the increased network traffic and
CPU needed to handle twice as much TCP/IP traffic, error processing,
retransmissions, etc. against the smaller data used sending flac.
This probably also clanks more memory, making the memory controller
work harder, etc.

I haven't looked at the internals of ACC, WMA, MLP or other
closed systems (as if I could) but flac was specifically designed
to be efficient to decompress on minimal systems like pocket
music players, etc. So I believe that you would need a
lot of "potential" hand waving before you could prove the case.

BTW, I think this really goes in the server-side versus player decoding
thread rather than this one, about global flac goodness.


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

Jacob Potter
2005-07-28, 09:28
On 7/28/05, Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
> In practice, you would have to balance the increased network traffic and
> CPU needed to handle twice as much TCP/IP traffic, error processing,
> retransmissions, etc. against the smaller data used sending flac.
> This probably also clanks more memory, making the memory controller
> work harder, etc.

I notice a distinct drop in the visualizer framerate when using
onboard FLAC decoding, so there's a pretty big CPU hit. (But I agree
that you need a lot of "possibly" and "theoretically" disclaimers
before translating that into lower audio quality).

- Jacob

max.spicer
2005-07-28, 11:50
Really? I've never played anything but FLAC so I wouldn't notice this, but I'm very surprised to hear it. I'd have thought the SB2 was designed to easily cope with anything that was in its initial specs.

Max


I notice a distinct drop in the visualizer framerate when using
onboard FLAC decoding, so there's a pretty big CPU hit. (But I agree
that you need a lot of "possibly" and "theoretically" disclaimers
before translating that into lower audio quality).

fuzzyT
2005-07-28, 12:45
Pat Farrell wrote:

> This tells me that one shouldn't bother to read AudioAsylum.

Your conclusion covers vastly too much ground. We have a paraphrased,
hearsay report of a statement attributed to one user of a well-populated
forum and you would judge that this somehow invalidates the statements
of the entirety of that group?

> Lossless means that the data is preserved.
>
> It is trivial to test that a lossless process is correct,
> compress and uncompress and then bit compare.

All true.

> Similarly, if you hear that Lossless WMA is different (more or less
> accurate ) from lossless AAC is different from MLP is different from
> flac, it is pure BS. The speeds, DRMs, platforms supported, etc.
> are different, but being lossless is like being pregant.
> You are or you are not. There are no degrees.

The problem with this is that no human can hear a bitstream.

These bits everyone is so fond of characterizing with pure perfection
are an abstraction. Information represented by physical changes in an
engineered system.

In this case, represented by the rise and fall of --analog-- voltages in
wire. Buffered and pumped into a processor for digital decoding. Sent
to an imperfect receiver into another device for D/A conversion.
Amplified and sent to an imperfect transducer and pumped into a
non-ideal acoustical space. Energy then transferred to another
transducer and converted to perception by an organic system of which we
have only the barest of understanding.

What could go wrong? Everything. "Perfect Sound Forever" was, is and
shall continue to be another case of marketing fluff.

FLAC encoder input = FLAC decoder output, certainly. But extending that
to a statement that a system processing identical bitstreams will
produce identical sound is to ignore an awful lot of real world complexity.

If you must have a rational model for expecting the observed behavior,
I'd float these as possibilities: power supply variance or noise due to
processor current consumption, RFI or other system noise due to
processor activity, difference in signal paths for PCM vs. decoded FLAC,
just to name a few.

Before attributing the strength of a mathematical proof to your
understanding of a physical system, it is best to be sure that you have
modelled the entirety of that system.

--rt

kevin
2005-07-28, 16:50
Jacob-- You'd have to get Vidur to confirm this, but I don't think it had to do with the processor being overtaxed or anything like that... I seem to recall him saying something about the FFT function just working completely differently than when using MP3 and PCM, so the fps is a bit lower... But this was a long time ago and I can't recall any exact details...

There was a bug about this, though:
http://bugs.slimdevices.com/show_bug.cgi?id=900


On 7/28/05, Pat Farrell <pfarrell (AT) pfarrell (DOT) com> wrote:
> In practice, you would have to balance the increased network traffic and
> CPU needed to handle twice as much TCP/IP traffic, error processing,
> retransmissions, etc. against the smaller data used sending flac.
> This probably also clanks more memory, making the memory controller
> work harder, etc.

I notice a distinct drop in the visualizer framerate when using
onboard FLAC decoding, so there's a pretty big CPU hit. (But I agree
that you need a lot of "possibly" and "theoretically" disclaimers
before translating that into lower audio quality).

- Jacob

dean
2005-07-28, 17:13
What's going on is that visualizer code is in the same thread as the
FLAC decoder and on a per-frame basis FLAC is using more real time,
which slows down the update frequency. The CPU's not overloaded,
rather there's a little bit of timing that could be improved.

On Jul 28, 2005, at 4:50 PM, kevin wrote:

>
> Jacob-- You'd have to get Vidur to confirm this, but I don't think it
> had to do with the processor being overtaxed or anything like that...
> I seem to recall him saying something about the FFT function just
> working completely differently than when using MP3 and PCM, so the fps
> is a bit lower... But this was a long time ago and I can't recall any
> exact details...
>
> There was a bug about this, though:
> http://bugs.slimdevices.com/show_bug.cgi?id=900
>

Jacob Potter
2005-07-28, 17:26
On 7/28/05, dean blackketter <dean (AT) slimdevices (DOT) com> wrote:
> What's going on is that visualizer code is in the same thread as the
> FLAC decoder and on a per-frame basis FLAC is using more real time,
> which slows down the update frequency. The CPU's not overloaded,
> rather there's a little bit of timing that could be improved.

That would do it. I just checked and the framerate goes back up around
12 seconds before the end of the last track in the playlist - I guess
that's when the FLAC decode finishes. I'm getting closer to 5 or 10
fps when it's doing the decoding.

Out of curiosity, how much of the CPU capability is being used?

- Jacob

vidurapparao
2005-07-28, 17:36
The visualizer framerate is lower with FLAC than with MP3. This is primarily a result of the firmware audio pipeline and FLAC decoder architecture, and secondarily because of the size of FLAC frames. From what I can tell, FLAC decompression itself doesn't put a greater load on the SB2 CPU than MP3.

The decoding process and visualizer computation run on the same thread in firmware. Visualizer frames are computed between invocations of the decoder. Any single invocation of the FLAC decoder results in decompression of a complete FLAC frame. The state machine within the FLAC decoder doesn't allow for decompression of a partial FLAC frame - as a result the thread effectively blocks till an entire frame has been decoded. Because of the size of a FLAC frame (~1/10th of a second of audio) this can take more time than the goal frame period of the visualizer (30 fps = ~33ms). The SB2 CPU architecture allows for 8 concurrent threads, so several other processes, including screen updates, network activity and audio processing (e.g. application of gain) can occur during this period...just not visualizer computation.

The MP3 decoder in the SB2 has a finer grained state machine and smaller frame sizes - this results in a higher framerate. Neither decoder comes even close to pegging the CPU.

Robin Bowes
2005-07-29, 03:46
ron thigpen wrote:
>
> FLAC encoder input = FLAC decoder output, certainly. But extending that
> to a statement that a system processing identical bitstreams will
> produce identical sound is to ignore an awful lot of real world complexity.

Ron,

I believe you're giving the right answer to the wrong question!

You are describing the vaguaries of the digital->analogue conversion
process, not the encoding/decoding of the flac format which takes place
in a non-timebound digital domain and can be proven to be entirely
accurate, i.e. what you put in you get out.

I read the original statement as saying that there was a possibility
that FLAC encoder input <> FLAC decoder output. And I interpret Pat's
response to say the same. It was this assertion that I described as
"rubbish".

Everything else you have said about PSUs, noise, RFI, etc., while
completly valid is not really relevant in this instance.

R.

fuzzyT
2005-07-29, 06:43
Robin Bowes wrote:

> Everything else you have said about PSUs, noise, RFI, etc., while
> completly valid is not really relevant in this instance.

Right-o. Which is what I get for reading and posting while most of the
organic CPU cycles are elsewhere engaged.

--rt