Why Does Codec Information Display Incorrect "Bits Per Sample"

[joshzeldin]

When I go to Tools -> Codec Information, and look at the bits per sample of my song, for example, it pretty much always says 32 bits per sample, even though my songs are usually only 16 or 25 bits.....why is it displaying the wrong information?

[Rémi Denis-Courmont]

VLC always gives the correct actual bit size. For the decoded samples. Most decoders output single precision samples, that's 32 bits per sample. 8, 16 and 64 can also occur.

So strictly speaking your question doesn't make sense. But the non-literal answer is that you're expecting something else which is not bits per decoded samples, such as the bit exact precision of a lossless audio stream.

[Lotesdelere]

What people expect to see is the information extracted from the file. That was the case with VLC version 2.x but it was changed for an unknown reason in VLC 3.x. There were already discussions about this topic:
https://forum.videolan.org/viewtopic.php?f=7&t=153646
https://forum.videolan.org/viewtopic.php?f=14&t=156969

Some other players rely on the MediaInfo libraries for providing such info but VLC is doing it on its own.
The end user wants to know how the file which is currently playing has been encoded, he doesn't care about the decoded samples.
Especially when VLC says that my 16-bit FLAC file is being played at 32 bits per sample:

Code: Select all

Audio Format : FLAC Channel layout : L R Sampling rate : 44.1 kHz Bit depth : 16 bits Compression mode : Lossless Replay gain : -3.11 dB

How come and why VLC is doing that ? What is the purpose ?
The extra 16 bits per sample are just useless since they must be filled with zeroes, it doesn't bring any precision but just padding with empty space.

[Rémi Denis-Courmont]

So your argument is that we should not produce a piece of information that we do have because you want another piece of information that we don't have. Well I disagree and IMO your argument is both silly and selfish.

We're not going to remove a valid truthful piece of metadata just because a few people insist that they don't want it. That's not how this project works, sorry. If you don't want to see decoded sample size, just ignore it.

And if you want something else shown ADDITIONALLY patch welcome.

And by the way, those "extra 16 bits" do bring extra precision, unless you're in the 0.01% of users passing audio straight to DAC with no processing at all, not even volume adjustment.

[Lotesdelere]

We are not asking to remove anything but to add back the information from the file which was in VLC v2.x. This information is still present in the log:

Code: Select all

wav debug: format: 0x0001, fourcc: araw, channels: 2, freq: 44100 Hz, bitrate: 172Ko/s, blockalign: 4, bits/samples: 16, extra size: 0 araw debug: samplerate:44100Hz channels:2 bits/sample:16

So we could have both informations: File bits per sample = 16 and Decoded bits per sample = 32


What is not clear is the technical reason why VLC is forcing this upsampling:

Code: Select all

main debug: conversion: 's16l'->'f32l' 44100 Hz->44100 Hz Stereo->Stereo audio_format debug: s16l->f32l, bits per sample: 16->32

Simple example:
I take a WAV sample file which is a rip of an audio CD, so it's 44.1 kHz 16 bits.
I upsample it to 32 bits float, like VLC does, then I do a bit comparison of the decoded audio output:

Code: Select all

All tracks decoded fine, no differences found. Comparing: "D:\Temp\Samples\Owner.wav" "D:\Temp\Samples\Owner-32float.wav" No differences in decoded data found.

No differences at all, no "improvement", no loss, just a bigger file.
Audio editors like Audacity have a good technical reason for doing such upsampling: to give room to apply effects and various amplitude variations while avoiding clipping.
But for a media player output it just adds padding filled with zeroes because in any case it won't create audio data that doesn't exist in the first place.

[Rémi Denis-Courmont]

VLC is converting PCM to float because the output and/or filters require it. It was already doing that in 0.9. Nothing to see there.

[Lotesdelere]

Still, we could still have both bits per sample informations being displayed: one for the file and the other one for the output:
File bits per sample = 16
Decoded bits per sample = 32

[Rémi Denis-Courmont]

It already says PCM S16 LE in that case. That's much more precise than "16-bit".

[Lotesdelere]

As we can see in the screenshot of post #3, what is actually displayed is: "Bits per sample: 32"

[Rémi Denis-Courmont]

So when I rebutted your argument in the FLAC case, you switched to PCM. Then when I destroyed that fallacious argument too, you came back to FLAC. Moving the goal post much?

I'm going to assume that you have zero arguments, and stick to my rebuttal above then. VLC says codex FLAC (correctly) and decoded bit size 32 bits (also correctly). I'm not going to remove accurate infos from the tab just because two people on the forum feel offended by them. That would be ridiculous.

N.B.: as noted in previous threads, this has been clarified to DECODED bit size in 4.0. We can't change the wording in 3.0 due to localisation workflow for stable releases.

[Lotesdelere]

As I already said in this post:
https://forum.videolan.org/viewtopic.ph ... 18#p540118

We are not asking to remove anything but to bring back the feature from VLC v2.x which was displaying the bits per sample information from the file currently playing. Information which is still present in the log.

So we could have both informations being displayed, for example:
File bits per sample = 16
and
Decoded bits per sample = 32

[Rémi Denis-Courmont]

As I said several times, if somebody wants some info added, they are welcome to propose a patch to do so.

[v81]

Is it not resonable that one wants information on what resolution the source is?
It's a fairly resonable indication of quality that i can not readily find anywhere else intuitive.

If the res is padded to 32bits, and many of those bits are pointless then what is the value of showing 32 at all?

Add to this it is odd behavior vs the v2.x precedent where the source depth was shown, leaves one incredulous as to why this pre-existing useful function has disappeared only to be replaced with something that is now effectively meaningless.

Remi, if you want to see what the codec is actually doing, then by all means show the workings of the codec.
I question what value that information is if it's just always going to show a value of 32, but you might have a valid reason... fine, but we had people wanting to know the resolution of their file and VLC 2.x showed this, and now it's nowhere to be seen.
Why not both as proposed above?

Again, as i said there was a precedent that showed good and useful info.

From where i sit having codec info show 32 all the time, and never changing is like having a green traffic light that never changes ever 100 metres on a freeway.

This issue has chapped my ass for years and I'm sure there are many others that have just put up with it, but what is clear is that we're not alone.

I'd have a crack at submitting a patch, but not all of us are rocket surgeons.
I have signed up to the GitLab to submit this but am still awaiting account activation from the admins end.

[Rémi Denis-Courmont]

Yes, insofar as this is a well-defined notion. Unfortunately, it is not, or rather, it depends on the codec if it is. Patches are welcome anyway.

[Lotesdelere]

VLC 2.x showed this, and now it's nowhere to be seen.

As I said in this post:
https://forum.videolan.org/viewtopic.ph ... 18#p540118
the information is available in the messages log, which means the player is well aware about this information but it doesn't display it.

Patches are welcome anyway.

The "patch" solution already exists in VLC 2.x.

[Rémi Denis-Courmont]

No MR, no patch.

[v81]

No MR, no patch.

What exactly is an MR?

[v81]

Well sadly after weeks pending my gitlab signup for VLC was denied... or maybe timed out.

I still think this is an issue that needs to be corrected.
And with fresh eyes i'll point out wht VLC itself is claiming...
"Information about what your media stream is made of"
Well i know it isn't made of 32 bit samples, so still we deserve to have this corrected.

[Lotesdelere]

Well sadly after weeks pending my gitlab signup for VLC was denied... or maybe timed out.

You can send an email to videolan (at) videolan.org about the Gitlab account issue.

Or join the IRC channel:

Server: irc.libera.chat
Channel: #videolan