Apple lossless (M4A) shows as 32 bit on 24 bit encoding

[Miss Sissy Princess]

I have a number of albums encoded as 24/96K and 24/192K Apple Lossless in .M4A files.  moOde puts sample rate "badges" of 32/96 and 32/192 on 24/96 and 24/192 albums respectively.  Examples are shown in the attached image.  

I opened one of the 24/192 songs (The Sound of Silence.m4a) with the Colibri music player which correctly reported that it was 24/192.
The Vox music player also showed it as 24/192.  

To be fair, MPlayerX's media inspector showed it as 32/192.

So which is correct?  Apple's own Music app on the Mac reports that the file is:

kind    Apple Lossless audio file
sample size: 24 bit
sample rate: 192.000 kHz

It's Apple's own CODEC, so that's the tie-breaker.

[Tim Curtis]

The sample rate data displayed in the Library for albums comes from MPD's "format" tag. It's populated by MPD during its database scan. The codec or utility that MPD uses to decode Apple lossless is reporting 32 bit. Could be a bug.

Feel free to PM me a download link to a zip of one of the files and I'll analyze it.

[Miss Sissy Princess]

Thanks, Tim. PM sent.

[TheOldPresbyope]

In the MPD User's Manual under Audio Format Settings, one finds this sentence

The following values are valid for bits: 8 (signed 8 bit integer samples), 16, 24 (signed 24 bit integer samples padded to 32 bit), 32 (signed 32 bit integer samples), f (32 bit floating point, -1.0 to 1.0), dsd means DSD (Direct Stream Digital).

I grant that this is in a narrative about the output format setting, but I wonder if somewhere in the chain, the 24-bit ALAC content is getting padded before ffmpeg tests it. 

Regards,
Kent

[Miss Sissy Princess]

In the MPD User's Manual under Audio Format Settings, one finds this sentence

The following values are valid for bits: 8 (signed 8 bit integer samples), 16, 24 (signed 24 bit integer samples padded to 32 bit), 32 (signed 32 bit integer samples), f (32 bit floating point, -1.0 to 1.0), dsd means DSD (Direct Stream Digital).

I grant that this is in a narrative about the output format setting, but I wonder if somewhere in the chain, the 24-bit ALAC content is getting padded before ffmpeg tests it. 

Regards,
Kent

Interesting find.  Thanks.  

To be clear, the badges show up with nothing playing -- on each album (art) displayed in the Window.  I checked the sample that I provided to Tim for his analysis and it's properly shown as 24/192 in Music (Apple's own player), Colibri, Decibel, foobar2000, and Vox.  It also shows as 24/192 in Invisor Lite.  (Note that the preceeding are all Mac Apps -- at least in the forms that I tried them).

[Tim Curtis]

I'm not sure what MPD is using to extract the sample rate and bit depth but the test file that @fmaxwell provided shows the following:

Mediainfo. This is used in the Playback screen and in Audio info. It's slow but since it's only used on-demand for a single file its not an issue.

Code:

pi@rp2:~ $ mediainfo --Inform="Audio;file:///var/www/mediainfo.tpl" /media/VFAT128/Test_mixed/Example24_192/01\ The\ Sound\ of\ Silence.m4a
24
192000
2
ALAC
5224592

MPD lsinfo. The Format element will already be in the MPD database when the Library is generated and so using this element is ultra fast as compared to shelling out and executing mediainfo for each file which totally kills the performance of the Library.

Code:

pi@rp2:~ $ telnet localhost 6600
Trying ::1...
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
OK MPD 0.21.11
lsinfo "USB/VFAT128/Test_mixed/Example24_192/01\ The\ Sound\ of\ Silence.m4a"
file: USB/VFAT128/Test_mixed/Example24_192/01 The Sound of Silence.m4a
Last-Modified: 2020-09-04T08:56:20Z
Format: 192000:32:2
Time: 187
duration: 187.451
Artist: Simon and Garfunkel
Album: The Graduate (24/192kHz)
Title: The Sound of Silence
Track: 1
Genre: Folk Rock
Date: 2014
OK

The bottom line is that for ALAC encoded m4a files getting the actual bit depth would require using mediainfo which if there were a lot of these files in a collection would totally bog down the Library.

I'd convert the files to FLAC using XLD. It's a lossless process and once in FLAC format the MPD Format element should contain the correct bit depth.

[Miss Sissy Princess]

I'd convert the files to FLAC using XLD. It's a lossless process and once in FLAC format the MPD Format element should contain the correct bit depth.

Thanks for the suggestion, but I've got thousands of tracks in ALAC, many of which were converted from FLAC to ALAC using XLD.  All of them work great in Apple Music and they transfer to my iPhone, iPad, and iPods (which I use as music sources in my vehicles).  If I convert them to FLAC, I can't listen to them on my iPhone, on my iPad, or in my vehicles.

The music files in my moOode library are transferred from my "iTunes" library folder using rsync.  I maintain all of the tags and album artwork under Music. 

I really do appreciate all of your effort on this, Tim, but I'll live with the incorrect bit depth being displayed in moOode.  That's a heck of a lot easier than trying to maintain two separate music libraries of 7800+ tracks (and growing) -- one for the Apple devices and one for moOode.  Maybe at some point MPD will be fixed so that it reports the sample depth correctly.

[Miss Sissy Princess]

The bottom line is that for ALAC encoded m4a files getting the actual bit depth would require using mediainfo which if there were a lot of these files in a collection would totally bog down the Library.

I had a couple more thoughts on this: 

1.  If MPD decided an album had 32 bit samples, just one call to mediainfo for one track in that album could confirm or refute that.  
2.  Actual recordings with 32 bit sample depth are really, really rare and will remain so.  If you had moOode assume that every "32 bit" track was really 24 bits, the display would be right almost every time, as opposed to being wrong almost every time.
3.  You're not the only one with this problem.  Here's an XLD trouble ticket talking about the same problem:  https://sourceforge.net/p/xld/tickets/433/

Note:  32 bit sample depth is probably a non-starter. There's not an audio DAC made that can do the 144 dB SNR required for 24 bits.  The best of them, which are balanced I/O, are in the mid 120dB range, which means that they might be good for 21 bits; even on these, the least significant three bits of a 24 bit sample are buried in the noise.  Now add in the SNR of the amplification, be it for speakers or headphones, and you lose more bits to noise.  Adding more bits doesn't improve anything.  It just wastes storage space, processing power, and money.

[Tim Curtis]

Number 2 is a good workaround. I'll implement for upcoming moOde 7 :-)

Prolly something like if (m4a and 32) then change to 24.

[Miss Sissy Princess]

Number 2 is a good workaround. I'll implement for upcoming moOde 7 :-)

Prolly something like if (m4a and 32) then change to 24.

Tim, thanks so much!  

Maybe something in the release notes or documentation saying that 24 bits means 'at least 24 bits' or '24 bits or more' could save you from someone else (other than me) whining when they have an actual 32 bit recording.  On the other hand, you could send them to me and I'd be happy to publicly ridicule them for having at least a dozen bits that are completely buried in the noise of their DAC and amp.