Bitconversion Question

[EdWoow]

Hello,

my mpd.log, running mpd on FreeBSD, I see following entries I would like to understand:

Oct 27 14:41 : decoder: audio_format=44100:24:2, seekable=true
Oct 27 14:41 : output: opened "nuprime IDA-8" (oss) audio_format=44100:32:2
Oct 27 14:41 : output: converting in=44100:24:2 -> f=44100:16:2 -> out=44100:32:2

Now I am wondering, what does f= stand for and why are we apparently converting a 24 Bit file first to 16Bit to then again convert it to 32BBit? Now latter one is required by the DAC and configured by me therefore, but why this step in the middle?

[MaxKellermann]

f= is the format required by the filter. To know which one, I'd need to see your configuration and know your MPD version, but if I had to guess, I'd say you have enabled volume normalization. That plugin is only implemented for 16 bit, and this is the part of the source code which enforces it:

MPD/src/filter/plugins/NormalizeFilterPlugin.cxx

Lines 66 to 69 in 72ba98c

	PreparedNormalizeFilter::Open(AudioFormat &audio_format)
	{
	audio_format.format = SampleFormat::S16;

It is true that this is an unnecessary loss of quality, and the plugin could as well be implemented for 24 bit, but nobody has done it. This plugin is mostly unchanged (minus code refactoring) since before I joined the MPD project (i.e. 2008), and at the time, MPD did not support more than 16 bit.

[EdWoow]

Thanks very much for your fast reply. I am not in front of the system right but I do know, I do have normalisation enabled. f for filter makes of course absolute sense. I will disable it for verification later on and report back.

Meanwhile, the loss in quality is not an issue for me, as not audible for my ears, I have just been curious what is going on. And it's filter processing. An ordinary audio chain in the end, it just did not think about this

Thanks again.

[MaxKellermann]

The loss of quality is only theoretical. It exists, but whether it's audible is of course questionable. There are people who claim to hear the difference between 44.1kHz/16bit and 96kHz/24bit (which nobody ever proved), but science/human biology tells a different story. Science says that 44.1kHz/16bit is enough for the human ear. More than that is only useful for audio processing (in studio when a song is produced), if a long chain of audio transformations loses quality in each step, so that in the end, you still have at least 16 bits left.

[GK-774]

"Science says that 44.1kHz/16bit is enough for the human ear." Well, no. Science does not say that ;-)

[EdWoow]

Thanks again. Indeed, the whole hifi business seems to be a rewarding object of study for the power of [auto]suggestion.

So I've removed the normalisation, I still have a filterpart in the chain, but it does not do anything any more, so no more conversion. Your guess was spot on. Interestingly enough however, the input file is always being treated as 24 Bit wide, even though this time I've explicitly used one 16Bit and one 32Bit mp3:

16Bit mp3:
Oct 28 22:30 : decoder: audio_format=48000:24:2, seekable=true
Oct 28 22:30 : output: opened "nuprime IDA-8" (oss) audio_format=48000:32:2
Oct 28 22:30 : output: converting in=48000:24:2 -> f=48000:24:2 -> out=48000:32:2

A 32Bit mp3:
Oct 28 22:34 : decoder: audio_format=44100:24:2, seekable=true
Oct 28 22:34 : output: opened "nuprime IDA-8" (oss) audio_format=44100:32:2
Oct 28 22:34 : output: converting in=44100:24:2 -> f=44100:24:2 -> out=44100:32:2

But maybe this is due to the use of the libmad decoder, as with ogg I do get less output - and not even a hint of a filter chain:

Oct 28 22:50 : playlist: play 40:"testfiles/compressed/f32le_192.ogg"
Oct 28 22:50 : decoder_thread: probing plugin vorbis
Oct 28 22:50 : decoder: audio_format=192000:f:2, seekable=true

Oct 28 22:50 : playlist: queue song 41:"testfiles/compressed/s16le_192.ogg"
Oct 28 22:51 : playlist: play 41:"testfiles/compressed/s16le_192.ogg"
Oct 28 22:51 : decoder_thread: probing plugin vorbis
Oct 28 22:51 : decoder: audio_format=192000:f:2, seekable=true

This is still a rather minimal mpd install even without ffmpeg, hence I cannot even play .wav files, but that is ok for now.

And again, this does in no way hamper my enjoyment with using mpd, just trying to gain some understanding. And I will revert to normalisation.

[MaxKellermann]

The f= is always there, even if the filter chain is empty. In this case, there's no change in audio format due to the filter, maybe because there's no filter. Only the output changes the audio format to 32 bit, maybe because your sound chip can't do 24 bit, so MPD chooses the next best format.
The "mad" decoder emits 24 bit samples, because libmad gives us 28 bit, so MPD discards the lower 4 bit and leaves 24 bit around. (There's no such thing as "bit depth" in most lossy codecs, so what codec implementations emit is rather arbitrary.)
The "vorbis" decoder emits 32 bit floating point samples, because that's the canonical format given to us by libvorbis. Had you compiled with the "Tremor" (=fixed-point) variant of libvorbis, you'd see 16 bit, because that's what Tremor gives us.

[EdWoow]

Indeed, I replaced mad with mpg123 and the output now is 16BIt. Probably because that is, what mpg123 put out.

And I fell for the logging. The convert line, like f.e.:

output: converting in=192000:f:2 -> f=192000:f:2 -> out=192000:32:2

only seems to appear in the log, if a file has a different sampling rate and/or format then the previous one. Or maybe after the device (soundcard) had been closed. I did not notice this before. So as you've mentioned, also ogg or flac display the filter, meeting above conditions.

long form (with convert):
Oct 29 11:27 : playlist: play 3:"testfiles/compressed/s16le_notag.mp3"
Oct 29 11:27 : decoder_thread: probing plugin mpg123
Oct 29 11:27 : decoder: audio_format=44100:16:2, seekable=true
Oct 29 11:27 : output: opened "nuprime IDA-8" (oss) audio_format=44100:32:2
Oct 29 11:27 : output: converting in=44100:16:2 -> f=44100:16:2 -> out=44100:32:2

Short form (without convert)
Oct 29 11:27 : playlist: queue song 4:"testfiles/compressed/s32le_441.mp3"
Oct 29 11:27 : playlist: play 4:"testfiles/compressed/s32le_441.mp3"
Oct 29 11:27 : decoder_thread: probing plugin mpg123
Oct 29 11:27 : decoder: audio_format=44100:16:2, seekable=true

Thanks again for your time and support. Helped a great deal in understanding. Stay safe

[MaxKellermann]

Both resampler libraries which are used by MPD (libsoxr and libsamplerate) require floating point input. So, as soon as MPD resamples, it needs to convert to float. After resampling, it will not automatically convert back to 16 bit, even if the input was 16 bit, because that would be another source of quality loss, which MPD attempts to avoid. Since your output doesn't support float output directly, MPD chooses the next best sample format, which is 32 bit.