Decoder Outputs

General Discussion about MPD – anything that doesn't fit in the other MPD forums.
Post Reply
Tappit
Posts: 8
Joined: August 3rd, 2018, 8:03 pm

Decoder Outputs

Post by Tappit » August 3rd, 2018, 9:23 pm

Like other players, MPD uses decoders for mp3 and aac which return a 24 or 32 bit output. This means that anyone needing a 16 bit output has to re-quantize or truncate the data.

Is there any way to make the decoders used by MPD resolve non-PCM sources to 16 bit?

max
Forum team
Posts: 735
Joined: January 15th, 2013, 3:43 pm

Re: Decoder Outputs

Post by max » August 4th, 2018, 6:24 pm

Are you aware that lossy codecs like MP3 are agnostic to the bit depth? Some codec implementations return just 16 bits, others like libmad generate 28 bit, but these are rather arbitrary choices.
What is it you really want to do here? What bothers you?

Tappit
Posts: 8
Joined: August 3rd, 2018, 8:03 pm

Re: Decoder Outputs

Post by Tappit » August 5th, 2018, 2:58 pm

The answer is yes. Bit depth has no relevance to the compressed file, but it does to the DAC or filter which the decoded output is fed to. Once a 16 bit source is encoded, there is no reason why it should not be decoded to 32 bit, and that seems to be becoming the norm now.

I use old filter chips and multibit converters, because they sound better to me, and the filter chip needs to know what bit depth it is dealing with. Most of my source files are 16 bit flac, so that is what I configure for, but radio streams are mainly mp3 or aac, and I do have a few mp3 files. I have tried comparing conversion vs truncation using a non-MPD player and, to be honest, truncation sounded better. A better solution would be to configure the codecs used by MPD to give a 16 bit output, or change to codecs which already do so.

Can either change be made by an average user?

max
Forum team
Posts: 735
Joined: January 15th, 2013, 3:43 pm

Re: Decoder Outputs

Post by max » August 6th, 2018, 8:33 am

Can you explain the difference between conversion and truncation? And what is it you believe MPD does? What kind of change do you want to make to MPD?

Tappit
Posts: 8
Joined: August 3rd, 2018, 8:03 pm

Re: Decoder Outputs

Post by Tappit » August 6th, 2018, 11:56 am

Truncation simply discards the unwanted bits, which leaves an offset. I am no expert but, so far as I know, conversion software properly dithers and rounds the sample to the required depth. Whether the difference is audible at these levels, I don't know, but I would prefer not to have to use either method.

For mp3, I think MPD uses a decoder which outputs 28 bits, and passes on 24 bits to the output. If not, I will be pleased to be put right. As most mp3 files will have started out as 16 bit PCM, it would be interesting to know the thinking behind a decoder which returns 28 bit PCM as the default.

I am asking whether MPD could easily be made to use different codecs which would return 16 bit outputs, or whether the codecs it does use can be configured by an average MPD user to give 16 bit outputs. This would eliminate the need to apply any conversion or truncation. I am aware that MPD itself is bit perfect, and it uses other software to do any processing.

max
Forum team
Posts: 735
Joined: January 15th, 2013, 3:43 pm

Re: Decoder Outputs

Post by max » August 6th, 2018, 12:18 pm

You can't "not use either method", and you can't "eliminate the need to apply any conversion or truncation".

No MP3 codec implementation uses 16 bits internally. The final step in each codec implementation is to convert internal sample representation (usually floating point) to the external sample representation (usually 16 bit for MP3, only libmad uses 28 bit). Internally, most implementations use floating point, because decoding MP3 (and other codecs such as Vorbis) involves lots of floating point math.

I could now easily tell you to use the "mpg123" plugin instead of the "mad" plugin, because libmpg123 emits 16 bit samples instead of libmad's 28, which allegedly avoids the conversion - but I would fool you that way, because internally, libmpg123 uses floating point, and in the resulting 16 bits travelling from libmpg123 to MPD, the unnecessary precision was already discarded (without dithering).

Don't fool yourself.

Tappit
Posts: 8
Joined: August 3rd, 2018, 8:03 pm

Re: Decoder Outputs

Post by Tappit » August 6th, 2018, 5:18 pm

OK Max, thanks.

If people who are clever enough to build an mp3 codec do not think it worthwhile to properly dither the output, then I will accept that truncation is OK at these levels.

I am not sure that your obvious contempt for me and my question is justified, though.

max
Forum team
Posts: 735
Joined: January 15th, 2013, 3:43 pm

Re: Decoder Outputs

Post by max » August 6th, 2018, 6:46 pm

You have a choice. You can use the "mpg123" decoder which truncates to 16 bit, or you can use the "libmad" decoder where MPD will dither the 28 bits to 16 bit. If you believe one sounds better than the other, use that.

There was no contempt. I just had a feeling you were trapped into fallacies, and I tried to find out what those were, and disproved them. There's so much superstition and hearsay about what improves or degrades quality. Your point sounded reasonable, until one looks what really happens behind the scenes.

Tappit
Posts: 8
Joined: August 3rd, 2018, 8:03 pm

Re: Decoder Outputs

Post by Tappit » August 7th, 2018, 10:06 am

You now say that MPD dithers libmad output to 16 bit. All the versions of MPD I have tried output 24 bits from mp3 and 32 bits from aac. Before you ask, yes, I have counted them.

My original post was not making a point, I was asking a question. The valid answers were "yes: and this is how you do it", or "no: and this is why".

max
Forum team
Posts: 735
Joined: January 15th, 2013, 3:43 pm

Re: Decoder Outputs

Post by max » August 7th, 2018, 2:34 pm

If you see 24 bit playback, then your output is not configured to 16 bit. But you started this thread with "needing a 16 bit output", so I assumed you had asked MPD to do 16 bit, but obviously you did not. So do you want everything 16 bit, or do you want MPD to choose automatically choose the best playback format? Whatever you decide (for whatever reason) - tell MPD about it.

Tappit
Posts: 8
Joined: August 3rd, 2018, 8:03 pm

Re: Decoder Outputs

Post by Tappit » August 7th, 2018, 3:56 pm

max,

I have been looking at the decoder websites, and it looks as if mpg123 will do anything, depending on build and configuration. You say the MPD version uses floating point and truncates to 16 bit, so I accept that, as I am sure you asked whoever did the build.

But, you also imply that libmad uses floating point math and outputs 28 bits. According to the web page it uses fixed point and gives only a 24 bit output, which is what I see.

MPD is bit perfect, as it should be. If it is fed 24 bits from a source it outputs 24 bits. If it is fed 16 bits, it will output 16 bits. If it is fed 32 bits it will output 32 bits. I was asking about decoder outputs, which are sources.

max
Forum team
Posts: 735
Joined: January 15th, 2013, 3:43 pm

Re: Decoder Outputs

Post by max » August 7th, 2018, 8:10 pm

There is no "MPD version" of libmpg123. MPD doesn't build libmpg123. You do, or your distribution does, or whoever, but that is out of MPD's scope.
You can ask libmpg123 to return floating point samples and skip libmpg123's internal truncation; the MPD decoder plugin doesn't do that, but it might be a good idea. This moves the truncation/dithering out of libmpg123 and into MPD.

The libmad website is slightly wrong. Look at the source code: https://github.com/markjeee/libmad/blob ... h#L94-L117
libmad clearly provides 28 bit samples, not 24 bit. Usually, applications throw away those 4 extra bits because no DAC can play 28 bit audio.

With lossy codecs, there is, by definition, no such thing as "bit-perfect". MPD tries hard to avoid dropping quality after those bits left the codec implementation, but the codec itself isn't bit-perfect.
But that wasn't the point - you explicitly asked to have 16 bit playback, which drops some quality. For reasons only you know.

Tappit
Posts: 8
Joined: August 3rd, 2018, 8:03 pm

Re: Decoder Outputs

Post by Tappit » August 8th, 2018, 9:03 am

OK, whatever.

Post Reply