09-05-2020, 02:36 PM
I didn't have any hi-res ALAC-encoded files on hand, mythical or otherwise, so I made one by transcoding a 96kHz/24bit FLAC sample I did have using ffmpeg.
I see the same behavior Tim already noted when he looked with tools like mediainfo vs lsinfo. I also notice that the content of the Audio information popup differs slightly during playback:
vs
I'm of the opinion that this is down to the libavformat and libavcodec libraries, which underpin ffmpeg, and the way MPD plugins interpret their output but I haven't managed to follow the bread crumbs through the C++ thicket to where that is done.
When I look at my two files using ffprobe, which is based on the same libs, the only difference I see is that the sample_fmt value is reported as s32 for the FLAC and s32p for the ALAC, where "p" signifies planar as opposed to multiplexed channel samples. Both are reported to be 24 bits per sample in the summary line but as 0 bits_per_sample in the details farther down(?!?). (I note too from libavformat docs that there is no s24 or s24p data type, only s8/s16/s32 types.)
Here's some data cherry-picked from the rather verbose output:
vs
This comparison was just for fun since, AFAIK, MPD as we have it configured doesn't gather info on FLAC material this way.
I've exhausted myself already
The MP4 container is a monster to parse. I can't think of a fast method to extract what we want from it without using the tools already in play and I prefer not to go another round in the MPD-issues ring. The proposed solution seems to be the path of least resistance
Regards,
Kent
I see the same behavior Tim already noted when he looked with tools like mediainfo vs lsinfo. I also notice that the content of the Audio information popup differs slightly during playback:
Code:
INPUT / OUTPUT
Source: SDCARD/KAR-BeeMoved/Sample_BeeMoved_96kHz24bit.flac
Encoded at: 24 bit, 96 kHz, Stereo FLAC
Decoded to: 24 bit, 96 kHz, Stereo, 3.746 Mbps
Destination: Local
Output rate: 16 bit, 48 kHz, Stereo, 1.536 Mbps
vs
Code:
INPUT / OUTPUT
Source: SDCARD/KAR-BeeMoved/Sample_BeeMoved_96kHz24bit.m4a
Encoded at: 24 bit, 96 kHz, Stereo ALAC
Decoded to: 32 bit, 96 kHz, Stereo, 3.181 Mbps
Destination: Local
Output rate: 16 bit, 48 kHz, Stereo, 1.536 Mbps
I'm of the opinion that this is down to the libavformat and libavcodec libraries, which underpin ffmpeg, and the way MPD plugins interpret their output but I haven't managed to follow the bread crumbs through the C++ thicket to where that is done.
When I look at my two files using ffprobe, which is based on the same libs, the only difference I see is that the sample_fmt value is reported as s32 for the FLAC and s32p for the ALAC, where "p" signifies planar as opposed to multiplexed channel samples. Both are reported to be 24 bits per sample in the summary line but as 0 bits_per_sample in the details farther down(?!?). (I note too from libavformat docs that there is no s24 or s24p data type, only s8/s16/s32 types.)
Here's some data cherry-picked from the rather verbose output:
Code:
ffprobe -showstreams Sample_BeeMoved_96kHz24bit.flac
...
Stream #0:0: Audio: flac, 96000 Hz, stereo, s32 (24 bit)
...
[STREAM]
index=0
codec_name=flac
codec_long_name=FLAC (Free Lossless Audio Codec)
profile=unknown
codec_type=audio
codec_time_base=1/96000
codec_tag_string=[0][0][0][0]
codec_tag=0x0000
sample_fmt=s32
sample_rate=96000
channels=2
channel_layout=stereo
bits_per_sample=0
vs
Code:
ffprobe -showstreams Sample_BeeMoved_96kHz24bit.m4a
...
Stream #0:0(und): Audio: alac (alac / 0x63616C61), 96000 Hz, stereo, s32p (24 bit), 3181 kb/s (default)
...
[STREAM]
index=0
codec_name=alac
codec_long_name=ALAC (Apple Lossless Audio Codec)
profile=unknown
codec_type=audio
codec_time_base=1/96000
codec_tag_string=alac
codec_tag=0x63616c61
sample_fmt=s32p
sample_rate=96000
channels=2
channel_layout=stereo
bits_per_sample=0
This comparison was just for fun since, AFAIK, MPD as we have it configured doesn't gather info on FLAC material this way.
I've exhausted myself already
The MP4 container is a monster to parse. I can't think of a fast method to extract what we want from it without using the tools already in play and I prefer not to go another round in the MPD-issues ring. The proposed solution seems to be the path of least resistance
Regards,
Kent