What is your preferred music file format and why?

There's some old SBD recordings of live shows floating around in .shn, but that's the only time I've ever seen that format.

 

So if folks aren't yet sick of my BS here's a fun thing I randomly noticed. Chain is Modi Multibit 2 >Magni Piety > HD600.


For context I recently got a USB CD drive to rip albums with because I found that I could often get physical copies of albums I liked (esp of older releases) for significantly cheaper than buying even "mere" redbook-quality FLACs of the same online. The first CD I bought in a good long while was Hayley Williams's Petals for Armor which I realised I streamed so often that, yeah, a lossless copy would be really nice to have.

tangent: it's a really nice album IMO if you're into groovy and sad-fi. One thing I love about it is that even on lossy streaming platforms you can tell that it's not overly polished in the sense that it comes off as sterile in terms of ambience and textures; the thing is just really fun.

The CD arrived well before the drive did, and I was very impatient so I "borrowed" a FLAC copy of the album from an "acquaintance" online. Not really proud of that since I've been moving away from that for years now but I figured it was more excusable here since I got the actual album. Won't try to justify it. Suffice to say this was a lot more engaging than the lossy version I'd been running with online.

The drive arrives a few days later and because my conscience is nagging at me I rip the album and replace the FLAC copy with a 1411kbps WAV from the CD. Because I'd remembered my own bullshit from this thread earlier in the year I decide to try and ABX the earlier FLAC v the WAV file and... heard no difference. Run a bit-comparator, no differences found. Alright sure they're the exact same I can rest easy without worrying about it whatsoever. Nice.

Just an hour or so ago I put the album on again (really not sick of it yet) and, for fun, try listening to it in NOS mode; I'd listened to the FLAC copy I'd gotten in both OS and NOS mode a few times each so was vaguely familiar with how it sounded in both configurations. I hit play and, after a few seconds, I get startled and mutter a vehement "what the f**k".

Going by timestamps in a chat with a friend between them egging me on to give this a shot and me taking this screenshot, seems like it took me less than minute per run which I'd qualify as rapid ABX-ing with my DAC in NOS mode.



I decide to run a null test in Audacity just to be DOUBLY sure, but then I noticed that there was actually a slight offset between the WAV I'd ripped and the equivalent FLAC file. When I say slight difference, incidentally, I mean it (mind the time scale up top):



So I zoom in further and do my best to align things e.g. below and trim the ends that overhung...



... before I realise that I could just convert the CD rips I have into FLAC on my own and properly discard the ones I found online. Keep it simple, stupid ; I very often make things harder on myself than I really have to, I notice. Either way I run an ABX test using the CD rip and the FLAC I'd compressed therefrom and notice that this is immediately more difficult, lending credence to the fact that even *minuscule* difference in timing e.g. the... milliseconds(?) that the two files were off by is enough to throw off perception.

Either way, even with my focus flagging (I despise critical listening), managed to get an okay score before I got distracted and my brain got reset:





To be VERY clear I am not proposing that there's a difference between FLACs and WAVs in general; I believe it was established from my madness earlier in this thread that there was just something screwy going on with how Bandcamp was handling all these things. What I am asserting is that the DAC I'm currently running, the Modi Multibit 2, might seem to handle the same songs differently in NOS mode, likely contingent on the sampling rate (the WAV was maximum 1411kbps whereas the FLAC file I'd converted myself was a "mere" 758kbps)-- when I switch the MMB2 back into oversampling mode I am unable to tell any difference between the WAV file and the FLAC file I'd ripped. I think this qualifies as a testament to the quality of the Schiit Footlong Mega Combo Burrito Digital Filter as the DAC's output in OS mode made it so that the WAV and FLAC file, the latter being just over half the sampling rate of the CD rip, were audibly indistinguishable.

Other than the noticeable treble ringing with the MMB2 in OS mode (which I am largely inured to at this point, I think), I do think that OS mode is by far my preference. Having said that I can definitely see NOS mode better suiting other folks' preferences, in which case I feel that it may be worth looking into different sampling rates for their media. Hate to say it but I'm starting to understand the HQPlayer folks

 

I do not question in any way that you may hear the difference but...
The problem is that after reading the thread, and I might have missed something, I am not even sure if it was really established what is being compared. AND I am very skeptical that we are comparing formats, let me explain why.

What I mean by that is best illustrated by the configuration of JRiver: it allows you to load the entire decompressed and decoded file into memory and only then sends PCM to DAC. That means that the only thing that happens when you start playback is just data streaming.
There is also an option to load the entire decompressed file into memory and then do real time simultaneous decoding and transmission of PCM chunks as they become available.

Otherwise, and here I quote ChatGPT verbatim:
"When playing a FLAC file without loading the entire PCM data into memory, the player decodes (decompresses) and sends the PCM data to the DAC simultaneously in real-time. There is no need to complete the entire decompression before starting playback. The player reads portions of the FLAC file, decompresses them on-the-fly, and streams the resulting PCM data to the DAC as it becomes available."

I read in more than one place that with some players, or/and hardware platforms, if the processing from FLAC to PCM, and streaming, is happening simultaneously, it may be enough to influence the stability and timing of data transmission, potentially reducing playback quality by introducing latency and jitter. It may vary with the player, the platform, interface to DAC etc

Well, I tried all three configurations playing FLAT files and I hear a slight difference, I would not call it distortion but some change in tonal balance between simultaneous decompression, decoding, and streaming, or. after decompression and decoding is done, loading the entire PCM file into memory before the streaming starts.
Therefore, in my view, it is more likely that the player, its configuration, and hardware platform, is affecting the SQ between WAV and FLAC of the same track, than file format.

If you start with WAV, you at least eliminate the step of decompression from the simultaneous processing, load of CPU may be lower, noise floor may be reduced etc..
The same would happen if you load the entire file decompressed from FLAC into memory, in both cases CPU still has to do simultaneous decoding and streaming but only after decompression is already done..
If the entire PCM is loaded into memory before playback, it is reasonable to expect that, when the player is doing only streaming, the noise floor of the player platform will be lower.

On very good players, like Bryston BDP-2, it should not make any difference but on PC, MAC, RPi, it just may.

For exactly the same reason , on the same platform, the player that can better optimize, or entirely eliminate the simultaneous decompression, decoding, and streaming, like JRiver, may sound justifiably better.

 

Quoting chatGPT is a bold move considering how often that one likes to make things up on the fly (I'm a hater of crypto/NFTs/"AI", and all that so feel free to ignore my jibe)

No but I get what you mean. It was proposed by Garns earlier on in this thread that it COULD just be to do with how decoding FLACs is extra work for the processor vs just passing PCM along, but even though I'm on a lower-end and older platform at this point I would imagine a Ryzen 3600 with more cooling than it needs (I have a Noctua D15 slapped on) is at the least competent enough to transmit things without stumbling onto its face.

I do have PlayPcmWin instaalled after Biodegraded's advice to try it out earlier on, and while I do still hear a difference I don't trust myself enough to fully discredit the possibility that *that* is confirmation bias because I cannot blind test via that in the same way I managed with foobar. Also, it was touched on earlier in this thread that I had already disproven that the issue was with my running FLACs per se:

... so if there IS a difference on that front, I'm basically deaf to it.

What I was pointing out in my post above was how I was amused at how much of an audible difference there was running FLAC v WAV with my DAC set to non-oversampling mode; I was surmising that the higher bitrate of the WAV might have been doing something to "fill in the gaps" so to speak. When I switch back to oversampling mode, I discern no audible differences whatsoever between both formats and fail ABX via foobar.

 

The same prompt on Grok, Gemini and ChatGPT o1 gives you the same answer just articulated differently. There is enough LLM engines available now to do meaningful verification. But that's digressing.

I am quoting ChatGPT because it articulated it better then I probably would. In JRiver , if you do not specify loading file into memory, it does indeed do processing of decompression, decoding and streaming simultaneously. I would bet that other players do that as well. JRiver is just offering a configurable way to make those phases sequential. To be more precise to split the processing into 1.decompression 2. decoding and streaming OR 1.decompression and decoding 2. streaming.

 

The world of audiophoolery is so full of nonsense, and no AI chat is going to be able to tell truth from fiction. Hey, many non-artificial intelligences can't.

There may be some contradiction in what I am about to write...

Even to a computer of twenty years ago, decompressing a data file and sending on the data was trivial. But how audiophools love to say, "Oooooh! Potentially this might be a problem!" Well, it isn't.

But all is not always sweetness and light in the world of computer audio playback. It is mostly to do with process priorities and interrupts. For instance, a PC will tend to prioritise video over audio. My classic example of this, albeit I have not experienced it for over twenty years, is the audio making a horrible noise as the mouse pointer is moved across the screen. Traffic signals: video gets a green, audio has to wait at a red. PCs are not real-time: to all intents and purposes they can do many things at the same time, but the truth underlying that has not changed in all the decades: they only do one thing at a time, but they switch between things really really fast.

Problems with priorities and interrupts can be as bad as dropouts and corruption that make music listening just impossible. Or they can be subtle. I am not technical enough (and my techiness is out of date too) too understand this, although I think that it comes under the same head of priorities and interrupts. I think that most of us have experienced digital playback simply lacking life. Like it is all there, but not all there. I just reboot and start the music before anything else (I have a general all-purpose machine) so that it hopefully grabs and keeps higher priorities. And it then sounds better.

Coming back to the thread, all this means that two listenings to two different files can be different. It is not magic, it is computer science. But I am not up to a deeper explanation.

And... I like FLAC. I usually add that, if all I can get is a MP3 then that'll do. But I prefer it not to be less than 128. That is actually good enough for my ears, even though I can still hear the "digital differences" I just wrote about.

There are things I like about FLAC that may not have anything to do with the sound (anyway, I sincerely and scientifically believe that lossless means lossless). I like that FLAC comes from some very brilliant audio-visual encoding guys. I like that it is free and has neither commercial origins nor ties. I like that it is open source (Is it a good read? don't ask me! I'm useless at basic maths, let alone data compression). It's the same reason that, when I am going for lossy compression, eg for the phone, I go for OGG rather than mp3. I doubt that I could (ever) hear the difference.

 

It does not matter how fast PCs can switch between things, how powerful is the platform etc ect. The only thing that matters if, for a specific player, fully simultaneous processing affects the latency in streaming PCM to a DAC, or not. The reason JRiver decided to introduce the option for sequential processing was because, in their testing, or in their developers opinion, separating the transmission phase from two other was making things better. I cannot say it was better in terms of measured latency, or it was audible for them. The slight difference I can hear maybe my platform, specific processing by JRiver, or whatever but it is consistent, and more pronounced using USB.

 

[QUOTE="Thad E Ginathom, post: 435824, member: 58]
Even to a computer of twenty years ago, decompressing a data file and sending on the data was trivial. But how audiophools love to say, "Oooooh! Potentially this might be a problem!" Well, it isn't.

But all is not always sweetness and light in the world of computer audio playback. It is mostly to do with process priorities and interrupts. For instance, a PC will tend to prioritise video over audio. My classic example of this, albeit I have not experienced it for over twenty years, is the audio making a horrible noise as the mouse pointer is moved across the screen. Traffic signals: video gets a green, audio has to wait at a red. PCs are not real-time: to all intents and purposes they can do many things at the same time, but the truth underlying that has not changed in all the decades: they only do one thing at a time, but they switch between things really .[/QUOTE]
Yeah but along came a Finnish mathematician who created a software that allows you to turn music files from PCM to DSD what have you not and more is betterer like bigger is betterer and in order to do the cutting edge stuff you need a real powerful computer, when you can do upsampling to 96 kHz, convolution for room correction and the “uncontainering” of flac on a Pi without any issues, if you use a real time kernel.
So there you are you actually need a powerful computer in order to make digital audio sound good. To me it looks more like an astute business model than a true advance in digital audio but each to their own.

 

Yup. And to me, almost all the paid software players smell of the same.

But some tuning/optimisation of PCs to play music can be very much real. Not to mention all the media management and streaming stuff. I'm not saying they are a complete waste of money. Even if one can get most of it for free.

And why would latency matter anyway? Latency matters in the studio, where people have to hear at the the same time as playing/singing, and the round trip of that sound matters a lot.

All that latency does in playback is introduce a delay. Like (exaggerated example) you press play, and have to wait for something to happen. Latency re interrupts, etc matters a lot. see my traffic signal analogy above. Latency as in, how long does it take to get from data to output, is utterly irrelevant. It's a manufactured sales point. Fake advertising.

 

Agree, latency may have limited or no impact unless is severe and leads to dropouts.
And it would be useful to separate the process of simultaneous processing from whether it is audible or not.
But that's not only potential effect of real time FLAC vs sequential processing. Potential timing errors between the player and DAC are more significant because they will result in jitter. The whole process has many variables and, depending on the quality of FLAC processing, the platform, clever mitigation of the problems inherent in the process. I do not think that dismissing some potential problems because other issues may be affecting the same process is not very productive.

 

@wormcycle, I have already overrun my technical competence to argue the point. So I have to accept that you may be right: I don't know. I have some doubts, but am now firmly into just my opinion...

Potential timing errors should be sorted out by the transmission protocol. That might be one of my opinions, as I'm unsure of the technical issues.

Perhaps I'm on firmer ground in saying there is no variable quality of FLAC processing. The file is uncompressed to the original data. That is simply how all lossless* compressed storage works, and it is either reliable or useless. Whatever the data, and whatever the compression process, what you get out is what was put in. If that was variable, nobody would use it. Lossless means lossless is non-negotiable in computer world.


*added the word later for clarity/pedantry

 

Ok, there seem to be a lot of misconceptions here. I'll try to explain as good I can as much as I understand—and my understanding isn't complete at all, either, of course.

First, some seem to think that the digital data that reaches the DAC might be different when FLAC vs WAV is used. This is not the case. The DAC (if it isn't a streamer with builtin DAC) does not understand FLAC or WAV, it only understands PCM. WAV is a container with uncompressed PCM plus a little extra information in it. The computer will the take PCM out of the WAV file or uncompress the FLAC file and then have PCM, too. If the FLAC and the WAV were created from the same source, all PCM bytes that reach the DAC will be 100% the same for both files, not the slightest difference between both.

Also, at least in case of USB, timing doesn't make a difference, either. All current USB implementations give a shit about timing, as buffers are used on both ends of the transmission. Data is not sent via USB at the moment when it drops out of the CPU (which, due to multitasking, wouldn't make sense, anyway). The USB controller in the DAC can tell the USB controller in the computer when to send bytes. Then, a packet or several packets of bytes are sent until the receiver says "Enough for now", then sending is paused and will be resumed when the receiver is ready again. This is completely independent of what the CPU has to do to obtain the PCM stream in the first place. The CPU will just deliver the PCM stream to the USB controller and its buffer. As long as it's not so slow as to produce a buffer underrun, i.e. the DAC asks for more data but none is available yet as the CPU hasn't delivered it to the USB controller yet, nothing at all will be different between FLAC and WAV in respect to the data that reaches the DAC. If your computer isn't constantly running near 100% CPU load, such a buffer underrun is next to impossible.

The DAC has its own buffer where the data comes in. It will read the data from that buffer when it converts it to analog, at its own timing, completely independent of what the CPU of the host computer did to obtain the PCM stream. (Note: When you're not using USB but other forms of digital transmission, timing from the host computer might be used, which makes things more complex, of course. Let's keep it to USB here in order to keep it simple.)

Theoretically, there might be transmission errors on USB. There are error corrections algorithms in place to correct them. In extreme cases of "very bad USB cable and extreme electromagnetic interference", the errors might not be correctable. Then, however, we are not talking about "better blackground, slighty larger space around instruments" or such stuff, but about very audible clicks and similar stuff.

But what might be the difference between FLAC and WAV, then? Why should things like a streamer or the Diretta protocol make a difference? It's definitely not in the digital domain. The buffer of the DAC will be filled with the same bytes in all the mentioned cases, without any errors.

I thought a lot about this myself as it didn't make any sense to me. But I am 100% sure that there's an easily audible difference between my DAC connected to a Pi 4 or a Holo Red—although, to repeat that, both will fill the DAC's buffer with 100% the same bytes.

I still don't know, but the best theory I heard revolves around electrical noise. Noise is unavoidable and will always be there. We are always surrounded by electromagnetic waves, produced by all our devices, by all cables, but also coming from natural sources. In fact, one goal of digital technology is to overcome the problems with noise, to be sure that what enters a cable on one side is exactly the same as what leaves it on the other side. The trick is to count a voltage as 1 when it's higher than x and as 0 when it's lower than x, and to have enough error margin (and other mechanisms like error correction algorithms) that the electrical noise can be ignored. It's normally much, much weaker than the signal itself and will only lead to small timing errors, i.e. the time when the signal crosses voltage x will be slightly different due to noise—also known as jitter.

As long as we stay in the digital domain, jitter doesn't matter at all. The receiving end must be able to decode the signal correctly, which it is even at very high amounts of jitter. Signal decoded correctly, same bytes out as bytes in, case closed.

But in a DAC, we want to convert the digital signal to analog. As I said, this is completely independent of what the host did before. The DAC reads the bytes from the buffer at its own timing. When it then converts them to analog, however, noise becomes relevant.

From this point on, my own knowledge is quite vague, so forgive me (and please correct me!) if I depict things wrongly.

All the signal levels we already talked about are differences from the ground level. The current value of the signal is a voltage on a line compared to ground voltage. Ideally, ground voltage should be perfectly constant, but it isn't. This is where noise comes in: When noise enters the device, the ground voltage will vary slightly.

No problem for digital data, it can deal with that. But now we are converting to analog. In a strongly simplified image, you can think of the analog sound wave that is created by the DAC being very slightly distorted by the constant minimal changes in ground voltage. And we can hear that if we listen closely. (More precisely, the noise in ground voltage leads to small amounts of jitter again, and this time, there’s no digital receiver that will be able to ignore the small timing errors, they will converted to analog as they are.)

Personally, I am 100% convinced that keeping electrical noise out of a DAC is beneficial to the sound. That's the only reason why a good streamer makes sense at all (at least if we're staying with USB): It is purposefully built in ways that keep noise away from the DAC, i.e. it will transmit much less noise via the USB cable to the DAC than a computer will.

So what about FLAC and WAV now? It's definitely becoming more esoteric here, but the general consensus (among people who believe in such stuff) seems to be that the amount of work the CPU and other chips have to do will influence the amount of noise they produce. This is true, of course, CPUs produce lots of noise, and as a rule of thumb, they will produce more of it the more they have to do.

The question is how much of a difference this makes for the noise that actually enters the DAC. There are different scenarios:

• Your DAC is directly connected to the computer that is decoding the FLAC. Maybe the additional load of decoding the FLAC will have an impact on noise in the DAC and thus on the sound? This depends a lot on your hardware and your local circumstances. It should have a lot more impact, however, if the computer is currently scanning the hard drive for viruses, creating a backup, or you are playing a game. Or if you are using HQPlayer on the same computer, for that matter.
• Your DAC is connected to a streamer, and you are using Roon with a RoonReady device, or HQPlayer. There should not be any impact whatsoever in this case, as Roon/HQPlayer decode the FLAC on the server and send uncompressed sound data over the network to the streamer. No direct connection to the DAC and normally not even to the streamer as there are network switches in between.
  
• Your DAC is connected to a streamer, and you are using UPnP/DLNA. In this case, the streamer gets FLAC and has to decode it. Maybe this could have an impact on the noise the streamer produces itself.

Diretta is all this driven to the extreme: The rationale behind it (as far as I understood when I had a quick look) is that less noise is produced if all equipment on the streamer is kept at a constant low load instead of the usual bursts of load when another heap of data arrives over the network. So instead of sending large data packets every now and then, small data packets are sent constantly. I haven't tried it myself. I could imagine that it might make a difference, but we're definitely far into esoteric territory there.

 

Super, @zottel, epic.

Sadly, audiophools are completely unable to follow such a clearly described data path, and will still fall into their morass of conceivably-potentionally-mightbe but-but-buts. But me no buts!

I gave your post a quick read now, and will return to give it a proper read tonight.

A quick response: I think that people tend to forget the A in DAC. Which is odd, as it's entire purpose is to output A! OK, sure, they know that, but they think of it as an entirely digital machine, whereas a vital part of it is analogue. And there has never been any real disagreement (except from some extremovists) that different analogue circuits can and do sound different.

Of course, this does not explain why two different inputs to the same DAC should sound different.

 

I use a Linux system which has on-demand CPU switching. My Linux system in Mint, but it has audio additions from KXStudio, which includes some tuning of interrupts. As I seem to recall from the time that I was researching this (these days I just use it) advice was to set the CPU to Performance, ie fast, before doing music work. Back in those days, I found that that was not necessary (at least, not for just listening) to use high speed for the CPU, but what helped to eliminate glitches was to fix the speed. It seemed to me that it was not speed, low or high, that messed things up, it was switching speed that caused problems.

Unscientific, lightly and informally tested. But perhaps something to think about for those pursuing better sound from a computer.