Converting WAV to FLAC which FLAC Level is sufficient

[wynpalmer]

That's not to say that I'm defending random subjectivist c**p. It still has to go through the same kind of evaluation/statistical assessment as any other extreme claim must and all too often even the slightest pretense at objectivity is ignored, and all questions concerning procedures, rationale etc. are dismissed without thought- and that is completely unacceptable.

 

[simbloke]

So you are saying a computer can't decompress files and reproduce the file as it was before it was compressed????
Codswallop. If that were so most computer systems would not function.

 

[maty]

As for the placebo ... all well-constructed and designed amplifiers are supposed to be indifferent. I opened a thread with a multitude of MP3 top quality not created by me and that contradicts that widespread belief. I only ask to compare three amplifiers.

https://www.audiosciencereview.com/...verify-the-quality-of-your-audio-system.8138/

 

[solderdude]

As for the placebo ... all well-constructed and designed amplifiers are supposed to be indifferent. I opened a thread with a multitude of MP3 top quality not created by me and that contradicts that widespread belief. I only ask to compare three amplifiers.

https://www.audiosciencereview.com/...verify-the-quality-of-your-audio-system.8138/

Isn't it likely that 1 or 2 of these amplifiers were not competently designed or measurably differ within the realm of audibility ?
Why did the guy making the files not simply record the output voltage of the amps with their loads.
That would be far more revealing and easier to compare as well as to properly level match.

This 'test' says nothing about how 'revealing' ones playback system is at all... that's why you have had no answers.

I am not a member at that DIY site so cannot see the FR plots and other measurement data on these amps.

This 'test' also has nothing to do with FLAC compression... the files are in MP3 regardless if the quality is highest or not.
(Personally I think MP3 VBR0 or 320 is sufficient for enjoying music)

 

[maty]

It is an elementary test, which should be easily overcome. But I suspect that many will be unable to differentiate between those three.

If they do not overcome it much less with more complicated ones!

 

[Soniclife]

I believe that the problem is not in the DAC but in the computer (CPU, registers, SMPS ...) and in the optimization of the OS, because it affects other DAC too.

That said, it is very frustrating to ignore why the theory does not match the reality in my two audio systems.

The reality is you have tried to prove there is an audible difference, and failed in ears only tests. You can accept this reality or continue tilting at windmills.

 

[KSTR]

[...]
However, it does mean that it's hard to just dismiss the possibility that for some people on some systems with some DACs that there might be an issue.
[...]

Yep, my POV as well. Actually this is the one and only reason why bit-identical streams (and packeted identically, as well) reaching a DAC could ever sound different, high levels of jitter and supply modulation leaking through to the analog side of a rather mediocre DAC.
Point is, the "bit-identical isn't enough" crowd doesn't seem to grasp that and therefore often erroneously attribute the sound change to the circumstances during the creating time of the file / bit-stream (like having the laptop running from battery vs mains during a CD rip). Actually, only conditions during playback matter.

 

[pkane]

I have measured the spectral characteristics of various digital interfaces as I've had to design receivers/transmitters for them.
Having a common 5v supply results in spectral impairments due to processor etc. activity that can result in low frequency modulation of the sequence. Depending on how the receiving/retiming is performed a residue of this modulation will exist in the output sequence, which results in AM which in turn can get converted to PM in the receiver as the detection thresholds can shift.
As to whether it is significant- I cannot say, but I can say that it does exist, and it is a function of the various power supplies and their spectral content, which in turn is, to some extent, a function of system activity levels.
I can't say that I've measured this for FLAC vs. WAV on my PC for example. I can't hear ANY difference with the DACs that I have.
However, it does mean that it's hard to just dismiss the possibility that for some people on some systems with some DACs that there might be an issue. The history of audio suggests that just sometimes, sometimes, the golden ears get it right, and the reasons can be quite surprising. (Matti Otala and TIM immediately springs to mind. Obvious in retrospect, but eye opening at the time).

But what is to say that higher CPU activity does not improve the sound instead of hurting it? What if higher CPU load causes higher frequency noise that then doesn’t manifest in the audible band? Maybe FLAC decompression is really good for audio? Or only with certain CPUs or certain motherboards? I can see it now: CPU and memory rolling becomes a thing in audiophile circles. Specific CPUs are better with FLAC others with WAV... oh, wait, I think it already is a thing

 

[Eirikur]

Again, read the Crystal paper. It explicitly defines the spectral and indeed temporal characteristics that are necessary for even relatively low levels of timing jitter to be audible.

Hi Wyn, this paper looks at PLL jitter which indeed is a well-established source for distortion.

Maty, however, seems to experience audible differences based on compressed versus uncompressed FLAC.
The contention lies in the fact that FLAC decodes to 100% bit-perfect PCM, and that a USB interface between PC and DAC cannot be the source of jitter when it operates as a pure a-synchronous data interface. Once the data is safely & timely out of the PC there is no way for the DAC to be influenced by the FLAC encoding unless the USB data stream can be corrupted without detection (or if the USB data buffer depletes).

Writing the above I suddenly realized we didn't ask @maty how exactly his DAC is connected to the PC.
Do you use USB or are you using optical or electrical SPDIF? If you're using SPDIF you may well experience all kinds of unexpected distortion: there is no error-correction in the bit stream and PC clock itself may be a jitter source. Even the circuit generating the optical signal may be subject to noise and even timing fluctuations.
Link: a simple experiment by Serene/Audio showing how an external USB converter can actually make things worse!

[edit] Wyn properly points out that legacy USB Audio Class devices use isochronous data transfer, and may therefore suffer unrecoverable bit errors. Although the receiver can detect this via CRC, it cannot request retries. When properly implemented, jitter is still not a problem as the USB-audio receiver adjusts the data frame sizes according to the observed clock difference, and reports this back to the sender.
XMOS Ltd. posted an extensive explanation of the original USB audio protocol.
Another article explains how cheap/poor USB implementations might indeed suffer from jitter. For example: suppose the USB device just maps the frame data onto its own clock pulses as best they fit. Link: Select your USB audio MCU with care - Scary stories from the test bench

Still, modern devices will surely implement USB Audio Class 2.0 which is fully asynchronous.

 

[maty]

With one very audiophile: cheap USB cable that came with the DAC, the one used for printer. USB-2 connector. I think the same thing happened with USB-3. I reserve them for external hard drives.

 

[maty]

Very old and badly picture

It was an experiment. Now with only one RCA cable.

Left: the first, the prototype, DC Blocker if I am not wrong.

And yes, better sound with the Würth 150 kHz ferrite. I have a lot of in my two systems.

 

[wynpalmer]

Hi Wyn, this paper looks at PLL jitter which indeed is a well-established source for distortion.

Maty, however, seems to experience audible differences based on compressed versus uncompressed FLAC.
The contention lies in the fact that FLAC decodes to 100% bit-perfect PCM, and that a USB interface between PC and DAC cannot be the source of jitter when it operates as a pure a-synchronous data interface. Once the data is safely & timely out of the PC there is no way for the DAC to be influenced by the FLAC encoding unless the USB data stream can be corrupted without detection (or if the USB data buffer depletes).

Writing the above I suddenly realized we didn't ask @maty how exactly his DAC is connected to the PC.
Do you use USB or are you using optical or electrical SPDIF? If you're using SPDIF you may well experience all kinds of unexpected distortion: there is no error-correction in the bit stream and PC clock itself may be a jitter source. Even the circuit generating the optical signal may be subject to noise and even timing fluctuations.
Link: a simple experiment by Serene/Audio showing how an external USB converter can actually make things worse!

Audio over USB is an isochronous transfer. There is nothing in the protocol that permits any corrections of the data stream to occur at the receiving end, nor for the source to retransmit any erroneous data. However CRC checking is permitted (but not required) and errors can, and often are, flagged, which can be an important diagnostic tool.
Besides, what we are talking about here is not packet errors per se, but what happens to jittery data when it gets to the USB receiver/DAC and how that system handles it. In essence it becomes an analog rather than exclusively a digital problem.
This argument also applies to any other digital interface that requires transmission and reception and processing back into bits (i.e. all of them).
For the DAC output to be impaired in some sense all that is required is that the jitter profile of the recovered data be unacceptable, and all digital data has jitter.
As has been stated and I paraphrase rather flippantly, "bit perfect does not mean perfect bits".
A well engineered interface/DAC will convert a substantially less than perfect bit stream, even if it is bit-perfect, into an adequately near perfect bit stream which remains bit-perfect, reducing the timing imperfections in the process. A poorly engineered or outmoded design will not be able to achieve the same level of perfection, even if the output remains bit perfect and free of errors.

 

[maty]

If one day I buy or build a new amplifier for my second audio system, I plan to buy the RME ADI-2 DAC (well, what I have really decided is that the chip must be from AKM). If then I still perceive differences it will be clear that the cause is the computer as I think.

By the way, when that picture was taken the computer was another with AMD 64 bits. New computer has an Intel i5 4600. Different computer but same problem.

 

[Thomas savage]

Can we not have this thread taken over by senseless audiophile imaginings and stick at least remotely to the OP.

@maty you seem to have a talent for making every thread about your eccentric audiophile obsessions often with no concern for the topic.

Please stick to the relevent info and try and avoid getting distracted by ferrites and DC blockers , aluminium thickness and dynamic range of some obscure recording.

 

[maty]

I have only explained what you see in the old picture. If it were new, only the ODAC and wiring would appear, as it is logic.

You forgot to mention the AMD and Intel processors. And RME ADI-2 DAC too.

 

[graz_lag]

I think someone needs to stress the idea behind FLAC compression:

It is no different from zipping a text document. The source audio file is a sequence of numbers that is no different from, say, a Microsoft Word document. FLAC compression (as opposed to MP3 and MQA which are lossy) merely removes redundancy in the numbers by, for example, substituting a token for patterns that might be repeating. Upon replay, the original numbers are re-substituted in place of the token.

Thus, upon replay, a FLAC file is an exact duplicate of the original audio; no better, no worse. There's no psychoacoustics involved, no assumptions, no compromises. The only issue is the small space advantage you might gain by giving the PC more time to do the compression, but this does not change the data in any way.

You're exactly right.
I'd like to report my experience with Linux, I do not have any one with Windows instead.
I use the command flac utility to convert my WAV files (either 16/44.1 or 24/96-192) to FLACs - testing then in several occasions the conversion back into WAV by means of the same command flac utility.
I only see differences in the metadata header between the original WAV and the WAV converted back from FLAC , which is not a problem to me as I always re-edit my FLAC tags anyhow.
Not seen any changes to the musical content.
Both the diff command and hexdump show the minimal differences in the metadata header between the original WAV and WAV converted back from FLAC.
The back & forth conversion process does not change the digital music stream.

 

[maty]

Nobody affirms that the information is not the same, hence the mystery, at least in my systems. Logic and theory dictate that they should sound the same.

 

[graz_lag]

Once in a while, pls. try to get some kick out from direct contact with AC power supply ... It may help ... Ha Ha Ha !
(We love you too much @maty !)

 

[maty]

That was a joke/grace I spent decades ago. I said that when I was sleepy and needed to wake up, I stuck my fingers in the plugs.

Lucky that the comment is yours, because if I become the author ....

 

[graz_lag]

Did you compare WAV vs. FLAC in memory playback configuration if you've doubt abt. possible interaction between processor load and audio performance ?