Search the Community
Showing results for tags 'm4b'.
I'm running emby on Synology NAS (DSM 6.xx). I'm using iOS 14 Phone / iPad and iMac (Catalina) to play music. I would like to ask wether the lossless audio files are transcoded to be played or not. As far as I understand (see https://support.emby.media/support/solutions/articles/44001161688-ios) emby can direct play Flac only. ALAC / m4a is not listed. As far as I understand there might be a second bottleneck to overcome: the iOS device "normally" transcodes to AAC before playing. So does the embay-ios app follow this procedure? Or do I listen to hi-res lossless audio? (if my file is lossless audio). In addition - what about m4b? is this format also ready for direct play?
Version 22.214.171.124 OS: Ubuntu 18.04.1 LTS hosted in Hyper-V I created audiobook library using Books type for NFS mounted directory with books in m4b format. (NFS is shared from ReadyNas) Books are displayed and i'm able to play them via Chrome and IOS app. ArtWork (visible in iTunes) is not displayed for most of the m4b: niether in chrome nor in IOS app. The only ArtWork is visible is when m4b has more then 1 video stream, which is used for ArtWork. (Those were actually created by mistake). For files with single video stream (as it should be normally) This is confirmed by multiple sample, all audiobooks with 2 and more posters are visible, with one regardless if it's mjpeg or png stream are not visible. I tried to do full rescan of the library - no result. P.S. Sorry, my audiobooks in Russian, not sure if it causes an issue.
yermak posted a topic in Web AppVersion 126.96.36.199 OS: Ubuntu 18.04.1 LTS hosted in Hyper-V Chome: Version 71.0.3578.98 (Official Build) (64-bit) Audiobook created in m4b format created with ffmpeg using -movflags +faststart After requesting playback embyserver.txt: 2019-01-07 22:19:01.437 Info HttpServer: HTTP GET http://192.168.1.222:8096/emby/Audio/56fe59bef25ea644b919242332aeaafd/hls1/main/107.ts?UserId=cf7907b74d66444e961dfa276f410195&DeviceId=TW96aWxsYS81LjAgKFdpbmRvd3MgTlQgMTAuMDsgV2luNjQ7IHg2NCkgQXBwbGVXZWJLaXQvNTM3LjM2IChLSFRNTCwgbGlrZSBHZWNrbykgQ2hyb21lLzcxLjAuMzU3OC45OCBTYWZhcmkvNTM3LjM2fDE1NDY2NzU5ODc3OTA1&MaxStreamingBitrate=140000000&Container=opus,mp3|mp3,aac,m4a|aac,flac,webma,webm,wav&TranscodingContainer=ts&TranscodingProtocol=hls&AudioCodec=aac&PlaySessionId=1546897003224&StartTimeTicks=0&EnableRedirection=true&EnableRemoteMedia=false&SegmentContainer=ts&AudioBitrate=384000&TranscodeReasons=ContainerNotSupported,AudioCodecNotSupported.UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36 2019-01-07 22:19:01.444 Info HttpServer: HTTP Response 200 to 192.168.1.172. Time: 1141ms (slow). http://192.168.1.222:8096/emby/Packages/Updates?PackageType=UserInstalled It seems that brawser just did not pass m4b as supported container. Transcoding log attached. Assuming that m4b is the same format as m4a, it should be played without forced transcoding, even if there is a need for transcoding then -a copy should be used instead of force reincoding to higher bitrate. Please also note flags passed to ffmpeg "-strict experimental -ab 384000" are not accurate, as ffmpeg does not require -strict experimental any longer (aac is quite stable) and bitrate is hardcoded as orginal bitrate was lower, thus probably should be just omited. P.S. Attached the file m4b-transcoding.txt