Which DACs will play and display the correct bit rate and frequency of non resampled 320 CBR files?

[Shadrach1]

Linux Mate.
Deadbeef music player.
Topping D10s DAC.

I’ve often wondered how people make the “can you hear a difference between 320 CBR or lower and 16 bit 44.1” comparisons. The Topping D10s with Deadbeef and Linux Mate locks up and displays 44.1 but doesn’t play the file. Is it possible that many are in fact listening to a 320 CBR file that has been resampled to 44.1 but are not aware of this? If so, I suspect many of the reported DBT tests results are invalid.

Some operating systems and music players will automatically resample.

In the spec sheet of most dacs I’ve looked at the lowest native bit depth and frequency they will play is 16/44.1. I’ve yet to find one that states it will play 320CBR or VBR files.

This is strange given it is generally accepted that most people can’t tell the difference between 320 CBR and Redbook so 320 CBR files would be the preferred file type for many given it’s smaller size.

So, the first point. It would be better imo if dacs displayed nothing if they cant play the file bit rate and frequency, or a display indicating this.

I didn’t have this problem with the HRT Music Streamer Dac. I assume it could either cope with the file type, or some resampling takes place either in the music player or the OS audio stack without me making any adjustments.

If I set Deadbeef music player to Direct Hardware Device With No Conversions the D10s won’t play the 320 CBR file. What’s more, if I replace the 320 file with a Redbook file in the music player I have to close Deadbeef, reset the playback options before the Redbook file will play.

If I load a 24/96 file and attempt to play it the Topping D10s shows 44.1 until I stop the track and restart it again.

Why can’t it make the switch on the first track?

This is the second Topping Dac I’ve found to be a problem in my system, the first being a DX3pro.

 

[Zek]

If I set Deadbeef music player to Direct Hardware Device With No Conversions the D10s won’t play the 320 CBR file.

It's normal, because DAC accepts min 16/44,1 files.

If I load a 24/96 file and attempt to play it the Topping D10s shows 44.1 until I stop the track and restart it again.

It's not problem of the DAC, but your audio player settings.

 

[voodooless]

DAC's don't play compressed audio streams unless they are also a streamer. Some software does the decompression and sends whatever that results in to the DAC. So they don't play CBR or VBR files. in fact, they don't play any "files". They just play a bitstream of PCM audio sent to it via the software controlling it (or DSD in some cases).

Your "HRT Music Streamer Dac", is a streamer, so it actually has the software to decompress the files, and thus also knows the compressed bitrate.

As for Deadbeef, I have no idea. Most decent music players handle sample and bitrate changes without issues. I doubt it's the DAC at fault here.

 

[Apesbrain]

Try a different output option in DeaDBeeF. Or, try a different music player/audio stack:

https://www.makeuseof.com/best-linux-music-player-apps/

Adding sound to MATE

When I originally wrote up how to install MATE I did not include the packages you need to enable audio play back (my excuse is that I was aiming to install as little as possible).

mike632t.wordpress.com

Switching to Pulse Audio on MATE Desktop

I’m a rather conservative type and I’ve been using ALSA as my audio back-end for longer then I can remember.

mike632t.wordpress.com

 

[Shadrach1]

DAC's don't play compressed audio streams unless they are also a streamer. Some software does the decompression and sends whatever that results in to the DAC. So they don't play CBR or VBR files. in fact, they don't play any "files". They just play a bitstream of PCM audio sent to it via the software controlling it (or DSD in some cases).

Your "HRT Music Streamer Dac", is a streamer, so it actually has the software to decompress the files, and thus also knows the compressed bitrate.

As for Deadbeef, I have no idea. Most decent music players handle sample and bitrate changes without issues. I doubt it's the DAC at fault here.

Yeah, that's helpful. I hadn't taken the difference between a streamer and dac into account.
So how do people make a valid comparison between 320 and redbook if the software is using a decompression algorithm?
I may be missing some vital point here.

 

[voodooless]

So how do people make a valid comparison between 320 and redbook if the software is using a decompression algorithm?

Just play the files... they both yield 16/44.1, so the DAC doesn't need to switch. You can also pre-decompress the files so both are WAV or FLAC already.

Preferably one used a tool like Foobar ABX to do a blind comparison, but I don't think it's available for Linux. But there is: https://manpages.ubuntu.com/manpages/impish/man1/abx.1.html for instance.

 

[Shadrach1]

Try a different output option in DeaDBeeF. Or, try a different music player/audio stack:

https://www.makeuseof.com/best-linux-music-player-apps/

Adding sound to MATE

When I originally wrote up how to install MATE I did not include the packages you need to enable audio play back (my excuse is that I was aiming to install as little as possible).

mike632t.wordpress.com

Switching to Pulse Audio on MATE Desktop

I’m a rather conservative type and I’ve been using ALSA as my audio back-end for longer then I can remember.

mike632t.wordpress.com

One of the advantages I've found wiith Deadbeef is it is easy to set up to play files at their native bit depth and frequency.
I don't really want to change the player or the OS.
Thanks for the links.

 

[staticV3]

So how do people make a valid comparison between 320 and redbook if the software is using a decompression algorithm?

Why do you think decompression would invalidate a comparison?

 

[Shadrach1]

Just play the files... they both yield 16/44.1, so the DAC doesn't need to switch. You can also pre-decompress the files so both are WAV or FLAC already.

Preferably one used a tool like Foobar ABX to do a blind comparison, but I don't think it's available for Linux. But there is: https://manpages.ubuntu.com/manpages/impish/man1/abx.1.html for instance.

So the decompression algorithm doesn't alter the sound of the sample in any way?
I was under the impression that any manipulation will alter the output be it audible or not.
Yeah I've used the Foobar ABX in the past when I still had a windows OS.

 

[voodooless]

So the decompression algorithm doesn't alter the sound of the sample in any way?
I was under the impression that any manipulation will alter the output be it audible or not.

You must decompress the data to send them to the DAC. You can do that on the fly, or do that before playback. It doesn't matter. By definition the type of compression you are using is lossy, so the sample that go into the compressor will never come out of the decompressor exactly the same.

 

[Shadrach1]

Why do you think decompression would invalidate a comparison?

The same reason that I believe compression may alter the sound. Not all the algorithms yield perfect results.

 

[staticV3]

Lossy compression will irreversibly alter the information.
Lossless compression will reversibly alter the information.
Decompression will always reproduce the exact contents of a file.

 

[Shadrach1]

You must decompress the data to send them to the DAC. You can do that on the fly, or do that before playback. It doesn't matter. By definition the type of compression you are using is lossy, so the sample that go into the compressor will never come out of the decompressor exactly the same.

This is what I thought.

 

[staticV3]

The same way I can convert a PNG to JPEG, then open up both in Photoshop and flip between them to check whether I can perceive the damage that's been done to the PNG, I can convert a WAV to MP3 and then A/B them check whether I can perceive the damage.

In both cases, the output device (DAC/monitor) has no understanding of file formats or compression. It only understands raw data, so the PC has to decompress everything before sending it out.

 

[Shadrach1]

Lossy compression will irreversibly alter the information.
Lossless compression will reversibly alter the information.
Decompression will always reproduce the exact contents of a file.

I'll look into this further because I'm not sure it's true.

 

[freemansteve]

One of the advantages I've found wiith Deadbeef is it is easy to set up to play files at their native bit depth and frequency.

Isn't that a feature of all the popular media players, like VLC, Foobar2K?

They just decompress and/or decode (where required) and throw the data at the DAC as PCM, unless a sound mixer is in the way....

Since the mixer has to feed the DAC from system sounds, music, web playback and other sound sources, where there may be different bit depths and sample rates, with a unified PCM profile, it has to convert on the fly, to 'homogenize' those various sound sources. This means some sound sources are up-converted and some-down-converted. But AFAIK, that's not the media player's fault. If you look up EqualizerAPO on this site there are some better explanations of what happens on PCs (E-APO is for windows , but the principle is the same, I would guess, on other OS's).

 

[dadregga]

I'll look into this further because I'm not sure it's true.

Feel free - that's how digital compression works. Reversible encoding and non-reversible encoding. Lotta math out there.

Is it possible that many are in fact listening to a 320 CBR file that has been resampled to 44.1 but are not aware of this?

No, it is not possible. MP3 encoding irrevocably removes information. Resampling back up to 44.1 at a later point can't add that information back in, because the thing doing the resampling doesn't know about it. It's been marked as "44.1" and will play back as that PCM format, but the data within is the same.

Think JPEG. If you take a picture of something as an 80x80 pixel JPEG , then blow it up to 1000x1000, blowing it up doesn't magically reintroduce detail or data that wasn't there to begin with.


(unless you use math and ML models to "guess" at what should have been there and reinsert it, as a lot of cool image enhancement tech does nowadays - DACs and audio codecs and PCM resampling most definitely do not do that, however)

 

[threni]

I'll look into this further because I'm not sure it's true.

You mean "I'm not currently at the point where I properly understand what's happening here". The post you replied to is an entirely correct, succinct statement of fact. You can't get back what you've already lost, but you can always get back that inferior version of the music if your bandwidth or disk space require it, or if you lack sufficiently accurate hearing. The lossy file doesn't get any worse.

 

[Vincent Kars]

I'll look into this further because I'm not sure it's true.

An obvious first is studying computer audio file formats.
Lets assume we are ripping a CD.
A CD contains 2 channel PCM audio with sample of 16 bit and a sample rate of 44.1 kHz.
We can rip to lossless formats like WAV or AIFF.
We can also rip to a lossless compressed format like FLAC, ALAC, etc.
This saves space but you still have large file sizes.
As in the 90’s HD was very expensive, they invented lossy compression and MP3 is the mother of lossy compression. You throw out information, all that is masked first, then you start to roll of the treble, Huffman encoding, etc.
Obvious, what you throw out is lost forever.

https://www.thewelltemperedcomputer.com/Intro/SQ/audio_formats.html



What happens on playback?
If you look at the back of a DAC you probably see inputs like Toslink (SPDIF over optical), coax (SPDIF over electrical), USB and maybe AES/EBU.
What you don’t see is an input for FLAC, an input for 320 VBR, etc. Luckily as there is a plethora of audio file formats out there.
On playback, you choose a file e.g. a 256 VBR MP3. The media player invokes the appropriate codec e.g. LAME and this codec will decode the MP3 into PCM so we have our 16 bit / 44.1 PCM and this will be send to the DAC using one of its protocols.

What happens if you have different sample rates?

If you do nothing, all files will be played at the rate as set in de audio panel.
If you want automatic sample rate switching, you need a driver bypassing the audio stack of the OS.
In Win this is WASAPI/Exclusive, on a Mac it is hog mode, on Linux it is probably using hw or plughw in ALSA but my Linux knowledge is a bit feeble.

So if your DAC don’t switch it is very likely not a problem with the DAC but with the system configuration.

 

[freemansteve]

If you have a play with something like Audacity, you can do all sorts of pointless things to fool people (or DAC) that say, what was a 256kbs MP3 is now a 24/96 FLAC, but there are tools that can detect that sort of fakery, like "Lossless Audio Checker" and so on....