(Bug) Music Library: ALAC with high bitrates

plexconnect

#1

I have some m4a files encoded in Apple lossless whose bitrate is higher than 1000Kbps. They do not play (my server has transcoding disabled), and I suspect that if transcoding was enabled (I can't do that, my Syno has an ARM processor and transcoding cannot be enabled) they would play with reduced quality.

XMLConverter.py has the following code:

        maxAudioBitrateUncompressed = '1000'

        audioATVNative = \
            Media.get('audioCodec','-') in ("mp3", "aac", "ac3", "drms") and \
            int(Media.get('bitrate','0')) <= int(maxAudioBitrateCompressed) \
            or \
            Media.get('audioCodec','-') in ("alac", "aiff", "wav") and \
            int(Media.get('bitrate','0')) <= int(maxAudioBitrateUncompressed)

The fact is that, if I change maxAudioBitrateUncompressed to 2000 all goes well. But looking at ATV3 specs I don't see the need to have a check for maxAudioBitrateUncompressed at all

Audio Formats

HE-AAC (V1), AAC (16 to 320 Kbps), protected AAC (from iTunes Store), MP3 (16 to 320 Kbps), MP3 VBR, Audible (formats 2, 3, and 4), Apple Lossless, AIFF, and WAV; Dolby Digital 5.1 surround sound pass-through

Can we have that check removed ? Or maxAudioBitrateUncompressed value increased to at least 2000Kbps ?


#2

Did we take abut that some time ago? Wasn't the "uncompressed 100kbps" your proposal?
:-D


#3

Yes Baa, 1000 was my proposal, but in the meantime I've found other alac files with higher bitrate, so I'm wondering if it makes sense to have a limit. Probably 2000 is too high to be exceeded for any stereo content. So far the highest bitrate that I've seen is 1080kBit/s, but I'm still converting my CD's to alac, so it's possible that some musics can exceed the 1080 value.

Incidently, my largest music file is ~106Mb in size but its bitrate is "only" 825kBp/s. If I remember well one of your objectives with this "limit bitrate" was to avoid LAN overrun with large files. What I observe is that the first song of an album takes some seconds (perhaps 3-5) to start, but I can skip to the following ones almost instantly. If that's the way that the aTV works, then I think that we cannot do nothing to improve it. In videos the file is "splitted into pieces" with the hls protocol, so we never have LAN overrun, but if music cannot be "splitted" then its better, I think, to support the overrun.