Mnejing 21 Posted December 31, 2022 Share Posted December 31, 2022 (edited) So I'm not entirely sure who this falls to. A little info. First, I don't use the Emby app on my phone for music. The lack of a position save for music makes the app a deal breaker (again, why hasn't this been implemented? There's a post I necro'd in the suggestions about it and it was supposed to be implemented "soon" back in Nov '21. I digress). I dug around and found Symfonium. It's not a perfect solution, but it has SOME form of being able to resume things like podcasts. I really just want a resume feature that works like videos, so I can listen to podcasts and live concerts without having to write down my position. Anyway. I'm a FLAC lover, but they're obviously quite large to stream. I certainly COULD move everything to my phone, but that's also inconvenient. Clearly transcoding is the solution. So I dig around and find the audio transcode setting under my user profile, and enable it. I fire up Symfonium, play a file and check my dashboard. Nothing. Then I find the setting in Symfonium as well. Sort of change, but now it's hit or miss whether or not it will play, and when it does, it's usually being shown as directplay (despite ffmpeg transcode logs saying it IS). What I can confirm is this: The Emby app itself has no issues at all. It transcodes just fine. It just sucks for resuming audio files. Symfonium is TRYING to get the server to transcode, but it's a mess. This brings me around to the first thing I said. I'm not sure who this falls to. I see it one of three ways There is an issue with the Emby implementation of ffmpeg. I'm not sold on this entirely (or my issue is not a singular issue), because the Emby app does not have this problem. There is an issue with 3rd party API requests not being formed properly by the server itself. As in, the server gets the request, but doesn't parse the ffmpeg command correctly. Like, are API calls to ffmpeg funneled through a template, or can anyone send whatever switches and commands to it? No idea, and I can't dig to find out. There is an issue with how Symfonium is forming the URI and an incorrect set of options are being sent to ffmpeg. It's all speculation! What I do have, however, is logs. I'll be attaching 3. One will be tagged as succeed, that is a file playing properly through the Emby app while on cellular. The other is a fail through Symfonium. The biggest standout for me are that Symfonium is attempting to play an ogg file directly, whereas the Emby app is attempting to play a playlist instead (and again, I didn't dig to see what that looks like, but I'd wager it's a playlist with a single entry). I suspect that's the root issue, but it's also curious that ffmpeg fails to even initialize the output stream. Anyway, enough rambling, time for the attaching! I'm fairly sure I stripped out the rest of my identifying stuff. Edited January 20, 2023 by Mnejing Link to comment Share on other sites More sharing options...
Tolriq 108 Posted December 31, 2022 Share Posted December 31, 2022 Symfonium have no direct control over what ffmpeg command are passed. It just says hey I can play X,Y and Z and set some preferences in the order. Since Opus is a better codec and it's supported, it's what is requested first. Opus does not support 96000 Hz files so it's probably the issue, Emby should set a proper value and pass it. Maybe there's a way for Symfonium to workaround this by adding some arbitrary limits to the initial request, but it should not be necessary. @Luke probably have the definitive answer here (Fix Emby part to ensure that vorbis target encoding is valid if ffmpeg requires it, and give the profile hack to force a 48khz max bitrate only for vorbis if that's what Emby select in the end. 1 Link to comment Share on other sites More sharing options...
pwhodges 1523 Posted December 31, 2022 Share Posted December 31, 2022 Opus supports encoding 96kHz files. It starts by converting them to 48kHz internally to remove frequencies which are inaudible to humans, such as the frequencies above 24kHz that 96kHz sampling can include. Getting rid of bloat with minimal or no effect on the listener is the whole purpose of lossy codecs. Paul Link to comment Share on other sites More sharing options...
Tolriq 108 Posted December 31, 2022 Share Posted December 31, 2022 Not all encoders do support higher sample rate since it's in all case at 48khz in reality. This is a supposition as it was an issue with Jellyfin too. In all cases Emby generates the command line for ffmpeg and seems to generate something that is not supported by ffmpeg and Emby also choose the profile to actually apply. The failing ones are opus, the working ones are aac. Symfonium always sends the same profile for local playback, I do not know Emby internals to know why it select different encoding and sometimes invalid ones. Link to comment Share on other sites More sharing options...
Mnejing 21 Posted January 1, 2023 Author Share Posted January 1, 2023 12 hours ago, Tolriq said: Symfonium have no direct control over what ffmpeg command are passed. It just says hey I can play X,Y and Z and set some preferences in the order. That's essentially why I opened my post with what I did. I haven't really dug in to the Emby API, so I was really just guessing based on the information I had. I was of the opinion that it was either Emby was trying to stream the wrong thing (and clearly, what each app is playing is not the same), or Symfonium was requesting the wrong thing. I kind of erred on the side of this being more of an Emby issue, hence why I posted here instead of the Symfonium thread. Either way, luke was mentioned so perhaps eyes will be on. Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 2, 2023 Share Posted January 2, 2023 Seems not Can you contact me at https://support.symfonium.app/ and provide both those files so I can try to reproduce and workaround? Link to comment Share on other sites More sharing options...
Luke 37029 Posted January 2, 2023 Share Posted January 2, 2023 Does the app have a transcoding option to mp3 that you could try to compare with? Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 2, 2023 Share Posted January 2, 2023 There's no setting that the user can toggle no With the files I'll be able to reproduce and debug more. Never had issues with my Flac files but I nearly never transcode so not so much tests. 1 Link to comment Share on other sites More sharing options...
Mnejing 21 Posted January 2, 2023 Author Share Posted January 2, 2023 (edited) Sorry, where on there would you like me to send the files? A PM? Do you just want the transcode logs? Edit: I made a thread in support. Edited January 2, 2023 by Mnejing Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 3, 2023 Share Posted January 3, 2023 I need the actual FLAC files to reproduce, the transcode logs are already here. Link to comment Share on other sites More sharing options...
Mnejing 21 Posted January 3, 2023 Author Share Posted January 3, 2023 My bad Link to comment Share on other sites More sharing options...
Solution Tolriq 108 Posted January 3, 2023 Solution Share Posted January 3, 2023 Ok so got the files, was able to repro and it's the sample rate but not in Opus in Vorbis. Adding "-ar 48000" to the ffmpeg command fixes the issue. @Luke This should probably be done automatically by Emby. Opus was broken before in Emby so I requested Vorbis and this trigger this. I tested and seems Opus now works correctly (without forcing the ar) probably with the switch to ffmpeg 5. So I'll use that now and it will fix the issue for Symfonium, but don't know if others could request Vorbis. Link to comment Share on other sites More sharing options...
Luke 37029 Posted January 19, 2023 Share Posted January 19, 2023 On 1/3/2023 at 3:34 AM, Tolriq said: Ok so got the files, was able to repro and it's the sample rate but not in Opus in Vorbis. Adding "-ar 48000" to the ffmpeg command fixes the issue. @Luke This should probably be done automatically by Emby. Opus was broken before in Emby so I requested Vorbis and this trigger this. I tested and seems Opus now works correctly (without forcing the ar) probably with the switch to ffmpeg 5. So I'll use that now and it will fix the issue for Symfonium, but don't know if others could request Vorbis. So you're saying it's fine now with the latest version of the server? Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 19, 2023 Share Posted January 19, 2023 (edited) @Luke, not really, what is fine now is transcoding to opus that had issues before (very very long time last time I tried, so don't know when it was fixed). The transcoding to Vorbis does not automatically add the -ar 48000 so fails on high bitrate. I think the server should handle this automatically, but it's probably possible to pass a max sample rate to the profile to add it from the client side too. Edited January 19, 2023 by Tolriq 1 Link to comment Share on other sites More sharing options...
Mnejing 21 Posted January 19, 2023 Author Share Posted January 19, 2023 (edited) Just attempted it with Symfonium 3.2.0. The behavior is the same as before. It's not transcoding and is instead direct playing the FLAC file, despite Symfonium being set to a specific bitrate (tested at 320 and 256). Emby dashboard reports direct play, and the app is showing the stream exactly as is being reported in Emby. Quote 02:29:17.713 elapsed=00:00:00.00 size= 0kB time=00:00:00.03 bitrate= 84.3kbits/s throttle=off speed=64.3x 02:29:18.212 elapsed=00:00:00.50 size= 768kB time=00:00:28.27 bitrate= 222.5kbits/s throttle=off speed=56.4x 02:29:18.712 elapsed=00:00:01.00 size= 1536kB time=00:00:58.45 bitrate= 215.3kbits/s throttle=off speed=58.4x 02:29:19.212 elapsed=00:00:01.50 size= 2560kB time=00:01:27.81 bitrate= 238.8kbits/s throttle=off speed=58.5x 02:29:19.712 elapsed=00:00:02.00 size= 3584kB time=00:01:59.85 bitrate= 245.0kbits/s throttle=off speed=59.9x 02:29:20.213 elapsed=00:00:02.50 size= 4608kB time=00:02:32.63 bitrate= 247.3kbits/s throttle=off speed= 61x 02:29:20.432 02:29:20.433 elapsed=00:00:02.72 size= 5276kB time=00:02:47.63 bitrate= 257.8kbits/s throttle=off speed=61.6x 02:29:20.433 video:0kB audio:5246kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.570888% There is a transcode log, and this is just a couple of secords of playing. That bitrate is not representative of what the client is receiving. Attaching logs from playback of files from the same album (I swapped files to avoid any potential caching issues that might not trigger a transcode, just in case). One is playback in the Emby Android app, the other is Symfonium. The Emby app does continue to delivery a properly transcoded version, as reported by the app, the Emby dashboard, and my data. Symfonium does not. Edited January 20, 2023 by Mnejing Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 19, 2023 Share Posted January 19, 2023 You miss Symfonium logs, but the transcoding does work in both logs. What you see in the dashboard is not relevant, Symfonium does not send the transcoding details as it can also report from offline cache and many cases where the value would be wrong. Link to comment Share on other sites More sharing options...
Mnejing 21 Posted January 19, 2023 Author Share Posted January 19, 2023 I'm going purely by the data being consumed on cellular, which is irrespective of what any app or dashboard is telling me. Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 19, 2023 Share Posted January 19, 2023 Open proper issue with logs then .... From the only data you provide : Quote Stream #0:0: Audio: opus, 48000 Hz, stereo, s16, 262 kb/s So the data is properly transcoded to Opus 256K Link to comment Share on other sites More sharing options...
Mnejing 21 Posted January 19, 2023 Author Share Posted January 19, 2023 I'm not going to argue this. I made a report on your forums, I've sent you files to test. I've shown you the differences between the approach the Emby app uses versus your own. It's still not working. I'm trying to clearly state that the content being received on my device is sometimes up to 10x larger than it should be if properly transcoded. It's not something in the background, it's very clearly occurring WHEN I play music via Symfonium. Whatever logs the apps present or Emby presents, I straight up cannot argue with the amount of data being consumed as reported by my cellular provider. Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 19, 2023 Share Posted January 19, 2023 You reported an issue, that issue was identified and solved. The only new data you show here proves that it was solved. So your current issue is something else. Either you understand and open a new issue with new logs so I can see what is eventually going on, or there's nothing I can do for you. There's no magic in application, I can only see what you provide. What you currently provide shows that there's transcoding and that it's working.... Source file is FLAC 28MB Played file is Opus 5.2 MB Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 20, 2023 Share Posted January 20, 2023 (edited) Just unbelievable ... I know reading is hard but really ... At no point I blamed Emby or Luke, I'm sorry that you can't read and understand how things works. You reported an issue, it was fixed. You say there's still an issue but do not provide anything to be able to solve it. The only thing you provide did not show any issue. It's like you are driving your car on the road and call the mechanic to tell that you car does not start. For the last time there's no fucking magic in applications ... Hidden So seems I'm blaming @Luke Seriously, I just can't understand how people can just blatantly lie, if you do not understand something ask .... Hidden Edited January 20, 2023 by Tolriq 1 Link to comment Share on other sites More sharing options...
Mnejing 21 Posted January 20, 2023 Author Share Posted January 20, 2023 (edited) Thank you. Conversation is over. Edited January 20, 2023 by Mnejing Link to comment Share on other sites More sharing options...
Tolriq 108 Posted January 20, 2023 Share Posted January 20, 2023 Play Store comments are public and searchable and your full name is not visible this is not doxxing, this is just showing your actions to the world. I'm done with random people assaulting me for no reasons, exposing public actions is perfectly fine. (Actions have consequences you know). Anyway I've removed the images .... Link to comment Share on other sites More sharing options...
Mnejing 21 Posted January 20, 2023 Author Share Posted January 20, 2023 (edited) Nope, deleting. Not worth it. Edited January 20, 2023 by Mnejing Link to comment Share on other sites More sharing options...
Recommended Posts